![]() |
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, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk