>Number: 10783 >Category: libstdc++ >Synopsis: std::vector::reverse_iterator could be smaller >Confidential: no >Severity: non-critical >Priority: medium >Responsible: unassigned >State: open >Class: pessimizes-code >Submitter-Id: net >Arrival-Date: Wed May 14 15:46:00 UTC 2003 >Closed-Date: >Last-Modified: >Originator: Sylvain Pion >Release: 3.2, 3.3, 3.4 (2.95 doesn't have the problem, I don't have 3.[01]) >Organization: >Environment: Reading specs from ./GCC/Linux-3.2/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.2.3/specs Configured with: ../gcc-3.2/configure --prefix=/home/spion/GCC/Linux-3.2 --enable-languages=c++ Thread model: posix gcc version 3.2.3 >Description: On my 32bit machine, sizeof(std::vector<>::reverse_iterator) is 8. Similarly for std::vector<>::const_reverse_iterator. All other iterators from the STL containers (except deque) have sizeof 4. I believe it could be made also 4 bytes if the empty base class optimization applied, but it seems it doesn't. Is it because there are 2 derivations from the same iterator<...> class ? Is there a way to fix it ? >How-To-Repeat: #include <iostream> #include <vector> int main() { typedef std::vector<int> V; std::cout << "sizeof(iterator) = " << sizeof(V::iterator) << std::endl; std::cout << "sizeof(reverse_iterator) = " << sizeof(V::reverse_iterator) << std::endl; } >Fix: >Release-Note: >Audit-Trail: >Unformatted:
Synopsis: std::vector::reverse_iterator could be smaller State-Changed-From-To: open->analyzed State-Changed-By: paolo State-Changed-When: Sun May 18 18:48:45 2003 State-Changed-Why: Hi. Interesting issue. For sure, a basic understanding of EBCO (see, f.i., Vandevoorde and Josuttis, 16.2) doesn't suffice to completely explain what's going on. Indeed, wrt v2 (as shipped with 2.95.x), reverse_iterator has an _Iterator member but also inherit from iterator (as _mandated_ by the standard). Nathan, could you please shed light on this? Thanks, Paolo. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10783
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 975 bytes --] The following reply was made to PR libstdc++/10783; it has been noted by GNATS. From: Paolo Carlini <pcarlini@unitus.it> To: gcc-prs@gcc.gnu.org, Sylvain.Pion@mpi-sb.mpg.de, ncm@cantrip.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: Re: libstdc++/10783: std::vector::reverse_iterator could be smaller Date: Sun, 18 May 2003 21:35:50 +0200 Well, on second thought, and giving justice to the clear explanation in V&J, in their §16.2.2 it is clearly stated that the EBCO has no equivalent for data members: this is reasonable considering that it would create problems with the representation of pointers to members. Therefore reverse_iterator is expected to have the same size of its iterator empty base (thanks to EBCO) + the size of its member current, that is two times the size of a plain iterator. Do you agree? Paolo. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10783
The following reply was made to PR libstdc++/10783; it has been noted by GNATS. From: Nathan Myers <ncm@cantrip.org> To: Paolo Carlini <pcarlini@unitus.it> Cc: gcc-prs@gcc.gnu.org, Sylvain.Pion@mpi-sb.mpg.de, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: libstdc++/10783: std::vector::reverse_iterator could be smaller Date: Sun, 18 May 2003 15:45:28 -0700 On Sun, May 18, 2003 at 09:35:50PM +0200, Paolo Carlini wrote: > Well, on second thought, and giving justice to the clear > explanation in V&J, in their ?16.2.2 it is clearly stated > that the EBCO has no equivalent for data members: this is > reasonable considering that it would create problems with > the representation of pointers to members. > > Therefore reverse_iterator is expected to have the same > size of its iterator empty base (thanks to EBCO) + the size > of its member current, that is two times the size of a > plain iterator. > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10783 I agree it would be a Good Thing for the reverse iterators to be the same size as the regular iterators. It seems to me that this is one of those cases where the regular empty-base optimization can't be applied. That is, the ABI forbids it because two base-class subobjects of the same type would have the same type. Often you can get around this sort of thing by giving the base an extra, defaulted, dummy argument, and deriving from a variant, so the two base subobjects that share the same address have different types. I think that doesn't work here because the derivation hierarchy and the argument list to std::iterator<> might be fixed by the standard. We might be able to get around it by giving each container a private iterator type, and then deriving the public iterator type from that, mixing in std::iterator<>. Then the reverse iterator would (be specialized to just contain an instance of the base type, and also mix in std::iterator<>. Another would be simply to derive privately from the regular iterator type and override some members. It would be nice to make a template that does this, so it could be used for all the containers. A tricky way would be to arrange that the addresses of the two base subobjects are at opposite ends of the object: struct empty {}; struct notempty { int i; }; struct iterator : empty { notempty n; }; // sizeof is 4 struct riterator_base { iterator i; }; // has empty at offset 0 struct riterator // has empty at both offsets 0 and 4. : riterator_base, empty {}; // sizeof should still be 4. Unfortunately this doesn't work. sizeof(riterator) is 8. :-( This is probably a result of an unfortunate oversight by the ia64 ABI group. Nathan Myers ncm-nospam@cantrip.org