Path: utzoo!attcan!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.c++
Subject: Re: goodbye cpp ??? (macros vs. inline functions)
Message-ID: <281@aber-cs.UUCP>
Date: 28 Nov 88 15:30:38 GMT
References: <6590072@hplsla.HP.COM> <1757@dataio.Data-IO.COM> <3637@pt.cs.cmu.edu> <1304@cod.NOSC.MIL> <12903@duke.cs.duke.edu> <265@aber-cs.UUCP> <1988Nov27.011355.29290@utzoo.uucp>
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: CS Dept., University College of Wales, Aberystwyth, UK
Lines: 96
X-Disclaimer: Any statement is purely personal.

In article <1988Nov27.011355.29290@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:

    In article <265@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
    >On the other hand I do really believe that cpp in C++ is not that
    >useful; #include's should be done with import/export...
    
    In other words, with new constructs that will have to resemble
    #include in many ways, except that they will undoubtedly be more
    complex.  Why bother?  Is there some specific benefit, apart from
    the change in syntax?

There are two points; one is speed, and the other is easier
configurability.  I have seen many export/import syntaxes for various
languages, and they do not seem to be more complex than #include.  I
would have doubts... Also, I do not like the wholesale imports favoured
by #include.

    Please remember that the new scheme will have to be one that can
    cope with search paths, separations between projects,
    standard/optional/local/project/program libraries, debugging vs
    compile-for-production, etc. -- simply having the construct always
    look in one standard place for things to import is not nearly good
    enough.  Only toy compilers always use the same libraries for all
    compilations.

I never advocated toy compilers! Indeed I think that export/import
could help a lot with the problems you mention, more so than cpp.
Well, after all #include is not especially user frindly or powerful. I
think that a proper export/import facility, with multics like paths,
would be more efficient, have finer resolution, be much more flexible
and easier to use than the often hairy things you have to do with
#includes and coordinate them with the linker etc... by hand.

    > ...conditional compilation can be done most often by a suitable constant
					     ^^^^^^^^^^
    >expression in a if...
    
    How do you make this work for declarations?  (I made the same blunder long
    ago.)

Most often, most often. I understand that C++ does not yet have fully
"executable" declarations :-). Another obvious example that cannot be done
but by macroprocessor is *parts* of statements or other syntactical units.
In other words, all cases where you "temporarily" violate the syntax
of the underlying language.
    
    >as to syntax extensions, I think something like ML/1 would be the
    >ideal thing here.
    
    "Ideal" in what sense?  Certainly not from an implementor's point of view.

Ideal because it allows the definitions of more humane-looking macro patterns
(not all syntax extensions you may want look like functions calls), it is
quite fast, the implementation is there. 
    
    Or from the viewpoint of a user who has to understand already-written code.

This I do not understand.

    The preprocessor may be ugly, but at least it is (apart from some of the
    fine points of macro expansion in draft-ANSI C) relatively simple and easy
    to understand.  (Programs that exploit it in fancy ways can be cryptic, but
    programs that exploit more complex mechanisms in fancy ways will be worse.)
    That is not a trivial virtue.

Well, it is quite fast, and it is quite ugly. Relatively easy and
simple to understand, well, you know, most people that use it use it
only for the simplest things, and still they are often astonished (how
many do not fully parenthesize EVERYTHING ?). Rather than simple, I'd
say simplistic -- as soon as you have to do non trivial things you have
to be a real wizard. It is a matter of opinion whether other mechanisms
would be rather less or more hairy in complex situations than cpp.

I would like to note that this discussion started with people being not
very satisfied with the preprocessor. It was a good thing (can we say a
very good hack?) when it was born, but fortunately the tendence now is
to bring more of its functions in the language framework, so that is be
more consistent and efficient.  This is indeed the spirit of C++, as
Dr.  Stroustrup correctly remarks.

On the other hand I think that having a macro processor is ESSENTIAL in
any case, because certain things can be done only outside the framework
of a language, i.e. things that violate its syntax, and require pure
macro processing/unrestricted string manipulation, such as conditional
compilation of declarations, or of parts of statements. I'd rather have
a nicer macroprocessor than cpp for this purpose, though.

As to practicalities, the here and now, cpp is with us, and for a long
time.  If you want to write portable code, put up with cpp. Don't even
try to modify it or to extend it. I would not even use a #pragma idempotent,
which is a good example of a useful, nearly harmless extension as you
can find -- a lot of cpp/compiler pairs or unities do not support #pragma yet.
-- 
Piercarlo "Peter" Grandi			INET: pcg@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science	UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)