Cuchulainn wrote: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.