Mensana
asked on
#include <list> in VC++ 6.0
I have a project that refuses to compile as soon as I try to include the STL library. I want to use some lists and when I include the header file, the compilation shows some errors related to the "new" and "delete" declarations in some MFC file. I could switch to MFC-based lists but I hate to do that because I used STL lists a thousand times before and I never had any problems. I don't understand what the problem is this time. I checked the projects settings and did compare them with other project settings where the STL works without problems.
I include the some of the errors shown by the compiler:
Compiling resources...
Compiling...
main.cpp
c:\program files\microsoft visual studio\vc98\include\new(35
c:\program files\microsoft visual studio\vc98\include\new(35
c:\program files\microsoft visual studio\vc98\include\new(35
c:\program files\microsoft visual studio\vc98\include\new(36
c:\program files\microsoft visual studio\vc98\include\new(37
c:\program files\microsoft visual studio\vc98\include\new(37
// ...
Did anybody else bumped into this horrible problem? I checked the MSDN site for a clue but couldn't find one. What might be the problem?
I include the some of the errors shown by the compiler:
Compiling resources...
Compiling...
main.cpp
c:\program files\microsoft visual studio\vc98\include\new(35
c:\program files\microsoft visual studio\vc98\include\new(35
c:\program files\microsoft visual studio\vc98\include\new(35
c:\program files\microsoft visual studio\vc98\include\new(36
c:\program files\microsoft visual studio\vc98\include\new(37
c:\program files\microsoft visual studio\vc98\include\new(37
// ...
Did anybody else bumped into this horrible problem? I checked the MSDN site for a clue but couldn't find one. What might be the problem?
did you include the
using namespace std;
?
using namespace std;
?
ASKER
Oh, I know that. However, "stdafx.h" is first include statement in my .cpp files, whereas #include <list> is in one header file.
ASKER
Yes, I did that too and guess what? I had another stupid error:
error C2871: 'std' : does not exist or is not a namespace
error C2871: 'std' : does not exist or is not a namespace
ASKER
I don't think there are problems with the include paths for the environment because I have other projects in the same workspace that work just fine. Like I said, I checked the settings for this project against the settings for another project that works and everything was the same.
try adding
#include <string>
#include <string>
would it be possible for you to post the file where all of this #including is going on?
would it be possible for you to post the file where all of this #including is going on?
you
#include <list>
has to be BEFORE
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
block of code in you cpp file. So if you have
in MyFile.h
....
#include <list>
....
then in
MyFile.cpp
it should be
#include "stdafx.h"
#include "MyFile.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
Hope it helps...
#include <list>
has to be BEFORE
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
block of code in you cpp file. So if you have
in MyFile.h
....
#include <list>
....
then in
MyFile.cpp
it should be
#include "stdafx.h"
#include "MyFile.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
Hope it helps...
ASKER
For MeatWeasel
I have so many projects with so many dependencies that I would have to e-mail you an archive with everything in it. Basically, my files header looks something like this:
#ifndef TSSTMCCONTROLLER_HPP
#define TSSTMCCONTROLLER_HPP 1
#include <afxsock.h>
#include "tsstmc.h" // these are header from other projects
#include "ap.h"
#include "gp.h"
#include "commdevice.h"
#include "tmcdatalink.hpp"
#include "timerclient.h"
#include "tmcmessageunion.h"
#include "FieldCodes.h"
#include "TokenException.h"
//#include <list> // must comment this line to compile
//using namespace std; // same as above
The .cpp file starts like this:
#include "stdafx.h"
#include "tsstmccontroller.h" // this is my header
#include <conio.h>
#include <stdio.h>
#include "gputils.h"
#include "eventmsg.h"
#include "devicerequest.h"
#include "tsstmc.h"
#include <sys/types.h>
#include <sys/stat.h>
For mblat
Usually that sequence of code is added by the Wizard. We didn't use it to generate this Win32 console app. I have nothing like that in my code.
This whole thing started to drive me nuts. Next thing I will try is to regenerate the app from scratch, maybe I just deal with some bad links.
I have so many projects with so many dependencies that I would have to e-mail you an archive with everything in it. Basically, my files header looks something like this:
#ifndef TSSTMCCONTROLLER_HPP
#define TSSTMCCONTROLLER_HPP 1
#include <afxsock.h>
#include "tsstmc.h" // these are header from other projects
#include "ap.h"
#include "gp.h"
#include "commdevice.h"
#include "tmcdatalink.hpp"
#include "timerclient.h"
#include "tmcmessageunion.h"
#include "FieldCodes.h"
#include "TokenException.h"
//#include <list> // must comment this line to compile
//using namespace std; // same as above
The .cpp file starts like this:
#include "stdafx.h"
#include "tsstmccontroller.h" // this is my header
#include <conio.h>
#include <stdio.h>
#include "gputils.h"
#include "eventmsg.h"
#include "devicerequest.h"
#include "tsstmc.h"
#include <sys/types.h>
#include <sys/stat.h>
For mblat
Usually that sequence of code is added by the Wizard. We didn't use it to generate this Win32 console app. I have nothing like that in my code.
This whole thing started to drive me nuts. Next thing I will try is to regenerate the app from scratch, maybe I just deal with some bad links.
Q. Do you have this errors in both DEBUG and RELEASE mode?
ASKER
mblat,
In DEBUG mode for sure. I think I start to have an idea as what might be the problem: it's the way the app was created. I think that for some apps MFC support is not automaticaly included unless you specifically ask for that. Can be the same case with STL?
In DEBUG mode for sure. I think I start to have an idea as what might be the problem: it's the way the app was created. I think that for some apps MFC support is not automaticaly included unless you specifically ask for that. Can be the same case with STL?
ASKER
mblat,
In DEBUG mode for sure. I think I start to have an idea as what might be the problem: it's the way the app was created. I think that for some apps MFC support is not automaticaly included unless you specifically ask for that. Can be the same case with STL?
In DEBUG mode for sure. I think I start to have an idea as what might be the problem: it's the way the app was created. I think that for some apps MFC support is not automaticaly included unless you specifically ask for that. Can be the same case with STL?
No, but the fact that in compiles in RELEASE mode and doesn't in DEBUG may indicate that you have incorrect sequeince of #includes
Some operators ( and if I am not mistaken new is one of them ) is redefined in DEBUG mode and it's definition is different between STL and "other" VC++ definitions.
So try to put your #include <list> as a very first include in your project.
Some operators ( and if I am not mistaken new is one of them ) is redefined in DEBUG mode and it's definition is different between STL and "other" VC++ definitions.
So try to put your #include <list> as a very first include in your project.
ASKER
mblat,
In DEBUG mode for sure. I think I start to have an idea as what might be the problem: it's the way the app was created. I think that for some apps MFC support is not automaticaly included unless you specifically ask for that. Can be the same case with STL?
In DEBUG mode for sure. I think I start to have an idea as what might be the problem: it's the way the app was created. I think that for some apps MFC support is not automaticaly included unless you specifically ask for that. Can be the same case with STL?
ASKER
mblat,
In DEBUG mode for sure. I think I start to have an idea as what might be the problem: it's the way the app was created. I think that for some apps MFC support is not automaticaly included unless you specifically ask for that. Can be the same case with STL?
In DEBUG mode for sure. I think I start to have an idea as what might be the problem: it's the way the app was created. I think that for some apps MFC support is not automaticaly included unless you specifically ask for that. Can be the same case with STL?
ASKER
Sorry, these guys have a problem with the Refresh button - it posts the same comment over and over again.
Mensana: did you try a release build (you didn't mention that - but it is important)
Also there's no indication that you actually #include<string> anywhere - do you do that?
I don't know how big your main.cpp is - but you could start with commenting out certain parts and see if it compiles.
i.e. comment out all but the header files - if there's still an error, you have a problem in your header files (either inclusion order, or more likely a syntactic error - very often forgetting a required semicolon or closing bracket at the end of one .h file leads to erros like those you give.)
BTW. errors in C++ are rarely stupid - they try to tell you something (although they sometimes speak a foreign language)
if you #include <list>, but "using namespace std;" gives you an error right afterwards, there definitely is something wrong - most likely with your code.
Also there's no indication that you actually #include<string> anywhere - do you do that?
I don't know how big your main.cpp is - but you could start with commenting out certain parts and see if it compiles.
i.e. comment out all but the header files - if there's still an error, you have a problem in your header files (either inclusion order, or more likely a syntactic error - very often forgetting a required semicolon or closing bracket at the end of one .h file leads to erros like those you give.)
BTW. errors in C++ are rarely stupid - they try to tell you something (although they sometimes speak a foreign language)
if you #include <list>, but "using namespace std;" gives you an error right afterwards, there definitely is something wrong - most likely with your code.
ok, everybody is looking at just the code ... there might be more to it ...
there is a beautiful article in MSDN (Q154753), titled "INFO: What Are the C/C++ Libraries My Program Would Link With?"
here's an excerpt from the article:
--------------------------
SUMMARY
This article describes the default libraries LIBC[D].LIB, LIBCMT[D].LIB, LIBCI[D].LIB, LIBCIMT[D].LIB, LIBCP[D].LIB, LIBCPMT[D].LIB, MSVCRT[D].LIB, MSVCIRT[D].LIB, and MSVCPRT[D].LIB that a program will link with when built using Visual C++.
MORE INFORMATION
When you build a release (or debug) version of your project in Visual C++, one of the basic C Runtime libraries (LIBC[D].LIB, LIBCMT[D].LIB, and MSVCRT[D].LIB) is linked by default, depending on the compiler option you choose (single-threaded <ML[d]>, multithreaded <MT[d]>, or multithreaded DLL<MD[d]>). A library from the Standard C++ Library or one from the old iostream library may also be linked depending on the headers you use in your code.
--------------------------
i suggest that u read the entire article first ... then check the libraries in the project settings ... there might be a clash among different sets of libraries specified in your settings.
i guess that is where the trouble is.
hope it helps :-)
here's the entire article ...
INFO: What Are the C/C++ Libraries My Program Would Link With?
Q154753
--------------------------
The information in this article applies to:
Microsoft Visual C++, 32-bit Enterprise Edition, versions 4.2, 5.0
Microsoft Visual C++, 32-bit Professional Edition, versions 4.2, 5.0
--------------------------
SUMMARY
This article describes the default libraries LIBC[D].LIB, LIBCMT[D].LIB, LIBCI[D].LIB, LIBCIMT[D].LIB, LIBCP[D].LIB, LIBCPMT[D].LIB, MSVCRT[D].LIB, MSVCIRT[D].LIB, and MSVCPRT[D].LIB that a program will link with when built using Visual C++.
MORE INFORMATION
When you build a release (or debug) version of your project in Visual C++, one of the basic C Runtime libraries (LIBC[D].LIB, LIBCMT[D].LIB, and MSVCRT[D].LIB) is linked by default, depending on the compiler option you choose (single-threaded <ML[d]>, multithreaded <MT[d]>, or multithreaded DLL<MD[d]>). A library from the Standard C++ Library or one from the old iostream library may also be linked depending on the headers you use in your code. For example, consider the following cases:
Case 1: Sample program test1.cpp
// test1.cpp
void main()
{
}
If you build test.cpp using the /ML (or /MLd, for a debug build) compiler option, your program will link with LIBC.LIB (or LIBCD.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MT (or /MTd, for a debug build) compiler option, your program will link with LIBCMT.LIB (or LIBCMTD.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MD (or /MDd, for a debug build)compiler option, your program will link with MSVCRT.LIB (or MSVCRTD.LIB, for debug build), in addition to other libraries. In this case, your program will be dependent on MSVCRT.DLL (or MSVCRTD.DLL for debug build).
Case 2: Sample program test2.cpp
// test2.cpp
#include <iostream>
void main()
{
}
If you build test.cpp using the /ML (or /MLd, for a debug build) compiler option, your program will link with LIBC.LIB (or LIBCD.LIB, for debug build) and LIBCP.LIB (or LIBCPD.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MT (or /MTd, for a debug build) compiler option, your program will link with LIBCMT.LIB (or LIBCMTD.LIB, for debug build) and LIBCPMT.LIB (or LIBCPMTD.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MD (or /MDd, for a debug build) compiler option, your program will link with MSVCRT.LIB (or MSVCRTD.LIB, for debug build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build), in addition to other libraries. For Visual C++ 6.0, your program will be dependent on MSVCRT.DLL and MSVCP60.DLL (or MSVCRTD.DLL and MSVCP60D.DLL for debug build). For Visual C++ 5.0, your program will be dependent on MSVCRT.DLL and MSVCP50.DLL (or MSVCRTD.DLL and MSVCP50D.DLL for debug build). For Visual C++ 4.2, your program will be dependent on MSVCRT.DLL (or MSVCRTD.DLL for debug build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build).
Case 3: Sample program test3.cpp
// test.cpp
#include <iostream.h>
void main()
{
}
If you build test.cpp using the /ML (or /MLd, for a debug build) compiler option, your program will link with LIBC.LIB (or LIBCD.LIB, for debug build) and LIBCI.LIB (or LIBCID.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MT (or /MTd, for a debug build) compiler option, your program will link with LIBCMT.LIB (or LIBCMTD.LIB, for debug build) and LIBCIMT.LIB (or LIBCIMTD.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MD (or /MDd, for a debug build) compiler option, your program will link with MSVCRT.LIB (or MSVCRTD.LIB, for debug build) and MSVCIRT.LIB (or MSVCIRTD.LIB, for debug build) in addition to other libraries. In this case, your program will be dependent on MSVCRT.DLL (or MSVCRTD.DLL for debug build) and MSVCIRT.DLL (or MSVCIRTD.DLL for debug build).
Headers determine whether the Standard C++ libraries, old iostream libraries, or neither will be linked. Compiler options (/ML[d], /MT[d], /MD[d]) determine which version of the libraries single-threaded, multithreaded, or multithreaded DLL is to be linked by default.
NOTE: It may seem that headers without the ".h" extension are Standard C++ headers and that headers with the ".h" extension are C Runtime headers or old iostream headers. This is not true. As explained below, the files <useoldio.h> and <use_ansi.h> determine the libraries your application will link with.
Actually, there are two header files, <useoldio.h> and <use_ansi.h>, that contain #pragmas. The #pragmas force either the old iostream library or the Standard C++ library to be linked in by default.
The header file <useoldio.h> contains #pragma statements, which force the old iostream library to be linked in. All old iostream headers include <useoldio.h>. So, if you include any old iostream header in your application, the old iostream library will be linked by default. The following table lists all the header files that include <useoldio.h>.
Old iostream Headers
--------------------
FSTREAM.H IOMANIP.H
IOS.H IOSTREAM.H
ISTREAM.H OSTREAM.H
STDIOSTR.H STREAMB.H
STRSTREA.H
The header file <use_ansi.h> contains #pragma statements that force the Standard C++ Library to be linked in. All Standard C++ Headers include <use_ansi.h>. So if you include any Standard C++ header in your application, the Standard C++ library will be linked by default. The following table lists all the header files that include <use_ansi.h>.
Standard C++ Headers
--------------------------
ALGORITHM BITSET COMPLEX DEQUE
FSTREAM FUNCTIONAL IOMANIP IOS
IOSFWD IOSTREAM ISTREAM ITERATOR
LIMITS LIST LOCALE MAP
MEMORY NUMERIC OSTREAM QUEUE
SET SSTREAM STACK STDEXCEPT
STREAMBUF STRING STRSTREAM TYPEINFO
UTILITY VALARRAY VECTOR XIOSBASE
XLOCALE XLOCINFO XLOCMON XLOCNUM
XLOCTIME XMEMORY XSTRING XTREE
XUTILITY YMATH.H
You cannot mix calls to the old iostream library and the new Standard C++ Library in Visual C++ 4.2.
Summary Table
--------------------------
| Compile Old New IOStream Libraries |
| Option IOStream or STL Linked With |
|=========================
| /ML No No LIBC.LIB |
|-------------------------
| /MLd No No LIBCD.LIB |
|-------------------------
| /MT No No LIBCMT.LIB |
|-------------------------
| /MTd No No LIBCMTD.LIB |
|-------------------------
| /MD No No MSVCRT.LIB |
|-------------------------
| /MDd No No MSVCRTD.LIB |
|-------------------------
| /ML No Yes LIBC.LIB, LIBCP.LIB |
|-------------------------
| /MLd No Yes LIBCD.LIB, LIBCPD.LIB |
|-------------------------
| /MT No Yes LIBCMT.LIB, LIBCPMT.LIB |
|-------------------------
| /MTd No Yes LIBCMTD.LIB, LIBCPMTD.LIB |
|-------------------------
| /MD No Yes MSVCRT.LIB, MSVCPRT.LIB |
|-------------------------
| /MDd No Yes MSVCRTD.LIB, MSVCPRTD.LIB |
|-------------------------
| /ML Yes No LIBC.LIB, LIBCI.LIB |
|-------------------------
| /MLd Yes No LIBCD.LIB, LIBCID.LIB |
|-------------------------
| /MT Yes No LIBCMT.LIB, LIBCIMT.LIB |
|-------------------------
| /MTd Yes No LIBCMTD.LIB, LIBCIMTD.LIB |
|-------------------------
| /MD Yes No MSVCRT.LIB, MSVCIRT.LIB |
|-------------------------
| /MDd Yes No MSVCRTD.LIB, MSVCIRTD.LIB |
--------------------------
Summary Table for CRT DLLs Used
--------------------------
| Import Library DLLs Used DLLs Used |
| Linked With (VC 5.0|6.0) (VC 4.2) |
|=========================
| MSVCRT.LIB MSVCRT.DLL MSVCRT.DLL |
|-------------------------
| MSVCRTD.LIB MSVCRTD.DLL MSVCRTD.DLL |
|-------------------------
| MSVCPRT.LIB MSVCP5(5|6)0.DLL |
|-------------------------
| MSVCPRTD.LIB MSVCP5(5|6)0D.DLL |
|-------------------------
| MSVCIRT.LIB MSVCIRT.DLL MSVCIRT.DLL |
|-------------------------
| MSVCIRTD.LIB MSVCIRTD.DLL MSVCIRTD.DLL |
--------------------------
REFERENCES
For additional information, please see the following article in the Microsoft Knowledge Base: For additional information about , please see the following article(s) in the Microsoft Knowledge Base:
Q154419 Standard C++ Library Frequently Asked Questions
INFO: What Are the C/C++ Libraries My Program Would Link With?
Q154753
--------------------------
The information in this article applies to:
Microsoft Visual C++, 32-bit Enterprise Edition, versions 4.2, 5.0
Microsoft Visual C++, 32-bit Professional Edition, versions 4.2, 5.0
--------------------------
SUMMARY
This article describes the default libraries LIBC[D].LIB, LIBCMT[D].LIB, LIBCI[D].LIB, LIBCIMT[D].LIB, LIBCP[D].LIB, LIBCPMT[D].LIB, MSVCRT[D].LIB, MSVCIRT[D].LIB, and MSVCPRT[D].LIB that a program will link with when built using Visual C++.
MORE INFORMATION
When you build a release (or debug) version of your project in Visual C++, one of the basic C Runtime libraries (LIBC[D].LIB, LIBCMT[D].LIB, and MSVCRT[D].LIB) is linked by default, depending on the compiler option you choose (single-threaded <ML[d]>, multithreaded <MT[d]>, or multithreaded DLL<MD[d]>). A library from the Standard C++ Library or one from the old iostream library may also be linked depending on the headers you use in your code. For example, consider the following cases:
Case 1: Sample program test1.cpp
// test1.cpp
void main()
{
}
If you build test.cpp using the /ML (or /MLd, for a debug build) compiler option, your program will link with LIBC.LIB (or LIBCD.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MT (or /MTd, for a debug build) compiler option, your program will link with LIBCMT.LIB (or LIBCMTD.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MD (or /MDd, for a debug build)compiler option, your program will link with MSVCRT.LIB (or MSVCRTD.LIB, for debug build), in addition to other libraries. In this case, your program will be dependent on MSVCRT.DLL (or MSVCRTD.DLL for debug build).
Case 2: Sample program test2.cpp
// test2.cpp
#include <iostream>
void main()
{
}
If you build test.cpp using the /ML (or /MLd, for a debug build) compiler option, your program will link with LIBC.LIB (or LIBCD.LIB, for debug build) and LIBCP.LIB (or LIBCPD.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MT (or /MTd, for a debug build) compiler option, your program will link with LIBCMT.LIB (or LIBCMTD.LIB, for debug build) and LIBCPMT.LIB (or LIBCPMTD.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MD (or /MDd, for a debug build) compiler option, your program will link with MSVCRT.LIB (or MSVCRTD.LIB, for debug build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build), in addition to other libraries. For Visual C++ 6.0, your program will be dependent on MSVCRT.DLL and MSVCP60.DLL (or MSVCRTD.DLL and MSVCP60D.DLL for debug build). For Visual C++ 5.0, your program will be dependent on MSVCRT.DLL and MSVCP50.DLL (or MSVCRTD.DLL and MSVCP50D.DLL for debug build). For Visual C++ 4.2, your program will be dependent on MSVCRT.DLL (or MSVCRTD.DLL for debug build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build).
Case 3: Sample program test3.cpp
// test.cpp
#include <iostream.h>
void main()
{
}
If you build test.cpp using the /ML (or /MLd, for a debug build) compiler option, your program will link with LIBC.LIB (or LIBCD.LIB, for debug build) and LIBCI.LIB (or LIBCID.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MT (or /MTd, for a debug build) compiler option, your program will link with LIBCMT.LIB (or LIBCMTD.LIB, for debug build) and LIBCIMT.LIB (or LIBCIMTD.LIB, for debug build), in addition to other libraries.
If you build test.cpp using the /MD (or /MDd, for a debug build) compiler option, your program will link with MSVCRT.LIB (or MSVCRTD.LIB, for debug build) and MSVCIRT.LIB (or MSVCIRTD.LIB, for debug build) in addition to other libraries. In this case, your program will be dependent on MSVCRT.DLL (or MSVCRTD.DLL for debug build) and MSVCIRT.DLL (or MSVCIRTD.DLL for debug build).
Headers determine whether the Standard C++ libraries, old iostream libraries, or neither will be linked. Compiler options (/ML[d], /MT[d], /MD[d]) determine which version of the libraries single-threaded, multithreaded, or multithreaded DLL is to be linked by default.
NOTE: It may seem that headers without the ".h" extension are Standard C++ headers and that headers with the ".h" extension are C Runtime headers or old iostream headers. This is not true. As explained below, the files <useoldio.h> and <use_ansi.h> determine the libraries your application will link with.
Actually, there are two header files, <useoldio.h> and <use_ansi.h>, that contain #pragmas. The #pragmas force either the old iostream library or the Standard C++ library to be linked in by default.
The header file <useoldio.h> contains #pragma statements, which force the old iostream library to be linked in. All old iostream headers include <useoldio.h>. So, if you include any old iostream header in your application, the old iostream library will be linked by default. The following table lists all the header files that include <useoldio.h>.
Old iostream Headers
--------------------
FSTREAM.H IOMANIP.H
IOS.H IOSTREAM.H
ISTREAM.H OSTREAM.H
STDIOSTR.H STREAMB.H
STRSTREA.H
The header file <use_ansi.h> contains #pragma statements that force the Standard C++ Library to be linked in. All Standard C++ Headers include <use_ansi.h>. So if you include any Standard C++ header in your application, the Standard C++ library will be linked by default. The following table lists all the header files that include <use_ansi.h>.
Standard C++ Headers
--------------------------
ALGORITHM BITSET COMPLEX DEQUE
FSTREAM FUNCTIONAL IOMANIP IOS
IOSFWD IOSTREAM ISTREAM ITERATOR
LIMITS LIST LOCALE MAP
MEMORY NUMERIC OSTREAM QUEUE
SET SSTREAM STACK STDEXCEPT
STREAMBUF STRING STRSTREAM TYPEINFO
UTILITY VALARRAY VECTOR XIOSBASE
XLOCALE XLOCINFO XLOCMON XLOCNUM
XLOCTIME XMEMORY XSTRING XTREE
XUTILITY YMATH.H
You cannot mix calls to the old iostream library and the new Standard C++ Library in Visual C++ 4.2.
Summary Table
--------------------------
| Compile Old New IOStream Libraries |
| Option IOStream or STL Linked With |
|=========================
| /ML No No LIBC.LIB |
|-------------------------
| /MLd No No LIBCD.LIB |
|-------------------------
| /MT No No LIBCMT.LIB |
|-------------------------
| /MTd No No LIBCMTD.LIB |
|-------------------------
| /MD No No MSVCRT.LIB |
|-------------------------
| /MDd No No MSVCRTD.LIB |
|-------------------------
| /ML No Yes LIBC.LIB, LIBCP.LIB |
|-------------------------
| /MLd No Yes LIBCD.LIB, LIBCPD.LIB |
|-------------------------
| /MT No Yes LIBCMT.LIB, LIBCPMT.LIB |
|-------------------------
| /MTd No Yes LIBCMTD.LIB, LIBCPMTD.LIB |
|-------------------------
| /MD No Yes MSVCRT.LIB, MSVCPRT.LIB |
|-------------------------
| /MDd No Yes MSVCRTD.LIB, MSVCPRTD.LIB |
|-------------------------
| /ML Yes No LIBC.LIB, LIBCI.LIB |
|-------------------------
| /MLd Yes No LIBCD.LIB, LIBCID.LIB |
|-------------------------
| /MT Yes No LIBCMT.LIB, LIBCIMT.LIB |
|-------------------------
| /MTd Yes No LIBCMTD.LIB, LIBCIMTD.LIB |
|-------------------------
| /MD Yes No MSVCRT.LIB, MSVCIRT.LIB |
|-------------------------
| /MDd Yes No MSVCRTD.LIB, MSVCIRTD.LIB |
--------------------------
Summary Table for CRT DLLs Used
--------------------------
| Import Library DLLs Used DLLs Used |
| Linked With (VC 5.0|6.0) (VC 4.2) |
|=========================
| MSVCRT.LIB MSVCRT.DLL MSVCRT.DLL |
|-------------------------
| MSVCRTD.LIB MSVCRTD.DLL MSVCRTD.DLL |
|-------------------------
| MSVCPRT.LIB MSVCP5(5|6)0.DLL |
|-------------------------
| MSVCPRTD.LIB MSVCP5(5|6)0D.DLL |
|-------------------------
| MSVCIRT.LIB MSVCIRT.DLL MSVCIRT.DLL |
|-------------------------
| MSVCIRTD.LIB MSVCIRTD.DLL MSVCIRTD.DLL |
--------------------------
REFERENCES
For additional information, please see the following article in the Microsoft Knowledge Base: For additional information about , please see the following article(s) in the Microsoft Knowledge Base:
Q154419 Standard C++ Library Frequently Asked Questions
ASKER
Vin32,
I suspect that there is the problem too.
Sorry guys, I wasn't able to build the release version because of some other problems and I really don't have time to solve them now.
I'll read the article. Being under a lot of pressure, I switched over to MFC stuff (which I hate to do). I still want to figure this one out as I might bump into it sometime in the future.
I suspect that there is the problem too.
Sorry guys, I wasn't able to build the release version because of some other problems and I really don't have time to solve them now.
I'll read the article. Being under a lot of pressure, I switched over to MFC stuff (which I hate to do). I still want to figure this one out as I might bump into it sometime in the future.
ASKER
OK, I read the whole article but still couldn't figure out what in tarnation is going on. I run VC++ 6.0 and the compile option is /MDd (multithreaded .Dll in debug). It says in there that one cannot mix old iostream library with Standard C++ library in VC++ 4.2, but is this still the problem under version 6.0? I don't think so. Also they suggest that there is no difference between headers with ".h" and headers without it, but obviously that's not the case.
When I link <list> the compiler crashes; when <list.h> is included, there are no errors in compilation, but I still cannot use list<CAType> _myList because the compiler complains that the list type is unknown:
error C2501: 'list' : missing storage-class or type specifiers
I add
using namespace std;
and i get
error C2871: 'std' : does not exist or is not a namespace
Heck, I've seen this a hundred times so far.
list.h is a different header. I looked for old iostream headers, but could not found ones that would affect me
Old iostream Headers
--------------------
FSTREAM.H IOMANIP.H
IOS.H IOSTREAM.H
ISTREAM.H OSTREAM.H
STDIOSTR.H STREAMB.H
STRSTREA.H
The truth is (still) out there (somewhere)...
When I link <list> the compiler crashes; when <list.h> is included, there are no errors in compilation, but I still cannot use list<CAType> _myList because the compiler complains that the list type is unknown:
error C2501: 'list' : missing storage-class or type specifiers
I add
using namespace std;
and i get
error C2871: 'std' : does not exist or is not a namespace
Heck, I've seen this a hundred times so far.
list.h is a different header. I looked for old iostream headers, but could not found ones that would affect me
Old iostream Headers
--------------------
FSTREAM.H IOMANIP.H
IOS.H IOSTREAM.H
ISTREAM.H OSTREAM.H
STDIOSTR.H STREAMB.H
STRSTREA.H
The truth is (still) out there (somewhere)...
1. The article talks about VC++ 4.2 & 5.0, but yes it equally well applies to version 6.0 too. I have been working with 6.0.
2. The article does mention that there is a difference among the headers. Which is contradictory to what you have mentioned.
3. You said that you have the /MDd option. I have also used multithreading, but I use /MTd. At least when using the Standard C++ headers. I would suggest you try that.
Hope this helps.
Sorry about this ... please ignore point no. 3 in my last comment.
Could you please check whether this dll you are building is using some other components that have been compiled separately ?
The idea is that if you are using /MDd in the project, all other dlls/libs that this project depends on must also be built using the same option. Sometimes such non-compatibility can give trouble, too.
ASKER
I checked all dependencies and all of them use the same compile option. I didn't say my project is a .dll because it's not. It's a Win32 console application. It wasn't me who started it, it's just that I have to update it and extend it now. Since I'm very fond of STL I try to use it everywhere. Now with this project it doesn't work and that infuriates me. I can figure out how this project was constructed. You know how many options you have when using the AppWizard (MFC support, empty project, console application, etc.). I suspected for a while that one of these options doesn't include support for STL.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Well, you have previously commented this: "I run VC++ 6.0 and the compile option is /MDd (multithreaded .Dll in debug)." My reply was based on that.
In case you have a console app, you must be using /MTd and not /MDd as the compile option.
Anyway, that is nopt what the problem is about, so I'll come back to it.
1. mblat could be right about the include file sequence. Please do check that.
2. Also, please check if all your headers have proper macros defined to prevent multiple inclusion of headers
#ifndef HEADER_MACRO
#define HEADER_MACRO
#endif
There is a small chance that it might be due to a very minor coding error by missing out one of the #endif statements.
ASKER
Ok,
I managed to track down this sequence in the myriad of files and headers that are linked from other projects in my workspace. I did find a file with this sequence
#ifdef _DEBUG
// ...
(it was a .h though) and if I link <list> before that header, it works just fine.
Looking in the MSDN I found this to be described as a problem (Q143207) with the intent being by design.
Hmmmm...
The workaround described there (including <new.h> before the _DEBUG ifdef) works and now I can include <list> wherever I want and I can use the std namespace just like I used to.
Thank you for your help.
I managed to track down this sequence in the myriad of files and headers that are linked from other projects in my workspace. I did find a file with this sequence
#ifdef _DEBUG
// ...
(it was a .h though) and if I link <list> before that header, it works just fine.
Looking in the MSDN I found this to be described as a problem (Q143207) with the intent being by design.
Hmmmm...
The workaround described there (including <new.h> before the _DEBUG ifdef) works and now I can include <list> wherever I want and I can use the std namespace just like I used to.
Thank you for your help.
The latter insists on being the first header included in MFC files.