On May 27, 2005, at 11:35 AM, Peter Dimov wrote:
John Maddock wrote:
OK, the following: boost::compressed_pair<const int, long> cp2; Gives me a compiler error with VC7.1 (it should as well, but it's not really a compressed_pair issue).
Why should it? std::pair works.
Oh, right. This is the eternal struggle over what it means to default construct a scalar - do nothing or zero initialize. This is so messed up in C++. :-\ std::pair zero initializes scalars on default construction. And (at least the Metrowerks implementation of) compressed_pair does not zero initialize scalars on default construction. People typically line up religiously on both sides of this issue: 1. Zero initialization is better than uninitialized because it is safer. 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. The result today is that scalars are special when it comes to default construction, and you really can't count on consistent handling of default constructed scalars within class types (and there is no going back because of backwards incompatibility). struct A { A() {} int i_; }; Default construct and contained scalar is std::vector<int> zero-initialized std::pair<int, T> zero-initialized std::complex<double> zero-initialized A uninitialized std::tr1::array<int, N> uninitialized std::tr1::tuple<int, ...> uninitialized ? (haven't double checked this one) compressed_pair<int, T> ??? I think it all started with map<key, int>: std::map<std::string, int> m; int& ir = m["one"]; // what value should ir have here? We should document how we default construct scalars in compressed_pair. Personally I fall into the Uninitialized (for efficiency) camp. But at this point I don't think there are any very good answers. -Howard