C++ newbie gets linking error
Hi,
I am writing my first C++ programs (been a SQL/DB programmer for last 10 years) on Sun Solaris. Here is my source code:
#include <list>
#include <string>
#include <iostream.h>
using namespace std;// You must use this to include STL!
int main()
{
// Create list instances
list<int> list1; // Empty list
size_t n = 10;
double val = 3.14;
list<double> list2(n, val);// Create n copies of val
list<double> list3(list2);// Create a copy of list2
cout << "Size of list1 " << list1.size() << endl;
cout << "Size of list2 " << list2.size() << endl;
cout << "Size of list3 " << list3.size() << endl;
// We iterate over the elements of list 3 and print its elements
// Create list iterator
list<double>::const_iterator i;
// Print every character in the list
for (i = list2.begin(); i != list2.end(); ++i)
{
cout << *i << ",";
}
}
and getting the following linker error:
/SUNWspro/9.0/exec/SUNWspro/bin/CC -o test test.cpp
Undefinedfirst referenced
symbolin file
std::bad_alloc::bad_alloc()test.o
void*operator new(unsigned,void*) test.o
ld: fatal: Symbol referencing errors. No output written to test
I have heard of Solaris C++ compilers having problem with the use of templates..... is this the problem here or am I just missing some arguments/libraries?
Thx in advance!
[1603 byte] By [
cougar91] at [2007-11-26 9:44:10]

# 1
You have not installed the required Solaris C++ Runtime Library patch. Your system has an old version of the C++ system libraries in /usr/lib, and they need to be updated.
You can get all current patches for Sun Studio from the patch page:
http://developers.sun.com/prodtech/cc/downloads/patches/index.jsp
Install all of the Solaris patches for the version of Solaris you are running on.
While you are at it, it would be a good idea to get the current patches for Sun Studio itself.
BTW, the comment
using namespace std; // You must use this to include STL!
is not correct.
In production code, the recommended way to use elements of the C++ standard library is to qualify uses of those elements with "std::", or to add individual "using" declarations. The "using namespace std;" directive pulls everything in the standard library into the global namespace, which can lead to collisions with names you declare.
For toy programs while learing C++, the directive is less likely to cause problems, but starting with good programming practices is always a good idea. This sample program can be modified to avoid "using namespace std;" by replacing that line with these two lines:
using std::list;
using std::cout;
# 2
I tried to compile your code, it works fine. About symbols, indeed they are part of standard library.I'm not sure, if you have applied the patches for Compilers, linkers and System or not.
In such case, you may get them from following website;
http://developers.sun.com/prodtech/cc/downloads/patches
# 4
In the interest of keeping code examples short and simple, textbook authors do things in their code examples that are not suitable for real-world applications. Apart from "using namespace std", you find global variables and functions with short names, and no attention paid to error detection or recovery. (They also use more explanatory comments in the code than a real-world program should have.)
That's OK when you are illustrating particular language points. You want to highlight the point, and not have a lot of distractions. But in my view, not enough authors go on to explain good programming practice, and show realistic examples.
For the case in point, the Standard Library declares thousands of names. They are in namespace std to help avoid collisions with user-defined names. Once you put "using namespace std" into your code, you import all of those names into the global namespace, creating opportunities not only for compiler complaints due to name collisions, but for subtle errors involving binding symbols to the standard library that you expected to refer to your own definitions.
I *never* write "using namespace std" in real code. I sometimes use it when creating tiny test cases for bug reports. But as you saw in my earlier comments, the difference in the sample program between a dangerous programming practice and a much better programming practice was one line of code!