Bug 46544 - std::map::at() defined even if __GXX_EXPERIMENTAL_CXX0X__ is not
Summary: std::map::at() defined even if __GXX_EXPERIMENTAL_CXX0X__ is not
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.5.0
: P3 trivial
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-18 15:32 UTC by Sebastian Mach
Modified: 2010-11-19 13:12 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Mach 2010-11-18 15:32:14 UTC
The function std::map::at(), first defined by the upcoming standard, slips into C++03 mode.

$ diff -ru include/c++/bits/stl_map.h.orig include/c++/bits/stl_map.h
--- include/c++/bits/stl_map.h.orig     2010-11-18 15:21:42 +0000
+++ include/c++/bits/stl_map.h  2010-11-18 15:20:02 +0000
@@ -452,6 +452,7 @@
        return (*__i).second;
       }

+#ifdef __GXX_EXPERIMENTAL_CXX0X__
       // _GLIBCXX_RESOLVE_LIB_DEFECTS
       // DR 464. Suggestion for new member functions in standard containers.
       /**
@@ -478,6 +479,7 @@
          __throw_out_of_range(__N("map::at"));
        return (*__i).second;
       }
+#endif

       // modifiers
       /**
Comment 1 Paolo Carlini 2010-11-18 17:06:06 UTC
As you can clearly see this feature is part of DR 464, a Defect vs C++03, already voted in CD1:

  http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464

We are delivering already *many* other features per DRs, in C++03 mode, both for the library and the core compiler.
Comment 2 Sebastian Mach 2010-11-19 11:13:49 UTC
(In reply to comment #1)

Thanks for clarifiying.

> As you can clearly see

It wasn't that clear to me. As a user of g++ and C++, and as a programmer, I am not into every DR, as I am already laden with getting codework done, and looking into the standards can already be hard enough if you relate it to release-pressure. Additionally grokking every single DR on top of that is not always managable.
Comment 3 Paolo Carlini 2010-11-19 11:20:17 UTC
I understand ;) As a general rule, if you see in the code mentioned a "DR XXX. YYY", with _GLIBCXX_RESOLVE_LIB_DEFECTS before, it means we are implementing a change beyond the letter of C++98/03, per the resolution of a successive ISO DR. For some time, many years ago, that _GLIBCXX_RESOLVE_LIB_DEFECTS was an actual macro and we tried to deliver both a vanilla C++98 and an amended version, depending on that macro, but it became quickly unmanageable, for various reasons (what to do with exported symbols, ODR, etc). Besides, according to the ISO rules, resolved DRs *are* part of the Standard in law, even if a completely new document does not exist yet.
Comment 4 Sebastian Mach 2010-11-19 13:12:10 UTC
(In reply to comment #3)
> As a general rule, if you see in the code mentioned a "DR XXX.
> YYY", with _GLIBCXX_RESOLVE_LIB_DEFECTS before, it means we are implementing a
> change beyond the letter of C++98/03, per the resolution of a successive ISO
> DR. 

Allright. I never stumbled over DR code, and that's prolly the reason why I did not recognize it (or possibly I thought that DRs are to be under -std=c++0x). Carved into synapses for the future.

> For some time, many years ago, that _GLIBCXX_RESOLVE_LIB_DEFECTS was an
> actual macro and we tried to deliver both a vanilla C++98 and an amended
> version, depending on that macro, but it became quickly unmanageable, for
> various reasons (what to do with exported symbols, ODR, etc). 

I already wanted to ask about a switch and it's non-presence, but seeing the number of DRs I already guessed it would be unmaintanable.

> Besides,
> according to the ISO rules, resolved DRs *are* part of the Standard in law,
> even if a completely new document does not exist yet.

That's both interesting and valuable knowledge, as I am nitpicky myself at times :D


Thanks for sharing your time :)