On Wed, Jun 2, 2010 at 6:03 PM, Tom Tromey <tro...@redhat.com> wrote:
>>>>>> "Basile" == Basile Starynkevitch <bas...@starynkevitch.net> writes:
>
> Basile> Still, my concerns on C++ is mostly gengtype related. I believe we
> need
> Basile> to keep a garbage collector even with C++, and I believe that changing
> Basile> gengtype to follow C++ could be quite painful if we follow the usual
> Basile> route of parsing our headers. Making a gengtype able to parse almost
> any
> Basile> C++ header file would be painful.
>
> It seems to me that C++ can actually make gengtype's job simpler.
>
> For example, rather than generating code that knows about the layout of
> container types, we can just instantiate template functions that walk a
> container using the standard iterator API.
>
> So if you see:
>
> static GTY(()) std::vector<tree> some_global;
>
> gengtype can just emit
>
> template mark< std::vector<tree> > ();
>
> ...
> mark (some_global);
>
>
> Mark would be a template function, with specializations for gcc data
> types and various STL things (hopefully I got the C++ right here :-):
>
> template<typename T>
> void mark (const std::vector<T> &c)
> {
> T::const_iterator i = c.begin(), e = c.end();
> for (; i != e; ++i)
> mark (*i);
> }
>
>
> In this sort of setup, unlike with C, gengtype needs to know very little
> about the structure of std::vector. Instead most of the work is
> deferred to g++. With this approach, maybe gengtype only needs to know
> about roots; each data type could supply its own mark specialization.
True. But then either we have to write all markers manually or have
gengtype generate those template overloads for types it handles.
The question is how error-prone it would be - but if we put in a
template<typename T>
void mark(const T&) { gcc_unreachable (); }
we might be safe to not miss implementations for something gengtype
does not handle itself.
Richard.
