which object orient language is most suitable for embedded programming?

Modular design can easily be object-oriented. For example a generic stack may be implemented in a .c and a .h file, and have:

stkobj *stkcreate(size_t size); void stkkill(stkobj *stk); void stkpush(stkobj *stk, int value); int stkpop(stkobj *stk); int stkempty(stkobj *stk); int stkfull(stkobj *stk);

A more complex example is my GPLd hashlib, available at:

--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer
Loading thread data ...

I'm not sure that some people might get the terms mixed up, hence the reason for asking.

I haven't ever done oo design for embedded systems, only modular. I am not an expert in formal oo design techniques, and I am curious as too what people are doing with their embedded designs to move to an oo design approach, rather than modular, which is conceptionally simpler than oo design - I have an oo design book on my shelf which is the size of a brick, but haven't got around to reading it yet.

I know what benefits an oo language can give in larger applications. For example, see XProgTool,

formatting link
I wrote this in Java, which is designed so that I can easily add support for new devices/protocols.

Personally, I find C/modular design a perfect fit for microcontrollers, and if the bicycle isn't broken... Although that doesn't stop me from being curious.

Regards,

Paul.

Reply to
Paul Taylor

There is a fair amount of 32 bit embedded these days with a reasonable amount of memory available (especially if not wasted on the OS).

You don't have to use these features.

Certainly a good coding standard and style guide is a must for C++.

Reply to
Marco

I remember the "Object Assember" in Apple's Macintosh Programmers Workshop. You could interface to the class-library called MacAPP from assembly code. However, the most common language for MacApp was Object Pascal. This was a little before C++ was becoming available.

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
 Click to see the full signature
Reply to
Petter Gustad

The size of C++ startup code is comparable to the size of a small application.

There are also compiler related inefficiencies such as the tables of pointers to functions have to be placed in RAM rather then in ROM, etc.

To me, the whole point of using C++ is avoiding the unnecessary technical knowledge about minor details. It is sad to see how much time is spent learning the features of the CPU/compiler/board/OS and fighting the stupid bugs instead of the actual development of the application.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

Hardly. The only overhead we have is two loops that go through a list of constructors and destructors for static object. (We don't use exceptions so I don't know what, if any, overhead that would add to start-up but it did have RAM and ROM overhead).

Then your compiler needs replacing. GCC for ARM places the vtables in ROM. The pointer to the vtable, however, is in RAM as it is part of the object.

--
Paul
Reply to
Paul Black

No true. I have implemented code for a small scientific instrument that uses C++. I wrote the startup code myself based on the C startup because I needed to init hardware in C earlier than zeroing BSS. The additional code needed to support C++ was a scan of a table of static constructors before main and destructors after. In fact the tables are empty in my case, so that overhead is wasted. I used GCC for ARM. Note, as discussed earlier this is without RTTI and exceptions - if you're using those then it really is an apples and oranges comparison.

Why? The tables of pointers to functions, commonly called vtables, can, and are, stored in ROM. Each object that has virtual member functions has a pointer to this table in RAM. But presumably if you have a vtable then you are using the indirect function calls for a reason, which would require something like function pointers or switches otherwise.

Perhaps. It is never a good idea to think that you an get away with an inferior programmer by providing a 'better' programming language.

Peter

Reply to
Peter Dickerson

That's pretty much what's done here: typedef'd interface structures with pointer call semantics can be very efficient in terms of call overhead, especially for functions with long arg lists. Works well at 8 bit micro level as well. The usual rule is that any globally visible function (ie: library function) or one with < one or two arguments is defined in this way. Most functions end up in libraries here, so we can get best value from the design and coding effort. Another usefull thing is that arguments can be added to the call interface without changing prototypes or usage elsewhere.

The original idea of 'C with classes` was very attractive, but anything that requires a malloc() or similar is dead from the start for most projects here...

Chris

Reply to
ChrisQuayle

Or, better still, an index (from a public enum) into a (private) array of instances of structs. That way, the struct definition can remain entirely private. (For member functions, expose a normal function that again takes an index. The world outside the scope of the file (or class) has no business knowing about its internals - only its publicly-exposed interface.)

Internally, yes, but no need to expose these externally.

Haven't run into this.

Steve

formatting link

Reply to
Steve at fivetrees

It's a valid question. To me, OO is nowhere near as revolutionary as its sometimes purported to be. It's structured programming as applied to data, not just code. OO is a set of ideas which (at best) help to encourage modular design. So, yeah, it's modular design.

But - I'm not just using buzzwords. I studied OO, learned C++, used it, and for my field (embedded) decided against using it. I'm a firm believer in "the principle of least surprise", and my experience was that C++ continued to surprise not just me, but the guys who had written the code in the first place. In particular, watching the "experts" try to understand something and having dozens of header files open in order to do so made a lasting impression. I'm happy to use a deliberately restricted toolset, a small set of familiar idioms, BUT to structure things in such a way as to make them yet more general. OO, as a methodology, is useful in this respect - and in particular, if done well (not including C++), the ethic of exposing only the interfaces which *need* to be exposed - and hiding everything else.

Steve

formatting link

Reply to
Steve at fivetrees

Absolutely.

Steve

formatting link

Reply to
Steve at fivetrees

LOL ;)

Steve

formatting link

Reply to
Steve at fivetrees

Oh, good shot, sir ;).

Steve

formatting link

Reply to
Steve at fivetrees

I've long thought that "exceptions" should have been called "nappies" ;).

More seriously, exceptions seem to have been introduced because programmers were traditionally so poor at dealing with error conditions. Adding "nappies" is perhaps understandable in such circumstances, but a better solution would have been more rigorous housetraining ;).

Steve

formatting link

Reply to
Steve at fivetrees

You had to write the startup code yourself...

They pay money for the problems solved, not for the rewriting of startups and standard libraries.

based on the C startup because I needed

Besides that, the C++ startup has a lot of extra functionality that can be used on the special occasions. Such as: If (OS == blabla), if (library == foobar), if (CPU_version == 12345) and so on, so forth. Of course, you can eliminate most of that. How much time it will take? Are you sure there will not be a problem in the future because you removed something essential?

In fact the tables are empty in my case, so that overhead

If I don't use exceptions and RTTI right now right here, it does not mean that I will not need all of that later.

You should adress this question to IAR systems. But, I don't mind that. My goal is developing an application for good and on time. They don't pay for proving a point or saving few bytes.

Rewriting the startups is definitely not the best use for the good programmer.

VLV

Reply to
Vladimir Vassilevsky

... snip ...

That's silly. I can see the objection for continuous dynamic long term operation, but not at initialization time.

--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer

What, if anything, does that mean?

--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer

I don't agree.

This is a method of implementation .

It isn't a design technique.

tim

Reply to
tim(yet another new home)

It's a method of implementing a design technique.

Steve

formatting link

Reply to
Steve at fivetrees

I should probably add that, where the handler more properly belongs in another module or class, I make use of registered callbacks. The distribution of code is perhaps a little different from e.g. C++, but in my view it's superior: the code is maintained where it belongs, and the methods are standardised - without any exposure of the innards of a module/class.

Steve

formatting link

Reply to
Steve at fivetrees

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.