This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]