C++

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is a bit of a genric question but...

I would like to asses the general suitability of usign C++ instead of C in ceartain applications. However, I have not even looked at C++ since University (and like a lot of things if you're not using it regularly you forget it).

I looking for guides/books/tutorial covering either a transition from C to C++ or learning C++ from scratch.

Ben
-Using IAR (& ocasionally CodeVision)
0.7734
1101111011000000110111101101

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure how much use it is (I avoid the black art myself) but there's always:

http://www.cplusplus.com/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't have a reference for you, but I do have some advice. Using C++ on a microcontroller is very different from using C++ on a PC. On a PC you have suffiecient resourse to fully adopt the object oriented mindset for which C++ was designed. Much of the C++ I see for micros is really a kind of extended C which uses a few features of C++ but often doesn't use the object oriented mindset. You get a kind of procedural/OO bastard technique that may be okay if you want to do it that way, but usually winds up confusing me. I personally would not use C++ on a micro project unless given very good reasons to do so. However, for an embedded project such as a set-top box that requires an ARM and PC like resources, C++ would be the only rational choice. Its like transportation. C is a compact car for local commuting, C++ is a fleet of transfer trucks.

Anyway, once you've looked into this a bit, I'd like to hear you opinion since there seems to be a rising interest in C++ from more recent Uni grads who learned C++ and now want to get into microcontrollers.

Oh, and: https://www.avrfreaks.net/index.p...

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

HWGA.

OOP stands on three "pillars":

- Encapsulation. Classes and objects with members, and a way of controlling the "reachability" of the members). A way simplified explanation would be "local variables on steroids". Any decent OO language/toolchain does encapsulation at compile time. It will cost you nothing extra per se in the running system(see end note though). With such classes you can get into the first part of the OO mindset: Objects can do actions (instead of functions work on data). Example: You "think" timer.Start(); instead of Start(timer);

- Inheritance. Call it subclassing if you want. Or specialization. Any decent OO language/toolchain handles this plain old inheritance at compile time. It will cost you nothing extra per se in the running system (see end note though). With inheritance you can get into the second part of the OO mindset: some classes have some things in common. Those common things belong in abase class that the more specific classes inherit from. Example: You think LCDModule.Home() for a base class, and then inherit this to classes LCDModule4bit and LCDmodule8bit in which you add more specific functionality. Both (sub-)classes have a member function Home().

- Polymorphism. This centers around the concept of virtual functions. Objects of subclasses can be handled as being of the base class, but will in fact act as the sub-class. This will cost you some but there is no support in general to claim that this will generate "loads of bloat". Generally speaking a call to a virtual function will cost you one extra indirection(de-reference of a pointer) per access to a member (calling a member function, accessing a member variable). This is a cost both in code size and execution time. Are you controlling a nuclear power plant real-time with a tiny2313? Stay away from polymorphism and virtual functions. Are you working on a user interface with menus, soft buttons etc on a mega32? Go for it! Example: You have this menu system. The base class is Widget. The sub-classes are Menu, MenuItem, SoftButton etc. Those sub-classes all know how to draw themselves. ThIn the base class there is a "specification" that every inheriting sub-class must implement Draw(). Objects are created to be of those sub-classes, and are held in a collection of Widgets (yes, the base-class). You now need to re-draw the entire screen:

foreach (widget w in widgetCollection){
   w.Draw();
}

In a non-OO world the widgets would be eg. structs with data and a type-of-widget field, and there would be one function for each type of widget. The "draw-them-all" would be something like

for (int i = 0; i

Apart from the details of the syntax, this does more or less the same as the OO version, but it is not only a matter of smoother syntax. It is, as Smiley hints at, a mindset. You think differently. The main difficulty in learning eg. C++ is not the language - it is to de-learn the old mindset and learn the OO mindset.

I realise that I am cheating a little, playing with a language that has a foreach statement (I know Smiley is using C# so lets blame it on that). You can do foreach in C++, but the syntax will not be just that smooth, and you need to know about template classes (let's not, not for now at least). Anyhow, the plain old for-variant in C++ goes something like:

for (int i = 0; i

And now for that note: The cost of C++ (not using virtual functions) might be bigger than I insinuated above, and as I understand it this would come from pulling in more runtime support than necessary. OTOH, I have seen no compiler switch for any toolchain that effectively said: "I won't be using virtual finctions. I won't be using dynamic allocation. Do not pull in run-time support for that".

There. Settled? If you don't stop making sweeping allegations that C++ (or any decent OO language) is generating bloat "per definition", or that C++ does not work in embedded systems, without providing firm facts on the costs or impossibilities I will keep on posting these ranting essays. I know you can all be moderate, humble, and think "it all depends" and "no definitive rule" when posting. Please do it when posting about OO also, or I will haunt you! :wink:

Bonus, if you held out this far:
Thinking OO step 4 is about hadling a system of objects not only using encapsulation/inheritance/polymorphism, but other structural concepts/constructs. Aggregation. Association. "Oh, that just plain old arrays, pointers or some such# you say. No, it's about another mindset and way of thinking. You implement association with eg pointers, but you design thinking "association".
Thinking OO step 5 is about using the first four steps to identify "semi-general" ways of designing and implementing different types (I'd like to say "classes", but that would be in another interpretation than above and possibly confusing) of problems. Design Patterns has been over-haussed, and then over-dissed. As often, the concept deserves something in-between.

Johan.SorryFor(new Rant("Object Oriented Programming"));

[EDITED several times for clarity and polishing of speling and constructs sentence]

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Wed. May 28, 2008 - 08:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
There. Settled? If you don't stop making sweeping allegations that C++ (or any decent OO language) is generating bloat "per definition" I will keep on posting these ranting essays.

There is an old American comic strip called "Pogo", and a famous quote: "We have met the Enemy, and He is us." Who is "you" in the above quote--you (pun intended) were the first and only to use the word "bloat" according to Firefox Find.

Perhaps (I'm not a C++ person) a similarly-structured C vs. C++ app will exhibit no [bleep]. Remembering my heretical views on tight, fast AVR apps especially of the Mega8 class: global (and local) register scratchpad variables, and use the heck out of them. Nearly all global variables; few locals. Not a lot of functions; mostly main(). I don't really think the compiler will be able to resolve everything into "direct access" and match the result, but I could well be totally mistaken.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

you (pun intended) were the first and only to use the word "bloat" according to Firefox Find

Yes, I know. The "bloat" has been up in earlier threads. In one of my edits I pondered to take it out, but I decided to leave it in. Just for your sake, Lee dear! :wink: And before re-reading and editing I missed the "C++ does not work inembedded systems"-part.

Quote:
I don't really think the compiler will be able to resolve everything into "direct access" and match the result, but I could well be totally mistaken.

Now you lost me. Are you talking about a OO toolchain being able to resolve a call to a member function so that the code size and execution time will not differ from your good old function call? There is nothing in principle AFAIK that would hinder myTimer.Start() to take the same amount of code and execution time as StartTimer(myTimer).

To condense my rant above: I am making a plea that we should not talk about the merits or drawbacks with OO in embedded in sweeping terms, but be precise and back claims up. I am not arguing for alwaus using OO/C++. I am asking for OO/C++ to get a fair trial.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Wed. May 28, 2008 - 09:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
There. Settled? If you don't stop making sweeping allegations that C++ (or any decent OO language) is generating bloat "per definition", or that C++ does not work in embedded systems, without providing firm facts on the costs or impossibilities I will keep on posting these ranting essays. I know you can all be moderate, humble, and think "it all depends" and "no definitive rule" when posting. Please do it when posting about OO also, or I will haunt you! :wink:

Though I did duck, I hope that wasn't aimed at me. I will use the term bloat though: the mindset to write a C++ program for an AVR that would, say, read an ADC and show the level on a 10 element LED would indeed be bloated. Just as the mindset that would write the central CAN network controller for an automobile engine in assembler would be withered.

The C++ mindset is hard for us old procedural guys to get our heads around and isn't necessary for much 8-bit microcontroller work. Someone fresh out of school trained in C++ will probably find it a lot easier and would tend to use it for smaller programs.

You've got to admit that all the things you mention are really only scratching the surface of real OO programming with C++ and all of it lies on top of C which means you have a shit load more stuff to learn, use, and maintain in C++ versus C. That expense is well worth it in some systems and not at all worth it in others.

And as an aside, I do use foreach in C# with is more like Java than C++, just to confuse the issue. I learned to use it because therr are C# objects that lend themselves to the pattern, especially in database manipulation. But I don't have access to any objects for the AVR that would lead me to use it in my microcontroller work.

No bad here, just a debate of the gray area between large and complex enough for C++ to pay off and small and simple enough for C to pay off.

But to be confrontational: I'll bet that the majority of AVR projects done in C++ are chimeras of C/C++ which don't reach the level of really showing an understanding or use of OO programming, while confusing the simpler procedural techniques that are the hidden backbone of the program.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The C++ mindset is hard for us old procedural guys to get our heads around

I thought that we where of similar age, Joe, it seems to me that you are both the brighter and more energetic one, so you should have an easier time than I had :)
Quote:
and isn't necessary for much 8-bit microcontroller work.

C isn't necessary either.

Quote:

C# with is more like Java than C++

Those are just three different OO languages. Apart from superficial syntactic matters they are quite similar. It's not the languages that are difficultm, and hard to learn. The difficult thing is to see what generalized concept that lies behind the specific language construct. Java and C¤ has "interface". C++ has not. Can you do the equivalent of a C#/Java interface declaration in C++. Certainly. A class with just pure virtual member functions. Does the skilled OO programmer think "Oh, a C++ class with just pure virtual member functions"? No. He thinks "Aha! An Interface!".

Quote:
I'll bet that the majority of AVR projects done in C++ are chimeras of C/C++ which don't reach the level of really showing an understanding or use of OO programming

If this says what I think it says, then I am not buying. One of the points of my rant was that you user as much of OO as you need. You know what you gain by using each "level". The above quote seems to argument that you are not using OO until you use it all. The corollary is that you don't really use plain C until you use dynamic memory allocation.

Quote:
while confusing the simpler procedural techniques that are the hidden backbone of the program.

This seems to argue that OO is confusing matters. I claim that it is clearing matters up, offering a better level of abstraction for large parts of the design and implementation process. As I read the above, I can construct this corollary: "while confusing the simpler machine instruction execution techniques that are the hidden backbone of the program". Tell me more about what you think is confusing? (Not a snide remark, I am really interested!)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Speaking of bloat, a bad compiler produces bigger code than a good compiler. The question is, how good are the AVR C++ compilers? I'd say GCC C++ has some issues, but I still use it.

Using virtual functions with the GCC compiler does indeed produce bloat. It has been noted by others, and myself.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting conversation guys...

I myself am not a C or C++ programmer, but I am an OO programmer via VB (arguably not really OO) or RealBasic (as OO as OO can be).

I know I will get flamed to no end with this, but C++ seems to do to C what VB did to plain old quickbasic..

Best way to look at object oriented programming is imagine every function, object, and variable in a tree structure. It's as simple as that.

A lot of books on the subject insist on using ridiculously complicated terms for very simple things... I think that is in part due to vendors wanting to confuse the customer into thinking his particular compiler or language is better than the other..

If you kick ass at C and are a poor schmuck at C++, you applications will certainly not benefit from you trying to patch a new language in. If you want to learn it simply to know it, go ahead, but my guess is everything "new" you will learn in C++ will be doable in C and chances are you already know how to do them. but they aren't called or written the same way.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
This seems to argue that OO is confusing matters. I claim that it is clearing matters up, offering a better level of abstraction for large parts of the design and implementation process. As I read the above, I can construct this corollary: "while confusing the simpler machine instruction execution techniques that are the hidden backbone of the program". Tell me more about what you think is confusing? (Not a snide remark, I am really interested!)

When I think microcontrollers I think about the microcontroller itself and all its tools. I think about memory and port I/O and PWMs and interrupts and etc etc. When I think OO I think tasks that need to be done by a black box. I think O2 sensor and air intake valve and spark timing and etc etc. In an OO programming mindset I'd design the whole system (at least as much as possible) thinking about concrete or abstract objects that are entirely divorced from any hardware implementation (some will argue this is good program design for any project). In a procedural programming mindset I'd be thinking that I need to communicate a command from a PC to an AVR using a USART, and that I need to set a PWM to such and such to get the motor speed at a rate determined by the input of a Hall sensor on a rotor shaft. I'd be thinking objects, sure, but they'd be my AVR hardware/software tools that I've been using since the Cretaceous.

To me OO is adding a complex layer of abstract thinking about the program. This extra layer of thought doesn't make a lot of sense to me for small programs on small microcontrollers where I can easily visualize what I need to do and what tools I have on the device and in the C language. I see the value of the extra OO layer for a large or especially complex program or one being written by a bunch of folks. The OO layer gives an overview and a structure to hang everything on. Again, back to the transportation analogy, a compact car looks just right in my driveway and a transfer truck looks just right backed up to a Supermarket loading dock. But a transfer truck would look crazy in my driveway in the same way that writing a C++ program to make an LED throwie would look crazy.

But all that said, if a person comes to this already being very familiar with C++, then it also wouldn't make much sense for them to try to shed that mindset when they are doing a tiny project if the micro can hold the code generated. To get back to the original point: 'confusing matters' if you don't know C++ and you can do the project okay with plain old C then adding that extra layer of abstraction would be confusing matters in just the same way that if you already have an OO mindset, trying to do a procedural C program would add an extra layer of learning that would also be confusing. The trick is to know when your personal mindset justifies which particular language. I use C++ and C# on a PC because there are so many objects available - it simplifies my life. and I use C on a Butterfly because I also many objects which in this case are tested C functions that I can use in a procedural mindset.

I think I'm repeating myself. I'm guessing that you find OO easier than I do and would use it for simpler programs than I would.

But you do raise a issue. Should students who are just starting out with microcontrollers learn C or C++ first. My bias would be to go with C since there are decades of materials available. I'm not really sure how much material is available for using C++ on AVR microcontrollers. Maybe we are going through a transition where we will slowly move to C++ just like we slowly moved away from assembler to C.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Skilled use of C++, and OO methods in general, can be helpful when requirements are subject to significant change, such as during a prototyping phase.

Of course, the smaller the app, the less advantage can be gained.

C: i = "told you so";

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Struth! As an engineer, who was trained from the begining in OO design using C++, and who now spends most of my time writing in C for AVR using ICC, I thought I might have some worthy pointers for the OP. But now I'm just too scared to share.

I'm not knocking anyone. I found reading all this stuff quite interesting and informative, but then I already know something about the OO approach. It may be a bit harder to grasp for the OP who is enquiring about a good method to learn the OO way which as been suggested is little more than a mind set.
I totally agree with this and altough coding in C, I still use a largely OO focus. The challenge then becomes "how to impliment what I see in my head as an object, into a smaller sub-set of the language. In any case I find implimentation really straight forward once the higher level concept is clear.

Opps, I've joined the waffle. So easy to get sucked in. All I really wanted to say was:

To the OP:
Ben, I would suggest you get a good book on C++. I recommend "C++ How to Program" by Dietel & Deitel but it may be a bit dated nowdays.

If you already know C then essentially you can flip through the 1st 5 chapters which teach the fundamentals of C and structured programming. They are still a great reference though and are presented in a way that will start you thinking in the right direction as you head towards using the specific OO tools.

Cheers
Steve

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think the useful part of sw design that c++ and objects brings is forcing the designer to think about the objects and methods each one uses. Designing the classes. I suppose you could do an oo design then program it in c. Is there a 'best practices' recommendation for putting classes/objects in files/modules/libraries? One file per class?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

One file per class?

That is very common, yes. (Of-course there is a header file with the class declaration too). Ive seen one class spread over several files - for very big classes (that really ought to be smashed...). I've seen several classes in one file - when they are closely related (eg. the "top of a framework").
Quote:

I suppose you could do an oo design then program it in c.

Of-course, and it has been done. (I'd rather leave the handling of the v-table to the compiler though...). During my time at Uni in the eighties I even came across an article where a group had done it in assembler.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]