This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: More test results...
Martin Sebor <sebor@roguewave.com> writes:
| Benjamin Kosnik wrote:
| >
| > > Apologies for intruding on this discussion, but I thought the change
| > > was actually pretty cool until I realized that it prevents the explicit
| > > specialization of the individual data members of the primary template
| > > inherited from the base.
| >
| > Que? Can you post code that demonstrates this, as I'm not quite sure what
| > you mean. Did you see the example here:
| >
| > http://gcc.gnu.org/ml/libstdc++/2002-03/msg00237.html
|
| I could have missed something, so feel free to ignore me if I'm off base.
| This should (and does) work:
|
| template <class T>
| struct B { static const int j = 0; };
|
| template <class T>
| const int B<T>::j;
|
| template <>
| const int B<void>::j = 2;
OK.
| but this can't:
|
| struct A { static const int j = 0; };
|
| const int A::j;
|
| template <class T>
| struct B: A { };
|
| template <>
| const int B<void>::j = 2;
OK.
While your example is well-formed, I don't think it scales to
numeric_limits<>. Here is why: The standard doesn't say whether
numeric_limits<> is exported or not. In case an implementation
exported it, explicitly specializing individual members may violate
the ODR. Therefore, any program playing that games is inherently
non-portable.
-- Gaby