Hello Alexei ----- Mensaje original ----- De: Alexei Alexandrov <alexei.alexandrov@gmail.com> Fecha: Viernes, Marzo 17, 2006 7:37 pm Asunto: Re: [boost][multi index] Warnings withlevel 4 on Microsoft compiler [...]
But what about
boost\multi_index\detail\hash_index_node.hpp(89) : warning C4610: struct 'boost::multi_index::detail::hashed_index_node_trampoline<Super>' can never be instantiated - user defined constructor required
This warning seems to have more sense and should not be disabled perhaps. Do you think it should be disabled on whole Boost level as well?
All these node classes are really never constructed, as they're placed directly in memory and used. C++ allows this when the class have so-called "trivial constructors" (see std 12.1.5) The idea is that these classes are nothing but structures of pointers and integral variables, so not calling any constructor is an allowed optimization --in the usual case, i.e. creating an object on the stack or on on the heap via new, the trivial ctor call gets optimized anyway (and cannot be avoided by the very rules of C++), but not necessarily so when creating objects thru an allocator interface, which decouples storage creation (allocate) from construction (construct). This issue is explicitly dealt with in std 3.8 "Object limetime". Now, strictly speaking the compiler is right that the object cannot be instantiated, since the std seems to mandate that a trivial constructor really exist, not merely that it would be trivial if it could be automatically generated --in this case it cannot because of base classes with private (trivial) ctors. To sum it up, the compiler is probably right that such an object cannot be instantiated according to C++ std, even resorting to the trivial-ctor allowance. Consequently, I'll rewrite this so that the warning disappears. On the other hand, I'm not very happy with this kind of "forward thinking" warnings: If I never construct such an object, why should the compiler complain? A warning should be aimed IMHO at making you think about idioms hiding potential programming errors, not techniques which *could* result in non-compilable programs, as is the case with all the warnings you've cited in this thread. Thanks for the information, best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo