[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org --- Noone is convinced this would be a positive change, let's close it.
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
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
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
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
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
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
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
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
--- 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=15284action=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
--- 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=15285action=view) new test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
--- 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
--- 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
--- 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
--- 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
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
--- 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::vectorint::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
--- 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
--- 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
