Topic: Designating constructors and destructors


Author: Petter Urkedal <petter@matfys.lth.se>
Date: 1999/01/15
Raw View
Graeme Bell wrote:
>
> Rather than create a new keyword why not (in the tradition of C/C++ :-)
> overload yet another existing one. No doubt I'm missing something obvious,
> but wouldn't "this" be a sensible candidate?.

For ctors and dtors, it would work, but is it intuitive enough?
However, `this' could not be used to denote the type of the class inside
member functions, so then the original point with a `self'-keyword is
lost
(see thread `Self & Inherited').

--
[- http://matfys.lth.se/~petter/ -]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1999/01/17
Raw View
Graeme Bell wrote:
>
> Petter Urkedal wrote in message <369B92D0.8C6F6582@matfys.lth.se>...
> >
> >Note, however, that a new keyword breaks present code, so it would be
> >better if `self' was treated as an automatically typedefed identifier
> >which could be overridden by a local typedef, but which would
> >nevertheless take precedence over a namespace or global identifier
> >(and thus still break some present code, but probably much less).
>
> Rather than create a new keyword why not (in the tradition of C/C++ :-)
> overload yet another existing one. No doubt I'm missing something obvious,
> but wouldn't "this" be a sensible candidate?.

No:

class X
{
public:
  this(int); // would be OK here
  this f()   // and here
  {
    return this(*this); // but not here
  }
};

But:

class X
{
public:
  self(int); // would be Ok
  self f()   // would be Ok
  {
    return self(*this); // would be Ok
  }
};
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: David R Tribble <dtribble@technologist.com>
Date: 1999/01/13
Raw View
mlsheltn@SPAM.memphis.edu (Xeno) writes:
>> C++ confused me for a while with the way constructors and destructors
>> are designated.
>>
>> Suppose that C++ merely had the keywords "constructor" and
>> "destructor" defined and used in the same way the access keywords
>> were applied?

Steve Clamage wrote:
> I don't see how your suggestion is superior to actual C++ syntax.
>
> Constructors:
> If you see what looks like a function that has the same name as a
> class, it is a constructor. No other function can be a constructor,
> so there should never be any confusion. If you could provide any
> name you like for constructors, it could be difficult to
> recognize them.

(And then there's the Eiffel approach.  When you declare a class,
you declare one or more "create" functions (constructors) for the
class; the Eiffel syntax has a special keyword and place in the
class declaration just for this purpose.)

If C++ did allow a class to have ctor functions with different
names (which differ from the class name), then it would also have
to require a 'Type::' prefix to specify the class type when
creating such an object.  It would also need some way to indicate
what the default ctor was for situations where it must be deduced
from the type alone.

For example:
    class Foo
    {
    public:
        constructor  make() default;   // default ctor
        constructor  fromInt(int i);   // another ctor
        ...
    };

    void foo(int i)
    {
        Foo    obj;               // calls Foo::make()
        Foo *  fp = new Foo;      // calls Foo::make()
        Foo *  f2 = new Foo::make();
        Foo *  fi = new Foo::fromInt(i);
        ...
    }

(One of the drawbacks to Eiffel is that it doesn't support function
overloading, which for the case at hand means that all of the
ctors for a class have to have different names.  C++ is better
in this regard; I could have called Foo::fromInt(int) simply
Foo::make(int).)

> Destructors:
> In principle, ~Foo() might mean "take the one's complement of the
> value returned by function Foo." But if you could provide any name
> you like for destructors, the opportunity for confusion is even
> greater -- you could never recognize a destructor call without
> examining the class definition.

I can't find a good reason for having more than one dtor for a
class, thus I see no reason for a 'destructor' keyword.  The tilde
syntax may be somewhat annoying, but rarely are programmers
bothered with calling a dtor explicitly anyway; they usually only
have to bother declaring and defining them.

> As with any language, some idioms look odd at first; with
> experience, they cease to be confusing.
>
> You can read more about this design decision (and many others)
> in Stroustrup's book "The Design and Evolution of C++".

And why pick on one particular idiom of C++?  There are plenty of
other "hard to read" and "annoying" idioms in C++ (and any other
language, for that matter) to choose from.  Good programmers ought
to be more concerned with writing good, readable, correct code in
the language at hand, however "flawed" it might be.

-- David R. Tribble, dtribble@technologist.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Petter Urkedal <petter@matfys.lth.se>
Date: 1999/01/13
Raw View
Chris Minnoy wrote:
>
> I don't think its a wise idea to change a thing about the constructor
> syntax.
> Having constructors and destructors with the same name as the class
> isn't to bad. However, if there has to be a change, than I think it's better
> to replace the constructor names by constructor and the destructor
> name by destructor BUT leave all the rest unchanged.
> This has the advantage that if the class name changes you have less
> function-names to change.

To the last statement I agree, but you have already proposed a
`Self'-keyword (or `self' to make it consistent with C++ naming
convention) in your message `Self & Inherited', so why not reuse
this keyword in that case. Your example then becomes

  class Base
  {
  public:
      self();    // default constructor
      self( const Base& ); // copy constructor
      self( int ); // init constructor
      virtual ~self() throw(); // destructor
  };

etc.  This would come naturally from the `self'-extension (together
with the relaxation of the requirement that the constructor shall
not be a typedefed name).

BTW, I don't think the tilde is so bad (maybe `!' would be better,
but now it's specified to be `~' anyway).

Note, however, that a new keyword breaks present code, so it would be
better if `self' was treated as an automatically typedefed identifier
which could be overridden by a local typedef, but which would
nevertheless take precedence over a namespace or global identifier
(and thus still break some present code, but probably much less).

 -petter.

--
[- http://matfys.lth.se/~petter/ -]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: "Graeme Bell" <graemeb@ihug.co.nz>
Date: 1999/01/14
Raw View
Petter Urkedal wrote in message <369B92D0.8C6F6582@matfys.lth.se>...
>
>Note, however, that a new keyword breaks present code, so it would be
>better if `self' was treated as an automatically typedefed identifier
>which could be overridden by a local typedef, but which would
>nevertheless take precedence over a namespace or global identifier
>(and thus still break some present code, but probably much less).

Rather than create a new keyword why not (in the tradition of C/C++ :-)
overload yet another existing one. No doubt I'm missing something obvious,
but wouldn't "this" be a sensible candidate?.

Graeme.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: mlsheltn@SPAM.memphis.edu (Xeno)
Date: 1999/01/10
Raw View
C++ confused me for a while with the way constructors and destructors are
designated.

Suppose that C++ merely had the keywords "constructor" and "destructor"
defined and used in the same way the access keywords were applied?

An example of current class syntax:

class Foo
 {
 private:
  int a;
  int b;
  Foo::Foo(); // constructor
 public:
  // rest of class functions and data
 private:
  ~Foo::Foo(); // destructor
 }

An example of proposed class syntax:

class Foo
 {
 private:
  int a;
  int b;
  constructor:
   anyname1(); //constructor
 public:
  // normal data and functions here
 private:
  destructor:
   anyname2(); //destructor
 }

And if you wanted to define multiple constructors:

class Foo
c {
 private:
  int a;
  int b;
  constructor:
   {
   anyname1();
   anyname2(int parm1);
   anyname3(int parm1, float parm2);
   }
 public:
  // rest of clas functions and data
 private:
  destructor:
   anyname4(); // destructor
 }

The constructor keyword works like the for and if keywords; if they aren't
followed by braces, they assume there is only one statement assigned to
them (and in this case one constructor defined). If multiple constructors
were intended but the programmer neglected the braces, the second and
subsequent constructors would end up never being called, being assumed to
be normal functions, and instances of the class intended to auto-call these
constructors would not be properly initialized, a bug that would probably
be difficult to track down. A solution might be to define a third keyword
to delineate where constructors and destructors stopped and normal
functions began, e.g.,

class Foo
c {
 private:
  int a;
  int b;
  constructor:
   anyname1();
   anyname2(int parm1);
   anyname3(int parm1, float parm2);
  normal:
   // some other private functions and data
 public:
  // rest of class functions and data
 private:
  destructor:
   anyname4();
 };

The inclusion of an access keyword could and probably also act the same way
(replacing normal with another private or any appropriate access keyword,
for instance). Multiple constructors with heterogenous access types are
AFAIK rare enough that having them defined manually isn't too time
consuming.


I don't understand copy constructors too well so I can't comment on them
yet. If multiple destructors were invented, they might also be implemented
in this way.

<private opinion section>
IMHO, I don't know why C++ wasn't done this way in the first place ...
requiring the functions to carry the same identifier as the class, with the
potentially confusing (to new users) requirement of having one name for
several functions, then having to use the (IMO tacky) tilde just to
designate the destructors; it's all just ambiguous and unnecessary IMO,
easily remedied with only two or three more keywords which would clearly
disambiguate things anyway and reduce the necessity of function name
overloading.


O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O=O
 Matthew Shelton a.k.a. Xeno, Man of Mystery and
 Master Supreme Imperial Overlord Commander
 Plenipotentiary, First Class, of the Cubical Empire
 * E-mail: mlsheltn@[latte OR mocha].memphis.edu
 * Homepage: http://www.people.memphis.edu/~mlsheltn
 Solicitors: DO NOT send me advertisements. If I
 want something, I'll come looking for it ...


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1999/01/10
Raw View
mlsheltn@SPAM.memphis.edu (Xeno) writes:

>C++ confused me for a while with the way constructors and destructors are
>designated.

>Suppose that C++ merely had the keywords "constructor" and "destructor"
>defined and used in the same way the access keywords were applied?

I don't see how your suggestion is superior to actual C++ syntax.

Constructors:
If you see what looks like a function that has the same name as a
class, it is a constructor. No other function can be a constructor,
so there should never be any confusion. If you could provide any
name you like for constructors, it could be difficult to
recognize them.

Destructors:
In principle, ~Foo() might mean "take the one's complement of the
value returned by function Foo." But if you could provide any name
you like for destructors, the opportunity for confusion is even
greater -- you could never recognize a destructor call without
examining the class definition.

As with any language, some idioms look odd at first; with
experience, they cease to be confusing.

You can read more about this design decision (and many others)
in Stroustrup's book "The Design and Evolution of C++".

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Parker Shaw <parkershaw@usa.net>
Date: 1999/01/10
Raw View
The current C++ syntax is quit good, and CONCISE.
Add constructor/destructor keywords will bring more
confusion, not less.

If constructor uses the same name as class, we can write
Stack *s=new Stack(10);

If constructor uses any name,
should we insert "class::" in front of constructor call?
How to prevent two constructors has the same signature?

Stack *s=new Stack::Anyname(10);

Stack *s=new Anyname(10);
List *l=new Anyname(10);

Also remember, a class only has ONE destructor.

Just as Steve said:
>As with any language, some idioms look odd at first; with
>experience, they cease to be confusing.

--
________________________________________________
Parker Shaw                  |  Make it correct
psha042@cs.auckland.ac.nz    |  Make it elegant
________________________________________________
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/01/10
Raw View
In article <3697dbf0.77978350@news.memphis.edu>, Xeno
<mlsheltn@SPAM.memphis.edu> writes
>IMHO, I don't know why C++ wasn't done this way in the first place ...
>requiring the functions to carry the same identifier as the class, with the
>potentially confusing (to new users) requirement of having one name for
>several functions, then having to use the (IMO tacky) tilde just to
>designate the destructors; it's all just ambiguous and unnecessary IMO,
>easily remedied with only two or three more keywords which would clearly
>disambiguate things anyway and reduce the necessity of function name
>overloading.

While I have some sympathy for your unhappiness with the way it is done,
the decision was not arbitrary.  Not least we have the advantage that we
can, at sight, distinguish a class ctor.  With your suggestion I would
have to keep looking back at the class definition to see if a name was a
ctor or not.

I am not sure why you think using a tilde is tacky, its meaning in C and
C++ is NOT and that seems a perfectly sensible way to distinguish a dtor
from a ctor.

While some programmers overdo function name overloading even the new
version of C (C9X) sneeks it in by the backdoor to handle mathematical
functions (I think that is a mistake, but that is another story)

BTW any apparent ambiguity is just that.  If I want to construct a class
instance I know what I must write, and if I provide an inappropriate or
ambiguous set of arguments the compiler will tell me.



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: James Kuyper <kuyper@wizard.net>
Date: 1999/01/11
Raw View
Xeno wrote:
....
> <private opinion section>
> IMHO, I don't know why C++ wasn't done this way in the first place ...
> requiring the functions to carry the same identifier as the class, with the
> potentially confusing (to new users) requirement of having one name for
> several functions, then having to use the (IMO tacky) tilde just to
> designate the destructors; it's all just ambiguous and unnecessary IMO,
> easily remedied with only two or three more keywords which would clearly
> disambiguate things anyway and reduce the necessity of function name
> overloading.

Function overloading is one of the most important features of C++;
functions which perform similar tasks using different inputs have the
same name. All constructors have the same task - constructing a valid
object of the specified type, so it's appropriate that they are called
the same way. That way, the work of figuring out which one to call can
be left up to the compiler, based upon the arguments provided by the
caller.

Another important advantage of the way it was done is that the basic
types and user-defined types can use similar syntax. I can write
string("Xyz"), or float(3); in either case, the result is an object of
the specified type constructed from the given argument. This is
particularly convenient for template programming. If you're still
learning about ctors and dtors, you probably haven't studied templates
yet, so it may be a while before you see why that's convenient.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: AllanW@my-dejanews.com
Date: 1999/01/12
Raw View
In article <3697dbf0.77978350@news.memphis.edu>,
  mlsheltn@SPAM.memphis.edu (Xeno) wrote:
>
> C++ confused me for a while with the way constructors and destructors are
> designated.

Others have already commented on this better than I can. It seems
that what you're really objecting to is doing things in a way that
you're not used to. But this isn't a valid objection for any
language. The language wouldn't exist if it didn't contribute
something new; that something new will always (by definition) seem
unfamiliar at first.

> Suppose that C++ merely had the keywords "constructor" and "destructor"
> defined and used in the same way the access keywords were applied?

Your suggestion, as offered, does not seem very palatable. We want
to be able to identify the constructor and destructor, and the
current rule seems to satisfy that quite well.

However, what if we changed it slightly? Instead of using Foo() as
the name of class Foo's constructor, use a keyword "construct"?

    class Foo {
        int i;
    public:
        construct() : i(0) { }
        construct(int x) : i(x) { }
        construct(const Foo&f) : i(f.i) { }
        destruct() { }
    };

Calling the constructors would be the same as we have now:

    {
        Foo x(3);            // Calls Foo::construct(int)
        Foo *y = new Foo(x); // Calls Foo::construct(const Foo&)
        Foo *z = new Foo();  // Calls Foo::construct()
        delete z;            // Calls Foo::destruct()
        delete y;            // Calls Foo::destruct()
    }   // As x goes out of scope, calls Foo::destruct()

The advantage would have been to simplify some of the rules in
template classes:

    template<class T>class Bar {
    public:
        Bar<T>(); // Oops -- that should be Bar(); without the <T>
        ~Bar();   // This is right... isn't it?
        // ...
    };
    typedef Bar<int> bi;
    bi*x = new bi;
    // Delete but don't deallocate:
    x->~bi(); // Oops! That's x->~Bar(); ...or is it x->~Bar<T>();

Could be replaced by:

    template<class T>class Bar {
    public:
        construct(); // Easy
        destruct();  // Easy
        // ...
    };
    typedef Bar<int> bi; // Same syntax
    bi*x = new bi;
    // Delete but don't deallocate:
    x->destruct();       // Very easy

---
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: "Chris Minnoy" <cminnoy@starlab.net>
Date: 1999/01/12
Raw View
I don't think its a wise idea to change a thing about the constructor
syntax.
Having constructors and destructors with the same name as the class
isn't to bad. However, if there has to be a change, than I think it's better
to replace the constructor names by constructor and the destructor
name by destructor BUT leave all the rest unchanged.
This has the advantage that if the class name changes you have less
function-names to change.

eg.

class Base
{
public:
    constructor();    // default constructor
    constructor( const Base& ); // copy constructor
    constructor( int ); // init constructor
    virtual destructor throw(); // destructor
};

Base::constructor() { /*...*/ }
Base::constructor( const Base& rhs ) { /*...*/ }
Base::constructor( int ) { /*...*/ }
Base::destructor() { /*...*/ }

However, if you derive from a class, you do need the same way of calling
a base class as before.

class Derived : public Base
{
public:
    constructor( const Derived& );
};

Derived::constructor( const Derived& rhs )
    : Base( rhs )  // !!!
{
//...
}

Chris Minnoy
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Boris Schaefer <sbo@psy.med.uni-muenchen.de>
Date: 1999/01/12
Raw View
mlsheltn@SPAM.memphis.edu (Xeno) writes:

| C++ confused me for a while with the way constructors and destructors are
| designated.
|
| Suppose that C++ merely had the keywords "constructor" and "destructor"
| defined and used in the same way the access keywords were applied?
|
| An example of current class syntax:
|
| class Foo
|  {
|  private:
|   int a;
|   int b;
|   Foo::Foo(); // constructor
              //^^^^^^^^^^
              // this is illegal, should be: Foo();
|  public:
|   // rest of class functions and data
|  private:
|   ~Foo::Foo(); // destructor
              //^^^^^^^^^^^
              // same as above, should be: ~Foo();
|  }
|

<snip>

| An example of proposed class syntax:

<snip>

| And if you wanted to define multiple constructors:
|
| class Foo
| c {
|  private:
|   int a;
|   int b;
|   constructor:
|    {
|    anyname1();
|    anyname2(int parm1);
|    anyname3(int parm1, float parm2);
|    }
|  public:
|   // rest of clas functions and data
|  private:
|   destructor:
|    anyname4(); // destructor
|  }

First off, I don't understand why you explicitely make all the
contructors and destructors private.  This way you can't create or
destroy objects of your class, except from friends and static member
functions.  I doubt that this is what you want.

Now, to your proposed syntax.

I don't like it.  When I look at at a file containing the definition
of the class members, with the current syntax I can easily spot the
constructors.  Everything that has the class name as function name and
no return value is a constructor.  Your syntax looses this capability,
because the definition of a constructor would look like this:

Foo::somename() { // some code }

Now you might say, that it's still distinguishable, because it dosen't
have a return value, but IMHO, it's worse than the current syntax.

<snip>

| <private opinion section>
| IMHO, I don't know why C++ wasn't done this way in the first place ...
| requiring the functions to carry the same identifier as the class, with the
| potentially confusing (to new users) requirement of having one name for
| several functions, then having to use the (IMO tacky) tilde just to
| designate the destructors; it's all just ambiguous and unnecessary IMO,
| easily remedied with only two or three more keywords which would clearly
| disambiguate things anyway and reduce the necessity of function name
| overloading.

I think the syntax is intuitive.  Look at the for allocating a Foo:

  Foo* f = new Foo(); // or Foo* f = new Foo;

would you like to change this to:

  Foo* f = new Foo::some_name();

or to:

  Foo* f = new some_name(); // which you shouldn't do, because
                            // some_name wasn't declared in this
                            // scope if it's a `named' constructor.

The current syntax makes it explicit that you want to create a Foo
object.  The alternative syntices (hmm, I don't think that spelling's
correct) could be mistaken for function calls that return a Foo*.

Consider this:

class Foo
{
public:
  constructor:
    some_name1() { }

  static Foo* some_name2() { return new Foo(); }
};

int main()
{
  Foo* f = new Foo::some_name1();
  Foo* f = Foo::some_name2();
}

this will certainly confuse a lot of people.

--
Boris Schaefer -- sbo@psy.med.uni-muenchen.de

The idle mind knows not what it is it wants.
  -- Quintus Ennius


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: jim.hyslop@leitch.com
Date: 1999/01/12
Raw View
In article <m3iuedb8u7.fsf@skywalker.grs.de>,
  Boris Schaefer <sbo@psy.med.uni-muenchen.de> wrote:
>
[snip]
> | class Foo
> |  {
> |  private:
> |   int a;
> |   int b;
> |   Foo::Foo(); // constructor
>               //^^^^^^^^^^
>               // this is illegal, should be: Foo();

Huh?? Since when?  It is perfectly legal to use class qualification inside a
class definition.  "Foo::" is simply ignored as being redundant.  If your
compiler rejects the code, I suggest you get a new one.

> |  public:
> |   // rest of class functions and data
> |  private:
> |   ~Foo::Foo(); // destructor
>               //^^^^^^^^^^^
>               // same as above, should be: ~Foo();
Same as above, it's perfectly legal.  Try it.

[snip stuff I agree on re: syntax]

Jim
Note to recruitment agencies:  I delete unsolicited email from
recruitment agencies without reading it, so don't even bother.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]