Re: basic_string linking related problem

Re: basic_string linking related problem

[Benjamin Kosnik]

... your link error is coming from an instantiation of
char_traits<unsigned char>. This instantiation is not specified in the
C++ standard. Furthermore, using basic types to specialize standard
components, instead of user-defined types, is not legal.

It is, however, a seemingly well-established practice. 

There has been a lot of discussion of this, mostly on Fridays during the
last two months on the libstdc++ list. If you search for this, you'll
find workarounds.

Perhaps char_traits specializations should be added for basic types.

-benjamin 

Re: basic_string linking related problem

[Karel Gardas]

On Wed, 9 Oct 2002, Benjamin Kosnik wrote:

> ... your link error is coming from an instantiation of
> char_traits<unsigned char>. This instantiation is not specified in the
> C++ standard. Furthermore, using basic types to specialize standard
> components, instead of user-defined types, is not legal.
>

OK, so I don't need to report anything into GNATS.

> It is, however, a seemingly well-established practice.
>
> There has been a lot of discussion of this, mostly on Fridays during the
> last two months on the libstdc++ list. If you search for this, you'll
> find workarounds.
>

I'll look at it.

Thanks,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

basic_string linking related problem.

[Karel Gardas]

Hello,

one of third party libraries which we are using for our project suffers
from linking problems with some unresolved symbols. I've tracked it down
to following code:

//
//snacc_basic_string_problem.cc
//
//#include <string.h>

//#include <iostream>
//#include <stdlib.h>
//#include <stdio.h>  // maybe

#include <iostream>
//#include <string.h>

int
main()
{
    std::basic_string<unsigned char> bytes;
    for (unsigned char i=0; i<255; i++) {
	bytes += i;
    }
    long len = bytes.length();
    const unsigned char* data = bytes.data();
    std::cerr << "len: " << len << std::endl;
    std::cerr << "data: " << data << std::endl;
}

Please try to compile and link it. It compiles well here, but linker
complains with unresolved symbols:

thinkpad:~/mujprog/c-cc/tests/gcc321$ c++ snacc_basic_string_problem.cc
/tmp/ccRiR23T.o: In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::replace(__gnu_cxx::__normal_iterator<unsigned char*, std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> > >, unsigned, unsigned char)':
/tmp/ccRiR23T.o(.gnu.linkonce.t._ZNSbIhSt11char_traitsIhESaIhEE7replaceEN9__gnu_cxx17__normal_iteratorIPhS2_EES6_jh+0xc3): undefined reference to `std::char_traits<unsigned char>::assign(unsigned char*, unsigned, unsigned char)'
/tmp/ccRiR23T.o: In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::_Rep::_M_clone(std::allocator<unsigned char> const&, unsigned)':
/tmp/ccRiR23T.o(.gnu.linkonce.t._ZNSbIhSt11char_traitsIhESaIhEE4_Rep8_M_cloneERKS1_j+0xb1): undefined reference to `std::char_traits<unsigned char>::copy(unsigned char*, unsigned char const*, unsigned)'
/tmp/ccRiR23T.o: In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::_M_mutate(unsigned, unsigned, unsigned)':
/tmp/ccRiR23T.o(.gnu.linkonce.t._ZNSbIhSt11char_traitsIhESaIhEE9_M_mutateEjjj+0x13b): undefined reference to `std::char_traits<unsigned char>::copy(unsigned char*, unsigned char const*, unsigned)'
/tmp/ccRiR23T.o(.gnu.linkonce.t._ZNSbIhSt11char_traitsIhESaIhEE9_M_mutateEjjj+0x16c): undefined reference to `std::char_traits<unsigned char>::copy(unsigned char*, unsigned char const*, unsigned)'
/tmp/ccRiR23T.o(.gnu.linkonce.t._ZNSbIhSt11char_traitsIhESaIhEE9_M_mutateEjjj+0x274): undefined reference to `std::char_traits<unsigned char>::move(unsigned char*, unsigned char const*, unsigned)'
collect2: ld returned 1 exit status
You have mail in /var/mail/karel
thinkpad:~/mujprog/c-cc/tests/gcc321$


I don't know if it's legal to use basic_string in user code. If it is,
then it's a bug somewhere and I'll submit it into GNATS. What I need and
main reason for asking here is: is the code above legal?

Compiler used is:

thinkpad:~/mujprog/c-cc/tests/gcc321$ c++ -v
Reading specs from
/home/karel/usr/local/gcc3.2.x/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs
Configured with: /home/karel/cvs/gcc/gcc3.2/configure
--prefix=/home/karel/usr/local/gcc3.2.x --enable-shared --enable-threads
--enable-languages=c++ --program-prefix=a --enable-__cxa_atexit
Thread model: posix
gcc version 3.2.1 20021007 (prerelease)
thinkpad:~/mujprog/c-cc/tests/gcc321$

I've got these errors with using gcc3.2 too:

thinkpad:~/usr/src/getronics/SNACC/c++-lib/src$ c++ -v
Reading specs from
/home/karel/usr/local/gcc3.2/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
Configured with: ../../gcc3.2/configure
--prefix=/home/karel/usr/local/gcc3.2 --enable-languages=c++,objc
--program-prefix=a --enable-__cxa_atexit
Thread model: posix
gcc version 3.2
thinkpad:~/usr/src/getronics/SNACC/c++-lib/src$


The interesting is that this program compiles/links well with using gcc
3.1.1 - so from this point of view - this is a regression in gcc3.2/3.2.1

thinkpad:~/mujprog/c-cc/tests/gcc321$ c++ -v
Reading specs from
/home/karel/usr/local/gcc3.1.1cxa_atexit/lib/gcc-lib/i686-pc-linux-gnu/3.1.1/specs
Configured with: /home/karel/cvs/gcc/gcc3.1/configure
--prefix=/home/karel/usr/local/gcc3.1.1cxa_atexit --enable-shared
--enable-threads --enable-languages=c++ --program-prefix=a
--enable-__cxa_atexit
Thread model: posix
gcc version 3.1.1
thinkpad:~/mujprog/c-cc/tests/gcc321$ c++ snacc_basic_string_problem.cc
thinkpad:~/mujprog/c-cc/tests/gcc321$ ./a.out
len: 255
data:
thinkpad:~/mujprog/c-cc/tests/gcc321$
thinkpad:~/mujprog/c-cc/tests/gcc321$


I'm waiting for confirmation that this is really bug, and then I'll submit
it into gnats.

Thanks a lot,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com