|
Boost : |
From: Michael Marcin (mmarcin_at_[hidden])
Date: 2007-12-03 06:10:11
Tobias Schwinger wrote:
> Michael,
>
> Michael Marcin wrote:
>> I ran into a compiler problem using the singleton library from the vault.
>>
>> singleton's constructor and destructor use instance_proxy before it is
>> defined. The trivial fix is to make the definition of the constructor
>> and destructor inline function at the bottom of the file (i.e. after
>> instance_proxy is defined).
>
> Actually, that shouldn't be a problem since 'singleton' is a template
> and things are complete once it's instantiated.
>
I think the compiler is allowed to check for an incomplete type before
it is instantiated. I believe this is the same problem that fusion
as_vector had a while ago.
http://article.gmane.org/gmane.comp.lib.boost.devel/166502
> Got some code that fails to compile?
Yes,
#include <boost/utility/singleton.hpp>
>
>> singleton_manager.hpp causes warning under msvc 8.0 in the
>> singleton_manager::cleanup function:
>>
>> warning C4706: assignment within conditional expression
>>
>> for
>>
>> while (!!(i = ptr_instance->ptr_first))
>>
>> if this could be rewritten without much effort to silence the warning it
>> would be nice.
>
> Yes (where interestingly the compiler could figure out this is not a
> typo here because of the '!!')...
>
> Maybe
>
> while ((i = ptr_instance->ptr_first) != 0l)
>
> will do the trick...
That works, or
context* i = ptr_instance->ptr_first;
while ( i )
{
context* next = i->ptr_next;
i->fnc_dtor(i);
i = ptr_instance->ptr_first = next;
}
>
>> Nit - there seems to be a lot of extraneous inline keywords for
>> functions defined inside the class definition.
>
> ...intentionally, because some compilers (under certain configurations)
> distinguish between "implicit" inline and "inline by keyword".
Hmm didn't expect that since the standard says its the same as declaring
it inline just after the class's closing ';' IIRC. Out of curiosity do
you remember what compilers do this?
Thanks,
Michael Marcin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk