josh@mit-vax.LCS.MIT.EDU (Joshua Marantz) (12/05/88)
>Conditional compilation without cpp: > >const UNIX = TRUE; >const MSDOS = FALSE; > >if (UNIX) { > /* code for UNIX systems only */ >} >else if (MSDOS) { > /* code for MSDOS systems only */ >} > >The compiler could dump the code for the constant conditional >that evaluates FALSE and keep the code that evaluates TRUE. >This is the simplest of optimizations and any compiler that does not >do this should be shot (at least the compiler writer should be :-). This approach often *requires* that you compile with the optimizer on. Otherwise the linker will need to resolve references to all platform-specific routines regardless of which platform it's on. I find it a pain to debug compiler-optimized code in a symbolic debugger. In addition, you may want to take advantage of syntactic extensions offered by specific compilers. For example, the VAX C compiler on VMS allows you to take addresses of constants to facilitate calling VAX run time library routines, which generally take their arguments by reference. Finally, the reality is that not all compilers make that optimization. There are those of us that for one reason or another, still have to use old tools (even after the people that created them have been shot by angry academics :-). The thing I like about CPP is that it seems to work with a base level of functionality on the six different C compilers we use to produce the products we sell. Perhaps if we adopt C++, we will find that all the compilers will accept exactly the same syntax and support the same class libraries, and that those class libraries will be enough to isolate us from the platform's file system, graphics system, and other system services. I doubt that will happen. But if they all support CPP, then I think we'll get by. -Joshua Marantz Viewlogic Systems, Inc.
leech@proline.cs.unc.edu (Jonathan Leech) (12/05/88)
In article <5202@mit-vax.LCS.MIT.EDU> josh@mit-vax.LCS.MIT.EDU (Joshua Marantz) writes: >In addition, you may want to take advantage of syntactic extensions offered by >specific compilers. For example, the VAX C compiler on VMS allows you to take >addresses of constants to facilitate calling VAX run time library routines, >which generally take their arguments by reference. An even more basic problem (again with VMS) is that virtually every reference to a library call or globally defined symbol involves an identifier containing '$', not allowed on other implementations. Followups to comp.lang.misc, please. -- Jon Leech (leech@cs.unc.edu) __@/ ``It seemed to him that in addition to being beautiful she brought out all that was best in him of intellect and soul. That is to say, she let him talk oftener and longer than any girl he had ever known.'' - P. G. Wodehouse
guy@auspex.UUCP (Guy Harris) (12/06/88)
>The thing I like about CPP is that it seems to work with a base level of >functionality on the six different C compilers we use to produce the >products we sell. Not all C implementations necessarily have "cpp". That just happens to be the way certain C language constructs, such as "#include", "#define", "#if", etc., are supported in many C compilers. Any reasonable C implementation had, however, damn well better support at least some minimal set of those constructs; they are specified as part of the language in K&R 1, and a larger set of them are also in the dpANS and are almost certain - hell, I'll go out on a limb and say "certain" - to appear in the final C standard. Furthermore, the copy I have of "The C++ Programming Language" *also* lists some of those constructs in the "Reference Manual", so I'd damn well expect any current C++ implementation to support them as well. I presume some people are arguing that those language features should be dropped from the C++; until that's done, though, dropping them from what purports to be a C++ implementation would be stupid.
jima@hplsla.HP.COM (Jim Adcock) (12/08/88)
Save Your Breath! -- I have yet to see anybody actually argue to prohibit use of cpp. What I (and others) argue is that if you commonly see lots of programmers using cpp to do common every day tasks, those tasks would better be built into the compiler, which can better do error detection and optimization. The prime example being: #include "yourSuperClass.h" Which ends up taking "forever" just to "compile" all the "#include *.h"'s, and programmers have to play lots of games with the .h files to "optimize" the amount of time to compile them, and not include them multiple times, etc. And your class writing activities get split between two files, the main class file and that class's .h files, and you keep having to reconcile the two files. Whereas, languages that have "import" and "export" features defined don't need separate .h files, typically the definition section of class is kept in a "compiled" form within the .o file for the class, and you are automatically guaranteed that the definitions are only included once, and are "precompiled", so you don't have to recompile these definitions everytime you want to use a class. And since the ".h" type information is automatically exported from the export section of your main class file, you don't have to work with two separate files for each class. Why don't we discuss what needs or doesn't need to go into C++ rather than worrying about cpp? Who can stop you from using cpp if you want to?
leech@zeta.cs.unc.edu (Jonathan Leech) (12/08/88)
In article <6590082@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: > Whereas, languages that have "import" and "export" features > defined don't need separate .h files... Having used one of these languages (HP massively extended Pascal), I prefer #includes. Changing the location of subroutines and type declarations can be a true nightmare in this language, since the import/export declarations must change accordingly. Indeed, a friend eventually wrote a preprocessor which extracted all the exports into one file to avoid this sort of nonsense. Keep it out of C++! -- Jon Leech (leech@cs.unc.edu) __@/ "Opossums ran amok in Chapel Hill this weekend..." _The Daily Tar Heel_, 11/1/88