#147 Container pointer specialization feature fails to compile

5.1
closed
5
2007-09-30
2007-09-20
No

Hi. The following problem is indicated in both 5.1.3 and 5.1 HEAD of the repository. When the pointer specialization optimization for containers is turned on (_STLP_USE_PTR_SPECIALIZATIONS defined) the code like this does not compile:

#include <vector>

struct A
{
std::vector< A > m_vec;
};

The output is:

lastique@linux-lastique:~> c++ -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=-4.1 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)
lastique@linux-lastique:~> c++ -I ./STLPort/stlport -L ./STLPort/lib -lstlport_gcc 1.cpp
./STLPort/stlport/stl/pointers/_tools.h: In instantiation of ‘stlp_priv::_StorageType<A>’:
./STLPort/stlport/stl/pointers/_vector.h:53: instantiated from ‘stlp_std::vector<A, stlp_std::allocator<A> >’
1.cpp:5: instantiated from here
./STLPort/stlport/stl/pointers/_tools.h:79: error: invalid use of undefined type ‘struct A’
1.cpp:4: error: forward declaration of ‘struct A’
./STLPort/stlport/stl/pointers/_tools.h:80: error: invalid use of undefined type ‘struct A’
1.cpp:4: error: forward declaration of ‘struct A’
./STLPort/stlport/stl/pointers/_tools.h:81: error: invalid use of undefined type ‘struct A’
1.cpp:4: error: forward declaration of ‘struct A’
./STLPort/stlport/stl/pointers/_tools.h:82: error: invalid use of undefined type ‘struct A’
1.cpp:4: error: forward declaration of ‘struct A’

The problem is that A is not defined at the point of the vector instantiation, but the latter (_StorageType, to be more specific) uses it in the context that requires it to be defined (a function call with a temporary of type A as an argument in the sizeof expression).

I have a solution for compilers with partial template specialization support (see patch attached), that was sufficient for me. But I haven't thought much of the solution for deficient compilers.

Discussion

  • Andrey Semashev

    Andrey Semashev - 2007-09-20

    The patch with a fix

     
  • Francois Dumont

    Francois Dumont - 2007-09-20

    Logged In: YES
    user_id=1096600
    Originator: NO

    Thanks, I will take care of it asap but only in trunk for next major release (5.2)

     
  • Francois Dumont

    Francois Dumont - 2007-09-20
    • assigned_to: nobody --> dums
     
  • Andrey Semashev

    Andrey Semashev - 2007-09-21

    Logged In: YES
    user_id=1819621
    Originator: YES

    Why not 5.1 branch? The patch is for 5.1 anyway.

     
  • Ulrich Eckhardt

    Ulrich Eckhardt - 2007-09-21

    Logged In: YES
    user_id=1522877
    Originator: NO

    The reason for why not in the 5.1.x release is simple, we want to push out a new release really soon now(tm), and the patch you suggest would add a new feature that would require testing things over again.

    BTW: instantiating vector (or pretty much anything from the C++ stdlib) on an incomplete type is undefined behaviour. That means that firstly it is not really a bug in STLport and secondly it means that your code becomes non-portable if you use it. I just wanted to point out this fact for the record and to avoid misunderstandings.

    cheers

    Uli

     
  • Francois Dumont

    Francois Dumont - 2007-09-28

    Logged In: YES
    user_id=1096600
    Originator: NO

    As promise, I have done a fix in trunk, you are welcome to test it. I haven't use your patch as using __type_traits might also require one day type to be completely defined with compilers having intrinsic type traits support.

     
  • Francois Dumont

    Francois Dumont - 2007-09-28
    • status: open --> pending
     
  • Andrey Semashev

    Andrey Semashev - 2007-09-29

    Logged In: YES
    user_id=1819621
    Originator: YES

    The original test example works for me. Will there be a unit test?

     
  • Andrey Semashev

    Andrey Semashev - 2007-09-29
    • status: pending --> open
     
  • Francois Dumont

    Francois Dumont - 2007-09-30

    Logged In: YES
    user_id=1096600
    Originator: NO

    A unit test for incomplete types ? There are already several because this problem is not specific to the pointer specialization feature. STLport use, when possible, compiler native type traits support, this suppose that types are completely defined when the feature is used. Look for IncompleteClass key word in unit tests.

    Your issue was known and simply consider as a limitation. Moreover the pointer specialization feature is not tested very often because it is an optional feature, I have to think about it to test it.

     
  • Francois Dumont

    Francois Dumont - 2007-09-30
    • status: open --> closed
     
  • Andrey Semashev

    Andrey Semashev - 2007-10-01

    Logged In: YES
    user_id=1819621
    Originator: YES

    But you said the feature doesn't use type traits so it won't break when compiler intrinsics are used. I found checks similar to what I'd posted here but they are flushed out by #if !defined(_STLP_USE_PTR_SPECIALIZATIONS). It would be sufficient to remove these conditions or replace them by checking for partial specialization compiler support (depending on whether you want it to show failure on deficient compilers or not).

    According to my vision of it, every feature, including optional ones, should be tested. STLport is a very wide spread and popular piece of software, so reliability should be one of the key features of it. As of this particular case, I think the test would be rather useful since it may catch errors that may appear in the code later. The case that triggered the topic, like the case in unit tests with IncompleteClass, is a quite often use case of STL containers, and I would like to see it tested. I come again, it's only my vision.

     

Log in to post a comment.