🚀 go-pugleaf

>From article <4hn54s$3am@engnews1.Eng.Sun.COM>, by clamage@Eng.Sun.COM (Steve Clamage):

[... other interesting discussion]
> I suppose I should also comment on the comparison with unneeded template
> instantiations. That isn't an optimization issue, but a correctness issue.
> Simple example:
> 	template< class T > class X {
> 		T t;
> 		...
> 		bool operator<( const T& rhs ) { return t < rhs.t; }
> 	};
> Suppose we instantiate X on a type T for which the "<" operator is not
> defined. That isn't a problem unless we invoke X<T>::operator<. So the
> language rule is that a compiler can't reject a program due to an
> invalid instantiation unless the instantiation is actually required.
[...]


Presumably this language rule also covers the situation below with an
incomplete type, and my C++ compiler (HP-UX cfront-based) is incorrect
to reject it?


I had an example where I needed only pointers,

   template<struct T> struct VBlock;
   struct VScratchRep;

   struct VScratch {
     VScratchRep *chunk;
     VBlock<VScratchRep> *free;
    };

   int main()
   {
    VScratch *p = (VScratch *)0;
    return 0;
   }

which the compiler would accept in isolation, but if during the same
compilation it saw the definition of VBlock<T>::operator[],

   template<struct T> struct VBlock {
     T &operator[](int i);
     T *v;
    };

   template<struct T> inline T &VBlock<T>::operator[](int i)
   {
    return v[i];
   }

it failed, needing to know the size of VScratchRep even though [] was
never called in this compilation.  (I discovered this when including two
header files while compiling something else.)

    Tony Bass

-- 
# Tony Bass                                     Tel: (01473) 645305
# MLB 3/19, BT Laboratories                     e-mail: aeb@saltfarm.bt.co.uk
# Martlesham Heath, Ipswich, Suffolk, IP5 7RE   DO NOT e-mail to From: line
#                                               Opinions are my own
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]