The Qsort challenge

David,

Thank you for expanding on your statement. I just thought that your original statement was that it was a standard practice in the "Industry".

I myself just don't see the need to ALWAYS do it (from my 16 years of development and 10+ years of C++ programming).

Quote:

---

1) When setting policy to get consistent results from a team of programmers a fixed policy which does not involve "judgment calls" is easier to define, implement and maintain.

---

I agree. But also,

1) have a policy that you will train your programmers so they know the language,

2) hire competent people who are capable of making intelligent decisions so that you don't need to impose unnecessary policies on programmers.

The above is with a smiley face, but should also be taken to heart.

3) Now you have a policy that gives your programmers a false sense of security. The programmer thinks: "I followed the policy, why think about the actual design".

4) I would tell the programmers to do more up front design to decide what is necessary.

Quote:

---

2) Any class which contains a pointer (almost) always need custom a copy constructor and assignment operator. Those which want to have the same pointer value should be explicitly documented in any case.

---

Agreed. Since I can't quantify a word like "almost".

Quote:

---

3) Any class which does internal reference counting, needs a copy constructor.

---

Don't forget the assignment operator.

Quote:

---

4) A class that today does not "need" a copy constructor will often be "upgraded" to contain a new data member that requires a copy constructor. As a (contrived example), consider a class with starts with 5 data members all built-in non-pointer types. This does not need a copy constructor or assignment operator to behave correctly. Over time additional members are added, they are all either build in types or well behaved classes, this goes on until there are 50 data members. THEN IT HAPPENS, a pointer data member is required. At this point the copy constructor and assignment operator are needed. The programmer now has to write the code for alll 51 members!!!!. Much better to amortize the cost (time) since day 1. It is hard to justify (to boss or client) why addding one "little pointer" requires a week of testing to insure that all 50 of the other members are being properly copied!!!.

---

I quess I would look at the flip side. If there was no reason to have a copy constructor in the first place, and you require people to write one, you are lengthening your development cycle unnecessarily. Your clients would probably be happier if you could deliver quicker and more reliably.

Quote:

---

5) Some classes which consist of just built in types and well behaved classes STILL require a (user written)copy constructor. Consider a simple object that counts the number of times a certain method has been called FOR THAT INSTANCE. This is often the type of item added for debugging and code coverage testing. Should a copy constructor be written (again having to implement and test ALL of the members) when this is added and then deleted when this is removed????

---

Well, if it was just for debugging, I would suggest putting the stuff in #if blocks.

Quote:

---

6) Many programmers never intend for their objects to be copied or assigned. They just dont think about it. If you REQUIRE them to write these functions, they must think. Either write a valid public method, or write an empty private method (explicitly stating that "you cant to this").

---

Again, hire competent people. I would agree with your statement but instead of "empty", I would tell them to declare them as private and not implement them.

Quote:

---

Default Constructor : All members should ALWAYS be initialized so this is required.

---

I disagree, if there is no reason to allow a default constructor to be called, declare the default constructor as private and don't implement it.

Quote:

---

Equality operator : A great many classes contain private data members that are not pertinent to equality testing [lazy evaluation patterns, item #5 above, etc.)

---

I agree. But you don't mention the case where equality testing isn't even valid.

Quote:

---

In short liefe is EASIER for everybody (in the long run) if these routines are ALWAYS implemented.

---

I disagree.

Regards,
John Flegert

John, I respect your opinions. They are based on your experiences the same as my opinions are based on my experiences.

I would just like to relate some of the details of the project that caused the formulation of this (albiet strict) set of design "rules" [for use in our firm, NOT the entire industry].

About 6 years ago, I contraced for a large project. Since we are a small firm, almost all of the work was handled by sub-contractors. We created top level designs and left the internal design up to the various contractors. During the two years of development we needed to move the work between the different contractors (1 we fired, 1 went bankrupt) as well as balance the work load to keep everybody active.

We ran into significant problems when transfering code from one cmpany to another. There were steep learning curves since each firm had their own set of techniques and styles. The items that caused delays were often trivial in nature (e.g. do "simple" method implementations go int the hpp or cpp file?, how are inlines handled?, are accessors necessary for reading and/or writing an int data member). The code was rapidly becoming VERY difficult to maintain as the various styles all started to appear within a single class.

We decided on implementing a complete software design and style guide. All internal programmers and exernal firms are required to adhere to these standards and practices.

Since this was implemented 4 years ago, we have been able to expand. Most of our implementation is done by a number of small firms literally around the globe. A class written by one company can easily be maintained and updated by another company, and it is virtually impossible to determine (without looking at comments or other documentation) which company has performed the work.

I agree that hiring the brightest and the best is always a good idea. I feel that having this policy really DOES allow the designer to concentrate on the BEST designs techniques available (e.g. Selecting the best Collection Class, implementing a Design Pattern in a complete and robust fashion).

As a final note, we make heavy use of full-cycle design tools. Most of our code-base is generated (at least as frameworks) from tools that parse UML structures (as well as generate them from the final code. Code analysis tools are used to produce the documentation as well as validating that the final code is in compliance with out policies.

Did this cost time (therefore money)? Yes, but it has proved to be the best investment we could have possibly made. Even with the downturn of the past 12-18 months, we are estimating that our earnings will be up over 30% this year.

In cases such as this, the BEST SOLUTION is the one that works best for the PERSON WHO HAS TO LIVE WITH IT.

David.

Quote:

---

Originally posted by TheCPUWizard
John,

The last one is the equality operator [==].

---

Nope. The fifth one is the address-of operator: operator&().

Sorry Graham, you are of course correct. I was looking at our internal documents, not the standard. I need to double check the source that I am using more often. However, if I spend any more time on this (and other) boards, I may succeed in not performing any real work at all.


Mea Culpa
David.

Following on from jflegert's post, with which I (almost) entirely agree:

Quote:

---

Originally posted by TheCPUWizard

Default Constructor : All members should ALWAYS be initialized so this is required.

---

Like jflegert, I disagree, but with a slightly different codacil: Explicitly declare ANY ctor and the compiler will not generate the default ctor. If you don't need a default ctor (a likely situation; that's why the rule is there), there is nothing to be gained by declaring it (private or otherwise). Better to simply leave it as a class that has no default ctor.

Conversely, if you don't want a default ctor, then you will need some other sort of ctor, and that will supress the default. So, there is never a need to explicitly supress the default ctor.

As for copy ctor/copy assign: personally I'd leave them unless the compiler-generated ones aren't sufficient.

Quote:

---

A class that today does not "need" a copy constructor will often be "upgraded" to contain a new data member that requires a copy constructor.

---

Then add the copy ctor when it becomes necessary. In my view (and I know: it's just my view), the presence of an explicit copy ctor should document the fact that there is something special about this class. It takes a while to look at a copy ctor and note that it does no more than the compiler-generated one. What is the point of:

Code:

---

class foo
{
public:
    foo(const foo&) {}
private:
    // data members
};

---

jflegert's point about competent programmers is valid, though: we can't design systems on the assumption that people are all novices or less than fully competent. Sure, some will be (we've all got to learn sometime), but that's what training and colleagues are for.

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 :(