🚀 go-pugleaf

Hello,

I found what I think could be a bug in the implementation of the
standard template library, nethertheless I would like your opinion
in wether it *is* a bug or a feature.

This was tested on a Solaris (SunOs 5.5) machine with gcc 2.7.2.
Unfortunately, I have not the possibility to test this with another
compiler/machine combination.

Please try the following:

--- file test.cc ---

#include <vector.h>
#include "test.hh"

void main (void) {
   CSample sample1;
   CSample sample2;

   sample2 = sample1;

   // uses the default Csample::operator=(const Csample&)

   sample2.CSample(sample1);

   // uses the default copy constructor Csample::CSample(const Csample&)
}

--- file test.hh ---

#include <vector.h>

class CSample {
   int testint;
   unsigned char testchar;
   vector<long> vlong;
};

--------------------

Now, this is getting down to the basics of a bug that cost
me almost two days to narrow down to.

First, confirm my assumptions in test.cc:
(1) sample2 = sample1 will call the operator= of class CSample
(2) sample2.CSample(sample1) will call the copy constructor of class
CSample

Now, if someone tryed this already, the compiler will compile test.cc:
   g++ -g -c test.cc      (ok)

Trying to link the file will produce:
   g++ -o test test.o

Undefined                       first referenced
 symbol                             in file
__as__t6vector1ZlRCt6vector1Zl      test.o
ld: fatal: Symbol referencing errors. No output written to test


So the linker doesn't find a link symbol called *...vector...*.
Well, it turns out that if you remove declaration (1), the
operator= of the class CSample, that holds the vector<long>,
this error doesn't happen.

Please note that this error does not happen with the automatically
generated copy constructor of CSample.

Now, if I declare 
CSample::operator=(const CSample& x) {
  testint = x.testint;
  testchar = x.testchar;
  vlong = x.vlong;
};

and re-compile the project the error does not occur.

I reason the following:

(1)
the compiler *does* generate a standard operator= for the class
CSample (as it is supposed to do, a operator= that will copy
each element using its own operator=, am I right?), but
unfortunately it misses to generate some sort of vector
function (due to name mangling, I cannot tell the real name,
just the symbol name). I suppose it uses a wrong vector::operator=
function. Am I right here?

(2)
the same compiler-generated copy constructor (which to me does
almost the same as a operator= call) works fine, without having
to define it yourself.


Please correct my wrongs and let me know what you think about
my assumptions. 

best regards,


Christoph.

--
Christoph Moar (christoph.moar@mchp.siemens.de)  Tel. (++49) 89 636-44628
SIEMENS AG Corporate Research and Development    Fax. (++49) 89 636-47457
Central   Departement   Technics   -   Information  and  Communication  1
Office Adress:  SIEMENS AG  ZT IK 1,  Otto-Hahn-Ring  6,  D-81739  Munich
Postal Adress:  SIEMENS AG  ZT IK 1,  D-81730 Munich
***   PGP PUBLIC KEY AVAILABLE ON REQUEST & ON KEY SERVERS WORLDWIDE  ***