Bill Caroselli <firstname.lastname@example.org> wrote:
OK. I want to jump back in here. When Adam wrote his comment I was willing
to let it slide but now that you are all ganging up on my I want to fight
back. (Please notice that I’m saying that tongue in cheek.)
Agreed, #ifdef’s and #pragma’s are ugly. But they solve a problem.
Would someone suggets that instead of using #ifdef’s that we maintain one
set of source files for one platform and another set of source files for a
different patform? Especially if only a few lines need to be unique for
each platform? I don’t think so!
Partly. I would suggest that common code be placed in common modules, and
then OS specific code be placed in OS specific modules. Paul Trunley’s
“ved” editor did just that. ALL the code that was OS independent was
placed in a variety of modules. Then, code that was OS specific was placed
in .c He ported it to VAX/VMS, QNX 2, QNX 4, and I ported it to
Linux and QNX 6. If something was found not to be portable to a particular
OS, then it was placed into an OS specific module, and anything that referred
to it was OS-independized (if that’s a word ).
The thing that this solves rather nicely is that it eliminates OS and
compiler specific hacks in the source – if OS/X and compiler/Y need some
funky option “#XYZZY” then that option is limited only to .c – if
you need to be anal about it, then -.c
Personally I would rather do my programming in a program, not a makefile.
Unless the code in the makefile simply compiled everything except the OS
specific modules. For a very educational (though slightly contrary point
of view) take a look at the Kermit sources from Frank da Cruz. All of the
FREAKING FILENAMES are 6 characters long plus the “.c” extension – it’s
Of course there is a place for conditional processing in a makefile. But if
I’m writing software that I want to me as easy as possible for someone else
to use without the need for them to read a lot of documentation, I think
… then you’d provide pre-built binaries…
that for the developer to stick a one line #pragma in a header file (which
must be included anyway) is much more efficient (no, to use Robert Krten’s
word, elegent) then to force every developer that would ever use these
<damn, someone who quotes me Oh hi Bill! >
routines to have to add several lines to their makefiles. Which by the way
implies that they must know before hand that it is necessary.
Sorry to disagree with you bill, but it’s still a quasi-democracy. I think that
putting in a) compiler specific and b) path specific things in a source file
is a “Bad Thing™”.
So let’s see a show of hands from other programmers.
</war mode off >
Bill Caroselli – 1(530) 510-7292
“Rennie Allen” <> email@example.com> > wrote in message
news:> 3C3F4BC0.firstname.lastname@example.org> …
Adam Mallory wrote:
I’m not sure when that would be useful - the last thing I would want is
have to wade through source code files, removing #pragma 's because they
reference differently named libs on different platforms. Or worse, the
pragma isn’t recognized. Obviously you could conditionally include
but all this makes for ugly code. Just my $0.02
I agree, pragmas are ugly, I remain blissfully ignorant of any of them.
The one described seems particularly ugly (reminds me of the Reeses
commercial - “you got build instructions in my source” - although the
result is considerably more distasteful than the chocolate and peanut
butter accident portrayed in the commercial >
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Consulting and Training at www.parse.com
Email my initials at parse dot com.