[Dev-C++] Bloodshed programming environment

[Bob W. <bo...@ph...>]

To All Bloodshed Experts:=20
(This is not a C++ question)

I wasted three hours late last night trying to compile and run three =
programs, each of which compiled and ran perfectly after some small =
corrections to some typing errors. The programs were copied from Sams =
Teach Yourself C++ in 24 hours, Third Edition by Jesse Liberty.=20

So, if they compiled and ran properly, what was the problem?=20

In the interest of ease of identification later (i.e., self =
documentation of a program's purpose), I gave discriptive names to both =
the project files and the actual programs.=20

                          Project File Name                              =
                             Associated Source File Name
  Passing Function Arguments by Pointer.dev    =
Passing_Function_Arguments_by_Pointer.cpp*
  Passing Function Arguments by Reference.dev  =
Passing_Function_Arguments_by_Reference.cpp*
  Passing Function Arguments by Value.dev      =
Passing_Function_Arguments_by_Value.cpp*

*The underline charcters were used between words rather than spaces =
because the Bloodshed environment does not allow a C++ program to have =
the same name as=20

However, I was unable to produce more than two .exe files in the same =
directory, and if I built or compiled the same file twice, the other =
.exe file would disappear.

When I shortened the names to:

          Project File Name                                           =
Associated Source File Name
  Passing by Pointer.dev        =
Passing_Function_Arguments_by_Pointer.cpp
  Passing by Reference.dev      =
Passing_Function_Arguments_by_Reference.cpp
  Passing by Value.dev          Passing_Function_Arguments_by_Value.cpp

all three compiled and there were three .exe files in the directory.=20

        Executable File Name
  Passing by Pointer.exe
  Passing by Reference.exe
  Passing by Value.exe

Earlier, Ioannis Varnos and I had exchanged emails about a problem I =
experienced with the Bloodshed programming environment, and she had =
recommended that I stay away from the project creation function of the =
Bloodshed environment and stick to creating and compiling non project =
related C++ programs. I discovered that the solution to my problem lay =
in making direct changes to the undocumented .dev or project file with =
the notepad, so I continued to work with projects. Eureka! I thought and =
searched the .dev files for a truncation of my long file names, but they =
were not truncated in the project files.=20

With Ioannis' advice in mind, I closed the project file upon which I was =
working and brought the .cpp files listed above into the Bloodshed =
"shell" one at a time and compiled them. The results were the same. I =
was unable to produce more than two .exe files in the same directory, =
and if I built or compiled the same file twice, the other .exe file =
would disappear.=20

Although it is not documented, at least I cannot find it, there must be =
a maximum length of a file name beyond which the compiler/linker =
combination throws away or disregards the rest of the file name. When =
the compiler/linker erased a previously existing .exe file of a =
different name, it always erased the oldest. That leads me to believe =
that it searches from the top until it finds a file that matches the =
compiler's target file name, at least to the limits of its file name =
space, it deletes, and writes a new one, or it overwrites it and changes =
the name in the file directory. My guess is that the some part of the =
compiler or linker does not support the full length of windows file =
names. If this is the case, it is a flaw that should be fixed. =
Ironically, the names of any .exe file compiled and linked was never =
truncated.=20

Before someone goes on the "yer-files-names-are-too-damn-long" rampage, =
consider the fact that, unless a compiler is totally compatible with =
operating system conventions, it is not operating system compliant, and, =
as such, it is not as versatile or as useful as it could be. Any such =
limitations or variances should be well documented and internal error =
trapping routines should provide immediate warnings to the user if =
he/she exceeds a limit such as the allowed length of the file name =
allowed by the programming environment which will result in the type of =
problems documented above.=20

I truly hope that someone will send me an email that points out how I =
either missed the obvious, i.e., the documentation, help screen, option, =
etc., but I don't hold out much hope of that. I would be interested in =
knowing any other things like this that others have discovered.=20

Regards,

Bob Wilson