12. Application Development in C++

[Cuchulainn]

The following are examples of good practice. Do you agree/disagree?



1. Use STL as much as possible

2. Use exception handling at strategic points (sparingly)

3. Multiple inheritance is synonymous with bad design

4. Sometimes your design can be 'too object-oriented'

5. It is possible to combine templates and inheritance

6. Composition is more useful than inheritance

7. Virtual functions are [2,10] times slower than non-virtual functions

8. Use boost smart pointers instead of raw pointers

9. C++ has a great future

10. Decomposition is needed for complex C++ applications

[Excel4Net]

The following are examples of good practice. Do you agree/disagree?



1. Use STL as much as possible

Agree. Choose the "right" version of STL though.

2. Use exception handling at strategic points (sparingly)

Agree. Also do take extra care when throwing exceptions explicitly.

The type of design where exceptions is unneccesary thrown where

a return value with an error code should have been used,

will turn debugging into a nightmare.

3. Multiple inheritance is synonymous with bad design

Disagree in generally.

Bad design is usually a complicated design, difficult

to understand, hard to change, etc.



MI might cause one's design to turn bad, but I would not

say MI is always a sign of bad design.

4. Sometimes your design can be 'too object-oriented'

5. It is possible to combine templates and inheritance

Agree. I suppose this is the sign of immaturity.



A seasoned developer would never create a mix

of templates, vertual methods, abstract classes

unless there a good reason to.

6. Composition is more useful than inheritance

It obviously more easier to maintain.



If something could be implemented as composition -

that might be a sign of that the inheritance relation

is artificial there.

7. Virtual functions are [2,10] times slower than non-virtual functions

Obvously I depends on the function itself.

If you are talking about virtual function call overhead -

I would not care and would rely on the compiler optimisations.

8. Use boost smart pointers instead of raw pointers

Agree.

9. C++ has a great future

Disagree. I have had such opinion 5 years ago and have it now.

This is why I don't really use C++ for strategic projects.



C++ was great 20 year ago, good 10 year ago. It could be

used as a niche language for now, but I don't think

it would stay as a niche languge for quant finance

for long.

10. Decomposition is needed for complex C++ applications

Agree. And once it done - each independent module should be

covered with a set of unit tests.

[Cuchulainn]

A seasoned developer would never create a mix

of templates, vertual methods, abstract classes

unless there a good reason to.

OO defines a set of common interface functions using 'virtual' while template classes place emphasis on data structures.



Example: mathematical vector spaces derived from vanilla arrays



template <tyopename T>

class Vector<T> : public Array<T>



So, IMO the opposite is true; the two paradigms are orthogonal in this context.

[Excel4Net]

A seasoned developer would never create a mix

of templates, vertual methods, abstract classes

unless there a good reason to.

OO defines a set of common interface functions using 'virtual' while template classes place emphasis on data structures.



Example: mathematical vector spaces derived from vanilla arrays



template <tyopename T>

class Vector<T> : public Array<T>



So, IMO the opposite is true; the two paradigms are orthogonal in this context.

I see you point. I have quickly commented on your points 4 and 5 in just one statement and that, I think, resulted in some misunderstanding.



Let me expand my last comment a little bit:



>4. Sometimes your design can be 'too object-oriented'

Yes, sometimes people over-engineer their programs, putting the "correctness" the design over the actual requirements.



In my opinion, in mostly happens for two reasons:



1.When someone learn to program in the object-oriented way - and the best way to learn programming in some way is to start programming in that way. The first attempts are usually not stellar - too many classes, too many (inter) dependencies between them, an inheritance tree is very complex.



But everyone should pass thru this stage.





2.The second reason is a belief what if to start with a "too object-oriented" design it will eventually, after some interations, get us to a point when the correct design architecture will magically reveal itself.



It usually does not work either.





When 1 or 2 happens in C++, templates (re: your p.5) are usually being left alone so they could make their contribution into over-designing the system:

Code: Select all


class SomeModel : public SomeBase<SomeModel>,

                           public SomeBaseEx<SomeModel>,

                           private SomeMixin<SomeModel>

{

}



[mohsinj677]

.When someone learn to program in the object-oriented way - and the best way to learn programming in some way is to start programming in that way. The first attempts are usually not stellar - too many classes, too many (inter) dependencies between them, an inheritance tree is very complex.


______________