C++ 在头文件中包含 STL

Question

Is it a bad or a good idea to include STL within a header file? Wherein you use them as a member variable of your own defined class.

My assumption is, there are people who really wanted their created library to be very independent on C++ standard library. So they are forced to rewrite again a type similar to the functionality available in C++ STL while other's try to forward declare in their header file the type they will be needed later. Which is other's sees this as a bad practice and not a good idea at all.

Please correct me if I'm wrong (I don't know much that's why all is just an assumption):

1. So what are the effects in terms of code portability (for those who really wanted their code to be platform independent) when forward declaring a type available on STL ?(I only know of a type of vector as suggested by MSDN can be forward declared but not guaranteed to work at all times).

2. If I include the STL in my header file, what problem could exist? And will this affect the portability of my code?

3. What if I include STL in the header file of my DLL and bring that DLL in other computers, what problem could I encounter?

4. And, can you give me an enlightenment why I should (should not) include STL in my header?

Answer 1

Use PIMPL idiom to create a compilation firewall on headers that expose / export STL types : Details

class MyList{
public:
//Some functions
private:
std::vector<int> _content;
};

If you create MyList in Vs2012 but the component is built in VS2008, then the code inside VS2008 will expect the memory layout as per STL 2008 but the layout will be that of STL 2012. This will create a whole host of issues.

1. Your component will not be portable across compilers let alone platforms. A component built in VS2008 using std::vector as a member variable will have a different size to the same compiled in VS2012 for example.
2. Yes, your code will be compatible across compilers in most scenarios except when you are using features of STL that is more up to date in older versions.
3. No problem as long as you have the runtime for the dll in the other computer.
4. You should not have stl types across dll/component boundaries for reusable code.

Answer 2

So what are the effects in terms of code portability (for those who really wanted their code to be platform independent) when forward declaring a type available on STL ?

Using standard C++ and the standard libraries at all times is the hallmark of portability.

If I include the STL in my header file, what problem could exist? And will this affect the portability of my code?

Longer compile time perhaps? And again, see the above answer.

What if I include STL in the header file of my DLL and bring that DLL in other computers, what problem could I encounter?

Mostly and AFAIK, DLLs only "store" the method definitions of your classes. You still need to include the STL headers in your .h files.

And, can you give me an enlightenment why I should (should not) include STL in my header?

You should, because you almost always want to use STL. Come to Lounge<C++> and you'll sure be enlightened.

Answer 3

If you are using Standard C++ STL library then you may not have porting issues as both Microsoft Visual C++ and g++ support these. Unless you you non standard STL headers then you will have issues.

Answer 4

Avoid STL in headers at all costs:

1. STL is full of implementation details. Leave that to source code.
2. Headers are your API, you only want to be exposing functions, structs and interfaces.
3. You may want to compile and link libraries in different modes - that leads to cross module errors if you are say allocating in debug and deleting memory in release. So do not use std::string to pass information across the API.
4. One you start to include just one header from STL you will find other modules start to leak in. You will end up with STL poisoning everything, no real interface and build times in minutes when it should be in seconds.

How would STL improve the following API? Consumers of IDog do not need to know the internal structure of a dog, only that it barks.

struct IDog
{
     virtual void Bark() = 0;
     virtual void Free() = 0;
}

IDog* CreateDog(); 

In your source code you might have

struct Dog: IDog
{
    Dog() {...}
    std::vector<VocalChord> vocalChords; 
    void Bark() override { Resonate(vocalChords); }
    void Free() { delete this; }
};

IDog* CreateDog() { return new Dog(); }