This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: patch to add #pushdef, #popdef to cccp,cpplib
Quoting Gerald Pfeifer (pfeifer@dbai.tuwien.ac.at):
> Please do not add that to EGCS! There are already way to many GCC
> language extensions (some of which are quite strange or even broken).
Did you have a particular problem with this extension? Your points all
seem like reasonable "rules of thumb" about extensions. I do not think
they apply to this case.
I can understand that the timing of this patch may not be well aligned
with more pressing development goals. But I do not think it is correct to
forbid anything unapproved by a standards committee. Existing practice
extensions help those very committees decide what is and isn't workable or
desirable.
> I think the goal should be support of ANSI/ISO C resp. C++, not some
> highly unportable extensions or a different language at all!
Gcc already has extensions. If people use gcc/egcs, they must make the
conscious choice to not use features that are non-standard. For a long
time I've had this problem with variadic macros and include_next. It is
simply a fact of life that gcc is an expanded dialect in the preprocessor,
C, and C++ -- you either use the extensions or not. As long as it is easy
to identify code that does or doesn't use them, I don't see the problem.
In fact, most C developers I know feel relief when they know something
*only* has to compile under gcc because then they can use all those
extensions.
In terms of the portability of the extension to other compilers, should
someone want to add this feature, this is an easy hack. It should not
take one very long to add a macro stack and push/pop to almost any C
preprocessor. E.g., the one by Dennis Ritchie that comes in the lcc
distribution or the old X11 one. It looked to be easy to add to all of
them, unlike many other gcc extensions. About the only requirement is
that the cpp implementation have a symbol table and trap redefinitions.
> For those who need a different, more powerful pre-processor, there is
> always the possibility to make it a separate pass in Makefiles etc.
Yes and no. Yes you could do that. But you give up other things. In
this case the addition is small. It operates on a macro-name level. The
prepreprocessor would have to rename all your macros for you. That would
likely reduce at least one longer term benefits of having cpp as a library
-- error and warning messages with non-expanded text. Also, you would end
up duplicating a lot of the processing of cpp just for a simple extension.
This feature is most logically thought of as a clean extension to the
macro system not a pre-cpp hack. m4 or other preprocessors do not meld as
cleanly with the system as its own cpp.
Also, a lot of developers are more willing to engage in a particular style
of programming when it is intrinisically supported by the system. I'm not
sure I know anyone that uses it who doesn't wish the C macro system were a
bit more hygenic. Yet none of them use their own pre-cpp to bypass that
macro system. This seems at least a small step in the right direction.
And the syntax is not some entirely separate macro language, but good 'ol
cpp. The semantics should be explicable in a couple sentences to anyone
who would ever want to use them. So, unlike learning m4 or some other
pre-cpp, whatever benefits this would give could be immediately exploited
by almost anyone. It's just a little more manual than would be optimal
(what with popdef). But "manual" is the style of cpp.
> Chuck, this is really not personal, but can you, for example, guarantee
> that you will we able to maintain that piece of code for say 20 years?
I don't take it personally. Mostly I think your objections are overly
general and feel like I should defend against them in detail. I hope you
don't take that personally.
While I'd surely support the patch for as long as seems appropriate, the
code is simple, isolated, and impacts little or nothing else in the
system. I #ifdef'd the syntax hooks (though not the implementation) so it
would be easy to add --disable-pushdef, though I'm not much of an autoconf
hacker (probably should have used a HAVE_ macro...).
It should not need to be maintained much at all past the initial debug
phase, and that should be very short for something this isolated. Indeed
the semantics and implementation of this extension are simple enought that
they would probably constitute "mental relief" from anyone working on the
bowels of the C++ world or the code optimizer.
I'll grant that there are some minor memory leakage issues. I would have
done something there, but the current cpp already blows these off citing
crash potential for freeing live memory. If memory profiling suggests a
need I could look at fixing that memory management. I could see a lot of
#push/#pop cycles in many header files starting to eat up a few bytes here
or there. And in cpplib-form that leaked memory could probably be
profitably reused by cc1/cc1plus. But this is hardly a showstopper in
terms of the language feature. The total memory is probably pretty
insignificant in a relative sense. Also the macro definitions still need
to be passed through to the debugger.
> Furthermore EGCS is not even fully ISO C++ compliant yet, I'd really
> like to see that compliance before even considering (further) extensions.
Why isn't it? Because that's a very hard problem. This is a simple
problem with a simple solution. To me the value of the feature is clear.
I hope it is to others as well. I grant that more complex and complete
solutions to the same problem exist or could be conceived. At some point,
as with all language design, it becomes a matter of taste.
Another issue is that this is a cpp extension, not a C++ extension. You
seem to be much more focused on C++. That is fine, but from my
perspective this feature is arguably more important to C developers where
the host language support for name space management is more meager.
The bottom line is that this capability makes it possible to use the
preprocessor more safely and more generally in a way I believe is
stylistically consistent. It enables things that simply could not happen
otherwise and are probably desirable. It doesn't interfere with existing
semantics. Also the feature should have essentially zero impact if it is
not used, so it seems like an easy thing to just try out.
Chuck