This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: map,const keytype


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]


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]