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)