The Qsort challenge

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