As a 50+ year software engineer, I’m going to make a radical comment.

If you are a professional,
know what you’re doing,
all programming languages are the same.
​

Sure, some do a lot more work for you. But it’s your responsibility to know what that work is.

Too many “professionals” let the underlying language design do what they should know by themselves. Not that that is bad.

But it works both ways. The underlying language designs also can result in some non-intended software failures.

By accepting blindly, “C is the best language”, one is also accepting C’s flaws - while being unaware of their compromise!

I can program an OOP application with memory management in a BASIC variant. I feel that many people would dis’ me because that’s “impossible”.

Not with 50+ years of experience.

 

Hello,

Perhaps this book might interest you:
https://archive.org/details/ProgrammingEmbeddedSystemsInCAndC

Bertus

 

As a 50+ year software engineer, I’m going to make a radical comment.

If you are a professional,
know what you’re doing,
all programming languages are the same.
​

Sure, some do a lot more work for you. But it’s your responsibility to know what that work is.

Too many “professionals” let the underlying language design do what they should know by themselves. Not that that is bad.

But it works both ways. The underlying language designs also can result in some non-intended software failures.

By accepting blindly, “C is the best language”, one is also accepting C’s flaws - while being unaware of their compromise!

I can program an OOP application with memory management in a BASIC variant. I feel that many people would dis’ me because that’s “impossible”.

Not with 50+ years of experience.

+1

C is not the best language but it's more than adequate for 99% of all embedded programming jobs and supported on almost everything. The best language is the one that gets the job done easily and correctly by the programmer.
https://forum.allaboutcircuits.com/threads/the-mphase-box.153401/
Some of us just think that C++ is a total hack and a new language like Rust will eventually be a replacement for C++ without the overhead of ancient compatibility with C.
https://en.wikipedia.org/wiki/Rust_(programming_language)

I don't understand by someone would say that's impossible as BASIC like C will be around forever.

 

As a 50+ year software engineer, I’m going to make a radical comment.

If you are a professional,
know what you’re doing,
all programming languages are the same.
​

Sure, some do a lot more work for you. But it’s your responsibility to know what that work is.

Too many “professionals” let the underlying language design do what they should know by themselves. Not that that is bad.

But it works both ways. The underlying language designs also can result in some non-intended software failures.

By accepting blindly, “C is the best language”, one is also accepting C’s flaws - while being unaware of their compromise!

I can program an OOP application with memory management in a BASIC variant. I feel that many people would dis’ me because that’s “impossible”.

Not with 50+ years of experience.

I agree with you. I also have written programs in OOP which used sub-programs in BASIC, C and even EXCEL using Active-X because they were the best choice for what I had to do.

 

I can program an OOP application with memory management in a BASIC variant. I feel that many people would dis’ me because that’s “impossible”.

Can you show an example? Sounds very interesting.

 

@ErnieM I don't know I am right or wrong so I am explaining my understanding. Suppose we can make simple automatic pet feeder with C only but if we need GUI based automatic pet feeder then we can use C++ because Its object oriented programming language

It is not necessary to use C++ for a GUI. The now near obsolete book "Programming Windows" by Charles Petzold described how to write programs to run in the Windows environment. It was written using the C language exclusively, which I believe was the same language Windows itself was written in for the most part. That is Windows 95 and 98 variants.

I used some Microchip graphic libraries when making some GUI apps for their PIC32 devices. These parts have a ton of RAM and ROM. The libs are written in C. The widgets or visual things you see are object like items but they are never (typically) created nor destroyed (as true objects are) but still very useful.

Can you show an example? Sounds very interesting.

Think of a class to make objects. It will have methods (or functions) you can call, and variables both public and private. A list of pointer references can be defined by a structure. A list of function pointers, some variables, and perhaps private variables that the class knows where they are tucked away.

When you create an object, or an instance of a class you begin by asking the memory manager for a piece of RAM memory large enough to fit the structure previously defined. Add in space for private variables. The create routine will get this memory, initialize it by loading function pointers and setting variables as they need be, then passing back a pointer to this piece of memory.

This pointer is referred to as "this," since *this* is the object we are working with. I've done exactly that in assembly, albeit when running Windows using the Windows memory management functions. If your language can do structures and function pointers then creating C++ type objects are easy. Other languages may make this harder but still is possible.

I did this to make COM or ActiveX (or whatever they call them now) objects. Microsoft based the COM object structure to match the structure of C++ objects

 

Can you show an example? Sounds very interesting.

I was going to reply, but ErnieM’s response is a good one. If you know the principles of OOP, you don’t need to use an OOP language. You can code all the necessary components in any other procedural language (I added “procedural” because programming an app with OO features might be a little harder for me in LISP).

I implemented a proprietary programming language in FreeBASIC (and migrated it to a mix, with the compiler written in BASIC and a run-time implemented in C).

Run-time commands were the objects. Each new command created a “command” object. Each object contained a token, a string parameter, and integer parameter and a pointer. In C++, this would be a structure; in BASIC, it was a set of dynamic arrays where all elements with the same index was part of one object.

“Commands” were relatively static for the most part. The next class of objects were more dynamic.

When executing a program, I created a “task” object. It contained a program counter integer and a pointer. As tasks started up, new objects were created; as tasks ended, the associated object were destroyed and released its memory it used.

This is a very simplified description of what I was referring to. Between this post and ErnieM’s post, I think we’ve answered your question.

 

I implemented a proprietary programming language in FreeBASIC

Perhaps I misunderstood you. I thought you would provide an example of OOP using BASIC. I'd be interested in seeing this in actual code. My first programming language was Microsoft's Level II BASIC on a TRS-80. I suspect BASIC has changed since then. It did allow for peeking, poking, and taking the address of a variable IIRC, I suppose you could use those creatively for OOP, but it seems like it might be cumbersome.

 

Perhaps I misunderstood you. I thought you would provide an example of OOP using BASIC. I'd be interested in seeing this in actual code. My first programming language was Microsoft's Level II BASIC on a TRS-80. I suspect BASIC has changed since then. It did allow for peeking, poking, and taking the address of a variable IIRC, I suppose you could use those creatively for OOP, but it seems like it might be cumbersome.

Sorry, the code is proprietary.

 

Not with 50+ years of experience.

I'd have guessed someone with 50+ years could back up their claim that one can use OOP with BASIC, by providing a small made up example of how that works. But I was just curious, BASIC remains best left to newbs learning the fundamentals of programming. Or better, not used by anyone anymore.

 

To program OOP just code protected code into separate files, then only make the functions / variables you want public.

Believe it or not, most C programmers do this to a level without even knowing it..
Download a library... Say a graphic library.. You only need to include it into your code... You don't care how it works, you just know it does, when you call a function within that library you can only pass variables the original coder want's you to pass.. Voila! protected code!! It's a simple class all variables and functions grouped together..

 

To program OOP just code protected code into separate files, then only make the functions / variables you want public.

Believe it or not, most C programmers do this to a level without even knowing it..
Download a library... Say a graphic library.. You only need to include it into your code... You don't care how it works, you just know it does, when you call a function within that library you can only pass variables the original coder want's you to pass.. Voila! protected code!! It's a simple class all variables and functions grouped together..

I've no idea when encapsulation, data hiding, scope rules, etc .. became part of OOP instead of old school normal structured programming in procedural languages such as C .

The software engineering concepts of coupling and cohesion predate object-oriented programming.
https://en.wikipedia.org/wiki/Coupling_(computer_programming)
https://en.wikipedia.org/wiki/Cohesion_(computer_science)

The software metrics of coupling and cohesion were invented by Larry Constantine in the late 1960s as part of Structured Design, based on characteristics of “good” programming practices that reduced maintenance and modification costs. Structured Design, cohesion and coupling were published in the article Stevens, Myers & Constantine (1974) and the book Yourdon & Constantine (1979); the latter two subsequently became standard terms in software engineering.

 

I'd have guessed someone with 50+ years could back up their claim that one can use OOP with BASIC, by providing a small made up example of how that works. But I was just curious, BASIC remains best left to newbs learning the fundamentals of programming. Or better, not used by anyone anymore.

I don’t like the tone of your reply. Perhaps if you were willing to sign an NDA, I might consider sharing an example. Perhaps I wouldn’t.

Regardless of your thoughts about BASIC, I still use it in support of a $300K enterprise. I could rewrite it in C or C++, but why waste my time replacing something that works?

I’m not about to write a program just because you asked. If you can’t respect my requirements, then I can’t respect your request.

 

I'd have guessed someone with 50+ years could back up their claim that one can use OOP with BASIC, by providing a small made up example of how that works. But I was just curious, BASIC remains best left to newbs learning the fundamentals of programming. Or better, not used by anyone anymore.

This is an example of Agilent Vee pro, which is an OOP, in which a call is made to Windows Media Player, passing in the name of the movie file to be played. The call could have just as easily made to a program written in BASIC or any other language. Parameters can be passed in and out of the sub program.

 

https://www.win.tue.nl/~wstomv/quotes/structured-design.html

p. 291--292
15.1.1 The efficiency of a system depends on the competence of the designer
There is not much point in talking about efficient systems or optimization if the system is being designed and/or programmed by people of only mediocre talent. Of course, this is a rather sensitive issue. One's ego makes it difficult to deal with one's own mediocrity, and one's manners make it difficult to accuse colleagues of mediocrity. Nevertheless, it is a fact that shoud be faced squarely: A surprisingly large number of analyst / designers design stupid systems, and an even larger number of programmers write horribly stupid code.

These are blunt words, to be sure. However, a classic study by Sackman et al. pointed out that, among experienced programmers, we can find a 25:1 difference in design time and debugging time. Equally disturbing is the fact that the resulting code can vary in speed and size by a factor ten. The most depressing fact of all was that Sackman's study indicated that there was no correlation between programming performance and scores on programming aptitude tests. H. L. Mencken observed that nobody ever went broke underestimating the intelligence of the American public. After visiting programming organizations around the country, the authors have concluded, somewhat sadly, that a similar statement could be made about programmers and designers.

Our point is simple: There is no substitute for competence. If you want a system designed and implemented efficiently, make sure it is done by people who know what they are doing --- which, by the way, has very little to do with the number of years they have been working in the computer field!

C++ won't change that.

 

BASIC remains best left to newbs learning the fundamentals of programming. Or better, not used by anyone anymore.

It really has its place.... If you learn visual basic.net you can produce some really good efficient programs.

Remember this... If the basic compiler was written by a proficient C or ASM coder, odds on it will produce tight code.. The same is said about C, C++, C#, OOP Pascal, and most high level programming tools..

Unix was built with C and has inbuit tools for compiling command line C code..

Objects have there place, They are extremely useful when programming in teams... This is one good reason why Arduino has become quite powerful.. Electronic developers only need to provide a class to add to the Arduino platform and bingo! They get a ton of sales.. Dev board, code and the lone programmer is away!!

I still think that you need the basic level of knowledge low level programming in asm or C, but once you know these things, objects become easier to understand and use... I use Lazarus to program windows apps to aid my life.. Pascal has always been kinda oop.. It has used units for years... Want a serial adapter... Just download one and stick it in the library list...

 

It really has its place.... If you learn visual basic.net you can produce some really good efficient programs.

Agreed, it has its place. I suspect however that Visual Basic is an altogether different language than the BASIC I learned on my TRS-80 in the 1980's.

If the basic compiler was written by a proficient C or ASM coder

Programming and design are two distinct qualities of a developer. One can be an amazingly proficient programmer but woeful at design. In fact that's the usual case in my experience. Lots of great programmers with no design skills. In some cases I've seen it to be in the developer's best interest to produce lousy designs; job security, no one can decipher their spaghetti code.

Unix was built with C and has inbuit tools for compiling command line C code..

I have a favorable view of GCC due to years of generally reliable use, but not so much for open sores in general. Last night you might have overheard me screaming at my woefully unresponsive DVR, cursing Torvolds and his ilk. In my experience, free software is usually overpriced. (Yes, I am ASSUMING that DVR has Linux under the hood, or something similar.)

C++ won't change that.

It might help if used properly. Working in critical embedded systems we mitigate mediocrity with things like code reviews and extensive testing. But these are expensive, which is reflected in the somewhat poor state of software products in general. E.g., my crappy DVR. I'd certainly agree that I can create a product successfully with either C or C++. But I can achieve success faster with C++ and with a more reliable end result.

 

It might help if used properly. Working in critical embedded systems we mitigate mediocrity with things like code reviews and extensive testing. But these are expensive, which is reflected in the somewhat poor state of software products in general. E.g., my crappy DVR. I'd certainly agree that I can create a product successfully with either C or C++. But I can achieve success faster with C++ and with a more reliable end result.

The problem just moves from bad code to dangerous code.

Bjarne Stroustrup — 'C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.'

Did you really say that?

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off". Yes, I said something like that (in 1986 or so). What people tend to miss, is that what I said there about C++ is to a varying extent true for all powerful languages. As you protect people from simple dangers, they get themselves into new and less obvious problems. Someone who avoids the simple problems may simply be heading for a not-so-simple one. One problem with very supporting and protective environments is that the hard problems may be discovered too late or be too hard to remedy once discovered. Also, a rare problem is harder to find than a frequent one because you don't suspect it.

 

Dear All

Can someone share their real time experience. I know here are so many experience person who have been worked on the real time project or still working on it.

I am very interested to know about your experience on embedded c++ Project.

Which micro-controller/processor / board you were using in your project ?

Which IDE you were using in your project ?

Thanks in advance

To answer the TP question: it doesn't. Beyond that, I use the MCU, and build the board around it. I use C, and inline assembler if needed. Why would you need or want anything else...?

 

Not true. C and C++ are general purpose languages and are equally suitable for most any processor out there.
Superior may (or may not) be an exaggeration. My guess as to why C++ has been somewhat slowly adopted in embedded systems has been that it isn't taught in engineering schools. And even when it is taught, I doubt there is much attention given to software design, which is a subject beyond just learning the language.
This has been largely debunked as a myth. If one understands how C++ (or C for that matter) consumes too many resources, then one can modify the design to accommodate what is available.

Another issue I see is the evolution of C++ (or rather de-evolution). Most all of the language additions made since Stroustrup's original add complexity and obfuscation IMO without adding much benefit. Similarly, many C++ advocates seem to think STL, Boost, etc. are inherently part of the language - which they are not; those libraries are largely useless and bloated IMO and, I'd guess, originated and thrived in academia rather than "the real world".

Actually, I think it's unfair to consider C & C++ 'general purpose' languages. They fill that role, but they are not 'run of the mill'. B.A.S.I.C. is 'run of the mill', as is Pythin, Java, PHP, etc. C is considered the 'high level assembler' for a reason. C is in terms of efficiency is limited only by the programmer. C++ on the other hand is handicapped by the linker. The real reason there is any issue at all with C++ being less acceptable than C in the embedded environment has nothing to do with code generation. The problem is with the linker. Unfortunately very few people ever advance far enough to even know what it is I'm talking about. Smart linking would make C++ possible for embedded. It's the only reason it isn't accepted as widely as C, now.