incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (STDCXX-152) error instantiating std::map on an incomplete type
Date Mon, 20 Feb 2006 21:14:27 GMT
    [ http://issues.apache.org/jira/browse/STDCXX-152?page=comments#action_12367079 ] 

Martin Sebor commented on STDCXX-152:
-------------------------------------

Copied from Rogue Wave QA incident #24464:

****Created By: sebor @ Jan 10, 2001 04:58:50 PM****
Subject: Re: Error 239: A class/union shall not contain a member with incomplete type.
Date: Wed, 10 Jan 2001 11:58:48 -0800
From: Alain Miniussi <alainm@cup.hp.com>
Organization: HP
To: Martin Sebor <sebor@roguewave.com>
CC: barry@uksr.hp.com, Dennis Handly <dhandly@cup.hp.com>
References: 1

Martin, I wonder if you already had to deal with that issue, and
what you think about it.

Barry Levie wrote:
>
> Alain,
> Dennis suggested that you might be able to help. I have included a copy
> of the previous emails to save you having to search back through the
> acxx mail messages.
>
> Thanks
>
> Barry
>
> Hi,
>
> I wonder if some one could be so kind as to improve on and confirm my
> answer that this is a user error. (Of course I may have got it wrong.
> :-))

That's a tricky question :-)

First, the problem is the
set<X>::iterator f();

that requires instantiation of set<X>, to illustrate the problem:
----------------------
// case 1:
template<class T>
struct Cont1 {
   T* t;
   typedef int iter;
};

struct Str1 {
   Cont1<Str1>::iter f();
};

// case 2:
template<class T>
struct Cont2 {
   T t;
   typedef int iter;
};

struct Str2 {
   Cont2<Str2>::iter f();
};

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

where Cont<n> and Str<n> stands for set and X respectively.

Str1 is ok since Cont1 does not need a completly defined T,
Str2 is not since it requires a completely defined T.

Now, the library can (but are they allowed to ?) choose to
implement set and  set::iterator so that it looks like 1 or 2.

All compiler agree that 1 is good and 2 is bad, but some libraies
manage to implement set like 1. RW seems to implement it as in
2 (ie, instantiating set<X> requires a complete X).

Martin, can you confirm that this explanation is correct, and tell
if it is a known issue ? or if the standard tells something about it ?

Thanks,

Alain

> Thanks
>
> Barry
>
>  A.03.30
>
> $ more fii.c
> #include <set>
>
> class Y  {
> };
> class X {
>   X():mep(new set<X>()),me(*mep){}
>   set<X>::iterator f();
>   set<X> *mep;
>   set<X>  &me;
> };
>
> Error 239: "/opt/aCC/include/tree", line 140 # A class/union shall not
> contain
>     a member with incomplete type.
>             Value        value_field;
>                          ^^^^^^^^^^^
> Error 239: "/opt/aCC/include/tree", line 140 # A class/union shall not
> contain
>     a member with incomplete type.
>             Value        value_field;
>                          ^^^^^^^^^^^
> Error 537: "/opt/aCC/include/tree", line 140 # Cannot create a 'X'
> object;
>     class X has only been seen as an incomplete declaration.
>             Value        value_field;
>                          ^^^^^^^^^^^
>
> I believe that despite the fact that it compiles with gcc 2.9 its a user
>
> error.
>
> Due to
> http://www.hp.com/esy/lang/cpp/tguide/index.html
> 3.4.33 Templates - Declaring a Variable of an Incomplete Type Disallowed
>
> and the fact that
>
> The ansi standard describes the point of instantiation.
> "14.6.4.1(3) says the point of instantiation  immediately precedes the
> declaration or definition that refers to the specialization."
>
> My example seemed more straight forward.
>
> #include <set>
> using namespace std;
>
> #ifdef USERERROR
> class Y ;
> #else
> class Y{};
> #endif
> class X {
> typedef set<Y, less<Y>, allocator<Y> > set_type;
> set_type   sd;
> set_type::iterator sdi ;
>
> };
>
> ======================================================
> Dennis Handly wrote:
> >I wonder if some one could be so kind as to improve on and confirm my
> >answer that this is a user error.
> Barry
>
> I think the compiler is correct.
> You can't use X inside itself unless a pointer, or used in a static
> data member.
>
> #include <set>
> class X {
>   X() : mep(new set<X>),me(*mep){}
>   set<X>::iterator f();
>   set<X> *mep;
>   set<X> &me;
> };
>
> Even -AA fails the same way.
>
> >My example seemed more straight forward.
>
> And pretty obvious.
>
> ============================================================
> Sorry I am back again on this topic.
>
> Dennis Handly wrote:
>
> ....
>
> >
> > I think the compiler is correct.
> > You can't use X inside itself unless a pointer, or used in a static
> > data member.
> >
> > #include <set>
> > class X {
> >   X() : mep(new set<X>),me(*mep){}
> >   set<X>::iterator f();
> >   set<X> *mep;
> >   set<X> &me;
> > };
> >
> > Even -AA fails the same way.
>
> It seems that in rb_tree gcc uses a template for  _Rb_tree_node while RW
>
> uses a struct which is why it compiles ok with gcc. The customer says
> his
> third party STL compiles ok with our aCC compiler, so guess this could
> be
> for the same reason.
> Is it worth raising a ER or do we just put this down to an
> implementation
> difference.
>
> Regards
>
> Barry
>
> gcc
>
> template <class _Key, class _Compare = less<_Key>,
>           class _Alloc = allocator< _Key >  >
>
> template <class _Key, class _Value, class _KeyOfValue, class _Compare,
>           class _Alloc = allocator< _Value >  >
> class _Rb_tree : protected _Rb_tree_base<_Value, _Alloc> {
>   typedef _Rb_tree_base<_Value, _Alloc> _Base;
> protected:
>   typedef _Rb_tree_node_base* _Base_ptr;
>   typedef _Rb_tree_node<_Value> _Rb_tree_node;
> .....
>
> template <class _Value>
> struct _Rb_tree_node : public _Rb_tree_node_base
> {
>   typedef _Rb_tree_node<_Value>* _Link_type;
>   _Value _M_value_field;
> }
>
> and with RW we have
>
> template <class Key, class Value, class KeyOfValue,
>  class Compare, class Allocator>
> class rb_tree
>  {
> ...
> struct rb_tree_node
>  {
> ...
>  Value value_field;
>  };
>
> ============================================================
>
> Dennis Handly wrote:
> > I think the compiler is correct.
> > You can't use X inside itself unless a pointer, or used in a static
> > data member.
> > #include <set>
> > class X {
> >   X() : mep(new set<X>),me(*mep){}
> >   set<X>::iterator f();
> >   set<X> *mep;
> >   set<X> &me;
> > };
>
> >It seems that in rb_tree gcc uses a template for _Rb_tree_node while RW
>
> >uses a struct which is why it compiles ok with gcc. The customer says
> his
> >third party STL compiles ok with our aCC compiler, so guess this could
> be
> >for the same reason.
>
> I'm not sure why it makes a difference.
>
> >Is it worth raising a ER or do we just put this down to an
> implementation
> >difference.
> Barry
>
> Let Alain look at it when he gets back.
>
> Perhaps we don't handle 14.6.4.1(1) (last sentence) right.
> I.e. is the point of instantiation the place in namespace scope after
> the use of the "me" reference, which would be after class X??
>
> =====================================================
> gcc
> template <class _Key, class _Compare = less<_Key>,
>           class _Alloc = allocator<_Key > >
> template <class _Key, class _Value, class _KeyOfValue, class _Compare,
>           class _Alloc = allocator<_Value > >
> class _Rb_tree : protected _Rb_tree_base<_Value, _Alloc> {
>   typedef _Rb_tree_base<_Value, _Alloc> _Base;
> protected:
>   typedef _Rb_tree_node_base* _Base_ptr;
>   typedef _Rb_tree_node<_Value> _Rb_tree_node;
> .....
>
> template <class _Value>
> struct _Rb_tree_node : public _Rb_tree_node_base {
>   typedef _Rb_tree_node<_Value>* _Link_type;
>   _Value _M_value_field;
> }
>
> and with RW we have
> template <class Key, class Value, class KeyOfValue,
>  class Compare, class Allocator>
> class rb_tree {
> ...
> struct rb_tree_node {
> ...
>  Value value_field;
>  };
****Modified By: sebor @ Jan 10, 2001 05:02:21 PM****
Subject: Re: Error 239: A class/union shall not contain a member with incomplete type.
Date: Wed, 10 Jan 2001 17:01:48 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
To: Alain Miniussi <alainm@cup.hp.com>
CC: barry@uksr.hp.com, Dennis Handly <dhandly@cup.hp.com>
References: 1 , 2

Alain Miniussi wrote:
>
> Martin, I wonder if you already had to deal with that issue, and
> what you think about it.

I've seen the question(s) on cxx-dev but I don't really consider it to be a
defect in the library. The implementation is perhaps less robust than it could
be (due to the fact that __rb_tree<> refers to __rw_rb_tree_node<>::_C_link_t
and that __rw_rb_tree_node<> contains as a member a value of the incomplete
type). <continue below>

...
> > I wonder if some one could be so kind as to improve on and confirm my
> > answer that this is a user error. (Of course I may have got it wrong.
> > :-))
>
> That's a tricky question :-)
>
> First, the problem is the
> set<X>::iterator f();
>
> that requires instantiation of set<X>, to illustrate the problem:
> ----------------------
> // case 1:
> template<class T>
> struct Cont1 {
>     T* t;
>     typedef int iter;
> };
>
> struct Str1 {
>     Cont1<Str1>::iter f();
> };
>
> // case 2:
> template<class T>
> struct Cont2 {
>     T t;
>     typedef int iter;
> };
>
> struct Str2 {
>     Cont2<Str2>::iter f();
> };
>
> -----------------------
>
> where Cont<n> and Str<n> stands for set and X respectively.
>
> Str1 is ok since Cont1 does not need a completly defined T,
> Str2 is not since it requires a completely defined T.
>
> Now, the library can (but are they allowed to ?) choose to
> implement set and  set::iterator so that it looks like 1 or 2.
>
> All compiler agree that 1 is good and 2 is bad, but some libraies
> manage to implement set like 1. RW seems to implement it as in
> 2 (ie, instantiating set<X> requires a complete X).
>
> Martin, can you confirm that this explanation is correct, and tell
> if it is a known issue ? or if the standard tells something about it ?

Yes, I think the example illustrates what's happening here. 17.4.3.6
[lib.res.on.functions], p2 enumerates library cases with undefined behavior:

-2- In particular, the effects are undefined in the following cases:
...
-if an incomplete type (basic.types) is used as a template argument when
instantiating a template component.

I think it should be possible to implement the containers such that your example
compiles but I have a feeling that the change might have an effect on the ABI of
the library (not the binary itself, but perhaps the binary of some 3rd party
library that instantiates __rb_tree).

I have created a PR #24464. It might get addressed in the next major release of
the library.

Regards
Martin


> error instantiating std::map on an incomplete type
> --------------------------------------------------
>
>          Key: STDCXX-152
>          URL: http://issues.apache.org/jira/browse/STDCXX-152
>      Project: C++ Standard Library
>         Type: Improvement
>   Components: 23. Containers
>     Versions: 4.1.2, 4.1.3
>  Environment: all
>     Reporter: Martin Sebor

>
> From http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-user/200602.mbox/%3c20060215231134.6717.qmail@web82211.mail.mud.yahoo.com%3e:
>   I am trying to use Boost built using stdcxx on Solaris. I was able to build the date_time
> library but when I try to compile a test program I end up with errors related to incomplete
> types. I have narrowed the issue to the following code
>    
>   #include <map>
> #include <string>
>   using namespace std;
>   template <class T>
> struct C {
>      typedef multimap<T,C> maps;
>      typedef typename maps::value_type value_type;
> };
>    
>   int main () {
>   C<std::string> c;
> }
>   When I compile using the default Sun CC libraries or rwtools7_std or stlport4, the
code
> compiles fine. But when I compile using stdcxx, I end up with the following errors.
>    
>   "/opt/idev3/dbapatla/apache-stdcxx-4.1.3/include/rw/_pair.h", line 55: Error: In this
declaration
> "second" is of an incomplete type "C<std::string>".
> "/opt/idev3/dbapatla/apache-stdcxx-4.1.3/include/rw/_tree.h", line 86:     Where: While
specializing
> "std::pair<const std::string, C<std::string>>".
> "/opt/idev3/dbapatla/apache-stdcxx-4.1.3/include/rw/_tree.h", line 86:     Where: Specialized
> in __rw::__rw_rb_tree_node<std::allocator<std::pair<const std::string, C<std::string>>>,
> std::pair<const std::string, C<std::string>>, std::string, __rw::__select1st<std::pair<const
> std::string, C<std::string>>, std::string>>.
> "/opt/idev3/dbapatla/apache-stdcxx-4.1.3/include/rw/_tree.h", line 259:     Where: Specialized
> in __rw::__rb_tree<std::string, std::pair<const std::string, C<std::string>>,
> __rw::__select1st<std::pair<const std::string, C<std::string>>, std::string>,
> std::less<std::string>, std::allocator<std::pair<const std::string, C<std::string>>>>.
> "/opt/idev3/dbapatla/apache-stdcxx-4.1.3/include/map", line 323:     Where: Specialized
in
> std::multimap<std::string, C<std::string>, std::less<std::string>, std::allocator<std::pair<const
> std::string, C<std::string>>>>.
> "test2.cpp", line 9:     Where: Specialized in C<std::string>.
> "test2.cpp", line 13:     Where: Specialized in non-template code.
> 1 Error(s) detected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message