I've transfered my BC++ 5.02 application to another developer and all paths for include and library are the same, however he gets the error reported on the subject.
How can we solve it?
Thanks in advance.
Moderator: Formatted paragraphs.
Last edit: Vidar Hasfjord 2021-09-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I recall having similar problems, I could not determine what exactly is causing this, but the solution was to make sure that <string> is included at the beginning of the files, before any OWL or OWLNext headers.
Jogy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Searching on the web I've seen that it seems to be somethig related to the conflict between std string class and Borlnad string class, but I wonder where the difference is since me and my colleague have exact the same IDE,and source files.
Gianni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wonder where the difference is since me and my colleague have exact the same IDE, and source files.
To find any macro expansion difference, compare the output of the pre-processor on both systems. To compare project settings, generate makefiles of the projects on both systems and compare the generated makefiles (the "*.ide" project files themselves are binary and may not match). Compare toolset versions, of course. If everything still matches, compare system environment variables.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In Borland C++ 5.02 I can't find how to get neither the pre-processor output nor the makefiles. Do you know how to do these actions?
"Project | Generate makefile".
The preprocessor is "bin\cpp32.exe". In IDE, on ".cpp" node generating the compilation error, select "Special | Preprocess" from the context menu. Also see "Options | Tools | CppPreprocessor".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
I've transfered my BC++ 5.02 application to another developer and all paths for include and library are the same, however he gets the error reported on the subject.
How can we solve it?
Thanks in advance.
Moderator: Formatted paragraphs.
Last edit: Vidar Hasfjord 2021-09-03
Hi, Gianni,
I recall having similar problems, I could not determine what exactly is causing this, but the solution was to make sure that
<string>is included at the beginning of the files, before any OWL or OWLNext headers.Jogy
Hi Gianni:
Are you using the same compiler in the new installation? Or perhaps are you using BCC5.5 in the original installation?
Sebas
Hi Sebastian,
Yes, we are using the same compiler BC++ 5.02.
Searching on the web I've seen that it seems to be somethig related to the conflict between std string class and Borlnad string class, but I wonder where the difference is since me and my colleague have exact the same IDE,and source files.
Gianni
To find any macro expansion difference, compare the output of the pre-processor on both systems. To compare project settings, generate makefiles of the projects on both systems and compare the generated makefiles (the "*.ide" project files themselves are binary and may not match). Compare toolset versions, of course. If everything still matches, compare system environment variables.
Thanks Vidar.
System variables are exactly the same.
In Borland C++ 5.02 I can't find how to get neither the pre-processor output nor the makefiles. Do you know how to do these actions?
Moderator: Formatted paragraphs.
Last edit: Vidar Hasfjord 2021-09-03
"Project | Generate makefile".
The preprocessor is "bin\cpp32.exe". In IDE, on ".cpp" node generating the compilation error, select "Special | Preprocess" from the context menu. Also see "Options | Tools | CppPreprocessor".
In the project window of BCW, just select the node (ie: mainDlg.cpp), right click->Special->Preproccess
Hi All,
Thanks for you support, I've solved the problem.
Gianni