This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: map,const keytype
- To: Anjul Srivastava <anjul dot srivastava at sanchez dot com>
- Subject: Re: map,const keytype
- From: <llewelly at dbritsch dot dsl dot xmission dot com>
- Date: Tue, 2 May 2000 12:01:01 -0600 (MDT)
- Cc: "'gcc at gcc dot gnu dot org'" <gcc at gcc dot gnu dot org>
On Tue, 2 May 2000, Anjul Srivastava wrote:
>
> Hello,
>
> I don't think this is the appropriate list, but nevertheless, I am hoping
> for some friendly help on this question:
>
> Can the Key type parameter in the template map be const?
>
> The Sun compiler is giving an error when declaring a map with 'const int' as
> a key type. gcc does not give an error. The Sun compiler team claims that
> the code violates the standard.
I think both g++ and Sun Workshop CC are correct.
In libstdc++-v2 (standard c++ library for gcc 2.95.2), and libstdc++-v3
(upcoming/experimental standard c++ library for gcc), the key field of
each pair is *constructed* (via placement new) with its initial value,
and there is never an attempt to assign it a new value. Remember that a
const object can be given a value once and only once, at construction
time. This is why g++ does not report an error.
>
> The standard says:
>
> >>From the C++ standard:
> >> Table 69 in 23.1.2, p7, says that
> >> X::key_type must be assignable;
However, given what the standard says, I think that g++ allowing
'const int' as a key_type should be viewed as an extension. I cannot
think of a way this extension could change the behavior of conforming
code, so it is probably a conforming extension. (By the way, libstdc++
inherited its map code from the SGI STL, so you may find other
compilers with this extension.)
I think it would be conformant for another compiler to give an error for
this code.
>
> The code is:
>
> >>--------------------------------------------------
> >>% cat map.cpp
> >>--------------------------------------------------
> >>#include <map>
> >>
> >>class DE_SQL
> >>{
> >>public:
> >> DE_SQL(void);
> >>protected:
> >> std::map<const int, int> mTable;
> >>};
> >>
> >>DE_SQL::DE_SQL(void)
> >>{
> >>}
> >>--------------------------------------------------
> >>% CC6 -V -c map.cpp
> >>CC6: Sun WorkShop 6 00/03/06 C++ 5.1
> >>ccfe: Sun WorkShop 6 00/03/06 C++ 5.1
> >>"/workspace/.mnt/buffy3/markw/buildbin-030600/SC5.1/include/CC/Cstd/map",
> >>line 251: Error: Multiple declaration for std::map<const int, int,
> >>std::less<const int>, std::allocator<std::pair<const int,
> >>int>>>::insert(const std::pair<const int, int>&).
> >>"map.cpp", line 9: Where: While specializing "std::map<const int, int,
> >>std::less<const int>, std::allocator<std::pair<const int, int>>>".
> >>"map.cpp", line 9: Where: Specialized in non-template code.
> >>1 Error(s) detected.
but I would not expect a multiple declaration error for what should really
be a const violation!
> >>--------------------------------------------------
>
> Now, I am puzzled as to why key_type needs to be assignable?
I do not know, but I would imagine it was done to
allow library implementors some leeway; I can certainly think of some
straitforward implementations that would be simpler if key_type was
assignable. Then again, one could always use placement new to call the
constructor.
> There is no
> interface function that seems to need to assign to an element. So, it could
> be something "under the hood" that needs assignment. I tried doing several
> things with maps after putting a message in the assignment operator code for
> the key, but I could never get it to execute.
As far as I can see, g++'s map implementation does not ever call the
assigment operator on the key; it uses the constructor.
> Does anybody know why the
> standard would require key_type to be assignable?
>
> Is it possible that the standard is in error?
It is 777 pages of complicated technical text. It would have been amazing
if it was error-free. There is a list of defect reports (bug reports) at
http://anubis.dkuug.dk/jtc1/sc22/wg21/ . The comittee has decided that
some of these DRs are errors that need to be fixed. I did not see any
that seemed relevant to this issue, however.
[snip]