Re: More test results...

[Martin Sebor <sebor at roguewave dot com>]

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.

Regards
Martin

Benjamin Kosnik wrote:
> 
> > Right but why were there implicit instantiations being generated?  If there
> > hadn't been, the problem wouldn't have been noticed.
> 
> The original code wasn't posted, but it was likely to not be using
> specializations, and thus implicitly generating instantiations of
> numeric_limts<string> from the generic numeric_limits template definition.
> 
> The details are archived in the thread, I believe.
> 
> Anyway...... on to another, separate issue.
> 
> > > If you've actually fixed the static const issue, then perhaps the stl
> > > changes to enums can be reverted. Thoughts?
> >
> > I haven't been following that discussion, sorry.
> 
> It's the whole
> 
> %cat > 1.cc
> const int i = 5;
> 
> %nm 1.o
> 00000000 r i
> 
> thing
> 
> You've said in private email that:
> 
> > With -O or -fno-keep-static-consts, it goes away.  Perhaps C++ should
> > default to -fno-keep-static-consts.
> 
> ...which I can verify does what I'd expect. Any hope to make this the
> default?
> 
> thanks,
> benjamin