Re: eliminate new operator paraphernalia

[Lars T. Kyllingstad]

Steven Schveighoffer wrote:
On Sun, 14 Feb 2010 13:17:44 -0500, Andrei Alexandrescu 
 wrote:


Currently new is baroque to the extreme. Should we eliminate the 
class-specific allocators in favor of a simple scheme for placement 
new? All that's really needed is to construct an object of a given 
type at a given address. All of the syntactic mess around it is 
unnecessary.


I think class-specific new and delete are not a useful feature.

Second, the whole new anonymous class thing is for Java's sake. Do you 
think we need to keep all that?


I suggest the following syntaxes for a type T, an integral length, an 
initializerlist a la "e1, e2, e3, ..." that could be empty, and an 
addr convertible to void*:


new T[length]
new T(initializerlist)
new(addr) T[length]
new(addr) T(initializerlist)

and call it a day.

What do you think?


Except for anonymous classes, that works for me.  I don't think I've 
ever used class-specific allocators, and except for slightly ugly 
syntax, you can cover custom allocators with your new syntax.


One thing however, let's look at how the syntax will change:

auto t = new T(x, y, z);

...

auto t = new(customAlloc(???)) T(x, y, z);

Whatever you do for ??? to get the allocation size of T needs to be 
easy.  I think right now, it is not a simple property of the class name, 
I think it should be, to make this as painless as possible.  Even with 
that, unfortunately, you must repeat the type, which may be significant 
if the typename is long or complex.


__traits(classInstanceSize, T)

...I think.

-Lars

Re: eliminate new operator paraphernalia

[Pelle Månsson]

On 02/15/2010 01:27 PM, grauzone wrote:

How is filling with .init not a waste of time?


It needs to fill with .init and run the default constructor (if any). 
Contracts, and all that.

Re: eliminate new operator paraphernalia

[Steven Schveighoffer]

On Sun, 14 Feb 2010 13:17:44 -0500, Andrei Alexandrescu  
 wrote:


Currently new is baroque to the extreme. Should we eliminate the  
class-specific allocators in favor of a simple scheme for placement new?  
All that's really needed is to construct an object of a given type at a  
given address. All of the syntactic mess around it is unnecessary.


I think class-specific new and delete are not a useful feature.

Second, the whole new anonymous class thing is for Java's sake. Do you  
think we need to keep all that?


I suggest the following syntaxes for a type T, an integral length, an  
initializerlist a la "e1, e2, e3, ..." that could be empty, and an addr  
convertible to void*:


new T[length]
new T(initializerlist)
new(addr) T[length]
new(addr) T(initializerlist)

and call it a day.

What do you think?


Except for anonymous classes, that works for me.  I don't think I've ever  
used class-specific allocators, and except for slightly ugly syntax, you  
can cover custom allocators with your new syntax.


One thing however, let's look at how the syntax will change:

auto t = new T(x, y, z);

...

auto t = new(customAlloc(???)) T(x, y, z);

Whatever you do for ??? to get the allocation size of T needs to be easy.   
I think right now, it is not a simple property of the class name, I think  
it should be, to make this as painless as possible.  Even with that,  
unfortunately, you must repeat the type, which may be significant if the  
typename is long or complex.


What about a template-ish approach?

auto t = new!(alloc) T(x, y, z);

where this is rewritten by the compiler to do:

auto t = new(alloc!T()) T(x, y, z);

Where alloc is a template function that has one type parameter, and  
returns an address to be passed to placement-new.  This allows  
compile-time introspection (including David's precise scanning feature),  
and avoids the double specification of type.


In essence, I'm adding another way to allocate, but I think it is as  
visible, and as easy to use, as placement new.  Plus it allows any kind of  
introspection you wish to use on allocation.


As far as anonymous classes, how do they clash with anything?  I don't see  
the point of removing them.  Yes, they are used extensively in Java  
because Java lacks true delegates, but there are other reasons to use it  
other than for callbacks.


I also agree with another poster that:

new T[length]

might be better suited as:

new T[](length)

Especially in the wake of T[N] where N is a constant being considered a  
real value type.


-Steve

Re: eliminate new operator paraphernalia

[Andrei Alexandrescu]

Sean Kelly wrote:

Andrei Alexandrescu Wrote:

Currently new is baroque to the extreme. Should we eliminate the 
class-specific allocators in favor of a simple scheme for placement new? 
All that's really needed is to construct an object of a given type at a 
given address. All of the syntactic mess around it is unnecessary.


I think class-specific new and delete are not a useful feature.

Second, the whole new anonymous class thing is for Java's sake. Do you 
think we need to keep all that?


I suggest the following syntaxes for a type T, an integral length, an 
initializerlist a la "e1, e2, e3, ..." that could be empty, and an addr 
convertible to void*:


new T[length]
new T(initializerlist)
new(addr) T[length]
new(addr) T(initializerlist)

and call it a day.

What do you think?


Yes, please :-)  That custom allocators are currently needed for placement new 
just stinks.  I agree with your assessment of custom allocators being 
problematic as well, though an alternative would be to continue allowing them 
as long as they accepted at least one argument (and the argument isn't size_t 
or whatever to avoid colliding with placement new).  This would at least make 
custom allocator use obvious at the point of instantiation, which is how 
placement new works as well.


Walter approved.

Andrei

Re: eliminate new operator paraphernalia

[Sean Kelly]

Andrei Alexandrescu Wrote:

> Currently new is baroque to the extreme. Should we eliminate the 
> class-specific allocators in favor of a simple scheme for placement new? 
> All that's really needed is to construct an object of a given type at a 
> given address. All of the syntactic mess around it is unnecessary.
> 
> I think class-specific new and delete are not a useful feature.
> 
> Second, the whole new anonymous class thing is for Java's sake. Do you 
> think we need to keep all that?
> 
> I suggest the following syntaxes for a type T, an integral length, an 
> initializerlist a la "e1, e2, e3, ..." that could be empty, and an addr 
> convertible to void*:
> 
> new T[length]
> new T(initializerlist)
> new(addr) T[length]
> new(addr) T(initializerlist)
> 
> and call it a day.
> 
> What do you think?

Yes, please :-)  That custom allocators are currently needed for placement new 
just stinks.  I agree with your assessment of custom allocators being 
problematic as well, though an alternative would be to continue allowing them 
as long as they accepted at least one argument (and the argument isn't size_t 
or whatever to avoid colliding with placement new).  This would at least make 
custom allocator use obvious at the point of instantiation, which is how 
placement new works as well.

Re: eliminate new operator paraphernalia

[dsimcha]

== Quote from grauzone (n...@example.net)'s article
> dsimcha wrote:
> > 2.  Pointer offset information for each type is determined at compile time 
> > using
> > template metaprogramming.
> Why don't you just ask Walter to make dmd generate the necessary
> information?

Three reasons:

1.  Walter has enough on his plate already.

2.  Using templates to do it is both cool and practical.  It's probably easier
than hacking the compiler.

3.  I find the fact that RTTI is such a black box and you can't customize it
without hacking the compiler, despite D's incredible compile-time introspection
facilities to be a weakness in the language.

Re: eliminate new operator paraphernalia

[grauzone]

dsimcha wrote:

2.  Pointer offset information for each type is determined at compile time using
template metaprogramming.


Why don't you just ask Walter to make dmd generate the necessary 
information?

Re: eliminate new operator paraphernalia

[dsimcha]

== Quote from Jacob Carlborg (d...@me.com)'s article
> On 2/14/10 19:17, Andrei Alexandrescu wrote:
> > Currently new is baroque to the extreme. Should we eliminate the
> > class-specific allocators in favor of a simple scheme for placement new?
> > All that's really needed is to construct an object of a given type at a
> > given address. All of the syntactic mess around it is unnecessary.
> Didn't dsimcha or someone work on an implementation of a precise GC that
> needed changes to this sort of things. If so, make sure you take those
> changes into account.

Here's the deal with that:

1.  The patch I created supported precise scanning of the heap, but not the 
stack
or static data segment.  This probably will be enough to solve **most** false
pointer problems, simply because most memory is on the heap, not the stack or
static data segment.

2.  Pointer offset information for each type is determined at compile time using
template metaprogramming.

3.  The pointer offset info needs to be passed to the GC.  My patch makes it so
that this information can be passed when using GC.malloc directly.  However, the
new operator does not get to do compile time introspection on what it's
allocating.  Under the hood, it's simply passed RTTI, which does not contain
enough information to generate pointer offset info from.  One possible remedy 
for
this is DIP8.  http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP8

Re: eliminate new operator paraphernalia

[Jacob Carlborg]

On 2/14/10 19:17, Andrei Alexandrescu wrote:

Currently new is baroque to the extreme. Should we eliminate the
class-specific allocators in favor of a simple scheme for placement new?
All that's really needed is to construct an object of a given type at a
given address. All of the syntactic mess around it is unnecessary.


Didn't dsimcha or someone work on an implementation of a precise GC that 
needed changes to this sort of things. If so, make sure you take those 
changes into account.



I think class-specific new and delete are not a useful feature.

Second, the whole new anonymous class thing is for Java's sake. Do you
think we need to keep all that?


Yes I think so. Removing that will break the whole DWT library.


I suggest the following syntaxes for a type T, an integral length, an
initializerlist a la "e1, e2, e3, ..." that could be empty, and an addr
convertible to void*:

new T[length]
new T(initializerlist)
new(addr) T[length]
new(addr) T(initializerlist)

and call it a day.

What do you think?


Andrei

Re: eliminate new operator paraphernalia

[Simen kjaeraas]

grauzone  wrote:

what does "paraphernalia" mean?


http://dictionary.reference.com/browse/paraphernalia :

1.  (sometimes used with a singular verb) equipment, apparatus, or
furnishing used in or necessary for a particular activity: a skier's
paraphernalia.
2.  (used with a plural verb) personal belongings.
3.  (used with a singular verb) Law. the personal articles, apart from
dower, reserved by law to a married woman.

--
Simen

Re: eliminate new operator paraphernalia

[grauzone]

Andrei Alexandrescu wrote:

Michel Fortin wrote:
On 2010-02-14 15:41:30 -0500, Andrei Alexandrescu 
 said:



Michel Fortin wrote:


Hum, what's the syntax for placement delete?


There is no need for placement delete. There will be a function 
clear() in object.d that only calls the destructor. (That is needed 
regardless.) You can carry deallocation with your own API functions.


What's the point in wasting a function name only to call the 
destructor? Why not just allow "object.~this()"?


You might want to clear an int etc. for which it's unclear whether the 
above should work.


Also, if you really want to put an object back in it's initial state, 
you could call both the destructor and the constructor. Anything else 
is going to break the object's invariant. I think it's best to leave 
breaking the object's invariants to a special syntax, hence 
"object.~this()".


Yah, clear destroys and then fills with .init.


How is filling with .init not a waste of time?

Now I'm not really sure, but I'm going to guess... you think it's safer?

I don't think "reusing" objects is safe memory management. OK, you 
probably could still sandbox such a program, and there will never be 
segfaults (except null pointer accesses). But the user could still have 
references to "dead" objects. Or even worse, "false" objects, that have 
been reinitialized even though some other parts of the program needed 
the old object. There, you have the same mess as with traditional manual 
memory allocation.


As a D user, I'm kindly asking for actually safe memory management 
primitives, that are more efficient than the old GC.


By the way, what does "paraphernalia" mean?


Andrei

Re: eliminate new operator paraphernalia

[Jonathan M Davis]

Andrei Alexandrescu wrote:

>> Also, if you really want to put an object back in it's initial state,
>> you could call both the destructor and the constructor. Anything else is
>> going to break the object's invariant. I think it's best to leave
>> breaking the object's invariants to a special syntax, hence
>> "object.~this()".
> 
> Yah, clear destroys and then fills with .init.
> 
> Andrei

How about reinit()?. clear() seems like a name which people would definitely 
want to use in their own code. The STL uses it for its containers, and you'd 
then have to come up with a new name for that functionality in any container 
classes in D. A name which is less likely to be sought after by programmers 
for their own classes would be better. reinit() is just what comes to mind 
for me, but I think that it would be a shame to lose clear() to Object.

- Jonathan M Davis

Re: eliminate new operator paraphernalia

[Andrei Alexandrescu]

Kasumi Hanazuki wrote:

I suggest the following syntaxes for a type T, an integral length, an
initializerlist a la "e1, e2, e3, ..." that could be empty, and an addr
convertible to void*:

new T[length]
new T(initializerlist)


This may be a bit off-topic, but now is the chance to think about the
array-new'ing syntax...

Currently, D has two syntaxes to allocate a dynamic array (type of T[]),

- new int[n]; // n can be a non-constant
- new int[](n);

and no way to allocate a static array (type of T[N]) dynamically.

- new int[3]; // this is not an int[3] but a int[]
- alias int[3] int3;
  new int3; // this is not allowed!

I think it is inconsistent in following points:

- {new int[1][2][3]} allocates an int[1][2][] of length 3
  (only the last parameter has the different meaning).
- {new int[3]} and {new int3} behave differently as shown above.

So I suggest that
- {new T[N]} would accept only a compile-time constant as N and
  allocate a T[N] as if T[N] were a struct type.
- {new T[](n)} would allocate a T[] of length n as if T[] were a class
  type and had a constructor taking one size_t parameter
  (same as current implementation).

With this semantics, {new int[2][3]} shall allocate an int[2][3],
{new int[2][](3)} an int[2][] of length 3, {new int[][](2, 3)}
an int[][] of length 3 having three int[] of length 2 as its elements.


Perfect. Thank you Kasumi-san.

Andrei

Re: eliminate new operator paraphernalia

[Michel Fortin]

On 2010-02-14 17:21:51 -0500, Andrei Alexandrescu 
 said:



Michel Fortin wrote:
On 2010-02-14 15:41:30 -0500, Andrei Alexandrescu 
 said:



Michel Fortin wrote:


Hum, what's the syntax for placement delete?


There is no need for placement delete. There will be a function clear() 
in object.d that only calls the destructor. (That is needed 
regardless.) You can carry deallocation with your own API functions.


What's the point in wasting a function name only to call the 
destructor? Why not just allow "object.~this()"?


You might want to clear an int etc. for which it's unclear whether the 
above should work.


Also, if you really want to put an object back in it's initial state, 
you could call both the destructor and the constructor. Anything else 
is going to break the object's invariant. I think it's best to leave 
breaking the object's invariants to a special syntax, hence 
"object.~this()".


Yah, clear destroys and then fills with .init.


...and call the default constructor for classes (and is not callable if 
there is no default constructor). If you don't call a constructor for a 
class, invariants can't hold.


Ok. That's fine for clear() then, but it's not the same thing as just 
calling the destructor. There should be a way to just call the 
destructor prior deallocation.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: eliminate new operator paraphernalia

[Kasumi Hanazuki]

I suggest the following syntaxes for a type T, an integral length, an
initializerlist a la "e1, e2, e3, ..." that could be empty, and an addr
convertible to void*:

new T[length]
new T(initializerlist)


This may be a bit off-topic, but now is the chance to think about the
array-new'ing syntax...

Currently, D has two syntaxes to allocate a dynamic array (type of T[]),

- new int[n]; // n can be a non-constant
- new int[](n);

and no way to allocate a static array (type of T[N]) dynamically.

- new int[3]; // this is not an int[3] but a int[]
- alias int[3] int3;
  new int3; // this is not allowed!

I think it is inconsistent in following points:

- {new int[1][2][3]} allocates an int[1][2][] of length 3
  (only the last parameter has the different meaning).
- {new int[3]} and {new int3} behave differently as shown above.

So I suggest that
- {new T[N]} would accept only a compile-time constant as N and
  allocate a T[N] as if T[N] were a struct type.
- {new T[](n)} would allocate a T[] of length n as if T[] were a class
  type and had a constructor taking one size_t parameter
  (same as current implementation).

With this semantics, {new int[2][3]} shall allocate an int[2][3],
{new int[2][](3)} an int[2][] of length 3, {new int[][](2, 3)}
an int[][] of length 3 having three int[] of length 2 as its elements.

Re: eliminate new operator paraphernalia

[Andrei Alexandrescu]

Michel Fortin wrote:
On 2010-02-14 15:41:30 -0500, Andrei Alexandrescu 
 said:



Michel Fortin wrote:


Hum, what's the syntax for placement delete?


There is no need for placement delete. There will be a function 
clear() in object.d that only calls the destructor. (That is needed 
regardless.) You can carry deallocation with your own API functions.


What's the point in wasting a function name only to call the destructor? 
Why not just allow "object.~this()"?


You might want to clear an int etc. for which it's unclear whether the 
above should work.


Also, if you really want to put an object back in it's initial state, 
you could call both the destructor and the constructor. Anything else is 
going to break the object's invariant. I think it's best to leave 
breaking the object's invariants to a special syntax, hence 
"object.~this()".


Yah, clear destroys and then fills with .init.

Andrei

Re: eliminate new operator paraphernalia

[Michel Fortin]

On 2010-02-14 15:41:30 -0500, Andrei Alexandrescu 
 said:



Michel Fortin wrote:


Hum, what's the syntax for placement delete?


There is no need for placement delete. There will be a function clear() 
in object.d that only calls the destructor. (That is needed 
regardless.) You can carry deallocation with your own API functions.


What's the point in wasting a function name only to call the 
destructor? Why not just allow "object.~this()"?


Also, if you really want to put an object back in it's initial state, 
you could call both the destructor and the constructor. Anything else 
is going to break the object's invariant. I think it's best to leave 
breaking the object's invariants to a special syntax, hence 
"object.~this()".



So why remove custom allocators? Those can be useful to catch all 
allocations of a specific class in an existing code base and improve it 
for some specific needs without having to change code everywhere. I'd 
rather see that better generalized (we talked about making 'new' a 
template earlier).


There are many problems with custom allocators. They hook the syntax 
and do something that's unbecoming. new T must place T on the 
garbage-collected heap, period. That gives the guarantee that the 
object has infinite lifetime and therefore dependable behavior. If the 
same syntax can be used to implement various other semantics, you can't 
count on anything in generic code.


Well, I agree that new should have dependable semantics. I disagree 
about it being always from a GC-allocated block. There are other ways 
to create infinite lifetime behaviour, like a smart pointer. Of course 
you can't do that with 'new' as it stands today because you can't make 
it return something else than a crude pointer. That's what need to be 
fixed I think.


You could say that having placement-new fixes that problem, and in a 
way it does because it allows you to create what I've described as a 
separate function. Except you have to use a different syntax to create 
the object which makes things less transparent (especially with generic 
code).


Also, having placement-new and regular-new share the almost same syntax 
isn't a good way to say that 'new' has dependable semantics. I think 
there is a better syntax for calling the constructor: "object.this()".




Also, why remove anonymous classes?


Walter thinks we need to keep them.


Is that your reason for wanting them removed? :-)


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: eliminate new operator paraphernalia

[dsimcha]

== Quote from Nick Sabalausky (a...@a.a)'s article
> And as for
> the infinite lifetime guarantee: I don't think I see any risk of a
> custom-allocated object getting yanked out from under generic code unless
> you did something *really* bizarre and obviouly pointless like lauch a
> thread that randomly marks elements in an object pool as unused.

...or allocated your object using a LIFO stack allocator of some kind.

Re: eliminate new operator paraphernalia

[Andrei Alexandrescu]

Nick Sabalausky wrote:
"Andrei Alexandrescu"  wrote in message 
news:hl9end$1u8...@digitalmars.com...
Second, the whole new anonymous class thing is for Java's sake. Do you 
think we need to keep all that?




It doesn't bother me having it, but I can't say I can imagine ever having a 
use for it outside a fully dynamic scripting language (or maybe Java, but 
well, Java tools and features tend to be useful primarily as workarounds for 
Java being it's usual Javay self).



new T[length]
new T(initializerlist)


Isn't that exactly what we already have?


new(addr) T[length]
new(addr) T(initializerlist)



I'm not sure I see the point of that. Can't you just call the ctor directly? 


You can't. I mean there is a __ctor thing but user code shouldn't depend 
on that.


Andrei

Re: eliminate new operator paraphernalia

[Andrei Alexandrescu]

Nick Sabalausky wrote:
"Andrei Alexandrescu"  wrote in message 
news:hl9n50$2f9...@digitalmars.com...
There are many problems with custom allocators. They hook the syntax and 
do something that's unbecoming. new T must place T on the 
garbage-collected heap, period. That gives the guarantee that the object 
has infinite lifetime and therefore dependable behavior. If the same 
syntax can be used to implement various other semantics, you can't count 
on anything in generic code.




Sounds to me like the exact same argument for eliminating operator 
overloading: "If we allow it, then someone could hijack '+' to do something 
unbecoming and then you can't count on anything in generic code". Generic 
code (at least in D) naturally comes with a risk of duckiness.


It's not the same argument, but I can't afford the time to debate that.

The whole point of custom allocators is to allow something to get the same 
result (get a new instance) through a different implementation.  And as for
the infinite lifetime guarantee: I don't think I see any risk of a 
custom-allocated object getting yanked out from under generic code unless 
you did something *really* bizarre and obviouly pointless like lauch a 
thread that randomly marks elements in an object pool as unused. 


My point is that custom new is not transparent at all. One typical 
example of class-specific new and delete is using malloc as a backend. 
So then you have some types for which you need to pair new and delete, 
and some for which you don't. Not good.


All that's needed is the ability to create an object at a given address, 
and the ability to destroy a given object. This is what the language 
must provide. All the rest can and should be built via regular facilities.



Andrei

Re: eliminate new operator paraphernalia

[Nick Sabalausky]

"Andrei Alexandrescu"  wrote in message 
news:hl9end$1u8...@digitalmars.com...
>
> Second, the whole new anonymous class thing is for Java's sake. Do you 
> think we need to keep all that?
>

It doesn't bother me having it, but I can't say I can imagine ever having a 
use for it outside a fully dynamic scripting language (or maybe Java, but 
well, Java tools and features tend to be useful primarily as workarounds for 
Java being it's usual Javay self).

>
> new T[length]
> new T(initializerlist)

Isn't that exactly what we already have?

> new(addr) T[length]
> new(addr) T(initializerlist)
>

I'm not sure I see the point of that. Can't you just call the ctor directly? 

Re: eliminate new operator paraphernalia

[Nick Sabalausky]

"Andrei Alexandrescu"  wrote in message 
news:hl9n50$2f9...@digitalmars.com...
>
> There are many problems with custom allocators. They hook the syntax and 
> do something that's unbecoming. new T must place T on the 
> garbage-collected heap, period. That gives the guarantee that the object 
> has infinite lifetime and therefore dependable behavior. If the same 
> syntax can be used to implement various other semantics, you can't count 
> on anything in generic code.
>

Sounds to me like the exact same argument for eliminating operator 
overloading: "If we allow it, then someone could hijack '+' to do something 
unbecoming and then you can't count on anything in generic code". Generic 
code (at least in D) naturally comes with a risk of duckiness.

The whole point of custom allocators is to allow something to get the same 
result (get a new instance) through a different implementation. And as for 
the infinite lifetime guarantee: I don't think I see any risk of a 
custom-allocated object getting yanked out from under generic code unless 
you did something *really* bizarre and obviouly pointless like lauch a 
thread that randomly marks elements in an object pool as unused. 

Re: eliminate new operator paraphernalia

[Justin Johansson]

Michel Fortin wrote:

Also, why remove anonymous classes?


Me thinks that whoever suggested that anonymous classes be removed is
best to remain anonymous. :-)

Justin Johansson

Re: eliminate new operator paraphernalia

[Andrei Alexandrescu]

Michel Fortin wrote:
On 2010-02-14 13:17:44 -0500, Andrei Alexandrescu 
 said:


Currently new is baroque to the extreme. Should we eliminate the 
class-specific allocators in favor of a simple scheme for placement 
new? All that's really needed is to construct an object of a given 
type at a given address. All of the syntactic mess around it is 
unnecessary.


I think class-specific new and delete are not a useful feature.

Second, the whole new anonymous class thing is for Java's sake. Do you 
think we need to keep all that?


I suggest the following syntaxes for a type T, an integral length, an 
initializerlist a la "e1, e2, e3, ..." that could be empty, and an 
addr convertible to void*:


new T[length]
new T(initializerlist)
new(addr) T[length]
new(addr) T(initializerlist)

and call it a day.


Hum, what's the syntax for placement delete?


There is no need for placement delete. There will be a function clear() 
in object.d that only calls the destructor. (That is needed regardless.) 
You can carry deallocation with your own API functions.


While I welcome a real placement-new syntax, I'm not sure adding it 
justifies any of the other changes you're proposing. Placement-new can 
be see as just another allocator taking a pointer as an argument and 
returning that same pointer as the address to use for whatever you're 
initializing.


Creating an object at a given address is really everything you need from 
the language to do whatever you want.


So why remove custom allocators? Those can be useful to catch all 
allocations of a specific class in an existing code base and improve it 
for some specific needs without having to change code everywhere. I'd 
rather see that better generalized (we talked about making 'new' a 
template earlier).


There are many problems with custom allocators. They hook the syntax and 
do something that's unbecoming. new T must place T on the 
garbage-collected heap, period. That gives the guarantee that the object 
has infinite lifetime and therefore dependable behavior. If the same 
syntax can be used to implement various other semantics, you can't count 
on anything in generic code.



Also, why remove anonymous classes?


Walter thinks we need to keep them.


Andrei

Re: eliminate new operator paraphernalia

[Michel Fortin]

On 2010-02-14 13:17:44 -0500, Andrei Alexandrescu 
 said:


Currently new is baroque to the extreme. Should we eliminate the 
class-specific allocators in favor of a simple scheme for placement 
new? All that's really needed is to construct an object of a given type 
at a given address. All of the syntactic mess around it is unnecessary.


I think class-specific new and delete are not a useful feature.

Second, the whole new anonymous class thing is for Java's sake. Do you 
think we need to keep all that?


I suggest the following syntaxes for a type T, an integral length, an 
initializerlist a la "e1, e2, e3, ..." that could be empty, and an addr 
convertible to void*:


new T[length]
new T(initializerlist)
new(addr) T[length]
new(addr) T(initializerlist)

and call it a day.


Hum, what's the syntax for placement delete?

While I welcome a real placement-new syntax, I'm not sure adding it 
justifies any of the other changes you're proposing. Placement-new can 
be see as just another allocator taking a pointer as an argument and 
returning that same pointer as the address to use for whatever you're 
initializing.


So why remove custom allocators? Those can be useful to catch all 
allocations of a specific class in an existing code base and improve it 
for some specific needs without having to change code everywhere. I'd 
rather see that better generalized (we talked about making 'new' a 
template earlier).


Also, why remove anonymous classes? They're just a shortcut syntax for:

void func() {
class Anonymous {
...
}
auto a = new Anonymous;
...
}

I don't really see what's the problem in allowing this:

void func() {
auto a = new class {
...
}
...
}

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: eliminate new operator paraphernalia

[bearophile]

Andrei Alexandrescu:
> What do you think?

Can the "new" keyword be removed from D2 and replaced by some class method 
"new"? :-)

Bye,
bearophile

eliminate new operator paraphernalia

[Andrei Alexandrescu]

Currently new is baroque to the extreme. Should we eliminate the 
class-specific allocators in favor of a simple scheme for placement new? 
All that's really needed is to construct an object of a given type at a 
given address. All of the syntactic mess around it is unnecessary.


I think class-specific new and delete are not a useful feature.

Second, the whole new anonymous class thing is for Java's sake. Do you 
think we need to keep all that?


I suggest the following syntaxes for a type T, an integral length, an 
initializerlist a la "e1, e2, e3, ..." that could be empty, and an addr 
convertible to void*:


new T[length]
new T(initializerlist)
new(addr) T[length]
new(addr) T(initializerlist)

and call it a day.

What do you think?


Andrei