I don't want to be a C programmer any-more. I need to the help of you GeeekS!!![migration]

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

I can remember myself when chose just 'C' as a good language and enough for my job several years ago. after about a year later I added C++ to my list[just C and C++smiley] but never seriously used it(in fact never used it and I just read some books about it[just "getting started" books]). I chose 'C' because some seemed-experts told me that by C I can write my programs in minimized size. they said me "OOP would occupy a big part of the memory and you don't need it because MCUs have small memory"(is it correct?). BUT today I want to choose C++ as my sexiest baby on the list.cheeky although I will use 'C' for simple and small projects and I think I know C enough to write my simple/small projects.

I want to use it from now on because I have seen many guys who are working/using C++ to write their programs. I feel the Embedded world is getting bigger and MCUs are getting cheaper and they are going to have bigger memory in the future. nowadays you can run and use a colour display. this is the cockpit of an old aircraft(F-4):

 

 

And now look at the cockpit of a modern one(F-35):

 

 

 

One more from a nice private jet:

 

A colour display need a very well GUI.wink writing a good GUI with 'C' will probably take time. more than "C++" or because it's a bit complicated then it would be better to write it by C++. that's why they have created C++. if we get back to many years ago(about 15-20 years ago yeah I think it's good) you could see everybody or many embedded programmers were using Assembly but now what happened to them? they are using C/C++. I think a revolution happened to them(embedded programmers). they changed their language programming. and now that's what I'm doing. I'm changing my main language programming. it's C++. now the questions:

 

1- What's your opinion about my arguing and changing my main language to C++?

2- Is there any problem/issue in ambush for me during this migration? e.g. can I use my C libs in C++ without any problem? and or Can I use something like Sprintf in C++? yeah I know there are other functions/commends like 'COUT' or 'CIN' to use but I think Sprintf occupies much less than those standard commands in C++ (or C++ compilers are enough smart to reduce the size of programs)or some-times for porting my libs I need them. won't I?

3- Please provide a book as "getting started" and another one as "source" for C++(the best you think). please note that I said just C++.

 

Thanks guys

"Hiss Hiss"

 

To moderators: Is here suitable for this topic? if not, then please move it.

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

Last Edited: Wed. Apr 6, 2016 - 12:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

1) C++ is the future so, yes, I would add it to your portfolio. What's more C is a subset of C++ so you aren't discarding anything by widening your focus to include the ++ bits. It does, however, require you to take a different approach to the top level design which may be tricky if you already know C in depth as the temptation is just to use "C like" solutions to implementation problems.

 

2) On the whole, yes, think about things like printf() and strcpy(). You use those happily in C++ and yet they are functions written in C. The key to linking the two is the magic words:

extern "C"

If you take a look at something like <string.h> you will find:

#ifndef _STRING_H_
#define _STRING_H_ 1

#define __need_NULL
#define __need_size_t
#include <stddef.h>

#ifndef __ATTR_PURE__
#define __ATTR_PURE__ __attribute__((__pure__))
#endif

#ifndef __ATTR_CONST__
# define __ATTR_CONST__ __attribute__((__const__))
#endif

#ifdef __cplusplus
extern "C" {
#endif

   [rest of file]
   
#ifdef __cplusplus
}
#endif

So everything in this file (and stdio.h and most of the others) is wrapped in:

extern "C" {
    ...
}

When C++ is being used it normally takes a simple looking function name like:

int add(int a, int b) {
    return a + b;
}

and gives it a really complicated looking internal name like "_Z3addii". That's because in one C++ program you can have more than one function with the same name as long as the function parameters are different. So if I had a char version of that:

char add(char a, char b) {
    return a + b;
}

then internally this would be called "_Z3addcc". This is so you can just call add() and if you pass it char parameters the char(char,char) version is called while if you pass it int's the int(int,int) version is called. The changing of simple function names like "add" to _Z3addii/_Z3addcc is called name mangling.

 

Now if you just wrote some C++ and called a function called strcpy() passing it a couple of char * pointers then the C++ would try to link with a function called _Z6strcpyPcPKc but the C function is really called "strcpy". So you tell the C++ compiler "here is a function that must always be referred to as 'strcpy'" and you do that with "extern "C"".

 

But as long as you understand this then you should have no problem calling existing C code from C++. Be warned that while not totally impossible it is very difficult to do things the other way round - you would find it very difficult to call a C++ function from some C code. What you don't realise when calling C++ functions is that there is always one additional parameter passed first to the function before all the ones you give. It's known as "this" and it is a pointer to the block of RAM where the class variables for the particular instance of the class where your called function is defined are located. You cannot easily generate the "this" value to pass into a C++ function when you try to call it from C.

 

But normally you are just going to be "calling backwards" to old legacy code like strcpy()/printf() and so on and (as long as they are defines extern "C") you will have no problem with that.

 

3) Like K&R is the "bible" for C, so the book by Bjarne Stroustrup is the "bible" for C++. See for example:

 

http://stackoverflow.com/questio...

 

for some suggestions.

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

Rohalamin wrote:
"OOP would occupy a big part of the memory and you don't need it because MCUs have small memory"(is it correct?)

No that is not correct. It is utter rubbish, an over-simplification and foul generalization. It has gbeen discussed here many times before and for a large part of those discussions the person claiming it has shown to just be ignorant.

 

You can construct cases for which C++ "bloats" or where it executes slowly, but you can do that using any language.

 

It is a fact that the language had as one of iit's design goals to be efficient, and that there would be no cost for language features not used.

 

I would say that "really learning C++" is the secondary goal. The hurdle for most people is changing the way they think - it's a paradigm shift to go from "classic C programming" to object oriented programming (regardless of what OO language you choose).

 

More on this later!

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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: 1

The fallacy that Johan is referring too is because it is true that C++ puts virtual function tables out in RAM when they could actually be contained in flash so some people berate C++ for "using all the RAM". One simple solution is to avoid the use (or over use) of virtual functions. On the whole your average LED flasher or whatever is going to be virtually identical in terms of generated code to C.

 

One slight gripe I have with C++ on AVR is that the people who control the C++ (not C) compiler in GCC won't allow anything non-standard to be added which means that the new __flash/__memx stuff for the C compiler is not in the C++ compiler. Two solutions to that: (1) just stick with PROGMEM anyway or (2) but the flash based stuff and accessor functions in extern "C" code.

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

JohanEkdahl wrote:
I would say that "really learning C++" is the secondary goal. The hurdle for most people is changing the way they think - it's a paradigm shift to go from "classic C programming" to object oriented programming (regardless of what OO language you choose).   More on this later!
This is to me the central problem.

 

I have yet to see a programming problem that I cannot solve in C (that is, if I can solve it at all). This may be mostly because I've only selected small and simple programming tasks. In order to know what I would gain from C++, I would have to spend some serious time to study it and then try to mold my hardening mind into the C++ paradigm (I've made a few failed forays in that direction). If I was just starting out and thinking about taking a job where lots of programmers work together on a large project, then I'd put in the work, but for the simple sort of things I do on a microcontroller, well I'm not sure it would be worth it. 

 

And, this also brings up the whole "Arduino is C++ thing'. IMHO the Arduino's use of C++ is a perfect example of what can really go wrong when folks only half understand something. What I think I'm seeing is some poorly implemented C++ created by folks who aren't thinking in the OO paradigm. And to me this is the risk: that folks who barely know C, start mimicking poorly understood C++ constructs and learn a jumbled style that doesn't use either C or C++ to their best advantage.

 

C really is simple and is modeled on the underlying machine - a fact that IMHO is very important for microcontrollers with their limited resources. And also IMHO C++, while a great language for teams on larger machines, doesn't really bring enough to the table for those of us still working with little resource limited devices like AVRs.

 

We've had this discussion before and I in no way mean to denigrate C++ for applications where it makes sense, I just don't see the learning curve making much sense for the kinds of things we do with AVRs. So, yes Johann please do 'more later' and try again to educate me as to why it can be a good use of our time to learn that paradigm shift to move up to C++.

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

Joe,

 

The idea is that it's about maintainability. Say you have an AVR with two UARTs the traditional idea in the old C world is that you'd have uart0_sendchar(), uart0_getchar(), send/get_string and so on. Then you'd have all the same for uart1 where the difference was that it was using UCSR1A and UDR1 and so on rather than UCSR0A, UDR0 etc.

 

When you found some bad bug in the code or thought of some great feature you now had to work through your sources putting the modification into the UART0 code then the UART1 code and so on.

 

What C++ tries to do is pull everything that is generic out into a kind of "top level template" then you create uart0 and uart1 classes that inherit from "uart common stuff" so now, when you have a common fix/feature you change the base class (lets call it) and the other inherit the change from it.

 

That's kind of the goal for C++, it's about keeping things in neat little boxes and building complex structures out of easily manageable building blocks.

 

Now as it happens I used to be a dyed in the wool C programmer and I always write C code (well the professional stuff anyway!) in a very modular fashion anyway so when I was first made to use C++ I baulked at it thinking it was just a nightmare of convoluted sytax just "getting in the way" but slowly but surely I am starting to see the benefit of working with a language in which modularisation is not just optional but it's a core principle of the language.

 

It is, however, very hard for dyed in the wool C programmers to "get" the C++ thing. I think all you can do is force yourself to use it for a year or two and by degrees you will start to see the advantages.

 

Young kids coming out of college who've only ever been exposed to object programming have a distinct advantage over us old grey beards! (having said that the evidence here is that they seem to omit teaching them about the need for proper specification and design - presumably the idea is that if you are doing everything in a modular way you can forget that? Well you can't).

 

BTW what makes you say the C++ usage in Arduino is being done by those who poorly understand? A lot of Arduino C++ library code I've looked at has looked pretty good to me. Or do you mean the "cores" stuff?

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

Thanks guys

Would you please give us the links of those topics?

clawson wrote:
...

3) Like K&R is the "bible" for C, so the book by Bjarne Stroustrup is the "bible" for C++. See for example:

...

Isn't this book for those who are toddling in programming?cheeky

Anyway, thanks for the link. I have already seen it. I asked that question because I thought there are other guys who have other suggestions/recommendations for books on C++.

 

 

@smileymicros

You have a very well book about programming AVR by C. I have read it. a book with eloquent prose. I really like it.smiley pardon me but I think you are wrong(at least a bit). we have the same problem with those in my country who use Bascom compiler. a poor compiler with a language which is not common between embedded programmers/compilers. those in my country who are working/using Bascom do not want/like to give up it and migrate to C/C++. if you want to find a job in my country, you should be a C/C++ programmer and no one of them wants to hire a Basic programmer. nevertheless they still insist on using Bascom.

 

About C

Indeed it's a great language but take a look at the history of MCUs or embedded. from about 20 years ago to now. look the changes. some-things have been changed. using C++ isn't limited to just bigger embedded projects. I have written a couple programs by QT. without learning another language. it's a great collection of libs + sooo beautiful interface. is there something like QT for C. surly you can do it by C but really is it like QT?

This is a simple example.

 

Some-things belong to their time!

 

 

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

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

My 2 cents as a Jr Freak and C# programmer...

 

Just like the picture shows, you can always use C, like there is always a need for a parking break.

 

"When all else fails, read the directions"

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

My opinion is C and C++ are different tools (even though they are from the same base) for different problems. Most embedded programmers (at least in the 8-bits world) probably do not gravitate towards C++ because there is frankly no need for object orientation in small projects. A typical microcontroller project will startup, initialize, and then do something in a loop until power goes out. There might be 300 lines of code written procedurally. There is no point in adding abstraction at those project sizes. It won't make the code easier to manage. If, on the other hand, you are working on a humongous project with 50000 lines of code, it might make sense to break it down into classes and avoid having 50000 lines of inline procedural code. Or if you are working with a lot of data structures that derive from others, or with hierarchical structures, etc.

 

The main problem is that C++ requires a different mode of thinking, and once you get that object-oriented mode of thinking, it's usually hard to turn back off. Having programmed most of my life in object oriented languages I find procedural languages clumsy and annoying when I have to work with them now. I would much rather define classes than structs. Global variables are stupid. All that jazz.

Last Edited: Wed. Apr 6, 2016 - 06:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

While K&R is recommended for each C coder to have on the shelf, when it comes to C++ Stroustrups "brick" is less so.

 

Don't get me wrong - It is a good book, but "heavy". Partly because it reflects the size of the language. While C is actually a very small language, C++ is a huge language.

 

And while C has been remarkably stable over its 40+ years of existence C++ has undergone several major changes. Again, don't get me wrong - there has bee very little if anything (At least, I can't think of anything right now) that has been thrown overboard. But e.g. the C++11 overhaul was such a change/addendum that Bjarne himself said something like "It feels like a new language".

 

Actually, if an ambitious student really wanted to grasp the underlying ideas about object-oriented programming I'm not that sure that I would recommend C++ for that. There are other "cleaner" languages that offers a lot of what C++ offers language-wise but does not have the mass of subtle and not so subtle intricacies that C++ sports.

 

As long as you're just talking the foundations of OOP (often referred to as "the three pillars") - encapsulation, inheritance and polymorphism  - then C++ will serve you well. But when you get into e.g. generic programming (template programming) and other stuff C++ gets quite intricate.

 

If someone asked me about what language to use to learn the principles of OOP I'd just as likely say "Java or C#". They both sport things that modern OO languages should. Like the template programming mentioned (though the flip side of C++ complexity here is that there is a lot of stuff you can do in C++ that I think you can't in Java or c# - google "template meta programming" for more). Or like lambda expressions (An OO person might describe this as "code becoming a first class object" - the idea, simplified, being that you can pass executable code around as objects. Think of it as "function pointers on steroids").

 

Add to this that there are things that definitively is OO (but perhaps rather OO Design than OO programming/coding) like "idioms" ("how you do certain things") or even "patterns" (a brilliant concept, but carried around by so many like carrying a hammer just looking for a nail that it was close to being ruined.)

 

So OO is more than just another type of languages with slightly different technicalities. It is a different way of thinking about things. In code this is reflected by (using a ring buffer as an example) you not doing

 

RingBuffer_t theBuffer;  // Typically a struct type
char c;
...
RingBuffer_Insert( &theBuffer, c);

but rather something like

RingBuffer theBuffer;   // theBuffer is an object of the class type RingBuffer
char c;
...
theBuffer.Insert(c);

This might seem just like a slightly different syntax. But behind it hides several important principles:

 

1) The ring buffer is the prime "thing"  - not the function

2) There is a set of operations supported on an object (it would be more correct to say "supported by the class" but that will lead too far right now)

3) By using the features of the OO language you can restrict access to the "inner workings" of the ring buffer, exposing it entirely to the outside world through an interface, the set of publicly accessible methods it supports.

 

Item 3) is the first pillar OO "encapsulation". Done well, you do not need to know how the ring buffer is working internally. Is it using an array? Or is it a linked list? (Stupid, of course, but for  the sake of this example only.) It does not matter to "the user". As long ass the operations on the RingBuffer works as documented that is enough. Encapsulation is about isolating (or hiding) the inner workings, the implementation, from the users. This goves great freedom for the implementer to change things. As long as he is adhering to the interface nothing will break.

 

But wait - there's more! Even if you are the sole programmer encapsulation is a concept that you can benefit from. Using it the code will become more modular, and different parts of the code will be dependent on each other just to the extent absolutely necessary. It is a way of doing things, a state of mind, an approach... Things like this os what I meant when I  sais something above to the effect that it is not about learning a language, but adopting a new way to think.

 

Also, not obvious from the above, the RingBuffer class can be specialized. You might want to have a type of ring buffer where characters are translated from, say, 8-bit ASCII to Unicode upon insertion. Most of the functionality should be identical to the plain 8-bit ASCII char  ring buffer. Instead of re-writing the whole class you can pick the RingBuffer class type and build on it. You "inherit" it's implementation and thten you override what kind of data it holds (now Unicode, rather than 8-bit ASCII) and you "override" the Insert function (OO purists would say "you override the method"). But, and here's an important point, other functions like Length(), Empty(), Clear() and so on is simply reused from the "basae class" you inherited from. The compiler helps you with this - the language has constructs for specifying this inheritance.

 

The inheritance establishes a system of types and sub types.

 

[And of course this is veeery sketchy - C++ folks, please don't jump in and bite on syntax errors - we're talking principles here!]

 

RingBuffer       ringBuffer1;   // A ring buffer for 8-bit ASCII chars
UnicodeRingBuffer ringBuffer2;  // A ring buffer for multi-byte Unicode characters

// PAY ATTENTION NOW!

RingBuffer * theRingBuffers[] = {
    &ringBuffer1,
    &ringBuffer2
};

Did you see that?!? A pointer defined as to point to something of the RingBuffer type can actually point to something of the UnicodeRingBuffer type! This is possible since UnicodeRingBuffer is a "sub-class" of RingBuffer. Put another way: All UnicodeRingBuffer's are by definition also RingBuffer's. (Cf. "All cars are vehicles", "All ducks are birds", "All workers are employees" etc etc.)

 

So, now we can do stuff like

 

for (int i = 0; i<2;  i++) {
    int length = theRingBuffers.Length();
}

 

Here we have an array that holds pointers to objects of the superclass. We can have such a pointer point to an element that actually is of the subclass. De-referencing the pointer to get to the object only the parts of the objects that was defined/implemented in the superclass are available. calling a member funtion through such a pointer will call the actual member funxtion defined in the superclass (i.e. RingBuffer) even if the object actually was created as being of the subclass (i.e. UnicodeRingBuffer). This is the second pillar - inheritance.

 

 

 

The third pillar then? Polymorphism.? It's about the possibility to reference objects of subclasses as being of the base class but still make them behave as the sub-class. That formulation does not make much sense for you right now, I know. So lets continue with a very contrived example. Well create three different ring buffers using the types of'em outlined above, and place them in an array. Already in this first part of the example, take good note of the element type of the array! Remember the Insert() function (or method). It was implemented once in the 8-bit ASCII ring buffer and then "overriden" in the Unicode sub-class. Now, watch..

ringBuffers[0]->Insert('a'); // This will insert into the ASCII ringbuffer using the non-converting Insert method
ringBuffers[1]->Insert('b');  // This will insert into the Unicode ringbuffer using the converting Insert method

The thing to note is that when implemented using polymorphism, the actual function used is based on the type of the object not the type of the handle! Stop and think about that. Stop and think once again. Yes, now you've got it!

 

Another example would be the one about the animals. You have a base class Animal. You inherit from that into (first level) sub-classes Insects, Birds and Mammals. You inherit from Insect to Spider and Cricket, from Bird to Owl and Duck, and from Mammal to Dog, Cat and Human. There is a mathod implemented for each of these classes called Sound() - perhaps your code plays the sound of the specific animal in a speaker...

 

// Let's just allocate dynamically this time - 'new' is C++ way of doing malloc()

Animal * theAnimals[] = {
    new Dog(),
    new Spider()
    new Duck(),
    new Owl(),
    new Cricket(),
    new Cat(),
    new Human()
};

...

for (int i = 0; i<7; i++) {
    theAnimals[i]->Sound();
}

// Your speaker will go
// Woff! <silent> Quack! Whoooo.. Ribbitt! Meeow! Doh!

Each time through the loop an Animal is "picked", not using any specifics - just Animal. But each object picked still know it's own way to make it's sound.

 

The third example is more real life: No code for this, but I think you'll get it.You have a graphical system where things of different shapes are drawn on a screen. Perhaps it's a CAD system.. Such objects are created, perhaps at the initiative of the user of the CAD system. All those objects of different shapes are held programatically in some kind of "collection" (my examples above has used a simple array, but it could be e.g. a linked list, a hash table or whatever as long as we can iterate over the elements).

 

The individual objects are of classes like Square, Triangle, Line etc. They all inherit from the base class Shape. The collection of shapes holds references to type Shape, the base class. Each sub class hass an implementation drawing that particular shape.

 

Now let's assume that the whole shebang needs redrawing. Perhaps sthe CAD program window was minimized and then restored. The program detects this and simply iterates over all of the objects asking them to redraw themselves.

 

This how GUI systems work. If they are implemented with OO (and they almost always is these days), there are a few base classes like Window, Rectangle... Then there are sub-classes (typically to Window) like button, Menu, RadioButton etc. When the UI of a program needs redrawing the program iterates through it's collection of things and asks each one of them to redraw itself!

 

And it does not stop there! If a thing is shown in the UI you can click on it. Now different "things" must react differently when clicked, and the specific behavior is implemented in the specific sub-classes. A button know what to do when clicked, a menu item know what to do, a caption knows what to do (probably "nothing") etc.

 

There's MUCH more to GUI OO systems, so I won't push this further.

 

Last comment: It might look like you solve everything with inheritance but don't fall into  that trap. There is another mechanism, often called "composition", that is at least as important. I'll go about it philosofically to start with: Say you want to represent a car and the parts it is made of. Well, you might lete the car inherit an engine. That works (although you'll soon see why it's not the prettiest mechanism for putting a big thing together from smaller paarts). The problem arises when we e.g. get to the wheels. My old Volvo has four of'em... Some languages support "multiple inheritance" but even with that you often can not inherit several times from the same superclass, or at least nmot without making some really weird manouvres! What we want is an object of type Car that references its parts (or have them as members). The general OO term for this is "composition".

 

In the first years of OO thtere was an over-use of inheritance to solve problems it wasn't very fitting for. It went so far so that there was a mantra (OO people might call it a "meme") eventually that was formulated like so: "Prefer composition over inheritance", meaning if you're assemblying something bigger from parts - use composition". and implying: "If you're specializing something more general - use inheritance".

 

Absolutely last comment: Hey youngsters! Learn OO immediately. I am not a youngster, and I still struggle daily to keet to the OO idiom (it does not help that I still code a lot in C...). Meanwhile my younger colleagues treat it as the most natural thing ever. So, there is no intrinsic thing about OO making it hard to adopt the paradigm. It is when you've coded too long using non-OO paradigms that there is resistance in the change-over. So get into it right away. Me, Joey and (possibly) Cliff will have to struggle the rest of our lives to be decent OO programmers.

 

I need a coffe so I'll stop here!

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

Me, Joey and (possibly) Cliff will have to struggle the rest of our lives to be decent OO programmers.

Probably a fair statement.  I'm not quite the old dog you and Cliff are, though ;-)

 

In fact, the first (rigorous) formal training I had in >>any<< language was OO (Ada).  Still have the course work in a box somewhere.  Then life took a detour.  I left coding behind for close to 20 years.

 

I'm in general agreement with the likes of @hugoboss, however.  It's very unlikely that diving into C++/OO will pay significant returns >>in my case<<, thus I have not spent the time needed to do so.  My circumstance may change, of course.  Never say never.

 

Were I to take the OO plunge, however, I'd likley go back to Ada before spending any significant effort on C++.  There are a few threads kicking around on the topic of Ada on AVR, ARM, and other embedded environments.  @gchapman has pointed out a number of excellent resources.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

First, I really don't know enough about C++ to be critiquing the Arduino, it was more a personal feeling than from knowledge.

 

Second, I did a bunch of C# building Windows based UI applications and still use it to build little helper programs that do things like calculate wholesale and retail sales prices based on reading a text file of component costs. But, honestly I don't think it did much for my OOniss.

 

Third, this whole thing jogged some memories of an attempt several years ago that I made to create generic AVR libraries. That would have been a really good place to use C++ I'm guessing. I didn't finish because no one else seemed interested so I moved on.

 

Finally, I really appreciate the C++ exposition you just gave. About 2/3 through I actually heard something physically pop in my brain, so I decided to stop and have at it again later after plenty of sleep and lots of coffee before attempting it again. Nothing wrong with your writing, but my brain may be way to old to adapt to this. I guess we'll see. 

 

Anyway, thanks!

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

smileymicros wrote:
About 2/3 through I actually heard something physically pop in my brain

Absolutely normal reaction. It is expected. It's the paradigm shift.

 

Also, I just blurped all that out without much thought. I feel I could do much better, more structured, better examples, more reasoning etc. But the difference between just "blurping out" and write some serious tutorial stuff (I've done a lot of that in earlier days, when teaching) is perhaps a factor 10 to 25 in time. Realistically, that won't happen. Let's just muddle though if you want to. Somewheere along the line there will be glimpses of Aha!s, silences of contemplation and flashes of enlightening. Hopefully..

 

BTW, by brain pops half of the rime. The other half of the time, it farts...

 

Re OO on AVRs: Yes the resource-challengedness of'em makes for just using a subset of OO. But it is not unlikely that there will be an abundance of more capable ARM Cortexes "owning" a larger area of the field in the future, and if so then more of the OO features of e.g. C++ could come to good use. And remember that one of the primary design goals of C++ was for it to "be efficient", and to place costs at build time rather than run time if possible. Template programming is one of those things. And encapsulation and inheritance (w/o polymorphism) brings no extra costs compared to doing the same in C. (But I've ranted about that uncountable times already, so I'll stop here awaiting the inspiration to actually write a serious piece on it.)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

This is all very interesting, but I suspect it goes way past what the OP would understand at this point. Not really surprising: its easier to ask a question than to understand the full-depth of its answers. OP: when you're expert enough to understand the answers, you won't need to ask the questions anymore. :-)

 

On another front, all these nice cockpit pictures and expert advice on embedded designs reminded me of the F22 squadron shot down by the International date line

ɴᴇᴛɪᴢᴇᴎ

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

I would like to learn C++. I've created a RTOS in C and can see how OOP could help.

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

This is all very interesting, but I suspect it goes way past what the OP would understand at this point.

You hardly know Amin well enough to make that assertion.

 

Don't be misled by a possible language barrier.  His English has, however, grown in leaps and bounds over his time here.  He's been with us for quite some time and has adequately demonstrated his expertise and experience.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Thu. Apr 7, 2016 - 12:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

netizen wrote:

On another front, all these nice cockpit pictures and expert advice on embedded designs reminded me of the F22 squadron shot down by the International date line

 

Transcript reads:

When you think of airplanes from the old days, with cables and that type of thing and direct connections between the sticks and the yolks and the controls, not that way anymore.

True.  Today we use egg-whites only.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

joeymorin wrote:
You hardly know Amin well enough to make that assertion.

Don't be misled by a possible language barrier.

I'm not a native English speaker myself, so I (quite naturally) tend to refrain myself from making such calls. I was only basing my thoughts on substance, FWIW.

For example, nice GUIs don't tell much about the language, it's fore and foremost a lib matter. If it's not, let's implement the F36 in javascript: it has some wicked GUI!

ɴᴇᴛɪᴢᴇᴎ

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

JohanEkdahl wrote:

smileymicros wrote:
About 2/3 through I actually heard something physically pop in my brain

Absolutely normal reaction. It is expected. It's the paradigm shift.

Nah, I've had epiphanies and this was more like a mini-stroke or an infected sinus suddenly opening up. 

 

JohanEkdahl wrote:

Re OO on AVRs: Yes the resource-challengedness of'em makes for just using a subset of OO. But it is not unlikely that there will be an abundance of more capable ARM Cortexes "owning" a larger area of the field in the future, and if so then more of the OO features of e.g. C++ could come to good use.

You bring up another large issue here in that I'm really wondering if maybe the whole microcontroller thing might be abstracted to a set of libraries that do everything you would want to do and in the past had to write from scratch. Arduino sort of suggests this in a way. What if there was a library for some ARM family and we could mainly just hook up stuff like building a lego thingee. Since the main barrier to the ARMs has been IMHO the difficulty of the tools and the steep learning curve, maybe a C++ library and some cheap tools could wipe out the need for 8-bit and C altogether. I know that has been predicted for years, but it almost looks like it is now possible if someone were to create the proper toolset. And like I said, that is fodder for an entirely different discussion. 

 

Last Edited: Thu. Apr 7, 2016 - 03:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PhillyNJ wrote:

My 2 cents as a Jr Freak and C# programmer...

 

Just like the picture shows, you can always use C, like there is always a need for a parking break.

 

Yes and that's why I said:

 

I will use 'C' for simple and small projects and I think I know C enough to write my simple/small projects.

hugoboss wrote:

... There might be 300 lines of code written procedurally. There is no point in adding abstraction at those project sizes. It won't make the code easier to manage. If, on the other hand, you are working on a humongous project with 50000 lines of code, it might make sense to break it down into classes and avoid having 50000 lines of inline procedural code...

Aren't 50,000 lines of codes too much?

IMO a team should work on such a thing. I haven't written too much codes(or as big as the lines of codes you're saying) but I think even 2-3 thousands lines of codes are huge for a programmer.

hugoboss wrote:
...

The main problem is that C++ requires a different mode of thinking, and once you get that object-oriented mode of thinking, it's usually hard to turn back off. Having programmed most of my life in object oriented languages I find procedural languages clumsy and annoying when I have to work with them now. I would much rather define classes than structs. Global variables are stupid. All that jazz.

Yup! indeed! OOP is a window to the new world of the programming. it's philosophic. it kinda looks like being a god/creator who is creating/making creatures.

netizen wrote:

This is all very interesting, but I suspect it goes way past what the OP would understand at this point...

No, you're way off. the first thing I learnt here was "search and inquiring before asking a question" then I know what my teachers are saying. the first book I read around this matter was  The Deitel and Deitel book: "C++ How To Program". but that wasn't too good to me. I confess that I read many pages and surfed many websites until ultimately got what does OOP mean! a guy + his projects that made me to start learning C++ was Andy's workshop. e.g. take a look here:

 

An FPGA sprite graphics accelerator with a 180MHz STM32F429 controller and 640 x 360 LCD

 

Sooo amazing!

And even if I'm not a professional it doesn't matter because all these guys were a novice. you, me,...

netizen wrote:

...Not really surprising: its easier to ask a question than to understand the full-depth of its answers. OP: when you're expert enough to understand the answers, you won't need to ask the questions anymore. :-)

Please use punctuations when you are writing English. isn't there any difference between "its" and "it's"? I don't know why every newcomer who comes here does not write English correctly.

Where are you from, netizen?

I think it's too soon to start kidding or joking. what do you think? I'm not angry but I'm trying to warn you of lighting the fire of a war. ok, let's talk about good stuff.smiley

 

Have you ever used OOP? have you written any code by C++? if so, then please tell us about it. what do you think about OOP and C++?

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

Last Edited: Thu. Apr 7, 2016 - 10:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Amin, there's a few mistakes in you're writing!

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

Lads, you just know things have hit rock bottom when people start picking on each other's grammar. Let's keep this civil or the big key will appear to lock this.

 

Cliff (wearing moderator's hat).

Last Edited: Thu. Apr 7, 2016 - 09:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, I was taking the piss.

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

Rohalamin wrote:
Aren't 50,000 lines of codes too much? IMO a team should work on such a thing. I haven't written too much codes(or as big as the lines of codes you're saying) but I think even 2-3 thousands lines of codes are huge for a programmer.

From a "small embedded" perspective 50 KLOCs is perhaps huge, but generally speaking it's just large. For products I've been involved in, team sizes has been everywhere from three to perhaps 15 and with source code masses of many hundred KLOCs down to the single hundred KLOCs.

 

It was many years ago now, but for one product I was the only programmer working full time coding for the project and I would imagine that the sum of all people coding would add up to being equivalent to two or three coders. Then there was two guys working quarter to one third of their time with requirements and UI design. The project lasted for 2.5 years and I would estimate that we produced perhaps 150 - 200 KLOCs of C++ Code before shipping version 1.0.

 

My rough estimate is that one line of C/C++ code generates roughly 10 machine instructions. For an AVR with 32KB of flash (i.e. 16K instructions) that will be a few KLOCs. A "stuffed" ATmega328 application isn't huge. I dare say it's not even large.

 

All this in a professional perspective.

 

For a hobbyist 1 KLOC might be daunting. For a professional it's perhaps a few days or (in the more extreme case) a few weeks of 9to5 work - which isn't a long period of time. So, it's "small".

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

Kartman wrote:

Amin, there's a few mistakes in you're writing!

laugh

Yeah

"The pot calls the kettle black"

cheeky

You remind me this movie

See No Evil, Hear No Evil

 

Edit:

@Johan

WoW!

That's amazing!

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

Last Edited: Thu. Apr 7, 2016 - 03:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

About books, I don't know why nobody want to talk about Herbert Schildt(his private website and Encyclopedia). IMO his books are the best for learning and especially as "source". you talk just about K&R. IMO K&R in some cases are not clear enough. e.g. I saw this topic about a month ago:

 

Switch/Case - two choices in a case

 

And Joey showed us this:

 

And here is the explanation which is represented in the C: The Complete Reference:

 

 

 

To me the second explanation by Herbert is so much clear than K&R. and also he has some greatZZ books about learning C/C++. e.g. Teach Yourself C++. I cannot find any version of it to buy.(available for me).sad

 

Anyway he is a computing author, programmer and musician.smiley

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

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

smileymicros wrote:
And, this also brings up the whole "Arduino is C++ thing'. IMHO the Arduino's use of C++ is a perfect example of what can really go wrong when folks only half understand something. What I think I'm seeing is some poorly implemented C++ created by folks who aren't thinking in the OO paradigm. And to me this is the risk: that folks who barely know C, start mimicking poorly understood C++ constructs and learn a jumbled style that doesn't use either C or C++ to their best advantage.
Another saw that problem then created Cosa to solve part of it.

Embedded Computing

Cosa, an Alternative Framework for AVR Boards

http://embeddedcomputing.weebly.com/cosa-an-alternative-framework-for-avr-boards.html

Cosa is an object-oriented framework that provides an interesting alternative to the standard Wiring/Arduino framework.

...

... Cosa only uses objects.

...

Boards are Arduino plus several AVR on a breadboard (tiny84, tiny85, tiny861, mega328p, mega1284p {STK500v1, Optiboot})

 

"Dare to be naïve." - Buckminster Fuller

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

gchapman wrote:
then created Cosa to solve part of it.

I can't think of anything more confusing than the example they give there:

 

a) Why on earth confuse the ab initio beginner who's going to want to do this stuff with complex details like using the watchdog ?!? It actually makes the Cosa version MORE complex looking than the plain Arduino code.

 

b) In the Arduino code example:

Picture

is obvious - anyone who's ever used an Arduino is going to know this will flash the LED on pin 13 and even if you are a true beginner it won't take long to make this connection. Meanwhile Cosa has:

Picture

Now I've dabbled a bit in computers and I like to think I know the odd thing about them but I have no idea what pin I might be expecting to see some activity on using this syntax ?!? Can I assume Board::LED is actually 13? Supposing I now add another LED to pin 5 how do I specify that ?

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

Rohalamin wrote:
A colour display need a very well GUI.wink writing a good GUI with 'C' will probably take time. more than "C++" or because it's a bit complicated then it would be better to write it by C++. that's why they have created C++.
Lots of GUI implemented via C or C++ some of which are FOSS.

A GUI via C++ (FOSS, BSD) :

DisplayCore

The Premium Display Framework for the chipKIT™ Environment

http://displaycore.org/?page=main

(if one is a Star Trek Next Generation fan, go to Widgets > LCARS)


from

Embedded Computing

LCD_screen Download

http://embeddedcomputing.weebly.com/lcd_screen-download.html

List of Recommended Alternatives

...

"Dare to be naïve." - Buckminster Fuller

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

JohanEkdahl wrote:
If someone asked me about what language to use to learn the principles of OOP I'd just as likely say "Java or C#".
... or Python?

JohanEkdahl wrote:
Or like lambda expressions (An OO person might describe this as "code becoming a first class object" - the idea, simplified, being that you can pass executable code around as objects. Think of it as "function pointers on steroids").
To the hacker of the black hat kind, their wet dream.

 

"Dare to be naïve." - Buckminster Fuller

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

gchapman wrote:
... or Python?

+1 - I've learnt more about thinking in terms of "objects" using Python than I have ever really done trying to get my head around C++ (or even Java).

gchapman wrote:
lambda expressions
Used my first lambda expression for the first time the other day in fact - most satisfying :-)

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

joeymorin wrote:
In fact, the first (rigorous) formal training I had in >>any<< language was OO (Ada).  Still have the course work in a box somewhere.
Last week I was going through some boxes and relocated a copy of Ada as a Second Language; what I read and did effort on to move from Ada83 (non OO) to Ada95 (OO).

Programming in Ada 2012 by John Barnes may be next to read and effort.

Alternatively, Python on a MCU seems to have the legs that Java on a MPU did not (though ARM sure did try).

Micro Python has moved into commercial wireless (Wi-Fi and late summer is LoRa + Wi-Fi) and IIRC some other Wi-Fi CoM also have Python.

There's also an instance of Micro Python on a dsPIC.


http://dl.acm.org/citation.cfm?id=541325 (Ada as a Second Language)

http://www.cambridge.org/us/academic/subjects/computer-science/software-engineering-and-development/programming-ada-2012

http://www.pycom.io/solutions/py-boards/lopy/ (LoPy)

https://github.com/micropython/micropython/blob/master/pic16bit/Makefile

 

"Dare to be naïve." - Buckminster Fuller

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

(if one is a Star Trek Next Generation fan, go to Widgets > LCARS)

Ooooo...

 

I just might have to make my own Android app to supplement the 'Tricorder' app I already have :)

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Rohalamin wrote:
what do you think about OOP and C++?

Fixing C

by

April 11, 2016

http://www.embedded.com/electronics-blogs/break-points/4441819/Fixing-C

...

C++ is, in my opinion, rather full of complexity and dark spaces where one is wise not to tread.

...

C has been the lingua franca of this business for many years.

Survey data shows it has most of the embedded space’s market share, and that the numbers haven’t changed much over the years.

...

More modern aspirants like Python just haven’t caught on.

C is going to be a major force for a very long time.

...

"That's why you should use a IDE or syntax aware editor." - horacechan

Some of the C and C++ IDE have some lint built-in.

May one lint.

 

"Dare to be naïve." - Buckminster Fuller

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

Rohalamin wrote:
3- Please provide a book as "getting started" and another one as "source" for C++(the best you think). please note that I said just C++.
(Transparency - I know enough C++ to produce an ever flowing list of errors from the compiler wink

Effective C++ in an Embedded Environment by Scott Meyers

http://www.aristeia.com/books.html

is mentioned in

Modern C++ in embedded systems – Part 1: Myth and Reality

by

February 17, 2015

http://www.embedded.com/design/programming-languages-and-tools/4438660/3/Modern-C--in-embedded-systems---Part-1--Myth-and-Reality

(page 3 of 3, about mid-page)

"Dare to be naïve." - Buckminster Fuller

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

I own a copy of Scott Meyers title above. Please understand that it is a (huge) set of (annotated) slides for a (half-day? one-day?) seminar he used to give in the past (*).

 

Don't get me wrong. It's good material. Scott is (well, was.., see footnote) one of the authorities on C++.

 

BUT... you should learn all the ins and outs of C++ properly before attempting this material. Use a PC and e.g. GNUs g++ an a good text-book for that. If it took you one month to start to feel really comfortable with C then you should spend at least 6 months or so with C++. Adjust accordingly.

 

For those with a solid but perhaps dated knowledge of C++ I can also recommend another set of slides from Scott Meyers: "The new C++". As above this is NOT for the beginners!

 

(*) Scott announced a while back that he would stop working with C++. I'm not sure if he just thought 25 years of writing and teaching was enough, or if he knows something the common man does not. He is known to be friends with some of the core people behind the "D" programming language. In fact, he did a talk at a D conference where he had some very well-founded critique of C++. It was also hilariously fun in parts - again, if you know the language. Search it out on Yotube and enjoy! 

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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: Mon. Apr 18, 2016 - 10:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rohalamin wrote:
3- Please provide a book as "getting started" and another one as "source" for C++(the best you think). please note that I said just C++.
Though not a book there's

Free webinar: Getting started with C++ in embedded systems

by

May 31, 2016

http://www.embedded.com/electronics-blogs/max-unleashed-and-unfettered/4442134/Free-webinar--Getting-started-with-C--in-embedded-systems

2016-Jun-07 (Tuesday) 1300 US ET (GMT - 4h) for one hour.

Not certain all would be able to access that webinar; the article links to two other articles with some answers in the articles' bodies and comments.

 

"Dare to be naïve." - Buckminster Fuller

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

To PhillyNJ..... the parking break isn't as bad as the flying break. You can walk away if something breaks while parking.

 

Imagecraft compiler user

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

My $0.02

 

C: bulkier looking code, more easily predictable code generation.  

Solid compile-time code generation features via preprocessor

Tried and true reliable and effective compiler optimizations

 

C++: less repetitious looking code, takes experience and a bit of luck to predict code generation.  

Intensely powerful compile-time code generation & type enforcement via templates whose power is evenly matched by its increasingly tricky syntax the more you push it.

More compile-time optimization opportunities than C (primarily via templates) but debatable whether the compiler you're using can pull it all off.

It's a software problem

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

malachib wrote:
C:

...

Solid compile-time code generation features via preprocessor

Embedded

Template meta-programming in C vs opaque pointer

by

December 27, 2016

http://www.embedded.com/design/programming-languages-and-tools/4443209/Template-meta-programming-in-C-vs-opaque-pointer

...

We invest in template development with some extra lines of code and a complicated macro construction to enjoy the safety provided by the compiler static checks.

...

 

"Dare to be naïve." - Buckminster Fuller

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

Uggg.The template code is truly ugly and does not work as apparently intended.

To prevent multiple definitions, only one FUNCTION is allowed.

Both allow one to lie about the size or type.

The memcpy version could be improved with a one-parameter macro that uses sizeof.

A two-parameter macro is about as good as one can get with standard C: type and data.

One can compare sizes, but otherwise, the compiler will have to depend on the programmer's honesty.

gcc has useful extensions in this regard.

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?