I have to give the usual disclaimer that that these are my own personal views and not those of the ESE Editor and publisher. They are also those of my employer.

 

Some of you will be reading this at the Embedded Systems Show. So come down the back of the hall to stand 440 and say hello. With any luck I will have a coffee on the stand. Bring your own doughnuts! There will be a daily competition for a dev kit (or two from IAR and Kanda). If you are not at the show: why not? The place is awash with ideas, coffee, people, companies showing everything that is new, things that you may not have seen before, as well as one of the best conferences in the UK. If you are there on the first day, the 19th we will be de-camping to the Alfaisal's balti house after the show. See map.

Oh yes, free pens, mugs, rulers, toys, note pads, stress-balls, small furry things and mouse mats. I still have a Yo-yo and slinky that Atria did about a decade ago!

The IEE have had a hand in the conference this year. Not that it was bad in previous years but the IEE have been able to pull in speakers from around the world. It really is top class. It is also cheaper for IEE members so it might be worth becoming an MIEE (if not a C.Eng) just for the conferences. Not only that IEE membership can be set a gain st tax either individually or by the company! The IEE will be on stand 402 so have a look and if you still can’t see a reason to join come and see me on stand 440 and tell me why not. (No, I am not on commission!)

I came across a comment on Usenet that really made me think. The poster said he would bet that his source code would have fewer first time compile errors than other people. This, he stated, was a measure that he was a Good Programmer. This was coupled with the argument that several languages were “safer” than C because their syntax precluded some errors. E. G. They had strong typing etc. It was the usual raft of Pascal, Ada, Modula 2 and a list of less well-known languages.

This apparently means that a Good Programmer writes syntactically accurate code and if it compiles in a “safe” language the program must be safe.. My mother can write faultless English (she was an “old school” secretary). However, this does not mean she was good at writing poetry or novels. I once saw a play in which, an actress playing Marilyn Monroe recited a chunk of the theory of relativity to Einstein. He was impressed. Don’t be said Marilyn, I am an actress, I can learn words without learning their meaning. Many programmers seem to think that knowing the syntax is enough.

 

The Bricklayers who build cathedrals can lay bricks but the can’t design the building so it is safe. In the past the builders were the architects hence the Freemasons with their secrets. The other guilds also had them but the church got involved where mathematics, geometry and the Great Architect were involved, as the medieval church was not a friend of science and knowledge. At least not outside the control of the church.

Teaching students in a “safe” language fosters the myth that if it compiles it is “Good”. I had this at university where we were taught using Modula 2 because it was “safe”. Though we had 4 different compilers and code that would compile on one but not on the other. A couple of the implementations were not very good at all. One was written in assembler with libraries that were so buggy that they were unusable but it was a “safe” language and the University used it. They refused to use an "unsafe" language like C.

The well-known and often miss-used example of the Arriane rocket shows that even with Ada, a "safe" language, just because it compiles it does not mean it is right. You can write bad code, that compiles cleanly, in any language!

I recently had a support problem with some code. It compiled cleanly apart from one strange error. An error which did not seem to make sense to the programmer. He even thought it could be a compiler bug.The client sent me the code and I ran a static analyzer over it... when I reduced the 300 odd warnings down to the top level ones we could trace the problem. There was a long string of problems leading up to the point where one error became visible. Some of the problems that came to light were redefinition of DEFINEs, use of variables before initialisation. We could have have fixed the single apparent fault but that would have left a whole string of underlying problems that would have resurfaced some time later, probably in the field. .Just because it compiles clean it does not mean it is safe.

Some re-engineering of the program into a modular system, the use of static for functions and the removal of global variables revealed some other problems and produced a safer program.

Teaching students with C, which is “unsafe”, means you [should] have to teach them safe programming techniques and awareness of engineering process. Lecturers should also marking down the use of unsafe and “clever” hacking techniques.

One of the reasons, I think, though I have no empirical evidence for this, that Ada is usually well written is that Ada is usually used in high-integrity systems. Therefore it mostly taught for that sort of environment. Proper software engineering and rigorous methods are used from the start. With C this is not the case. How many universities (or other courses) teach C with the use of static analysis and a safe subset of C? How many teach it as though it is going to be used in a safety critical environment? Probably very few, if any.

Teaching programming using a safe language teaches nothing it simply instills the belief that the compiler will catch the errors and if it compiles it is safe. I can right sentences that pass the spy chucker and word seas they are correct but they are not sensual. (That sentence did not get a green let alone a red line from Word’s checkers!). I think I will stay with that and write sensual copy rather than sensible copy! Next month this column will be in Mills and Boon. :-)

The analogy for a using a “safe” language was given that you don’t buy a car with no air bags, seatbelts and dodgy breaks. Well certainly not with dodgy breaks, when you press the break pedal you want the car to stop. However, there are times when you turn off the air bags and don’t use seat belts. The airbags are turned off in a couple of specific cases but fortunately it is usually by specialist drivers. Seatbelts on the other hand tend to be ignored by some of the less sensible drivers. These less sensible drivers tend to be the ones who also gain points and loose licences for other offences. Also there is a legal requirement to pass a test a theory and practical driving test before you can drive.

This is unlike programming where practitioners are not tested before they can program. We are not taught that we must use “seatbelts” or there is a penalty, which may result in the loss use the right to program. Where anyone can “disable air bags” without being qualified. Apparently in the US it is illegal for a garage to disable airbags without written governmental authorisation.

Where, when driving and or fixing cars, many things may invalidate your insurance. We don’t need insurance to program, yet…. but that will come. Though there are many consultants who do carry professional indemnity insurance now. However the only insurance I have seen is available for Chartered engineers.

One of the main arguments against licensing I have come across whether stated explicitly, implied or in many cases something not even the speaker may be really conscious of is the fear of falling on the wrong side of the line.

"

There are many self taught people who think they not have the requirements to be Chartered or MIEE and “everyone” knows one C.Eng who they wonder how the hell they got the C. Eng. There will always be mistakes but I have yet to see much in the way of concrete evidence either way. I came a cross a wonderful set of diagrams in “Professional Software Development” by Steven McConnell that says it better than I can explain If you take all the embedded developers in the UK (or anywhere else) and stack them up you get the diagram shown here. Figure from Professional Software Development, (c) 2004 Steven C. McConnell, All Rights Reserved. Used with permission from the author.

Bring in licensing and in an ideal world we get the picture shown here fig 19-2. All the good guys above the line and all the cowboys below. For non-UK readers a “cowboy” is not the term of professionalism or endearment it might be in Texas or Montana. The fear of many is that they will be below the bar. Well I think many older candidates will be pleasantly surprised. There is a route, which does not require the electronics or software degree. Call the IEE and find out. Stand 420 at ESS However in practice we will find that the actual picture will look like fig 19-3. Yes, some people who should be in do not make it. Also some who probably should not do get licensed or chartered. However like Steve’s picture shows I would suggest that for a good many years to come (a couple of decades?) you are more likely to be in than out and very few who should be in miss the cut. Figures from Professional Software Development, (c) 2004 Steven C. McConnell, All Rights Reserved. Used with permission from the author. This is a very young profession and many came into it before there were recognised software (or even electronics) degrees. However as time goes on, as with medicine, law and civil engineering, the route in will only be with the required qualifications. Also companies will start to do the appropriate in house training, as employees will demand it. Those companies who don’t do the training will find they do not get the better staff.

Yes, I have assumed, that the better people will want the appropriate training. Give me a good reason why a newly qualified doctor or lawyer would not want a job that gives the training for the next stage of their career? The arguments will be the same for software engineering.

In any event it is not just there C.Eng there are two other levels Incorporated Engineers and Engineering Technician. Many will go for these. Those who do not go for any of them will in time will be, by default deemed to be below that standard. You may be able to tell give yourself reasons for not getting in the system but will others believe you? If you are at the ESS go to stand 420 and talk to the IEE. You may be pleasantly surprised about the requirements.

An absolutely fascinating articled appeared in the Usenet NewsGroup comp.lang.C++ entitled “Is C faster than C++?” below is the article containing the question, the first response and a fascinating level headed comment from P.J.Plauger of Dinkumware who produce C and C++ libraries used in many compilers, including embedded ones so he knows what he is talking about.

“Ganesh" <ganeshb@gmail.com> wrote in messagenews:1127158620.940774.16190@g49g2000cwa.googlegroups.com...
My opinion is that C++ may introduce some hidden costs, that may be visible only to an experienced programmer. Lower the level of programming, (maybe) lower the overheads. This is IMHO.

"Mabden" <mabden@sbc_global.net> wrote in message news:q5b_e.640$Y_5.493@newssvr11.news.prodigy.com...
And it is wrong. Read "The Design and Evolution of C++" b Bjarne Stroustrup.
Pg. 28: "The explicit aim was to match C in terms of run-time code..."

"To wit: Someone once demonstrated a 3% systematic decrease in overall run-time efficiency compared with C caused by the use of a spurious temporary introducuced into the function return mechanism by the C with Classes (FYI: precursor to c++) preprocessor. This was deemed unacceptable and the overhead promptly removed."

The basic tenet of C++ is to be a better C, and to not add overhead into programs that do not use C++ features.

Anything you believe about "hidden costs" are similar to your beliefs about UFOs and gods. Ie: non-existent

.In article <ccKdnQezu_JD1qTeRVn-iQ@giganews.com>, P.J. Plauger <pjp@dinkumware.com> writes
Well, no. Anything you believe about "hidden costs" are similar to whatever other beliefs you can prove or disprove by reproducible experiment. And experiments repeatedly show varying nonzero costs intrinsic to C++ that are not present in C.

Exception handling is an obvious case in point -- the implementation can effectively eliminate performance costs by raising code size, or conversely, but the cost is there in some form. You can sometimes argue that the equivalent checking in C has a nonzero space/time cost, and that is true; but whether the costs are comparable depends strongly on the particulars of a program. You can also argue (as above) that the extra costs are being steadily eliminated as they are discovered, but that is only true up to a point. It's fun to highlight the successes, less fun to admit the failures (so far) to eliminate extra overheads.

Virtual function calls raise issues similar to those for exceptions, but typically with much smaller costs. OTOH, input/output using the Standard C++ library drags in *way* more code than does the Standard C library for (loosely) comparable operations. And the I/O performance gap has closed dramatically over the past decade, but it's still there.

Then there's the oft-repeated mantra that C++ can be *more* efficient than C; and occasionally that's doubtless true. But on average, IME, a C++ program will be 5 to 15 per cent larger and/or slower than a comparable program written in C.

Again IME, that's a price well worth paying, in practically all cases, for the improved productivity that you can get by writing large programs in C++ instead of C. Historically, C began winning over assembly language when its extra overhead dropped to about 30 per cent. It's a rare application, even embedded, where even 50 per cent overheads are worth addressing by going to lower-level coding techniques. It's way cheaper to use faster or bigger hardware, even when you're shipping hundreds of thousands of devices.

I consider it a mark of zealotry to pretend that there are *no* additional overheads when using C++ instead of C. That requires a leap of faith akin to believing in UFOs and gods. But more important, you don't have to be a C++ zealot to decide on the basis of reasonable evidence that it's well worth the real and measurable costs that are still there.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
27 September 2005

/////////////////////////////////////////////////////////////////////////////////////

There followed the usual nit picking by the usual crowd saying in some specific, and often convoluted, cases he was wrong. However I would agree that in general Assembler is 10-30 % smaller and faster than C and C is 5-15% smaller and faster than C++. Now this does not mean we should all rush off and use assembler. C is much faster, in general, than assembler to write. It is also much easier to test with simple tools than assembler.

On the other hand C++ is a lot more complex than the C (C90) that is used for most embedded compilers. The C++ tools are a lot more complex as well, apart from which there are no C++ tools for many platforms. In many cases you are much better off using a solid C compiler than a less solid C++ compiler. I have seen people trying to find C++ compilers for 8-bit systems because they want C++ despite the fact that there were no decent tools for the target and they had a good C based development system. All because C++ was “progress”!

Now don’t give me the fashionable rubbish about being Object Orientated. There is a lot of ivory tower rubbish talked about that. Many will say C++ is not true OO and smalltalk is etc. However when it comes down to real world Engineering (and buzzwords aside) good modular programming with C is, practically speaking OO. I know there is no inheritance or polymorphism but that is splitting hairs when it comes down to engineering a program. Modules and objects are similar for most purposes. I recall an aircraft instrument programmer saying how they did object oriented systems using assembler. When the instruments in the aircraft were changed all they had to do was change the associated object/module in the control software. “plug and play in assembler 30 years ago. So you can do Object Based programming with C (or even assembler). You can even use UML… I-logix run courses in OB UML for C.

So choose the language you use for sound engineering reasons not fashionable reasons because you want something on your CV. There will be times when C++ is the best choice, times when C will be better. Sometimes even assembler will be the best choice. A Master Carpenter will have many saws, each with a specific purpose whereas most DIY people have one or two. So things to think about..

Many thanks to those who have sent me emails recently on certification and other topics. I will get back to you all soon. I had intended to sooner but running a company intervened :-)

Any comments, praise or death threats to chills@phaedsys.com or stand 440 at ESS and tell me over a coffee.