I can has @nogc and throw Exceptions?

Jonathan Marler via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Feb 13 11:23:35 PST 2015


On Friday, 13 February 2015 at 19:10:00 UTC, Adam D. Ruppe wrote:
> On Friday, 13 February 2015 at 19:03:10 UTC, Jonathan Marler 
> wrote:
>> T construct(T,A...)(void* buffer, A args)
>> {
>>  return (cast(T)buffer).__ctor(args);
>> }
>
> This is wrong, you need to initialize the memory first to the 
> proper values for the class, gotten via typeid(T).init. 
> std.conv.emplace does this correctly, either use it or look at 
> its source to see how to do it.

That's what I was looking for! Thanks.

>
>>  ubyte[ __traits(classInstanceSize, Exception)] 
>> exceptionBuffer;
>
> When the stack unwinds, this will be invalidated... I don't 
> think stack allocated exceptions are ever a good idea. I don't 
> think malloc exceptions are a good idea either, the catcher 
> would  need to know to free it.
>
> You might preallocate a pool of GC'd exceptions though, then 
> throw the next one in the list instead of making a new one each 
> time.

Yes I am aware of these things. Stack allocated exception are 
dangerous if you let them get thrown above the function they were 
allocated in.  But this is easy to prevent by simply making sure 
you catch the exception in the function you allocate it in.  And 
yes malloc'd exceptions would be odd since the convention is to 
allocate them on the GC heap so no one would think they had to 
free them.  Also you could use a global...but I'm also aware of 
the caveats of this, between excessive TLS memory and the dangers 
of using shared or __gshare memory. A pool of pre-allocated 
exceptions is an idea I was throwing around...but with this new 
emplace function it opens up my options.  Thanks.




More information about the Digitalmars-d-learn mailing list