template bug ?

template bug ?

[Milos Grundman]

// gcc version pgcc-2.91.57 19980901 (egcs-1.1 release)

template <int i> class a
{
public :

template <int j> int f() const { return f<j-1>(); };
template <> int f<0>() const {  return 0; };
};

int main()
{
a<2> x;
return x.f<1>(); // maybe it is incorrect
}

Re: template bug ?

[Alexandre Oliva]

On Dec  2, 1998, Milos Grundman <grundman@mip.ups-tlse.fr> wrote:

> return x.f<1>(); // maybe it is incorrect

Your code is correct, but egcs 1.1* require you to prefix `f' with the 
`template' keyword.  This should not be needed, and this problem is
already fixed in the latest development snapshots of egcs.
Unfortunately, another bug was introduced that causes it to reject
explicit specializations of templates within class bodies.

Mark or Jason, do you feel like accepting such specializations again?
They're definitely valid...

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: template bug ?

[Alexandre Oliva]

On Dec  3, 1998, Mark Mitchell <mark@markmitchell.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes:
Alexandre> Mark or Jason, do you feel like accepting such
Alexandre> specializations again?  They're definitely valid...

> We've been around and around on this, and I think we all agreed
> they're not.  As I recall, it's become clear that a member-declaration
> cannot be a specialization, judging from the grammar.

Unlike you, I couldn't find any such restriction in the grammar, and I
even found an example of an explicit specialization within a class
body in the Standard [temp.class.spec.mfunc]/2, so I have changed my
mind, and I hope you do too.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: template bug ?

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes:

    Alexandre> Mark or Jason, do you feel like accepting such
    Alexandre> specializations again?  They're definitely valid...

We've been around and around on this, and I think we all agreed
they're not.  As I recall, it's become clear that a member-declaration
cannot be a specialization, judging from the grammar.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: template bug ?

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes:

    Alexandre> Unlike you, I couldn't find any such restriction in the
    Alexandre> grammar, and I even found an example of an explicit
    Alexandre> specialization within a class body in the Standard
    Alexandre> [temp.class.spec.mfunc]/2, so I have changed my mind,
    Alexandre> and I hope you do too.

I doubt I willl:

    member-declaration:
      decl-specific-seqopt member-declarator-listopt;
      function-definition ;opt
      qualified-id;
      using-declaration;
      template-declaration;

The only one of these that comes close to allowing a specialization is
template-declaration, but:

    template-declaration:
      exportopt template < template-parameter-list > declaration

and here the temlpate-parameter-list may not be empty, so something
like:
   
    template <>
    void f<double>(int);

is not allowed.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: template bug ?

[Alexandre Oliva]

On Dec  3, 1998, Mark Mitchell <mark@markmitchell.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes:

Alexandre> Unlike you, I couldn't find any such restriction in the
Alexandre> grammar, and I even found an example of an explicit
Alexandre> specialization within a class body in the Standard
Alexandre> [temp.class.spec.mfunc]/2, so I have changed my mind,
Alexandre> and I hope you do too.

> The only one of these that comes close to allowing a specialization is
> template-declaration, but:

>     template-declaration:
>       exportopt template < template-parameter-list > declaration

> and here the temlpate-parameter-list may not be empty

I see your point, and I agreed with you until I found an example of
this use in the Standard.  IMO, even though the grammar does not allow
this use, we'd better support it, maybe printing a warning, otherwise
people will point at the snippet from the Standard and say egcs can't
do template specialization.

Maybe Jason can get authoritative information from the Committee: did
they really intend to allow this use or was the snippet included in
the Standard by mistake?

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: template bug ?

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes:

    Alexandre> I see your point, and I agreed with you until I found
    Alexandre> an example of this use in the Standard.  IMO, even

That's not normative.

    Alexandre> though the grammar does not allow this use, we'd better
    Alexandre> support it, maybe printing a warning, otherwise people
    Alexandre> will point at the snippet from the Standard and say
    Alexandre> egcs can't do template specialization.

It would help if you wouldn't tell them it was legal. :-) 

    Alexandre> Maybe Jason can get authoritative information from the
    Alexandre> Committee: did they really intend to allow this use or
    Alexandre> was the snippet included in the Standard by mistake?

Perhaps.  But, I don't really see why we should implement stuff that
is specifically not allowed by the standard.  Where there are
underspecified areas, it's nice to get input about intent, so that,
since we have to pick something, we can pick the right thing.

In this case, you're asking us to implement something that's clearly
disallowed by normative text, whether intentionally or not.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Template bug?

[Manuel Menezes de Sequeira]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

I'm not sure whether it is a compiler bug, but KAI C++

correctly compiled the code below and I've checked

the Draft Standard and it seems to me to be legal code.

My version of egcs is 1.1.2 distributed in RedHat 6.0.



// Template 1:

template <class R, class T>

R f(T i) {

    // do something

}



// Template 2 (specialization):

template <class R, class T>

R f(T* i) {

    // do something else

}



int main() {

    int i = 0;



    double d;

    d = f<double,int>(i); // should instantiate template 1

    d = f<double>(i); // should instantiate template 1



    d = f<double,int*>(&i); // should instantiate template 1



    d = f<double,int>(&i); // should instantiate template 2

    // Up to here, all is well.

    // EGCS reports ambiguity in this line:

    d = f<double>(&i); // should instantiate template 2

}





--

Manuel Menezes de Sequeira              Manuel.Sequeira@iscte.pt

Tel: +351.1.7903909                     Mobile: +351.936.2337428

Fax: +351.1.7903099             URL: http://torga.iscte.pt/~mms/

Gab. 9, DCTI, ISCTE,  Av. Forças Armadas,  1600 LISBOA, Portugal

Re: Template bug?

[Alexandre Oliva]

On May 19, 1999, mitchell@codesourcery.com wrote:

>>>>>> "Manuel" == Manuel Menezes de Sequeira <mms@torga.iscte.pt> writes:
Manuel> template <class R, class T>
Manuel> R f(T i) {

Manuel> template <class R, class T>
Manuel> R f(T* i) {

> The question is which of these is more specialized.  The answer is
> neither; trying to deduce the arguments of either from the other does
> not bind `R', since deduction does not look at the return-type.  So, I
> believe EGCS to be correct.

Indeed.  It seems to me like one of those corner cases that nobody
considered (or at least nobody considered worth specifying).  IMO, it
would be a good idea if the standard could be ammended so that, in
case of explicit specification of some of the template arguments, they
need not be considered when evaluating partial ordering of function
templates.  But maybe this just opens a can of worms...

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: Template bug?

[mitchell]

>>>>> "Manuel" == Manuel Menezes de Sequeira <mms@torga.iscte.pt> writes:

    Manuel> template <class R, class T>
    Manuel> R f(T i) {

    Manuel> template <class R, class T>
    Manuel> R f(T* i) {

The question is which of these is more specialized.  The answer is
neither; trying to deduce the arguments of either from the other does
not bind `R', since deduction does not look at the return-type.  So, I
believe EGCS to be correct.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
>From obrien@NUXI.com Wed May 19 10:58:00 1999
From: "David O'Brien" <obrien@NUXI.com>
To: law@cygnus.com, kip@lyris.com
Cc: Philipp Thomas <kthomas@gwdg.de>, egcs-bugs@egcs.cygnus.com
Subject: Re: FreeBSD linking against libc_r instead of libc
Date: Wed, 19 May 1999 10:58:00 -0000
Message-id: <19990519105833.D59912@nuxi.com>
References: <Pine.SOL.4.05.9905190918350.14999-100000@luna> <10765.927133083@upchuck.cygnus.com> <10765.927133083@upchuck.cygnus.com>
X-SW-Source: 1999-05/msg00455.html
Content-length: 876

> The problem with the patches (in general) from the FreeBSD folks is they
> still need a fair amount of work before we can add them to the tree.  

And I've asked for clarification and I get back single word answers in
which I can't figure out what you are trying to say.


> I'm not in a position to do the rewrites myself, so I'm stuck waiting
> on the FreeBSD folks to iterate on their changes.  

> There may also be legal issues with some of the patches.  I don't
> offhand see any in the pending queue because of legal stuff though.

WHAT legal issues??  I have mailed the copyright assignment form to RMS
many weeks ago.  The changes to freebsd-elf.h are my changes as I am the
maintainer of the FreeBSD EGCS port and the one that brought EGCS into
our base tree.  I am being selective what I've submitted.

-- 
-- David    (obrien@NUXI.com  -or-  obrien@FreeBSD.org)
>From kip@lyris.com Wed May 19 10:58:00 1999
From: <kip@lyris.com>
To: law@cygnus.com
Cc: Philipp Thomas <kthomas@gwdg.de>, obrien@nuxi.com, egcs-bugs@egcs.cygnus.com
Subject: Re: FreeBSD linking against libc_r instead of libc 
Date: Wed, 19 May 1999 10:58:00 -0000
Message-id: <Pine.SOL.4.05.9905191050430.16028-100000@luna>
References: <10765.927133083@upchuck.cygnus.com>
X-SW-Source: 1999-05/msg00454.html
Content-length: 2295

Sorry about not being more observant standard procedure. Thanks for your
efforts.

					-Kip Macy

On Wed, 19 May 1999, Jeffrey A Law wrote:

> 
>   In message < Pine.SOL.4.05.9905190918350.14999-100000@luna >you write:
>   > I submitted a fixed freebsd-elf.h a couple of weeks ago and never got a
>   > response about it
> I sent you a response yesterday.  Did you get it?
> 
>   > What form should I submit it in so that it is easiest
>   > to incorporate?
> Your patch wasn't put in becuase it wasn't a patch, but a file replacement
> with what appeared to be totally unrelated changes when compared to the file
> in our repository.   Do not send file replacements, send diffs.
> 
> http://egcs.cygnus.com/contribute.html
> 
> 
> 
>   > This is not a criticism, but a comment on economic reality: Cygnus has a
>   > much stronger vested interest in Linux than in FreeBSD. Cygnus is before
>   > all else a commercial entity and thus has to prioritize where its efforts
>   > are placed. I just think it fortunate that they are able to contribute to
>   > the community as a whole.
> It has absolutely nothing to do with Cygnus's financial issues.  Decisions
> about what patches to work on integrating has nothing to do with Cygnus's
> needs.
> 
> I *do* prioritize based on community and developer interest, relationship 
> with the contributor, long term needs, and other non-Cygnus priorities.
> 
> The problem with the patches (in general) from the FreeBSD folks is they
> still need a fair amount of work before we can add them to the tree.  I'm
> not in a position to do the rewrites myself, so I'm stuck waiting on the
> FreeBSD folks to iterate on their changes.  There may also be legal issues
> with some of the patches.  I don't offhand see any in the pending queue
> because of legal stuff though.
> 
> 
> Note how differently the FreeBSD situation is from the OpenBSD situation.
> Marc Espie dedicated the time and effort to fix up the problems (both
> technical and legal) with the OpenBSD patches and we have integrated them.
> 
> It can take some time, but when the contributor is willing to play by the same
> rules as everyone else and update their patches per our comments, then the
> patches will go in unless the basic idea behind the patches is wrong.
> 
> jeff
> 
> 

Re: Template bug?

[Alexandre Oliva]

Knut Akesson <ka@s2.chalmers.se> writes:

> I might have found a bug in the egcs-1.1 compiler. I got this error
> message :

>> test.cpp: In method `class T<double>::A S<double,char>::foo<double, char>()':
>> test.cpp:37:   instantiated from here
>> test.cpp:32: conversion from `T<char>' to non-scalar type `T<double>::A' requested
>> test.cpp: In function `int main(...)':
>> test.cpp:37: conversion from `T<double>::A' to non-scalar type `T<char>::A' requested     

The error message is misleading, but the problem is quite easy to
fix.  Just insert `typename' before the template-dependent type name
`T<C>::A', and you should be done:

    typename \
>   T<C>::A foo() { return T<C>(); }

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Template bug?

[Knut Akesson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

Hi,

I might have found a bug in the egcs-1.1 compiler. I got this error
message :

> test.cpp: In method `class T<double>::A S<double,char>::foo<double, char>()':
> test.cpp:37:   instantiated from here
> test.cpp:32: conversion from `T<char>' to non-scalar type `T<double>::A' requested
> test.cpp: In function `int main(...)':
> test.cpp:37: conversion from `T<double>::A' to non-scalar type `T<char>::A' requested     

when I compiled the following code. The code compiles with both
egcs-1.0.3 and MSVC5, and is legal as far as I know.

template<class C> 
class T {
public:
  class A{};
  operator A() const { return A(); } 
};

template<class B, class C> 
class S {
public:
  T<C>::A foo() { return T<C>(); }
};

void main() {
  S<double, char> s;
  T<char>::A t = s.foo();
}

/Knut
________________________________________________________________
Knut Ã…kesson                           +46 (0)31 772 3717 (work)
Department of Signals and System       +46 (0)31 772 3730  (fax)
Control Engineering Laboratory         +46 (0)31 27 48 26 (home)
Chalmers University of Technology
S-412 96  Gothenburg                    mailto:ka@s2.chalmers.se
Sweden                        http://www.control.chalmers.se/~ka
________________________________________________________________

Re: template bug?

[Jason Merrill]

>>>>> Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> This is not valid ISO C++ code, line 4 should actually read
>   typename T::inside_class damn;

> I agree, however, that the error message you got in this case is 
> somewhat confusing.

> Moreover, shouldn't this be handled by the "implicit typename" gcc
> extension? (Mark? Jason?)

No.  implicit typename only works when the context is a template
instantiation, like A<T>, not when it's a template parm itself.

Jason

Re: template bug?

[Gerald Pfeifer]

On Wed, 25 Mar 1998, Dave Taylor wrote:
> 	template <class T>
> 	fart(T &a)
> 	{
> 		T::inside_class damn;
> 	}

This is not valid ISO C++ code, line 4 should actually read
  typename T::inside_class damn;

> 	u.cc: In function `int fart(T &)':
> 	u.cc:4: parse error before `;'

I agree, however, that the error message you got in this case is 
somewhat confusing.

Moreover, shouldn't this be handled by the "implicit typename" gcc
extension? (Mark? Jason?)

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: template bug?

[Dave Taylor]

Thanks.  I clearly need a C++ refresher.  :)

	=-ddt->

On Thu, 26 Mar 1998, Gerald Pfeifer wrote:

> On Wed, 25 Mar 1998, Dave Taylor wrote:
> > 	template <class T>
> > 	fart(T &a)
> > 	{
> > 		T::inside_class damn;
> > 	}
> 
> This is not valid ISO C++ code, line 4 should actually read
>   typename T::inside_class damn;
> 
> > 	u.cc: In function `int fart(T &)':
> > 	u.cc:4: parse error before `;'
> 
> I agree, however, that the error message you got in this case is 
> somewhat confusing.
> 
> Moreover, shouldn't this be handled by the "implicit typename" gcc
> extension? (Mark? Jason?)
> 
> Gerald
> -- 
> Gerald Pfeifer (Jerry)      Vienna University of Technology
> pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/
> 

---------
Dave Taylor, Owner
Crack dot Com, Inc.  http://crack.com

Re: template bug?

[Jason Merrill]

>>>>> Dave Taylor <ddt@crack.com> writes:

> The following file:
> 	template <class T>
> 	fart(T &a)
> 	{
> 		T::inside_class damn;
> 	}

> compiled with "g++ -c t.cc" barfs with

> 	u.cc: In function `int fart(T &)':
> 	u.cc:4: parse error before `;'

You need to say "typename T::inside_class".

Jason

template bug?

[Dave Taylor]

The following file:

	template <class T>
	fart(T &a)
	{
		T::inside_class damn;
	}

compiled with "g++ -c t.cc" barfs with

	u.cc: In function `int fart(T &)':
	u.cc:4: parse error before `;'

(This works with gcc 2.7.x)

Any ideas?  Lemme know.  Thx.

	=-ddt->

---------
Dave Taylor, Owner
Crack dot Com, Inc.  http://crack.com

Re: Template bug ?

[Munagala V. S. Ramanath]

Alexandre Oliva <oliva@dcc.unicamp.br> replies to my bug report:

> Munagala V S Ramanath writes:
> 
> > When I add <> after the function names at lines 14 and 15 as suggested
> > by the diagnostic I get further errors:
> 
> > ------------------------------------------------------------------------
> > ram@dust tests: /d2a/exper/bin/gcc bug2.C -lstdc++
> > bug2.C:13: parse error before `>'
> 
> there must be a declaration of the function template before it is
> referred to inside the body of the class template.  In order to
> declare the function template before the definition of the class
> template, you must have already declared the class template, like
> this:
> 
> template< class T, class UT, int NFRAC >
> class Fixed;
> 
> template< class T, class UT, int NFRAC > inline Fixed< T, UT, NFRAC >
> Mul( const Fixed< T, UT, NFRAC > &a1,
>      const Fixed< T, UT, NFRAC > &a2 );
> 
> template< class T, class UT, int NFRAC > ostream &
> operator<<( ostream &os, const Fixed< T, UT, NFRAC > &a );
> 
> template< class T, class UT, int NFRAC >
> class Fixed {
> // ...

After prepending the above 3 forward declarations at the top of my file,
I still get a warning (but it now compiles):

------------------------------------------------------------------------
ram@dust tests: /d2a/exper/bin/gcc bug4.C -lstdc++
bug4.C: In function `class Fixed<long int,long unsigned int,8> Mul<long int, long unsigned int, 8>(const class Fixed<long int,long unsigned int,8> &, const class Fixed<long int,long unsigned int,8> &)':
bug4.C:54: warning: sorry: semantics of inline function static data `int const NBITS' are wrong (you'll wind up with multiple copies)
------------------------------------------------------------------------

I have other programs with static data in inline functions and they do
not produce this diagnostic so I don't quite understand the warning: is
it saying inline functions should not have static data or that it cannot
inline the function or something else ?

Ram

Re: Template bug ?

[Alexandre Oliva]

Munagala V S Ramanath writes:

> When I add <> after the function names at lines 14 and 15 as suggested
> by the diagnostic I get further errors:

> ------------------------------------------------------------------------
> ram@dust tests: /d2a/exper/bin/gcc bug2.C -lstdc++
> bug2.C:13: parse error before `>'

there must be a declaration of the function template before it is
referred to inside the body of the class template.  In order to
declare the function template before the definition of the class
template, you must have already declared the class template, like
this:

template< class T, class UT, int NFRAC >
class Fixed;

template< class T, class UT, int NFRAC > inline Fixed< T, UT, NFRAC >
Mul( const Fixed< T, UT, NFRAC > &a1,
     const Fixed< T, UT, NFRAC > &a2 );

template< class T, class UT, int NFRAC > ostream &
operator<<( ostream &os, const Fixed< T, UT, NFRAC > &a );

template< class T, class UT, int NFRAC >
class Fixed {
// ...

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Template bug ?

[Munagala V. S. Ramanath]

Hi,

The file appended below compiles fine with gcc-2.7.2 but produces the
following diagnostics when compiled with egcs-1.0:

------------------------------------------------------------------------
ram@dust tests: /d2a/exper/bin/gcc bug2.C -lstdc++
bug2.C:14: warning: friend declaration `class ostream & operator <<(class ostream &, const class Fixed<T,UT,NFRAC> &)'
bug2.C:14: warning:   will not be treated as a template instantiation
bug2.C:14: warning:   unless you compile with -fguiding-decls
bug2.C:14: warning:   or add <> after the function name
bug2.C:15: warning: friend declaration `class Fixed<T,UT,NFRAC> Mul(const class Fixed<T,UT,NFRAC> &, const class Fixed<T,UT,NFRAC> &)'
bug2.C:15: warning:   will not be treated as a template instantiation
ld: Undefined symbol 
   Mul(Fixed<long, unsigned long, 8> const &, Fixed<long, unsigned long, 8> const &)
   operator<<(ostream &, Fixed<long, unsigned long, 8> const &)
collect2: ld returned 2 exit status
------------------------------------------------------------------------

When I add <> after the function names at lines 14 and 15 as suggested
by the diagnostic I get further errors:

------------------------------------------------------------------------
ram@dust tests: /d2a/exper/bin/gcc bug2.C -lstdc++
bug2.C:13: parse error before `>'
bug2.C: In function `class Fixed<long int,long unsigned int,8> Mul<long int, long unsigned int, 8>(const class Fixed<long int,long unsigned int,8> &, const class Fixed<long int,long unsigned int,8> &)':
bug2.C:44: warning: sorry: semantics of inline function static data `int const NBITS' are wrong (you'll wind up with multiple copies)
------------------------------------------------------------------------

Here are the egcs version details:

------------------------------------------------------------------------
ram@dust tests: /d2a/exper/bin/gcc -v
Reading specs from /d2a/exper/lib/gcc-lib/sparc-sun-sunos4.1.2/egcs-2.90.21/specs
gcc version egcs-2.90.21 971202 (egcs-1.00 release)
------------------------------------------------------------------------

Here is the program bug2.C:

=====  BEGIN bug2.C  ===================================================

#include <fstream.h>

#define INT32   long
#define UINT32  unsigned long

//---------------------------------------------------------------  Fixed
//
template< class T, class UT, int NFRAC >
class Fixed {

    // (A)
    friend ostream &operator<< <>( ostream &os, const Fixed &a );
    friend Fixed Mul <>( const Fixed &a1, const Fixed &a2 );
    //friend ostream &operator<< ( ostream &os, const Fixed &a );
    //friend Fixed Mul ( const Fixed &a1, const Fixed &a2 );

public:

    static const T
        min     = static_cast< T >( 1 ) << ((sizeof( T ) << 3) - 1),
        max     = min - 1;

    Fixed( const int &a ) : val( a << NFRAC ) { }
    Fixed( const double &a ) {
        val = static_cast<T>( a * 1.5 );
    }

    Fixed operator=( const Fixed &a ) { val = a.val; return *this; }

private:

    T val;
};                                                              // Fixed

//-----------------------------------------------------------------  Mul
//
//
template< class T, class UT, int NFRAC > inline Fixed< T, UT, NFRAC >
Mul( const Fixed< T, UT, NFRAC > &a1,
     const Fixed< T, UT, NFRAC > &a2 ) {

    typedef Fixed< T, UT, NFRAC > Fix;
    Fix d = 0;
    static const int NBITS = sizeof( T ) * 8;
    return d;
}                                                                 // Mul

//----------------------------------------------------------  operator<<
//
// output a fixed point number (some loss of precision possible)
//
template< class T, class UT, int NFRAC > ostream &
operator<<( ostream &os, const Fixed< T, UT, NFRAC > &a )
{
    return os << a.val;
}                                                          // operator<<

typedef Fixed< INT32, UINT32, 8 > Fix8;

//----------------------------------------------------------------  main
//
// Test program
//
main()
{
    Fix8 f1( 10 ), f2( 20 );

    cout << "max = " << Fix8::max << ", min = " << Fix8::min
         << ", f1 = " << f1 << ", f2 = " << f2
         << endl;

    f2 = Mul( f1, f1 );
    cout << "f1 = " << f1 << ", f2 = sqr(f1) = " << f2 << endl;

    return 0;
}                                                                // main
=====  END bug2.C  =====================================================