Re: [PATCH][libcpp] New deferred output pragma

[Basile Starynkevitch <basile at starynkevitch dot net>]

Tom Tromey wrote:
> > > > > > "David" == David Stubbs <stubbs@IceraSemi.com> writes:
>
> David> This patch adds a new deferred_output pragma to the preprocessor.
>
> A new extension requires some justification, not just a description.
> The current rule, I think, is that the justification be extraordinary.
>
> So, I'm afraid my inclination is to reject this idea even in principle.
> That said, I am not extremely active in GCC and I am open to being
> convinced, or dissenting opinions, or being overruled.
>
> David> #define EMIT_AT_EOF(name,body) void name() {body}
> David> #pragma GCC deferred_output EMIT_AT_EOF
>
> I'm not overly fond of this design, but I confess I don't have a better
> idea.

I am not sure to have understood all the details of the patch. Maybe the 
approach might be more similar to m4 divert & undivert...

However, I could imagine cases where it might be useful, assuming 
special plugins & possibly other extensions. Let pretend that plugin 
could install their own magic macros (like e.g. __COUNTER__ or __TIME__, 
e.g. some macro which expands to some "magical" stuff, implemented by a 
plugin).

Then, we might imagine a plugin which produce extra serialization 
routines (old people like me remember RPCXDR). It could process every 
structure having an extra plugin attribute (like 
__attribute__((serialize)) for instance), and for each such structure, 
generate the appropriate serializing routine, and the #pragma GCC 
deferred_output could handle or produce these.

An even more silly example could be our gengtype for GGC. We could 
replace the gengtype program by a plugin (that would not be a good idea, 
only mentioned for illustration) and replace the #include "gt-foo.h" 
appearing at end of our foo.c with a deferred_output pragma.

But I also would like more detailed discussion of why this patch & 
deferred_output pragma is useful. Could the original poster (Devid 
Stubbs?) give some realistic uses cases? Why does he want the patch?

Regarding additional CPP pragmas, a pragma which I might find convenient 
is a functionality (e.g. a #pragma GCC merge_lines) like  #line but 
telling CPP to not increment the line number for every consecutive lines 
(until the next #pragma or #line).

The intent would be for code generators. When they generate several 
lines for a single original source, they usually code

#line 3 "foo.melt"
  some_complex_code();
#line 3 "foo.melt"
  some_other_code();
#line 3 "foo.melt"
  if (some_complex_condition) some_other_stuff();
#line 3 "foo.melt"
  it_is_boring_to_need_all_these_sharpline();
#line 4 "foo.melt"

(at least the MELT plugin & translator does something similar).

It would be simpler for the generator to output
#pragma GCC merge_lines 3 "foo.melt"
  some_complex_code();
  some_other_code();
  if (some_complex_condition) some_other stuff();
  it_is_boring_to_need_all_these_sharpline();
#line 4 "foot.melt"


 Cheers.


--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***