   How to extern a vector?
  I have two cpp files. In the main cpp I create a vector...//main.cppstd::vector< int > myVec;...In the second cpp I 'tell' it about this vector via extern...//other.cppextern std::vector< int > myVec;...Everything works fine up to this point, no errors or anything. However, if I try and do ANYTHING with the vector inside 'other.cpp' I get the following error ->: error LNK2001: unresolved external symbol "class std::vector<int,class std::allocator<int> > myVec" (?myVec@@3V?$vector@HV?$allocator@H@std@@@std@@A)This 'extern trick' works great with all other data types (ints, floats, even custom structs). Why wont it work with vectors?   
  Inside main.cpp, are you sure you have the std::vector<int> myVec outside of any class or function definitions?   ;  Well, it is in a HEADER, but no its not inside any definition*WOW thats CRAP! Sure enough its because its in a header... wtf? Why does it work if myVec is declared inside main.cpp, but NOT if myVec is declared in a HEADER thats attached to main.cpp?There has to be away to get this to work when myVec is declared in a header...   ;  In your original post you said it was in main.cpp, not a header. So which is it?   ;  See my post above, it IS in a header*Edit Wait, nm! Looks like it DOES work from a header. lol my mistake[Edited by - ZealousEngine on July 26, 2006 7:30:45 PM];Quote:Original post by ZealousEngineSee my post above, it IS in a header*Edit Wait, nm! Looks like it DOES work from a header. lol my mistakeWell, it shouldn't.  Not at least if more than one .cpp file includes that header (directly or indirectly).  Variable definitions should never go in headers.The reason is this:  When build your code, there are two primary steps, compiling and linking.  When compiling, each .cpp file is compiled one at a time, independently.  The .cpp file is altered by forcibly inserting all the files that it includes straight into the file, at the locations where those files are included.  This creates one single file that contains all the content from the .cpp file and all the .h files that it directly or indirectly includes.  This is compiled into an object file.  You'll end up with one object file per .cpp file.  Then the linker comes along, links all the different object files together, and creates one final .exe (or .dll, et cetera).Here is what happens when you define a variable in a header:  Each translation unit (also called a compilation unit, and it corresponds with each .cpp file) that includes that header ends up reserving a chunk of memory to represent that variable.  Remember, all the includes get blindly inserted into the .cpp file, and the whole thing is compiled.  The compiler has no way of knowing that a particular .h file "belongs" to a particular .cpp file, and thus the variable should only be created in one translation unit.  The problem is that when the linker tries to link everything together, it doesn't know which variable to use.  They all have the same name, so it complains about multiple definitions.When you use the extern keyword, you're basically telling the compiler, "Hey, there is a variable of this type and this name defined somewhere.  We don't care where at the moment (it might even exist in the current translation unit), just compile assuming that it exists somewhere."  Then, when the linker comes along, it thinks, "Hey, looky here.  We have a reference to some variable with a particular name, but it's not the variable itself, just an as-yet unattached reference.  Let's look in all the translation units and see if we can find it...  Yup, here it is.  I'll make a link to it."Does that help explain why you might have been having problems before, and why you should use the extern keyword to begin with?  I have found that understanding the build process in C/C++ often clears up a lot of confusions that people (most definitely including myself at one point) have regarding .cpp files, .h files, inline functions, template functions, linker errors, and so forth.  Once you know what the compiler and linker are doing, the solutions to many problems become quite obvious.   