Topic: Template class copy constructor syntax


Author: vincent@clt53ae.world (Vincent LADEUIL "clt53aa")
Date: Thu, 18 Nov 1993 08:30:52 GMT
Raw View
In article <1993Nov11.175035.16944@eUNiiCE.canada.dg.com> allen@eUNiiCE.canada.dg.com (%Allen B. Taylor) writes:

   Xref: edf.edf.fr comp.std.c++:4828 comp.lang.c++:46666
   Newsgroups: comp.std.c++,comp.lang.c++
   Path: edf.edf.fr!julienas!mcsun!uunet!news.sprintlink.net!dg-rtp!wingnut!eUNiiCE!allen
   From: allen@eUNiiCE.canada.dg.com (%Allen B. Taylor)
   Date: Thu, 11 Nov 93 17:50:35 GMT
   Organization: Data General (Canada) Inc., National Headquarters
   Lines: 29

   Can anyone tell me if either of the two specifications for copy constructor and
   assignment operator are correct or incorrect?  Borland C++ seems to accept both
   forms, but Form 1 has been reject on other compilers I've tried.

    Form 1:
    template <class T>
    class Blah
    {
      T *x;
      public:
      Blah();
      Blah(Blah &);   // <--
      Blah &operator=(Blah &); // <--
    };

    Form 2:
    template <class T>
    class Blah
    {
      T *x;
      public:
      Blah();
      Blah(Blah<T> &);  // <---
      Blah &operator=(Blah<T> &) // <---
    };

   I suspect that form 2 is closer to proposed ANSI, but the latest documentation
   I have is the Ellis & Stroustrup ARM, which manages to avoid the subject
   entirely.

The following IS actually legal and may be useful :

template <class T>
class Blah
{
  T *x;
public:
  Blah();
  Blah(Blah &);   // <--
  Blah &operator=(Blah<T> &); // <--
  Blah &operator=(Blah<int> &) ;
         ^^^
};

So IMHO Form 2 is more explicit of what the operator do.

Well, may be I say that because I am very suspicious with
what make the compiler behind me :-)




Author: allen@eUNiiCE.canada.dg.com (%Allen B. Taylor)
Date: Thu, 11 Nov 93 17:50:35 GMT
Raw View
Can anyone tell me if either of the two specifications for copy constructor and
assignment operator are correct or incorrect?  Borland C++ seems to accept both
forms, but Form 1 has been reject on other compilers I've tried.

 Form 1:
 template <class T>
 class Blah
 {
   T *x;
   public:
   Blah();
   Blah(Blah &);   // <--
   Blah &operator=(Blah &); // <--
 };

 Form 2:
 template <class T>
 class Blah
 {
   T *x;
   public:
   Blah();
   Blah(Blah<T> &);  // <---
   Blah &operator=(Blah<T> &) // <---
 };

I suspect that form 2 is closer to proposed ANSI, but the latest documentation
I have is the Ellis & Stroustrup ARM, which manages to avoid the subject
entirely.




Author: grumpy@cbnewse.cb.att.com (Paul J Lucas)
Date: Fri, 12 Nov 1993 22:25:19 GMT
Raw View


Author: rmartin@rcmcon.com (Robert Martin)
Date: Fri, 12 Nov 1993 23:56:47 GMT
Raw View
allen@eUNiiCE.canada.dg.com (%Allen B. Taylor) writes:

>Can anyone tell me if either of the two specifications for copy
>constructor and assignment operator are correct or incorrect?

> Form 1:
> template <class T>
> class Blah
> {
>   Blah(Blah &);   // <--
>   Blah &operator=(Blah &); // <--
> };

> Form 2:
> template <class T>
> class Blah
> {
>   Blah(Blah<T> &);  // <---
>   Blah &operator=(Blah<T> &) // <---
> };

Form 2 is correct.  Form 1 is not.  The only time the template name
can be used without the formal argument list is when it is the name of
the constructor.

--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++




Author: jamshid@ses.com (Jamshid Afshar)
Date: Sat, 13 Nov 1993 01:14:15 GMT
Raw View
In article <1993Nov11.175035.16944@euniice.canada.dg.com>,
%Allen B. Taylor <allen@eUNiiCE.canada.dg.com> wrote:
> template <class T>
> class Blah {
>   public:
>   Blah(Blah &);   // <--
>   Blah &operator=(Blah &); // <--
vs.
>   Blah(Blah<T> &);  // <---
>   Blah &operator=(Blah<T> &) // <---
> };
>
>I suspect that form 2 is closer to proposed ANSI, but the latest documentation
>I have is the Ellis & Stroustrup ARM, which manages to avoid the subject
>entirely.

ARM 14.7 uses the example:

 template<class T> class task {
   //...
   friend task<T>* preempt(task<T>*);  // error
   friend task* prmpt(task*);  // error
 }

and says "The declaration of prmpt() is an error because there is no
type `task', only specific template types, task<int>, task<record>,
and so on".  I think the same rule applies to non-friend declarations
within a class.  So, I don't think your first version is strictly
legal according to the ARM -- you must use <T>.

For code readability's sake, it's possible that ANSI/ISO C++ will
relax this rule to allow the template-name to be used anywhere in the
scope of the template as template-name<template-arg-list>.  In that
case both versions of your code and prmpt() above will be legal.

Jamshid Afshar
jamshid@ses.com




Author: rfg@netcom.com (Ronald F. Guilmette)
Date: Mon, 15 Nov 1993 08:51:07 GMT
Raw View
In article <1993Nov11.175035.16944@eUNiiCE.canada.dg.com> allen@eUNiiCE.canada.dg.com (%Allen B. Taylor) writes:
>Can anyone tell me if either of the two specifications for copy constructor and
>assignment operator are correct or incorrect?  Borland C++ seems to accept both
>forms, but Form 1 has been reject on other compilers I've tried.
>
> Form 1:
> template <class T>
> class Blah
> {
>   T *x;
>   public:
>   Blah();
>   Blah(Blah &);   // <--
>   Blah &operator=(Blah &); // <--
> };
>
> Form 2:
> template <class T>
> class Blah
> {
>   T *x;
>   public:
>   Blah();
>   Blah(Blah<T> &);  // <---
>   Blah &operator=(Blah<T> &) // <---
> };
>
>I suspect that form 2 is closer to proposed ANSI, but the latest documentation
>I have is the Ellis & Stroustrup ARM, which manages to avoid the subject
>entirely.

This is a little know flaw (which some folks would prefer to call a "feature")
in several C++ compilers.

In general, when referencing a template your reference must be of the general
form `TNAME<targs>', however within the definition of the template itself,
some compilers allow you to omit the <targs> part, with the understanding
that this implies a reference to the *current* instance of the template
(with whatever args were used to create the "current" instantiation).

I personally feel that this bit of semantic sugar is totally unnecessary and
altogether ill-advised, however I believe that the committee is heading in
the general direction of accepting it anyway.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------




Author: JCARTER@LINCOLN.GPSEMI.COM
Date: Mon, 15 Nov 1993 14:25:15 GMT
Raw View
In article <rfgCGIz98.K1r@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <1993Nov11.175035.16944@eUNiiCE.canada.dg.com> allen@eUNiiCE.canada.dg.com (%Allen B. Taylor) writes:
>>Can anyone tell me if either of the two specifications for copy constructor and
>>assignment operator are correct or incorrect?  Borland C++ seems to accept both
>>forms, but Form 1 has been reject on other compilers I've tried.
>>
>> Form 1:
>> template <class T>
>> class Blah
>> {
>>   T *x;
>>   public:
>>   Blah();
>>   Blah(Blah &);   // <--
>>   Blah &operator=(Blah &); // <--
>> };
>>
>> Form 2:
>> template <class T>
>> class Blah
>> {
>>   T *x;
>>   public:
>>   Blah();
>>   Blah(Blah<T> &);  // <---
>>   Blah &operator=(Blah<T> &) // <---
>> };
>>
>>I suspect that form 2 is closer to proposed ANSI, but the latest documentation
>>I have is the Ellis & Stroustrup ARM, which manages to avoid the subject
>>entirely.
>
>This is a little know flaw (which some folks would prefer to call a "feature")
>in several C++ compilers.
>
>In general, when referencing a template your reference must be of the general
>form `TNAME<targs>', however within the definition of the template itself,
>some compilers allow you to omit the <targs> part, with the understanding
>that this implies a reference to the *current* instance of the template
>(with whatever args were used to create the "current" instantiation).
>
>I personally feel that this bit of semantic sugar is totally unnecessary and
>altogether ill-advised, however I believe that the committee is heading in
>the general direction of accepting it anyway.
>
>--
>
>-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
>------ domain address: rfg@netcom.com ---------------------------------------
>------ uucp address: ...!uunet!netcom.com!rfg -------------------------------




Author: r.lightwood@trl.oz.au (Liron Lightwood)
Date: Mon, 15 Nov 1993 23:34:24 GMT
Raw View
grumpy@cbnewse.cb.att.com (Paul J Lucas) writes:

>From article <1993Nov11.175035.16944@eUNiiCE.canada.dg.com>, by allen@eUNiiCE.canada.dg.com (%Allen B. Taylor):

>>        Form 1:
...
>>    Blah(Blah &);   // <--
>>    Blah &operator=(Blah &); // <--

and
>>        Form 2:
...
>>    Blah(Blah<T> &);  // <---
>>    Blah &operator=(Blah<T> &) // <---
>>

> Form 2 is legal and will always be accepted; form 1, I believe
> is becoming legal.  IMHO, I wish they would have just picked one
> and stuck with it.  Yet more confusion.

HOWEVER

Shouldn't the argument be a const in both cases?
i.e.

            Blah(const Blah<T>&);
and
            Blah &operator=(const Blah<T>&);

If this is the case, then both form 1 and form 2 above are INCORRECT forms of
the copy constructor and assignment operator.

Any comments?

Liron Lightwood                       Internet: r.lightwood@trl.oz.au
Research Laboratories                 Phone: +61 3 253 6535
Telstra / Telecom Australia           Fax:   +61 3 253 6362
P.O. Box 249 Clayton 3168 Australia   Disclaimer: My views, not my company's.