why default assignment can NOT be used for const reference?

Originally Posted by anon

Sorry if it bothers you. I guess languages reflect the chauvinist history of mankind and I even try to use the neutral singular "they" sometimes, but I guess it would be easier to accept that

Mankind is a word that refers to all men of our kind.
He refers to everyone who is male or if you assume that the user/programmer IS male (which is not always the case).
Just because this is a programming forum, don't think you can get away with it

Originally Posted by CornedBee

Well, having a default implementation even of pure virtual functions is useful if there's stuff that most overriding functions have to do. (But not if all overriding functions have to do it - to enforce this, use the NVI pattern.)

The destructor thing is, admittedly, something of a hack. It's like a Java class with the abstract modifier but no abstract functions. You can't instantiate the class itself, but you can instantiate a subclass, even if it did nothing but derive.

I just realized that it's possible to make it that way, in case it's a valid reason for implentation of pure virtual functions.

Originally Posted by Elysia

Just because this is a programming forum, don't think you can get away with it

Yes, he can. What are you going to do about it?

Don't start an argument over this now.

Originally Posted by Elysia

Mankind is a word that refers to all men of our kind.
He refers to everyone who is male or if you assume that the user/programmer IS male (which is not always the case).
Just because this is a programming forum, don't think you can get away with it

The funny thing is, most people look at the use of generic "He" as being somehow sexist against females, when it is actually sexist against males if you think about it.

But then again, why then, does "she" exist, if you refer to everyone as "he"? Now that's something to ponder on.
It's not as much as being a sexist, most people don't even realize or think of it. Hey, it's what we always do, so why think about it? ...Or so they tend to think alike in the lines of thinking and thoughts.

I always refer to someone with a neutral word or way.

Originally Posted by Elysia

But then again, why then, does "she" exist, if you refer to everyone as "he"?

Maybe because women are inherently superior and so they're the ones who get the unambiguous pronoun

Oh now that's inheretely funny. The world works in a strange way, no?

I didn't mean to start a discussion, I meant to forestall one. I see that I've failed, so let me be more explicit:

There will be no more discussion of pronouns here, or I will have to delete the posts.

Originally Posted by CornedBee

I didn't mean to start a discussion, I meant to forestall one.

That didn't seem much like an attempt to stop one. Perhaps you should be more explicit instead?

I see that I've failed, so let me be more explicit:

There will be no more discussion of pronouns here, or I will have to delete the posts.

You're the boss. My lips are sealed. And the keys on my keyboard banned

Originally Posted by Elysia

Yes, I know what they are and everything, and it's exactly as I described. If were create pure virtual functions to make sure a class can't be instaciated, then what's the point of defining them when they're always overriden by derived classes?

The point of defining pure virtual functions is that they can be called, and the C++ standard explicitly allows them to be called. For example;

Code:

class Abstract
{
    public:
        virtual void f() = 0;
};

void Abstract::f()
{
     // perform some default action
}

class Concrete: public Abstract
{
     public:
          void f();
};

void Concrete::f()
{
     Abstract::f();
     // do something specific to class Concrete
}

This is actually quite allowable in C++. Yes, it is possible to achieve the same effect by other means, but the point of defining a pure virtual function is to allow explicit or implicit calls of that pure virtual function (calling a pure virtual destructor is an example of an implicit call). The decision to call a (defined) pure virtual function is, in practice, a design trade-off ..... there is no absolute rule that says it is always a good thing or a bad thing to do.

I understand the NEED to do so, but I do not see a need to make a pure virutal destructor since, as you mentioned, they must be defined, but since it's a pure virtual function, it isn't supposed to be called, and thus it doesn't meet the define for my interpretation of a pure virtual function.

And this is where your interpretation is showing you are failing to understand the purpose of pure virtual functions. The purpose of pure virtual functions is to prevent instantiation of a class, and to provide an interface that can be inherited by a derived concrete class while selectively forcing the derived class to override selected functions. It has got nothing to do with preventing that function from being called.

A pure virtual destructor can be used in specific cases where a base class must be abstract (i.e. not instantiable) but it is optional for a derived class to override any supplied virtual function because the base class can provide a sensible default behaviour for every virtual function. For example, some design paradigms specifically require that concrete (i.e. instantiable) classes not be derived from, and there are techniques to enforce that. Such paradigms work will if the concrete classes are derived from multiple abstract classes. An practical application is "mixin" classes, which provide default implementations of virtual functions for use by derived classes through multiple inheritance, but it is inappropriate that the mixin class itself be instantiated.

I'll leave finding more information on mixin classes as an exercise.