Unhelpful Assumptive Arrogance in C++ Builder5
vernonner3voltazim
C++ Builder, or if there is some workaround about
which I am currently ignorant, let me know! Thanks!
Now, let me work my way up to describing it....
A while back I decided to write a Windows program that
could be compiled from a single .C file (not counting
standard header files) by three different compilers,
with no editing needed when switching between compilers.
At the time I started the project, I had available to me
Borland (Turbo) C++ 4.52 (free part of a "Learn C/C++"
package), Borland C++ Builder 5 (standard), and
Microsoft Visual C++ 6.0 (professional). Later I
discovered the Open Watcom C++ compiler, and included
that as part of my goal.
The multi-compilable project was successful. With no
editing of the source code, every compiler yielded zero
errors, and only the Borland C++ Builder5 offered any
warnings (3, but they are actually irrelevant). Anyone
interested in either multicompiling or in (potentially)
Extreme Encryption can find the program here:
http://primarycryption.sourceforge.net/
(source code is accessible through a link on that page).
OK, as a single-file compilable, It Was Good. However,
as a SourceForge project with ambitions of becoming one
of a related group, involving such things as code-block
sharing and "localization" for other languages, I had
to break the program up into chunks. While those chunks
have not yet been posted to SourceForge's CVS system, I
can describe them here:
fundmntl.c -- in a "trunk" directory; holds some
fundamental #defines & other settings.
common.c -- in a "limb" subdirectory; holds global
variables and subroutine functions;
also has #include "..\..\..\fundmntl.c"
crypti0n.c -- in a "branch" subsubdirectory; holds the
WinMain() and WndProc() functions
english.c -- in a "bough" subsubsubdirectory; holds
an array of phrases for display to user;
also has #include "..\..\common.c" and
#include "..\crypti0n.c"
OK, the general idea is that the stuff in fundmntl.c
will be available to all lower-level directories for
multiple projects, even across different CPU platforms.
The stuff in common.c will also be available for
multiple projects, specific to one CPU. The stuff in
crypti0n.c is a specific project. and the stuff in
english.c is for a specific language version of that
project.
IN ORDER TO PREVENT EDITS TO THE SOURCE CODE for
different language versions of a project, I decided
that the Compiler Project should focus on english.c
--which is why the file has those two #include's,
and why the #include in common.c references fundmntl.c
from the lowest-level location of english.c
That is, should somebody decide to translate the
phrases and create an espanol.c file in its own
subsubsubdirectory, then THAT file would become
the focal point for compiling the specific project,
and none of the higher-level files would need any
editing.
THIS WORKS for the Borland C/C++ 4.52 compiler, for
the Microsoft Visual C++ 6.0 compiler, and for the
Open Watcom C++ compiler. All of them can create
working executables, when told to build english.c
BUT the Borland C++ Builder5 refuses to cooperate
with this plan. It keeps complaining that the
english.c file has no WinMain() function -- and
worse, it creates a default "english.cpp" file
containing a default WinMain() function and an
#include (well UseUnit) of english.c
A working executable is NOT created.
That Arrogance Must Cease. If Borland wants its
top compiler to be fancy enough to "help" a
programmer by providing essential functions,
then AT LEAST it should be smart enough to
follow all the #include's first, before assuming
that the programmer hasn't written one!!!!!!!!!!
Thanks in advance!