On Wed, Jun 2, 2010 at 1:22 AM, Ian Lance Taylor <i...@google.com> wrote:
> Basile Starynkevitch <bas...@starynkevitch.net> writes:
>
>> On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
>>> (2) we should prefer standard solution over home-grown hacks, unless
>>> there is a clear demonstration of value. For example, it would be
>>> unwise to prefer our current VEC_xxx over std::vector. Conversely,
>>> we should probably have our own hash table, since there is none in
>>> C++98.
>>
>> I am not entirely convinced of that. VEC is supported not only by
>> infamous vec.h macros (which we surely want to replace by some template,
>> possibly std::vec) but also by gengtype (and the Gcc Garbage Collector).
>
> As you say, gengtype includes specific support for VEC. Using
> std::vector instead will require some work in gengtype, but not too
> much. Currently gengtype generates code like this for a VEC:
>
> size_t l0 = (size_t)(((*x).base).num);
> for (i0 = 0; i0 != l0; i0++) {
> if ((*x).base.vec[i0].jump_functions != NULL) {
>
> It should be entirely feasible to make it generate std::vector
> accessor functions instead.
>
parsing class definition is sufficiently simpler than parsing full C++.
We can just enhance gengtype "pseudo-parse" any C++ standard header
to write out the object layout of any struct we are interested in
(e.g. std::vector).
The pseudo-parser would have to skip most top-level declarations except those
that declare types.
