[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc.glisse at normalesup
                   |                            |dot org

--- Comment #10 from Marc Glisse <marc.glisse at normalesup dot org> 2011-10-28 09:31:30 UTC ---
Just noticed this accidentally while looking for something else. And I am
opposed to hiding the standard typedefs (particularly iterator_category), even
in some debug mode. An iterator is either a pointer or a class with the
typedefs. If you want to portably detect iterators (for sfinae purposes),
that's exactly what you'll test, since iterator_traits is not guaranteed to be
sfinae-friendly.

On the other hand, I would not be opposed to a signature: iterator&
operator--()&; for the decrement operator (notice the final '&') when support
appears in the compiler. Next time I read --v.end()...

Note that IIRC Howard's libc++ uses pointers, which should make those issues
more visible.

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

--- Comment #11 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-10-28 09:40:36 UTC ---
Interesting, thanks.

By the way, I would guess Sylvain' email doesn't work anymore, thus it's
unlikely that he can give us his feedback ;) (or does he have a forward in
place, as far as you know?)

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-10-28 09:57:01 UTC ---
(In reply to comment #10)
> An iterator is either a pointer or a class with the
> typedefs.

Or a type for which iterator_traits has been specialized?

I'm not really interested in the patch, I did it as a proof of concept and
reverted it in my tree a long time ago

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

--- Comment #13 from Marc Glisse <marc.glisse at normalesup dot org> 2011-10-28 10:18:43 UTC ---
(In reply to comment #12)
> (In reply to comment #10)
> > An iterator is either a pointer or a class with the
> > typedefs.
> 
> Or a type for which iterator_traits has been specialized?

Yes. Sadly, that's not portably detectable. The 2 categories above are those
that can be tested. And having a private iterator_category completely breaks
sfinae in C++03.

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[sylvain.pion at sophia dot inria.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

--- Comment #14 from sylvain.pion at sophia dot inria.fr 2011-10-29 04:22:49 UTC ---
(@Paolo : I still receive email at my old address, so far)

I don't have a strong opinion on this.  It's certainly nice to have a strongly
compliant mode to make it easier to write portable code, although that doesn't
replace proper testing with other compilers anyway.  I understand that there
can be a small drawback here, and maybe not a lot of motivation to dig further
on this particular question.

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #10)
> that's exactly what you'll test, since iterator_traits is not guaranteed to
> be sfinae-friendly.

N.B. that's changed for C++14.

I'm still not motivated to implement this request though.

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

--- Comment #16 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #15)
> I'm still not motivated to implement this request though.

It would break too much code.

If people really insisted (which they don't), I believe it would be safer to
specialize iterator_traits and _remove_ the nested vector::iterator::* typedefs
than to make them private, since access control in C++ is a trap.

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[chris at bubblescope dot net]

------- Comment #9 from chris at bubblescope dot net  2008-03-09 20:28 -------
Sorry to be pedantic, but could this be added to _GLIBCXX_DEBUG_PEDANTIC. I've
previously tended to assume that _GLIBCXX_DEBUG should change only flag code
that should fail in non-debug mode, but fails to be detected, whereas
_GLIBCXX_DEBUG_PEDANTIC ensures that the code is standards compliant.

On another note, could this be added when just -pedantic is added? I think it's
a useful flag to add, I'm just trying to avoid having to change a bunch of
working, although non standards-complaint code :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[jwakely dot gcc at gmail dot com]

------- Comment #8 from jwakely dot gcc at gmail dot com  2008-03-09 15:52 -------
Created an attachment (id=15285)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15285&action=view)
new test


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[jwakely dot gcc at gmail dot com]

------- Comment #7 from jwakely dot gcc at gmail dot com  2008-03-09 15:51 -------
Created an attachment (id=15284)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15284&action=view)
make nested iterator typedefs private in debug mode

It's "accepts implementation-defined" not "accepts invalid" - and it's
obviously by design that GCC accepts its own implementation-defined constructs!

This patch makes the typedefs inaccessible in debug mode and fixes up a couple
of functions that refer to them directly, rather than through iterator_traits.

Tested x86_64/linux. I also tried testing with -D_GLIBCXX_DEBUG added to
testsuite_flags but got lots of spurious failures that I don't think are
related to this change (as with parallel mode testing, all the
23_containers/*/synopsis.cc tests fail in debug mode - I haven't investigated
why)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[pcarlini at suse dot de]

------- Comment #6 from pcarlini at suse dot de  2007-04-17 17:04 -------
I also had a look lately, and probably I'm coming to your same conclusions...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[chris at bubblescope dot net]

------- Comment #5 from chris at bubblescope dot net  2007-04-17 16:48 -------
I've done a bit of research into this. Looks like, as Andrew says the standard
doesn't have much to say on the issue. Any method of removing this is going to
make some other things a bit more messy I think, and I found a few pieces of
code that use this and it seems unnesasary to break it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[chris at bubblescope dot net]

------- Comment #4 from chris at bubblescope dot net  2007-03-17 17:52 -------
The main problem I can see with changing this is that you would have to decide
if you were going to remove the same options from the iterators of all other
standard containers. To not do so would seem to be inconsistent, but doing so
would probably break a huge amount of code.

This seems to be part of a larger issue, should these typedefs be defined in
any of the standard iterators. Having an "offical decision" by the standards
committee would probably be useful.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[sylvain dot pion at sophia dot inria dot fr]

------- Comment #3 from sylvain dot pion at sophia dot inria dot fr  2007-03-17 17:35 -------
I'm not sure about the standard requirements.  My "user question" is that
I want to develop with GCC as my main compiler, and I want it to catch
non-portability bugs as much as possible.

@Chris: note that std::iterator_traits would not need to be specialized for
std::vector::iterator if it was made a friend of it, so that it would be the
only one able to access these types.

The compiler I know which still has a pointer for std::vector::iterator is PGCC
(the Portland Group Compiler).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[chris at bubblescope dot net]

------- Comment #2 from chris at bubblescope dot net  2007-03-17 17:19 -------
Depending on how you read it, 24.3.1 looks to me like it might require that. It
says that iterator_traits is defined to include:

typedef typename Iterator::value_type value_type;

and that it is specialised for various types of pointers. If we removed
std::vector<int>::iterator::value_type, we would then have to overload
iterator_traits for vector, and I'm not sure we are allowed to.

Out of interest, which compilers still have a pointer for
std::vector::iterator?


-- 

chris at bubblescope dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chris at bubblescope dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247

[Bug libstdc++/31247] std::vector::iterator::value_type is accessible

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-03-17 17:00 -------
IIRC iterator is an implemention defined type so this is valid.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247