On Wed, Apr 4, 2012 at 1:20 PM, Diego Novillo <dnovi...@google.com> wrote: > On 4/4/12 5:06 AM, Richard Guenther wrote: > >> Btw, I think we should only start forcing C++ when 1) there is a >> branch/patch out >> that shows benefit from using C++. I previously mentioned that I'd like >> to see >> 2) a patch that _properly_ wraps a C++ class for consumption by our >> garbage >> collector (thus, not a hack that works for a specific case but >> infrastructure >> that we think will work for _all_ cases, including libstdc++ container >> use). > > > My idea was to start with something like converting VEC() which would > require dealing with GC. > > I did not intend to make the conversion and the switch as a single > operation, however. Seemed like too much to change in a single patch. > > >> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be >> combined >> by transitioning vec.h to a C++ template class, with proper GC support. >> (not sure that I can veto anything - heh)
I think vec.h is the canonical example of something that we agree on that using C++ is an improvement and a case where we have to get GC support right. If you say the changes doing GC "right" and transforming vec.h are too big to be done together, then well. You only know if you did things right if you have both the "new" GC and a user (vec.h in C++). So yes, maybe too big for a patch but not too big for a branch (where you could merge the GC infrastructure changes separately from the vec.h change). But both need to be developed together. Oh, and did we address all the annoyances of debugging gcc when it's compiled by a C++ compiler? ... Richard. > Well, none of us can, really. Except maybe RMs in the context of release > branches. > > > Diego.
