C++ Was a Joke

[Dave Frederickson]

A fake interview with Bjarne Stroustrup where he supposedly revealed that C++ was a joke. Good for some laughs. An Interview with Bjarne Stroustrup

[HP67]

(03-04-2014 05:27 PM)Dave Frederickson Wrote:  A fake interview with Bjarne Stroustrup where he supposedly revealed that C++ was a joke. Good for some laughs. An Interview with Bjarne Stroustrup

An oldie-but-goodie. Unfortunately there is more truth in there than some would like to admit.

[Garth Wilson]

On another forum I'm on, there was a volley of posts between two professional programmers who had both been using OOP in their work for 15+ years, one of them saying it was ill-conceived, that no one thought in terms of objects, etc., while the other one was saying that he definitely does think in terms of objects and OOP has its place, which apparently is for GUIs and plug-ins, something whose insides I'm not the least bit familliar with. I do a fair amount of programming of microcontrollers for embedded applications where the microcontroller will never run anyone's code but mine, and I don't touch graphics. I've read various descriptions for what the parts of OOP are, watched YouTube videos on OOP, and none of it has ever really made any sense to me, at least as presented.

A nephew who's majoring in CS said, "If you're defining a car for example, you don't want to have to define a wheel four times. You make it a re-usable object." My immediate response was that there were subroutines decades before OOP, and, although you might have different kinds of wheels in something so you can't just use the same one for everything--for example, although they are all round and turn on their axis, they will have different diameters and other attributes--I do that kind of thing with macros all the time, not OOP. After all the reading though, I do suspect I've done a little OOP in Forth without knowing it.

[Han]

(03-04-2014 09:42 PM)Garth Wilson Wrote:  On another forum I'm on, there was a volley of posts between two professional programmers who had both been using OOP in their work for 15+ years, one of them saying it was ill-conceived, that no one thought in terms of objects, etc., while the other one was saying that he definitely does think in terms of objects and OOP has its place, which apparently is for GUIs and plug-ins, something whose insides I'm not the least bit familliar with. I do a fair amount of programming of microcontrollers for embedded applications where the microcontroller will never run anyone's code but mine, and I don't touch graphics. I've read various descriptions for what the parts of OOP are, watched YouTube videos on OOP, and none of it has ever really made any sense to me, at least as presented.

A nephew who's majoring in CS said, "If you're defining a car for example, you don't want to have to define a wheel four times. You make it a re-usable object." My immediate response was that there were subroutines decades before OOP, and, although you might have different kinds of wheels in something so you can't just use the same one for everything--for example, although they are all round and turn on their axis, they will have different diameters and other attributes--I do that kind of thing with macros all the time, not OOP. After all the reading though, I do suspect I've done a little OOP in Forth without knowing it.

I believe your nephew's analogy is not entirely correct. He was probably referring to inheritance when creating a new object based on existing objects (so that you don't re-invent the wheel). But the idea behind object oriented programming is that rather than thinking of a program as merely a sequence of commands applied to data, the data and commands can be categorized as objects with attributes (both in the sense of data values as well as procedures associated with that object). Even your microcontroller can be considered as an object that has certain states (low power, on, off) and procedures that it must run. The difference between the type of programming you do (in which case there is only one object -- the microcontroller, and everything else is either data or procedures related to the microcontroller) and OOP is that OOP would likely break down the "microcontroller" object into a larger collection of smaller objects. For example if your microcontroller is comprised of several subsystems, then an OOP approach would likely create "objects" out of each subsystem -- each subsystem has a certain number of data values associated with it as well as what procedures must be run to maintain those subsystems.

The end result is the same; OOP just makes it a bit easier to organize code as everything is very modular not just by code, but also by design.

[pascal_meheut]

(03-04-2014 05:27 PM)Dave Frederickson Wrote:  A fake interview with Bjarne Stroustrup where he supposedly revealed that C++ was a joke. Good for some laughs. An Interview with Bjarne Stroustrup

Excellent. And so true for a fake (I managed C++ projects in the past and even wrote the WP34s emulators with it but as I learned from my mistakes, I kept it simple and used around 10% of the language ;-)

[Garth Wilson]

(Replying to Han's post) So perhaps the borders to OOP are pretty fuzzy? I do do multitasking on the microcontrollers, without a multitasking OS, and the various tasks are rather autonomous. I also make very heavy use of macros, so I don't have to keep looking at their uninteresting internal details once they're bug-free, but the code they produce takes various forms depending on the inputs.

[Thomas Klemm]

(03-04-2014 10:05 PM)Han Wrote:  He was probably referring to inheritance when creating a new object based on existing objects (so that you don't re-invent the wheel).

Maybe just different instances of the same class.

Cheers
Thomas

[Thomas Klemm]

(03-04-2014 09:42 PM)Garth Wilson Wrote:  I've read various descriptions for what the parts of OOP are, watched YouTube videos on OOP, and none of it has ever really made any sense to me, at least as presented.

About 30 years ago I attended a lecture of Niklaus Wirth based on his book: Algorithms and Data Structures. It showed me how both are inherently related. If the data can be structured well to a given problem the program is usually much simpler.
OOP combines both: an object is data together with processes. Years later I realized that a closure is a dual concept: a function with related data. Thus both are similar: just looking from a different angle.
We don't have much structure in FOCAL programs: no proper names for variables, no types, at least some kind of array, just GTO and XEQ. Thus programs for difficult problems tend to become hard to write and read. This is very similar to assembler programming.
Analogies for OOP from the real world (e.g. animals, cars, ...) didn't help me to understand the concept. Geometric shapes were even a bad example as they violated the Liskov substitution principle. But it was easy once I knew what's going on under the hood.

Cheers
Thomas

[Garth Wilson]

I haven't seen that book, and perhaps I should get it, although I have read "Thinking Forth" which is very good and really is at least as much about programming concepts and habits and structure as it is about Forth itself, and the things there can be applied to some extent in other languages as well. I'm not sure what the relation of OOP is to how Forth allows you to define custom defining words and what their children will do, allowing for example advanced custom data structures.

As for program structures in assembly, I do that with macros I've written to get better control of code by making it much more clear what you're doing, and getting rid of the mass of labels and jumps that commonly constitute assembly code. The macros let you keep full control of every speck of code laid down by the assembler, without having to keep looking at the internal details. In most cases there is absolutely zero penalty in program memory taken or in execution speed. You get a lot of the benefits of higher-level languages, without losing the performance benefit of assembly. Code becomes quicker to develop, more bug-free, and easier to maintain, meaning that it's easier to come back later and figure out what you did when you decide to add a feature or change something.

For an example, take this short piece of code from my I²C sample code, actual code I used on a PIC12CE673 which had no SSP (even though the I²C serial EEPROM was onboard, with CLK and SDA on bits 6 & 7 of the GPIO) so the I²C had to be bit-banged:

Code:

RCV_I2C_BYTE:
        I2C_DATA_UP
        CLRF      EEPROM_DATA           ; Init EEPROM_DATA as 0.
        MOVLW     8
        MOVWF     LOOP_COUNT1
rib1:   I2C_DATA_UP
        I2C_CLK_UP
        CALL      RD_I2C_BIT
        I2C_CLK_DN
        DECFSZ    LOOP_COUNT1, F
        GOTO      rib1
        RETURN                          ; The ACK or NAK bit must be sent separately.
 ;----------------------------

(Even there, you can see the use of macros, as for example I2C_DATA_UP is more clear than BSF GPIO,6 but assembles exactly the same thing.) The loop is to gather the 8 bits of data to read for one byte. If we do a FOR...NEXT loop with the macros, we get:

Code:

RCV_I2C_BYTE:
        I2C_DATA_UP
        CLRF      EEPROM_DATA              ; Init EEPROM_DATA as 0.
        FOR LOOP_COUNT1, 8, DOWN_TO, 0
            I2C_DATA_UP
            I2C_CLK_UP
            CALL  RD_I2C_BIT
            I2C_CLK_DN
        NEXT      LOOP_COUNT1
        RETURN                             ; The ACK or NAK bit must be sent separately.
 ;----------------------------

Looking at the .hex file output, you would have no way of telling which source code it came from, because the resulting assembled code is exactly the same for the two versions. In BASIC you would probably have the FOR...NEXT count up instead of down, but here it's more efficient to count down and end at zero since it allows branching on the Z flag without doing another comparison first. This way it just assembles the DECFSZ LOOP_COUNT1,F and then the GOTO like the more-manual version above.

Here's an example of using an "IF...END_IF" in a PIC16F72 (and as you can see, it's also in part of a CASE statement-- "CASE" being from Forth, but called "SELECT CASE" in BASIC, and "switch" in C).

Code:


           CASE_OF  4                         ; We were waiting for the low address byte to be shifted out to the flash memory.
               RAM_BANK  1                    ; Is that finished yet?  (Check buffer-full bit in SSP-status register.)
               IF_BIT  SSPSTAT, BF, IS_SET    ; If so,
                   RAM_BANK  0
                   CLRF  SSPBUF               ; send out a dummy byte in order to get the first data byte to read,
                   INCF  FLASH_RD_STATE, F    ; then increment the state.
               END_IF
           END_OF

In this case, the serial-port shifting for the given hardware takes time, and there's too much to do to twiddle our thumbs, so I have kind of a multitasking system where every time a task is called up, it looks to see if there's anything it can or should do at the moment, and if not, lets the computer move on to do other necessary things while it's waiting. (Don't worry about it being left in RAM bank 1 if the buffer-full bit is not set. There's a RAM_BANK 0 instruction right after the END_CASE.)

This is still assembly language, although I patterned and named many of my structure macros after common Forth control structures. They are formed much the way Forth compiles them. A stack is formed in the assembler for the assembler itself to use to keep track of things like jump addresses that will need to be filled in when they are found, all in the first pass (since we're not using labels). Since it's a stack, the nesting of structures is automatically accommodated.

As you get a lot of decision-making, branching, looping, and exceptions to unevetful straight-line code, the macros become more and more valuable. It's nice going a hundred lines or more without a single label, and being able to more easily see the structure and the conditions under which the program carries out various operations. See the article for more info.

[HP67]

Very nice, Garth. I write assembler for a living and I also use macros heavily. I don't like structured programming so I don't write those kinds of macros. I find IF/ENDIF useful but my code is usually not algorithmic so I don't have need for loop control.

What I do write macros for is to encapsulate control blocks and operations on them. We've been doing this before C++ came out btw I don't use OO but quite a lot of the concepts I do use and like are considered OO concepts after the fact. I think we all agree on the value of strict interfaces and encapsulation. We can go a bit further and package control blocks and fundamental operations on those control blocks like allocation and deallocation, serialization, chaining, etc. and come up with what would be considered an "object." As you, I don't do GUI, and I don't have a need for today's OO in any of the code I write. But you and I are writing assembly/assembler and most of the code today by volume is web stuff, and GUI, and that is mostly about using Java or other OO languages and OO GUI toolkits.

They did put men on the moon without OO, and I have worked on fairly good sized projects in assembler that run constantly in business-critical environments (as in if they don't work, people will lose their jobs and the lawyers will be popping open their briefcases) so nobody is going to convince me I need OOP or that OOP is the one true way. OTOH I don't think OOP is useless or wrong, it's just another tool in the bag to use or not use, as appropriate in each situation.

[Tugdual]

I think that for low level coding OOP doesn't indeed make a lot of sense. I work on simulation softwares with no real time aspects. I switched on OOP decades ago and it took me about 6 months to start thinking a different way. Also OOP didn't make much sense before STLs (a step above macros) and boost which is an amazing library. Finally I started Qt few years ago and I remain very impressed by this environment which truly is an OO achievement. To me OO reduced the analysis time (users talk and think object because real world is made of objects) and introduced productivity. All libraries are not identical, it is not all about OO being the graal, talent remains a big part of solutions and if assembly is your language to deliver quality and if this is aligned with your company strategy then definitely the way to go.

[David Hayden]

Robust programs require clear code and well defined interfaces. You can do that well, or poorly, in any language.

OO helps me define the interfaces. You can wrap things up in nice little packages (objects). Consider RPL objects for example. All objects have a prolog. Then can be executed, skipped and displayed (converted to text). It's natural to define an "object" class with a prolog and methods to execute, skip and display the object. A real advantage of this comes when you need to define a new object: You know that you have to write the execute, skip and display methods.

But the real advantage comes in things that are easy to overlook. For example, you can create an array of any object type, even the variable length types. If you want to access to 87th element of an array, then you'd really like to skip right to that element if the elements are all fixed length. Rather than add logic in the array code that says "if it's an array of reals or complex numbers or characters then skip right to it" you can add a "fixed length" flag to the object and the code can say "if it's an array of objects that are fixed length then skip right to the correct place."

Now when you go create a new object, you know that you need to define that flag. Otherwise, you'd have to somehow remember to go change that obscure code in the array processing - only you wouldn't remember to do it until Joe Horn found the bug after the code was released.

Dave

[Joe Horn]

(03-05-2014 09:11 PM)David Hayden Wrote:  ... Otherwise, you'd have to somehow remember to go change that obscure code in the array processing - only you wouldn't remember to do it until Joe Horn found the bug after the code was released.

Releasing code actually creates bugs, just like serving coffee during flight causes turbulence. Universal law.

[Thomas Radtke]

(03-04-2014 10:05 PM)Han Wrote:  He was probably referring to inheritance when creating a new object based on existing objects (so that you don't re-invent the wheel).

Or classes. Didn't know objects can be extended in C++. Another good reason to not touch this language if there's a way around it - just too complex.

(03-04-2014 10:05 PM)Han Wrote:  OOP just makes it a bit easier to organize code as everything is very modular not just by code, but also by design.

Exactly this was my experience with Java. It's easier to write, read and maintain the source code than for any non-OOP language.

[Marcus von Cube]

A few more or less (un)related comments:

Another big point in OO design is visibility and encapsulation of data and code. A class defining the properties and behavior of the objects it represents has data and methods which are visible from outside: This is the public interface which should be well thought out, documented, and stable in order to be useful (especially for other developers or further projects).

Then there is the protected interface. It consists of methods and data which are not visible from outside but help in extending the class by the concept of inheritance. It's meant for developers who need to provide similar or extended functionality which may require to reuse some of the internal workings of the original code without rewriting or copying it.

Last but not least there there are private methods and data. They serve like local variables and subroutines but are subject to change without notice.

A big difference between an attribute of an object (be it private, protected or public) and a local variable is that the former saves state during the lifetime of an object. A static local variable in C isn't the same because it exists just once in memory while an attribute exists once for each object. In classic C you would either need to pass the context as a parameter or use arrays and a reference index to access the right data.

The main problem of C++ is that it is a superset of C. You're not forced to follow the object oriented programming paradigm, classic C style modularization works as well with only very few differences to plain C. This leads to a wide range of coding styles. There are a few other concepts in C++ which may lead to confusion (implicit casts combined with operator overloading is a debugging nightmare!). Java has tried hard to avoid all this at the cost of some added verbosity. You simply can't write Java code without using the keyword class!

[Howard Owen]

Code:


imma Tire()
   I have an outside diameter.
   I have an inside diameter.
   I have tread. It's *this* thick.
   I'm made of rubber. It's *this* hard.
   I'm inflatable to a max pressure of *this* 

   You can ask me what my max tread is.
   You can ask me what my max pressure is.
   You can ask me what my rubber hardness is.

   You can tell me what percent of my max pressure I'm at.
   You can ask me what percent of my max pressure I'm at
   You can tell me what percent of my tread is left.
   You can ask me what percent of my tread is left.
   You can tell me how fast I'm losing pressure.
   You can ask me how fast I'm losing pressure.

imma SnowTire()
  I'm a lot like a Tire()
  except I have thicker tread.
  except that I'm made of harder rubber.
  except that my max pressure is lower.

imma TankTread()
  I'm nothing like a Tire().
  Start over.

[Sylvain Cote]

It is possible to use objects, interfaces, design patterns, exceptions, reflection, etc
in a micro-controller environment but you have a lot of work to do to make it happen.

I have prototyped and then lead a successfull project using GNU C++ for ARM with a
Cortex-M3 MCU and FreeRTOS 7/8.

The internally designed board has the following: (partial listing)
- Cortex M3 MCU with 96KB RAM & 768KB Flash
- external 8MB of flash for firmware/config. updates (2MB) and data storage (6MB)
- GSM/3G cellular radio with IP stack in the radio for transferring data/firmware/config/etc
- Sensors: GPS module, Accelerometer, etc

50k devices in the last year has been shipped with the following C++ framework platform in it.

Today, a medium complexity application with two boot loaders fit in a little less than 400k
of Flash and the application consume around 50K of RAM.

One thing that I underestimated was the time it take to convert a seasoned C procedural embedded
software developper into a "java like server" developper. I started with a team of 6 persons
(excluding me), lost 2 persons in the process that could not follow and for the 4 persons left
it took them 12 months to fully integrates all the concepts and be completely autonomous.

Best regards,

Sylvain

PS: The following list some of the constraints imposed on the project ...
> service oriented architecture
- each service is delivered as pluggable library
> Hardware Abstraction Layer (HAL)
- defined with interfaces
> Hardware Implementation Layer (HIL)
- classes implements the interfaces define in HAL
- allow fast changes in the hardware without impacting software behaviour
- each HIL is delivered as pluggable library
> OS Abstraction Layer (OSAL)
- defined with interfaces
- also include some concrete classes that are OS generic
> OS Implementation Layer (OSIL)
- classes implements the interfaces define in OSAL
- allow transparent RTOS and target platform changes
- each OSIL is delivered as pluggable library
> object oriented programming
- single inheritance is allowed (multiple-inheritance is not)
- all classes must derive from the CObject (root) class
- all concrete classes are final and cannot be derived
- ex: [CObject]<-[CService]
> object instanciations & associations
- no composition is allowed
- only aggregation is permitted and through constructors only
- aggregation is done with references only (no pointers allowed)
- all objects must be statistically instanciated (exception: inter-task messaging)
- all aggregations must be done before the main function is called
> programming by interfaces
- interfaces are defined using pure abstract classes
- interfaces must derived from the CObject class or from another interface
- ex: [CObject]<-[IBus]<-[CSpiBus], [CObject]<-[IAddress]<-[CSpiAddress]
> unit tests
- unit testing framework design from scratch to use the less possible RAM/Flash
- all test cases must run in the MCU itself
> design patterns
- most designs from the GOF used (facade, chain, command, responsability, etc)
- ex: [CObject]<-[ICommand]<-[CCommandChain], [CObject]<-[ICommand]<-[CCommandMock]
> memory management
- custom memory allocator (for inter-task messaging only)
- multiple fixed size memory allocator (no fragmentation)
> exceptions management
- custom thread implementation
- to reduced stack usage
- to keep the thrower/catcher in the same RTOS task
- no throw in catch allowed (to reduced stack usage)
> miscellaneous features
- namespace used
- RTTI not allowed (consume way to much memory and flash)
- custom reflection implemented (cost only 4 bytes of RAM per instanciated object)
- no templates (well almost, only used 3 times in the entire framework)
- no standard C++ libraries allowed (iostream, stl, etc)
> there is lot more that I could add to this list but I think the above will suffice for now

[Marcus von Cube]

(03-10-2014 03:11 AM)Sylvain Cote Wrote:  PS: The following list some of the constraints imposed on the project ...

To make a long list short: C++ has way too many features to be useful without very strict rules. (Java has avoided much of the complexity of C++ but it goes into a different direction making it hard to implement on resource limited devices).

Your list reminds me very much of the Symbian mobile phone operation system, stemming from EPOC32, the Psion operating system. The design rules were aiming at stability without losing too much of the power of object oriented design.

I'm coding in OO-ABAP on an SAP system at the moment. The programming style isn't exactly the same but OO is OO. It's just a way of thinking...