|
Boost : |
From: Daniel Krügler (dsp_at_[hidden])
Date: 2004-02-03 05:42:33
>>But I took it as honest as possible and searched for the definition(s)
>>of any of the definitions of those static "value" members declared in
>>any of the (macro hidden) AUX_WRAPPER_NAME classes. Regrettably I didn't
>>find any of these definitions in my 1.30.0 or in the last official
>>1.30.2 release. Can someone give me a pointer, where these definitions
>> can be found?
>
>
> I pointed you at the file above. Please use a CVS snapshot or the
> release candidate for the basis of your patch 1.30.x is very
> different.
Thanks for that hint, Dave. I took the last officially available files
and found one **further** MSVC7.1 bug concerning static data members -
sigh! (I posted the problems some minutes ago to the m.s.v.c. news group)
The following program causes a linker error using the /Za flag (disable
language extensions):
b.h: -------------------------
#ifndef B_H_INC
#define B_H_INC
template <typename T>
struct B
{
static const int val = 123;
};
template <typename T>
const int B<T>::val; // Definition provided, but not recognized...
#endif -------------------------
main.cpp --------------------
#include "b.h"
void foo(const int&)
{
}
int main()
{
typedef B<double> MyB;
foo(MyB::val);
}-------------------------
I could verify, that the same kind of linker error occurs for boost
sources, if a program accesses the address of constant static data
member of integral/enumeration type of any template class.
Currently I have not found any workaround for this, despite the
provocative proposal to add in the configuration file
/boost/config/compiler/visualc.hpp
the following lines:
#if (_MSC_VER <= 1310) && !defined(_MSC_EXTENSIONS)
# define BOOST_NO_INCLASS_MEMBER_INITIALIZATION
#endif
Can someone support or deny these awful observations???
Some further informations regarding my personal tests: The
corresponding data member definition is recognized, if the
in-class initialization is changed to an out-of-class initialization,
which obviously makes these kind of constants not suitable as part of
usual ICE's....
Daniel
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk