Re: header file guards conflict

[Akim Demaille]

Le 21 mai 2012 à 18:27, Hans Aberg a écrit :

> On 21 May 2012, at 18:17, Akim Demaille wrote:
> 
>> Le 21 mai 2012 à 17:55, Hans Aberg a écrit :
>> 
>>> Is there any reason to not put all stuff that is public in the parser 
>>> header? This would eliminate the need for any additional header files.
>> 
>> That's the plan for those that need not be public.
>> location.hh is different: you may use it for your
>> ASTs if you wish.  I, for one, do that.
> 
> Hm, I meant: put all stuff that the user might access in the parser header, 
> and the other stuff in the parser source. The names belonging to different 
> parsers won't collide if given different namespaces.

That's too much dependencies to inject.  An AST does
not need details about the parser, especially since these
details may change when you touch the grammar.  Even adding
empty lines in the grammar can change the header.  It would
be disastrous to force a compilation of an AST hierarchy
because of an eager #include where location.hh would
suffice.

Besides, when possible, it is certainly desirable to keep
a single version of the code, to avoid bloating the binary.
Weaker argument in the present case, I agree.