Re: [PATCH 1/2] Introduce obstack_new, poison other "typed" obstack functions

[Tom Tromey <tom@tromey.com>]

>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:

>> foo *f = new (obstack) foo ();

Simon> I thought about this.  The downside I see is that it forces new to
Simon> allocate on an obstack.  What if you want to use the standard new for
Simon> the same type in another context?  Maybe this doesn't happen in
Simon> practice though.

Good point.  We could have another mixin to provide a second operator
new, but that seems sort of ugly.

Simon> So if that was the main reason an obstack is used, you
Simon> might as well reconsider using an obstack at all [1].  But if the
Simon> obstack is used for the more efficient memory allocation, then it
Simon> would still make sense to use an obstack and track the objects
Simon> separately so that they can be destroyed properly.  What we need is
Simon> (not sure this is realistic): everywhere we allocate an object on an
Simon> obstack and don't keep track of it for further destruction, have a
Simon> static_assert there that the type should be trivially destructible.

Yeah.  And I'm not sure if this is doable either.  Maybe if we removed
allocate_on_obstack and switched completely to your obstack_new, and
then made it static_assert is_trivially_destructible.

Simon> Or maybe there are better C++ ways of getting the same advantages as
Simon> with an obstack (efficient allocation for a bunch of objects
Simon> allocated/freed at the same time, data locality)?

I'm not totally sure that obstacks are so great.  For example see
https://sourceware.org/bugzilla/show_bug.cgi?id=17143

In the past I think many times, something was put on the objfile obstack
simply because it was convenient.  For example I know there were cases
where this was done with hash tables (even though hash resizing means
leaking storage) just because it was simpler than trying to find the
correct spot to clean up.

This aspect is certainly something we can do more easily now with C++ --
just make the members clean up after themselves.

Tom