Re: [boost] Re: compressed_pair requirements?

----- Mensaje original ----- De: Peter Dimov <pdimov@mmltd.net> Fecha: Viernes, Mayo 27, 2005 7:47 pm Asunto: Re: [boost] Re: compressed_pair requirements?
Howard Hinnant wrote:
2. Uninitialized is better because it is much faster, especially if you have containers of such elements. You can always explicitly initialize if you want.
Technically... you can't put an uninitialized (non-character) scalar in a container; copying an uninitialized scalar is undefined behavior.
A similar issue also renders the following snippet illegal (unless someone has filed a DR): typedef set<int> int_set; pair<int_set::iterator,int_set::iterator> p; According to 20.2.2.2, the default ctor of std::pair works as if implemented like pair():first(int_set::iterator()),second(int_set::iterator()){} and int_set::iterator(), being a singular value, cannot be copied. A technical nitpick save for the fact that I actually was once static asserted by an overzealous checked STL implementation (don't remember which, I think it was Comeau). IMHO, std::pair default ctor should be defined as pair():first(),second(){} Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

JOAQUIN LOPEZ MU?Z wrote:
IMHO, std::pair default ctor should be defined as
pair():first(),second(){}
This doesn't change things. pair() {} is what you probably want. What can I say, I'm glad that your and Howard's view didn't prevail when std::pair was being defined. If I had it MY way, typedef set<int> int_set; pair<int_set::iterator,int_set::iterator> p; would have compiled on no compiler because int_set::iterator wouldn't even have had a default constructor. (Your code will probably fail at runtime on most debugging STLs, by the way.)
participants (2)
-
JOAQUIN LOPEZ MU?Z
-
Peter Dimov