libstdc++/10783: std::vector::reverse_iterator could be smaller

libstdc++/10783: std::vector::reverse_iterator could be smaller

[Sylvain.Pion]

>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:

Re: libstdc++/10783: std::vector::reverse_iterator could be smaller

[Nathan Myers]

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

Re: libstdc++/10783: std::vector::reverse_iterator could be smaller

[Paolo Carlini]

[-- 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
 

Re: libstdc++/10783: std::vector::reverse_iterator could be smaller

[paolo]

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