'new' class method

[KennyTM~]

Yigal Chripun wrote:
> KennyTM~ wrote:
>> Yigal Chripun wrote:
>>> KennyTM~ wrote:
>>>> KennyTM~ wrote:
>>>>> Bill Baxter wrote:
>>>>>> On Sat, Oct 25, 2008 at 2:04 AM, KennyTM~ <kennytm at gmail.com> wrote:
>>>>>>
>>>>>>>>  auto a = Class();  // heap   (default)
>>>>>>>>  auto a = Struct(); // stack   (default)
>>>>>>>>
>>>>>>>>  auto a = Class.new(stack)(); // stack
>>>>>>>>  auto a = Struct.new(stack)(); // stack
>>>>>>>>
>>>>>>>>  auto a = Class.new(heap)(); // heap
>>>>>>>>  auto a = Struct.new(heap)(); // heap
>>>>>>>>
>>>>>>>>   void *addr;
>>>>>>>>   auto a = Class.new(addr)(); // placement
>>>>>>>>   auto a = Struct.new(addr)(); // placement
>>>>>>>>
>>>>>>> I strongly *oppose* using stack and heap as keywords because there
>>>>>>> are also
>>>>>>> (partly irrelevant) data structures called stack and heap, even
>>>>>>> though
>>>>>>> according to the guideline these class/structs should be named Stack
>>>>>>> and
>>>>>>> Heap.
>>>>>> Right, that's why both Benji and I proposed making them *context*
>>>>>> keywords.  Just like "Windows" is a keyword only in the context of
>>>>>> extern( ).  This would make heap and stack keywords only in the
>>>>>> context of new(  ).
>>>>>>
>>>>> I see. But with the your new(...) syntax this can't be done because it
>>>>> is ambiguous with
>>>>>
>>>>>   void* stack = allocate();
>>>>>   auto C = Class.new(stack)();
>>>>>
>>>>> The placement new syntax should use some other syntax.
>>>>>
>>>> or do it like this:
>>>>
>>>>    auto C = Class.new(placement, addr, etc)();
>>>> //--------------------^ use this to specify it is a placement new.
>>> maybe just add the concept of allocators.
>>> auto C1 = Class.new(parameters/*, Allocator = GC.DefaultAllocator */);
>>> auto C2 = Class.new(parameters, HeapAllocator); // on heap
>>> auto C3 = Class.new(parameters, StackAllocator); // on stack
>>> auto C4 = Class.new(parameters, MyPlacementNewAllocator);
>>> etc..
>>> initial Allocator hierarchy could be part of the run-time, and could be
>>> user extended to allow for placement new.
>>>
>> This can't work because parameters (I bet you mean constructor arguments
>> here) can be variadic.
> 
> I did mean the constructor arguments. The syntax itself is less
> important here, I was more talking about the concept of Allocators.
> like the ones in STL, for example.
> 
> regarding the syntax:
> a few possibilities that come to mind:
> 
> a) new!(Allocator)(args)..

Then Allocator must be known in compile time? Though also in STL.

> 
> b) Allocator is just a regular parameter which you can add to your args
> list. now the c-tor need some machinery to handle the allocator.
> I'd say something like:
> a c-tor does two things, gets memory and puts stuff into that memory.
> so the first thing a c-tor does is automatically calls a default
> Allocator for the type to get memory, *unless* you call one explicitly
> yourself. it's similar to the way a c-tor has an implicit super() call
> if you don't call that yourself only this probably will need additional
> machinery to work.

Yes. Although the problem right now is syntactical. :(

> 
> other ideas how to approach this?
> 

Use the semicolon:

   Class.new(parameters; allocator params);