On Tuesday, 11 February 2014 at 17:03:13 UTC, Dmitry Olshansky
wrote:
10-Feb-2014 02:25, Jakob Ovrum пишет:
On Sunday, 9 February 2014 at 20:26:20 UTC, Dmitry Olshansky
wrote:
I'm saying that basically classes imply infinite lifetime
model. Then
you may work extra hard and do things like emplace and manual
allocation.
Infinite lifetime is also only with `new`. The "extra work"
with emplace
and manual allocation is the domain of library code (e.g. `C c
=
alloc!C(ctorArgs);`).
I thought of this for a while and I think lazly dynamic
allocation is still better. First things first - there is still
lazy initialization both ways.
The only potential gain of statically allocating memory here is
on the first exception being thrown, which doesn't gain
anything for our prime case of "many exceptions".
I was thinking of disadvantages such as GC heap fragmentation,
accidentally causing collection cycles in response-critical code
(though minor when an exception is thrown, for obvious reasons),
and being usable for people have disabled the `new` operator in a
custom GC-free druntime.
Lastly if the said exception is never thrown, static allocation
would waste more memory of each thread (TLS). This is
especially true for cases where not every thread runs the same
code (which is not a small part of the landscape).
Yes, this is a killer point. I was saying the exception is only
allocated if the template is actually instantiated, and if it is,
it's safe to say it's used - but by no means by all threads!
So yeah, dynamic allocation it is.
I'm thinking that I probably should compile this discussion to
some
implementable enhancement request for Phobos.
Are you talking about `emplace` for nested classes and such?
`cachedException` or some such sounds like something suitable
for std.exception.
Thoughts?
I like it. I also like the name; I couldn't think of a good name
myself... though it does cause some redundancy on use:
throw cachedException!MyException(args...);
It still needs some changes in druntime/object.d though, to
prevent infinite loops on exception chaining.
