This site will look much better in a browser that supports webstandards , but it is accessible to any browser or Internet device.

Professional Hardwarenear Programming


© 2009 Peter Thoemmes, 2009-06-20

C++ is an excellent programming language for server software. When it comes to graphical user interfaces Qt is a wonderful portable C++ widget library, but for servers I always simply go for 'ascii art' user interfaces. C++ directly uses the operating system's C language SDK. It has the priceless power of the Standard Template Library (STL), which is the fastest collection of generic algorithms I know. The STL can also manage all the heap memory securely without memory leaks. Bjarne Stroustrup introduced with C++ everything the C language was missing, like object-oriented programming, templates and references. But the teams around the world did not sufficiently support the idea of a widget library coming with the C++ compiler. So there was never a C++ widget library defined in the C++ Standard. What a pitty! That opened the door for many other languages popping up and filling that gap. Rarely any of the new programming languages can really do more then C++, as C is the stuff most modern operating systems are made of and so C and C++ can provide access to everything the system can do. So today's situation is that many things already invented and optimized in C and C++ are invented again in other languages with the old kind of bugs, being fixed in C and C++ for a long time. Furthermore a lot of libraries have been developed, which hide the TCP/IP socket stuff and even pretend that network and/or database access is just a function call. That makes generations of programmers acting stupid when is comes to network/database access. Most of those libraries (I call them 'software that the world don't need') do produce a lot of overhead (middleware bloat). Compared to what they actually do (a file goes from here to there; a few bytes pass the network; a database query is executed; and so on) the time the developer needs to set them up, to learn how stuff works and to get thinks working is extraordinarily expensive. And last but not least: a third company earns a lot of money by that.

--------- Excursion:

The reasons why there are such monster libraries can only be that a lot of software companies tried to keep their developers busy and their business running. Since the end of the 1990's everything the developer needs is there, meaning the software developing industry ran into a saturation. Almost all the things that came after, are just a kind of fine- tuning. So the managers of that monster library providers try to generate an artificial demand and try to confuse old and new customers as much as they can, so they keep on selling stuff. Beside this there are brands, meaning that many times customers go for a product, because the seller caught them by 'names'. So a name of a databases, a programming language, a middleware product, an application server and so on can make a customer doing a decision. Fact is: it doesn't matter at all in the first place what technology the developer uses behind the scene. The developer must ensure that he knows exactly what he is doing, that he knows that the underlying technology will perform a good job and that he ensures that the customer's business will run safe with the new product. Much more important then 'names' (brands) are the guarantees the developer gives to you. Here just hard figures do count: operational temperature range of the equipment, data throughput, processing times, maintenance intervals, radio frequency sensitivity and and and. Be sure: you will get a good product only from a team (sometimes just one developer) of experienced programmers working in a serious environment (serious doesn't mean at all that they will have no fun!). Young guys are trained by old guys and at the same time they show up with new ideas. Old guys are inspired by the new guys' ideas and at the same time keep things stable and reliable by their well prove old ideas.


My C++ servers are developed based on an objec-toriented concept on top of strict layering. So layering comes first! Whatever I do: separation by layering is the most important rule. It guarantees reliable, stable and maintainable software.

The basic layering concept of our portable C++ servers looks like this:

+---------------------------------------------------------------+ Layer 3 | SERVER APPLICATION | +---------------------------------------------------------------+ | | +-----------------------------+ +-------------------------------+ Layer 2 | STREAMING ENCODERS/DECODERS | | ... | +-----------------------------+ +-------------------------------+ | | +---------------------------------------------------------------+ Layer 1 | CORE HELPER | | Filesystem Operations, String Operations, Mathematics, | | STL helper, Encryption, Hashing, Config file helper, ... | +---------------------------------------------------------------+ | | +-----------------------------------------+ +-------------------+ Layer 0 | PLATFORM INTERFACE | | HARDWARE ACCESS | | Filesystem, Networking, Keyboard, | | API wrapper based | | Monitor, Date/Time, High resolution | | on the underlying | | counter, Threading, Locking, ... | | kernel drivers | +-----------------------------------------+ +-------------------+