Bjarne Stroustrup on Modern C++

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Good article on the state of C++ today and computer science education in general :-

http://www.ddj.com/cpp/207000124

It covers a lot of issues that have been raised here a few times so is well worth a look...

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

i've just finished reading it, was a very interesting and enthralling read, i kind of got clued to the screen, that was until the phone call informing me of a nice delivery to pick up from reception. but thanks i enjoyed that.

 

Skimmed over it so far, and it is a great interview. He and I are one regarding the lack of education on modern computer science courses - and I particularly chuckled when he mentioned people unfamiliar with proper practise criticising the decisions made for C++ structure and what-have-you. You simply wouldn't believe the number of people I have encounted both in realisty and forums with that attitude, not just for C++ but software engineering in general, when they have no idea what they are talking about.

Anyway, enough of my ranting. Will read the article proper later.

 

I have to say it made a lot of sense to me I agreed with practically everything he said. I've sucessfully used C++ for real time embedded and for large scale apps, you use the portions that make sense in each case. Hes also right about ditching lanaguages every few years is counterproductive, and how education needs to teach the fundamentals and that to learn it all takes 5-6 years. Also on how he mentions the short commings of the language, almost every other lanaguage has a much better standard library, I agree the threading, network and memory management primitives are very important for C++ to advance.

 

I read this article when studying OOP in C++. Having been trained in vb.NET using visual studio with everything available as a component, it came as a surprise to have to write my own date class. We also had to write using a plain text editor which nearly killed me as a result of the number of mistakes that I made. The learning curve for C++ after other high level languages is quite a steep one but well worth the effort. It is interesting to note that some of the more troublesome features of C++ such as multiple inheritance and pointer arithmetic are now either discourages or forbidden altogether in subsequent languages such as C#.

 

Multiple inheritance was used because there was no language support for interfaces. Concepts of mixins and duck typing are alive and well, as are traits types. Languages don't have multiple inheritance largely because they use other idioms or have interfaces as first class language constructs.

You will never get away from managing memory at some level, it may not be strictly required for high level languages and for business apps, but it is very useful for systems programming. Lanaguages like .Net and Java still have things like stong and weak references, and you must still be aware of the memory model when writing advanced code. The introduction of references vastly reduced the need for pointers in modern C++, only small parts of system libraries should need to use them.

 

Good link and article. Sometimes I think brain capacity and ego size must be inversely proportional. Also reminded me of something Joe Celko said in a forum about meeting him at a conference:

Posted 07-16-04 on Microsoft's microsoft.public.sqlserver.programming newsgroup.

 

That's how I learned to code!

I'm still a firm believer in it being the programmer rather than the language at fault here. If you place C++ in the most expert of hands it is truely a wonderful language.

Be glad that you're not in my job where we mainly deal with assembly, C++ and reverse engineering bytecode.

 

Totally agree, look at ORM and microsofts approach of ADO and datasets, in fact M$ deliberately avoided releasing a pure ORM framework for these very reasons. The relational model is incredibly powerful and backed up by years of research by mathematicians, it should be the default approach unless you know what you are doing. Look at EJB, it was a massive foul-up, largely for two reasons :-

1. No seperation of concerns, there is no need to marry a component model, distributed computing and persistence. The three areas are concerned with solving quite different problems.

2. A very poor ORM technology and poor use of that technology. ORM should be used carefully.

Doesn't seem so bad to me, foreign keys rarely have the same name as the primary key they reference, theres normally a naming convention of tablename + keyname. A data dictionary seems to be a rather archaic concept. It is a global glossary, in a complex system made up of many packages, namespaces, components, and classes, its probably pretty useless other than as a key to other technical documentation, and yes I have done Yourdon, SSADM, UML, RUP and Agile before you ask, they all have their advantages and disadvantages !

“Dictionaries are like watches; the worst is better than none, and the best cannot be expected to go quite true.”

-- Mrs. Priozzi Anecdotes of Samuel Johnson, 1786

Sounds like Mr Celko is the one with the ego...

 

I have to admit I usually create the data dictionary last as part of the project's documentation. But that's because I use a RAD approach rather than a waterfall model. And I'm still not terribly sure what Agile is all about to be honest... seems to combine the disadvatages of both if you ask me (never ending changes and a full dev cycle).

I don't see it that way. He's just confident he's right... and he usually is. Guys with big egos with continue down a path they know is wrong just to save face.

 

Well agiles not really something that should be applied to an in production database schema, so the advantages are likely to be lost on most DBAs.

However anyone who has seen 'analysis patalysis', or a project generate a years worth of documentation and no code only to be terminated will understand the benefits.

Some parts are similar to Iterative and RAD, de-risk the project by delivering early and often. Requirements change, the market changes, the requirements may have been wrongly stated etc. The cost of detection of bugs curve is often used to state that requirements must be nailed down and 100% right as early as possible, in reality this approach can actually load risk onto a project and lead to over engineering.

Releasing early and often does produce its own inefficiencies but you are at least getting real feedback of the viability of your designs. Architects build models, engineers go into wind tunnels, electronics engineers use simulators and create prototypes, these are all ways of reducing risk by getting early feedback.

The idea is to use feeback cycles to produce a spiral of virtuous improvement, look at how athletes 'raise the bar' using sports science.

 

A good definition of Agile....





Harry.