Re: Great example of why "everything is a tree" sucks

[Alec Teal <a dot teal at warwick dot ac dot uk>]

The name David Malcolm comes to mind, I remember watching a GCC ... 
bucket, tub, some sort of large container (pot?) talk on it.

He was replacing all the macros with a class with no virtuals (only one 
data member, as used by the macros in effect) and so forth and using 
inheritance, doesn't that solve this? (or "wont that solve this?" 
<--future tense)

C++11 has a lot of great things (like std::is_base_of and 
std::remove_pointer in type_traits) that help with this, I'm pretty sure 
these came from Boost, most good things come from Boost (read: I am 
certain they came from Boost and that Boost lets us do them, but it's 
been so long I couldn't tell you exactly how without reading 
documentation again). If C++11 stuff can't be used (I'm not saying we 
should, just observing, I agree that fairly old compilers should be able 
to build GCC) can't we just use what Boost does?

I never spend much time looking but Boost does say which versions of 
what compilers are supported. If they can do it surely we can?

This would allow some pretty solid compile time checks to be introduced 
I would have thought?

Alec


On 12/11/13 20:52, Diego Novillo wrote:
> On Tue, Nov 12, 2013 at 3:35 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>
> > Note that we have tons of code which accept either objects or types,
> > both in the frontends and in the middle-end, so changing TREE_TYPE
> > from tree to something else is definitely non-trivial.
> Well, sure it's hard.  This is the whole point behind Andrew's
> refactoring project: setting up the groundwork for this kind of
> conversion to be possible.
>
> The software engineering atrocities that we have committed in the code
> base are going to take a few iterations to fix.  But fix them, we
> must.
>
> I am convinced that this is the only way for GCC to avoid untimely
> oblivion; and allow it to evolve in ways that are now hard or
> impossible to implement.
>
>
> Diego.