On 08/05/2016 08:37 AM, Aldy Hernandez wrote:
After looking at all this code, I realize no size will fit all if we
want something clean. So, I take my approach back. I think we're best
served by a couple different approaches, depending on usage.
Yup.
My question is, how wed are we to an alloca based approach? Can we
replace the non-critical uses by std::string (diagnostics,
BLAH_check_failed(), building a string to manipulate the output of
env("SOME_VAR"), etc?).
I don't think we are at all wed to alloca.
Then for things like the GCC driver wanting to create a vector of passed
commands, we could use auto_vec<> (*gasp*, using a vector to represent a
vector ;-)). Note that auto_vec<> uses malloc (or GC) but creating a
malloc'd vector at startup is hardly on the fast path.
For the remaining things we could use either alloca with a malloc
fallback for trivial things like set_user_assembler_name() that only
have one exit point, or take it on a case by case basis.
But it seems to me that we can use an STL container for the non critical
things (which are the majority of them), and something else (perhaps an
RAII thinggie TBD later).
Is this reasonable? I'd like to know before I spend any time converting
anything to std::string and auto_vec<>.
Yes, this is all reasonable to me. I'm a big believer in moving towards
standard library implementations of things. In this case we get to
remove the allocas *and* make the code easier to grok for those that are
familiar with the C++ standard library.
Jeff
