The Qsort challenge

Graham, et. al.

As I stated. this is MY personal/professional OPINION. It is right FOR ME, because it works BEST for ME (and by extension those whom do work for my firm). I do not mean that this is what "everyone should do". At the very least other people should take a look at your, mine and John's optinions and make their own CONSISTENT (i.e. Always or only when required) decision.

Your point about auto generation of the parameterless constructor is 100% on the money.

As a side note your copy constructor is distinctly different than what the default copy constructor is (I am sure this was either unintentional or simply in the interest of brevity). As written, your copy constructor states that the target object should contain the same values as a default constructed object and should ignore the state of the source object. Again, I am sure this is not what you intended.

I think this discussion has been fruitful since it presents differing viewpoints without resorting to the "you are wrong" syndrome. Thanks to all for their ideas.

Yes, I should have put the full initialiser list on: which leads to the point that, if you leave the copy constructor to the compiler, then data member additions will be automatically handled correctly (apart from those, etc.......), whereas by declaring a redundant one, you've got to remember to update it for each new member. And what are the odds on someone forgetting? And doesn't that counterbalance the argument about when the new data member demands a copy ctor? Anyway, my principle reason is the documentary one, since ctors have to be maintained and considered with all changes the state list of a class - I just like to have an explicit ctor (or any of the compiler-generated funcs) mean that there is something special going on. Good grief, the number of times I create a class in MSVC++ and the first thing I do is to delete the ctor and the (really annoying) virtual dtor that it puts in. That really bugs me, actually: the virtual dtor that VC++ automatically gives you. It shows a fundamental wrong-headedness on the part of whoever put it in.

Yep, this is about personal opinions but, as you say, I think it's important to have these debates - someone may have an argument that you've not heard before that you find convincing (happens to me every time I read a Scott Meyers article). Maybe those who are learning can glean something useful and so improve their skills.

COMPLETE agreement on the need for this type of discussion/debate. When I first read Scott Meyers "Effective C++" back in 1994 [when I started serious C++ development], I disagreed with about 30 (of his 50) points. After implementing a number of systems, talking with other (more experienced) people [the "expo's" were better back then, not just sales events], my thoughts on his points changed dramatically.

I no longer think any of his points are wrong, although I still prefer to use some alternative methods.

Your point on the maintance of constructors is well taken. The object framework (developed in house over the years) that we use dictates the explicit use of copy constructors (most classes have a "Tracker" object member that must NOT be copied as it needs to be in its initial state at the creation of the containing object). Also as I mentioned in a previous post, we use a number of tools to create/maintain/document/validate all of our code, this provides a good check for un-initialized members.

Question: You state you often delete the default constructor template. Assume you have a class that just has a single int data member. How do you handle its initialization???

Regarding default virtual dtors (MSVC++), [Scott Meyers #14 covers this rather well], I thing MS decided that since inheriting from a class without a virtual destructor can induce many headaches, whereas having a virtual destructor when a plain destructor will suffice [albiet at the potential increase in object weight], it was better to err in the direction that they did. [I am NOT saying they were right, just that there was come point behind it...]. "Add Class" is basically a wizard, there are other methods of adding a class to a project...

If we are going to discuss "When to make a destructor virtual", I think that would be a great topic for a new thread.

David.

Quote:

---

1) AnthonyMai's statement....

"Basically std::sort is broken whenever you have some class where appropriate copy constructors can not be written."

If you mean the compiler can not write them the point is meaningless. good design requires the 5 "auto" functions should ALWAYS be implemented for EVERY class. If the statement was meant that a programmer could not write a copy constructor for a class, I would surely like to see a sample.

---

Was it you forgot or was it your ignorance? A guy with your kind experience should have seem plenty of examples of class objects that simple can not and should not be copied, or that once you make a copy something changes and it no longer looks the same.

Singleton is one example. By its very definition singletons can NOT be copied and a copy assignment operator should never be needed.

Auto pointers are another example. You can assign an auto pointer just like you assign a regular pointer. But unlike assigning regular pointers where no side effect happens, once an auto pointer is assigned, the reference count changes, so you don't get a duplicated instance of the auto pointer class, it is no longer the same as the original instance since the reference count is not the same, even the original instance has been altered during the copying.

So in the case of auto pointer, you simply can not make "true" copy of the objects. Once you attempt to copy it, it changes the original. This is why you would run into trouble trying to do std::sort() on objects where auto pointers are involved. Here is a case where nothing has broken the standard C++ rule, neither the auto pointers nor the std::sort() has broken the C++ rules. But put them together and it doesn't work. And in this case Qsort() would break C++ rules but it works.

The point I want to make is NOTHING works on every thing on every situations. You can find plenty of cases where Qsort doesn't work and std::sort() works (except not on VC++, BTW), but I can also find plenty of cases where std::sort() doesn't work but Qsort works. And also the bottom line is whether something complies with std C++ is absolutely NOT a golden rule for whether something would work or not.

I concede that in GCC when virtual data members are involved, Qsort() would have problem.

For the time being, I believe Qsort works on virtually every conceiveable type of classes on VC++. On some other compilers, Qsort may not work when there is virtual data member or virtual inheritance involved (virtual functions are OK), but works just fine when no virtual data member or virtual inheritance is involved. If some one can find an example where Qsort still doesn't work under this confinement, I would like to know.

Since virtual inheritances and virtual data members are seldom used, comparing with virtual functions which are much more common place, Qsort has a pretty broad domain of usefulness, probably even broader than std::sort(), which requires both the availability of STL and that the object must be appropriately copyable and the copy operator must be available and accessible.

Quote:

---

For the time being, I believe Qsort works on virtually every conceiveable type of classes on VC++. On some other compilers, Qsort may not work when there is virtual data member or virtual inheritance involved (virtual functions are OK), but works just fine when no virtual data member or virtual inheritance is involved. If some one can find an example where Qsort still doesn't work under this confinement, I would like to know.

---

What about the class Gabriel posted on the first page?

Anthony, your two examples are both cases where a copy constructor needs to be written or at least declared. The problems arise when you DONT explicitly do it and allow the compiler to do it for you.

In the case of Singleton's the (usually) correct copy constructor is just a private declaration with no implementation. This prevents accidental copies.

In the case of "Smart" pointers the method varies. It can be either a private declaration as above (if the designer wishes to prevent copies) or a "proper" copy constructor that handles the required functions (ownership, reference counting, or what ever else makes the pointer "smart").

My position on the various sort implementations is that anything that RELIES on a feature that is not covered by the standard is WRONG.

Additionally, it is my opinion that anything that can be done to allow the compiler to check for errors is better than having to count on a human always getting it right or having runtime checks (I do agree that there are times this is not possible). The worst scenario is when a delivered program operates incorrectly (a crash or unhandled exception being the ultimate incorrect operation).

David: I often delete the default constructor because a large proportion of the classes I write are not default constructable - it's as simple as that. I suppose I'd like a wizard that has a set of checkboxes:

Default constructable?
Copyable?
Acts as base class?

My objection to the virtual destructor is, I suppose, more philosophical than anything. A class is part of a (polymorphic) hierarchy or it isn't. That decision really ought to be made very early in the design stage... if a class changes from one to the other at a late stage, I would suggest that that implies that the class is not well-defined and the design is suspect. It is possible that a useful stand-alone class could later profitably become the base for a polymorphic family, but I feel that that's the exception, not the rule. Therefore, I consider virtual destructors (like many other things) to be a matter of deliberate choice rather than "well, it does no harm". And also there's the documentary aspect: I consider a virtual destructor to imply strongly that there is a polymorphic inheritance hierarchy here.

Quote:

---

For the time being, I believe Qsort works on virtually every conceiveable type of classes on VC++. On some other compilers, Qsort may not work when there is virtual data member or virtual inheritance involved (virtual functions are OK), but works just fine when no virtual data member or virtual inheritance is involved. If some one can find an example where Qsort still doesn't work under this confinement, I would like to know.

---

Quote:

---

What about the class Gabriel posted on the first page?

---

In a broad sense Gabriel's case can be considered a case where a class data member (val_) is explicitly "virtualized", using the visible virtual pointer (the self_ pointer). You don't access val_ directly. In stead you access it through a pointer self_, by changing self_ you could be pointing to different values of val_. Actually virtual data members are usually implemented in pretty similar ways, except that real virtual pointers are invisible and they are only changed when inheriting from a base class.

Graham,

That would be a better wizard...Remember any of us can always create an add-in that does exactly what we like.

Agree that a virtual destructor DOES imply that the class is intended to be polymorphic in nature, and a non-virtual implies the opposite. One of the things I like about other languages is the ability to EXPLICITLY state these items (e.g. keywords such as final, override). Alas C++ does not inforce these items and gives rise to unusual behaviour such as:

1) Base (CBase) class member is not virtual, first level derived class (CLevel1):public CBase) IS DECLARED virtual, second level derived class CLevel2:public CLevel1) also overrides the function.
Case a CLevel2 object to a CLevel1 object and the CLevel2 method still gets called, Case EITHER derived class to a CBase pointer and the base gets called. [I just
know someone will post a class where this is intended...]

2) A user is developing a class based on a deep and/or complex hierarchy and declares a "new" method (missing the fact this is already a method of one of the base classes). This gets really messy if the accidently overriden method was declared virtual.

Alas, ANY language (or specific compiler, debugger, IDE) has its limitations as well as its benefits.

Absolutely. That's why we're professionals and get paid a lot..... when we're in work, that is :(

David,

Quote:

---

Originally posted by TheCPUWizard
...
1) Base (CBase) class member is not virtual, first level derived class (CLevel1):public CBase) IS DECLARED virtual, second level derived class CLevel2:public CLevel1) also overrides the function.
Case a CLevel2 object to a CLevel1 object and the CLevel2 method still gets called, Case EITHER derived class to a CBase pointer and the base gets called. [I just
know someone will post a class where this is intended...]
...

---

If I understand your example, it sounds like behaviour I would expect. What did you expect?

Thanks,
John

John,

It is EXACTLY the behaviour you SHOULD expect, IF you are looking carefully at the code. On the other hand if you are not the developer of the code, or have been away from it for a while, it is easy to make a mistake and get unexpected results.

As an example, if there was an existing collection of (CBase) objects that was performing a number of operations already, and you added a call to the aforementioned method, it would be easy to make an incorrect assumption.

This is a case that is well known to the experienced programmer, and is usually avoided. My original post on this sub-topic was that other languages DO have either warnings or errors that would at least alert the programmer that different (virtual/non-virtual) behaviours are occuring [e.g. "CDerived1::f() hides CBase::f()"]

I am NOT advocating a switch to these other languages, each language has it's merits for specific application. About 80& of our development is in C++ (most of the remaining is in C#/VB.NET for Web application). On the other hand, I AM pointing out that even experienced programmers and gurus are human (at leat I think so :) ), and DO make mistakes. Having tools to prevent or at least alert the person is a great boon when schedules are tight and people are overworked/tired.

David.

David,

I believe you are trying to make a valid point, I just think you are using a bad example. If someone has a collection of CBase objects, and calls a non virtual method of CBase, what could they be expecting?

Now, to me, the following code may be confusing (if one was looking at class C and not paying much attention to class B):

Code:

---

class B
{
public:
    virtual void foo() { TRACE("B::foo()\n"); }
};

class C : public B
{
public:
    void foo() { TRACE("C::foo()\n"); }
};

class D : public C
{
    void foo() { TRACE("D::foo()\n"); }
};

void f()
{
    D  d;

    C *c = &d;

    c->foo();
}

"D::foo()" is printed.

---

John

John,

Agreed that my sample may not be the best. I used it because last year that exact problem bit one of our staff.

He was looking as some code that was commented as "Process Class Specific Operations". All of the existing functions WERE virtual in the base. The function that was to be added was INCORRECTLY not declared as virtual in the base. He looked at the header for "CLevel1" the function he needed to add was declared as virtual and all of the existing functions were in the same area of the header and also declared virtual. HE SIMPLY MADE A MISTAKE by not looking at the base class (which is what the pointer was declared as).

As a result, the code was not ready in time for our European test site (client also in Europe) to run the anticipated test during their day time shift. We ended up paying over $500 for them to sit idle that night.

If there had been a tool which would have produced some type of notification, this loss of time and (quantifiable) money would have been avoided.

David.

Quote:

---

Originally Posted by Yves M

Arg, I would love templated typedefs The workarounds are not always pretty

---

Me too.
You probably noticed that typedef is particulary useful and even needed when dealing with templates, and that in some cases template typedefs could be needed.

However templated typedefs can be replaced by an alternative method which needs more typing, but has the same features.
Like that:

Code:

---

template<typename T>
class SharedVector
{
public:
typedef std::vector<boost::shared_ptr<T> > value_type;
};
// now, you can use SharedVector<T>::value_type

---

I found that particulary useful with specialization:

Code:

---

template <class T>
class FastConstReference
{
public:
typedef const T& value_type;
};
template <>
class FastConstReference<int>
{
public: typedef int value_type;
};
// similar code for all builtin types.
// now we can write a container using FastConstReference<T>::value_type at some points were a const reference is needed for efficiency with big objects, and values are still faster with builtin types.

---

I hope that C++0x will include typedefs templates...
:)

SuperKoko, I hope you realize that you have replied to a thread that's been sleeping for 3.5 years... ;)

I just realized that now...
:D