Board index » cppbuilder » Re: Declarations that declare nothing

Re: Declarations that declare nothing


2008-07-01 02:28:48 AM
cppbuilder91
"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote:
Quote
Put the constructor into the class' private area.
I do prefer the current situation though. It's annoying enough to have
to do that with the copy c'tor and assignment operator in such cases,
without having to do so with a default c'tor as well.
Alan Bellingham
--
Team Browns
ACCU Conference 2009: to be announced
 
 

Re:Re: Declarations that declare nothing

"Alan Bellingham" < XXXX@XXXXX.COM >wrote in message
Quote
"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote:

>Put the constructor into the class' private area.

I do prefer the current situation though. It's annoying enough to have
to do that with the copy c'tor and assignment operator in such cases,
without having to do so with a default c'tor as well.
I can see that. I think it's just a matter of taste. I prefer
to not have to create the default one when that's the normal
case.
The behavior that always confuses me is when someone
writes a dtor like:
~someObject() {}
I always wonder if it's replacing the default dtor. I know
it's not but then I wonder why it's not.
 

Re:Re: Declarations that declare nothing

Quote
>>Put the constructor into the class' private area.
Don't you mean the protected area?
Quote
>
>I do prefer the current situation though. It's annoying enough to
have
>to do that with the copy c'tor and assignment operator in such
cases,
>without having to do so with a default c'tor as well.

I can see that. I think it's just a matter of taste. I prefer
to not have to create the default one when that's the normal
case.

The behavior that always confuses me is when someone
writes a dtor like:

~someObject() {}

I always wonder if it's replacing the default dtor. I know
it's not but then I wonder why it's not.

Has anything been gained by making a destructor protected? A protected
constructor prevents unwanted instantiation.
Fraser.
 

{smallsort}

Re:Re: Declarations that declare nothing

"Fraser Ross" < XXXX@XXXXX.COM >wrote in message
Quote
>>>Put the constructor into the class' private area.

Don't you mean the protected area?
No. Alan implied that he wanted to prevent the default
ctor from being invoked. If it's protected it can be invoked
in a derived class.
Quote
>The behavior that always confuses me is when someone
>writes a dtor like:
>
>~someObject() {}
>
>I always wonder if it's replacing the default dtor. I know
>it's not but then I wonder why it's not.
>

Has anything been gained by making a destructor protected? A protected
constructor prevents unwanted instantiation.
None that I can think of at the moment but that's not
what I was referring to.
 

Re:Re: Declarations that declare nothing

Quote
>>>Put the constructor into the class' private area.

Don't you mean the protected area?
I meant private
If what you want is no viable default constructor, asking for an addition to
the compiler is redundant. You can achieve it with all flavors of C++, even
that from 1990 by declaring it in the private area where nothing but a class
instance or item declared as a friend can access it.
Quote
Has anything been gained by making a destructor protected? A
protected constructor prevents unwanted instantiation.
If protected it can also be invoked by an instance of a descendent class.
If private it cannot.
Quote
>~someObject() {}
>
>I always wonder if it's replacing the default dtor. I know
>it's not but then I wonder why it's not.
As I understand it, if you provide a destructor then no other destructor
will be quietly provided by the compiler. If you do not provide a
destructor then the default one will be provided by the compiler. Therefore
you cannot supply a default constructor because you are not the compiler.
. Ed
Quote
Fraser Ross wrote in message
news:48695f8b$ XXXX@XXXXX.COM ...

>>>Put the constructor into the class' private area.

Don't you mean the protected area?

>I do prefer the current situation though. It's annoying enough to
>have to do that with the copy c'tor and assignment operator in
>such cases without having to do so with a default c'tor as well.
>
>I can see that. I think it's just a matter of taste. I prefer
>to not have to create the default one when that's the normal
>case.
>
>The behavior that always confuses me is when someone
>writes a dtor like:
>
>~someObject() {}
>
>I always wonder if it's replacing the default dtor. I know
>it's not but then I wonder why it's not.

Has anything been gained by making a destructor protected? A protected
constructor prevents unwanted instantiation.
 

Re:Re: Declarations that declare nothing

Duane Hebert wrote:
Quote
"Alan Bellingham" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote:
>
>>Put the constructor into the class' private area.
>I do prefer the current situation though. It's annoying enough to have
>to do that with the copy c'tor and assignment operator in such cases,
>without having to do so with a default c'tor as well.

I can see that. I think it's just a matter of taste. I prefer
to not have to create the default one when that's the normal
case.
I can't decide on this issue. As an experienced C++
programmer, I don't see what the new syntax gains,
that we didn't have by declaring stuff private. As a
C++ teacher, I know that declaring stuff private
seems a very obscure technique to novices.
If there's any changes regarding the way we control
the creation of those special member functions (e.g.
dctor cctor, dtor, asop) by the compiler, I'd really
like to have a simple to remember and very obvious
to understand syntax for preventing it, plus the
elimination of the difference between the conditions
for automatic creation of the dctor and all the other
special member functions.
I've found that students have a hard time remembering
the latter and while they find that having to write
those functions in order to not to have them is a
rather strange and subtle way.
Quote
[...]
Schobi
 

Re:Re: Declarations that declare nothing

"Ed Mulroy [TeamB]"
Quote
>Has anything been gained by making a destructor protected? A
>protected constructor prevents unwanted instantiation.

If protected it can also be invoked by an instance of a descendent
class.
If private it cannot.
I meant making the destructor protected instead of public. I can't
think of anything. An instantiation can be prevented by making the
constructors non-public. A non-public destructor can't do a job that is
already done.
Fraser.
 

Re:Re: Declarations that declare nothing

"Fraser Ross" < XXXX@XXXXX.COM >wrote:
Quote
I meant making the destructor protected instead of public.
Making a destructor protected is, in my experience, useful for one
thing, which is preventing deletion of the derived class by the pointer
to base.
(It's also a signal that your class isn't to be considered as a complete
object yet.)
If you want that, then the chances are that your base is some form of
'mix-in' class, providing functionality to the derived class, but not
being what the derived class is to be considered in the 'Is-A'
hierarchies.
For example, consider a drawing package. A circle may be derived
normally from a Shape, and therefore Is-A Shape. But it might also be
derived from Serialisable, which contains common code for writing the
object. Private derivation isn't appropriate, since you wish to be able
to call the write() method on your Circle, and also on, say, your
ColourPalette object (and a ColourPalette is obviously not a Shape). But
any code dealing with pointers to Serialisable probably shouldn't be
deleting those objects, and the easiest way to ensure that is to make
deletion through those pointers impossible.
Making a destructor private is a different thing - usually to be found
with COM-style AddRef/Release semantics.
Alan Bellingham
--
Team Browns
ACCU Conference 2009: to be announced
 

Re:Re: Declarations that declare nothing

"Alan Bellingham"
Quote
"Fraser Ross"

>I meant making the destructor protected instead of public.

Making a destructor protected is, in my experience, useful for one
thing, which is preventing deletion of the derived class by the
pointer
to base.
There is a reason then.
I'm not particularly impressed by the proposal N2326.
There are two methods that are used to make an abstract base class. One
is with a pure virtual function, usually the destructor. The other is
by making the constructors and destructor protected but there are
loopholes to that method such as friends.
Has nobody ever suggested a keyword to signify an ABC such as:
class abstractbase {
};
? If the constructors and destructor are implicitly protected then is
what is wanted without doing much typing.
If a polymorphic deletion is required a second keyword could imply a
public destructor:
class abstractbase polymorphicdestroy {
};
Fraser.
 

Re:Re: Declarations that declare nothing

"Fraser Ross" < XXXX@XXXXX.COM >wrote in message
Quote
There are two methods that are used to make an abstract base class. One
is with a pure virtual function, usually the destructor. The other is
by making the constructors and destructor protected but there are
loopholes to that method such as friends.
I think that there is only one way to make a class abstract and
that is to have it include a pure virtual function. Making the ctor
protected (or private BTW) doesn't prevent the class from being
instantiated. Check out the singleton pattern for example.
Quote
Has nobody ever suggested a keyword to signify an ABC such as:

class abstractbase {
};
I think the pure virtual function(s) idea is fine.
Quote
? If the constructors and destructor are implicitly protected then is
what is wanted without doing much typing.
If a polymorphic deletion is required a second keyword could imply a
public destructor:

class abstractbase polymorphicdestroy {
};
??? I want polymorphic destruction to be automatic
as it is now with my virtual dtor. You know that you
don't need an abstract base class to have
polymorphic behavior? You just need to use
inheritance and a base class pointer. Or am I
just not following you?
 

Re:Re: Declarations that declare nothing

Quote
>Has nobody ever suggested a keyword to signify an ABC such as:
>
>class abstractbase {
>};

I think the pure virtual function(s) idea is fine.
There is a cost to adding virtual functions. It doesn't look to me that
abstract classes were seen as important when C++ was invented.
I'd rather have a keyword that makes a class have the defaults I want
than have to write out all the special members. Most classes fall into
certain categories of use. This new syntax with default and delete is
orthogonal to access scope, as is friend declarations. Is anything
else?
Fraser.
 

Re:Re: Declarations that declare nothing

"Fraser Ross" < XXXX@XXXXX.COM >wrote in message
Quote
>>Has nobody ever suggested a keyword to signify an ABC such as:
>>
>>class abstractbase {
>>};
>
>I think the pure virtual function(s) idea is fine.

There is a cost to adding virtual functions. It doesn't look to me that
abstract classes were seen as important when C++ was invented.
I'm having a hard time following your logic. You were talking about
abstract base classes. If I want an ABC, it's probably to use as
an interface and I don't see the utility of that without virtual functions.
In fact, I would consider an abstract base class without a virtual dtor
an error in most cases.
Quote

I'd rather have a keyword that makes a class have the defaults I want
than have to write out all the special members. Most classes fall into
certain categories of use. This new syntax with default and delete is
orthogonal to access scope, as is friend declarations. Is anything
else?
I would prefer to have the default behavior more intuitive and
have the ability to override it when I intend to. As I said up thread,
I don't see why the default ctor is not created when a user supplied
NON default ctor is added. I think the compiler should supply a
default ctor unless the user supplies a default one.
 

Re:Re: Declarations that declare nothing

"Duane Hebert" < XXXX@XXXXX.COM >writes:
Quote
"Fraser Ross" < XXXX@XXXXX.COM >wrote in message
news:486a42ed$ XXXX@XXXXX.COM ...

>There are two methods that are used to make an abstract base class. One
>is with a pure virtual function, usually the destructor. The other is
>by making the constructors and destructor protected but there are
>loopholes to that method such as friends.

I think that there is only one way to make a class abstract and
that is to have it include a pure virtual function. Making the ctor
protected (or private BTW) doesn't prevent the class from being
instantiated. Check out the singleton pattern for example.
That's true, but only to the extent that other code is a friend or
otherwise has access to the constructors. If you cannot access the
constructor at all, and cannot call code that has such access, the
class is "effectively" abstract, in that it's not instantiable.
The singleton pattern can work with an internal or external singleton
interface. The External interface is performed in a seperate class,
and it requires that requires that the constructor of its <T>object
is public, or that the it is a friend of <T>such that it can access
the constructor. Alternately, the singleton "interface" can be bolted
directly onto a class, exposing an "instance" method that internally
allocates an object.
Not that I'm a big fan of singletons. The more I use them, the less I
wish I had to! They make it very difficult to unit-test code and make
it hard to simulate two processes running in one. (Process A runs
normlly on one host, process B runs on another host, each has their
own singletons. But say you want to write a test that simulates
process A and B in one real process, by instantiating the tested
component twice. How do you make one object use one singleton and the
other object use the other?)
I haven't found a good solution to that other than to fork a child
process and marshal commuincations through pipes or sockets. A real
pain.
Quote
??? I want polymorphic destruction to be automatic
as it is now with my virtual dtor. You know that you
don't need an abstract base class to have
polymorphic behavior? You just need to use
inheritance and a base class pointer. Or am I
just not following you?
... and virtual functions. :)
--
Chris (TeamB);
 

Re:Re: Declarations that declare nothing

"Fraser Ross" < XXXX@XXXXX.COM >writes:
Quote
There is a cost to adding virtual functions. It doesn't look to me that
abstract classes were seen as important when C++ was invented.
What definition of "abstract" are you using? Given your first
sentence, it sounds like like would like polymorphism without virtual
functions? Well, there is compile-time "static" polymorphism, but
it's a compmile-time polymorphism, with the morph only happening once,
when the program is built.
--
Chris (TeamB);
 

Re:Re: Declarations that declare nothing

"Chris Uzdavinis (TeamB)"
Quote
"Fraser Ross"

>There is a cost to adding virtual functions. It doesn't look to me
that
>abstract classes were seen as important when C++ was invented.

What definition of "abstract" are you using? Given your first
sentence, it sounds like like would like polymorphism without virtual
functions? Well, there is compile-time "static" polymorphism, but
it's a compmile-time polymorphism, with the morph only happening once,
when the program is built.
I want to prevent a class from being used to create concrete objects
without having a pure virtual function. This is not for polymorphism.
Its only to aid the programmer. At present I can define the
constructors, destructor, asop and copy constructor with protected
access but that takes quite a lot of typing. If this for instance was a
recognised syntax I would have what I want:
class name protected {
};
Fraser.