Re: [boost] [multi index] Warnings withlevel 4 on Microsoft compiler

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2006-03-18 06:50:45

Hello Alexei

----- Mensaje original -----
De: Alexei Alexandrov <alexei.alexandrov_at_[hidden]>
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