C++ vs C

[Chris Hills]

I guess you are right on this, although I do not know if there are cheap
32-bit CPUs for embedded devices.


Anyway, where C is efficient for a specific task, there is no reason why
the low level part of C++ would not be also efficient.

size of executable in ROM.... no instanciating on the fly.

Most embedded systems *require* not dynamic memory useage. It all has to
be fixed.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

Ioannis Vranos wrote:

[ ... ]

Yes I suppose you have something like Z80 CPU in mind, however as
far as I know many processor manufacturers, like Intel, Motorola
(at least in the past), etc produce decent contemporary CPUs for
embedded devices that handheld devices like Pocket PC use.

So if such processors are relatively cheap, how should one use 20
years old technology?

There are also special markets where you have to deal with things like
special certifications and such, and you may not be able to get the
processor you'd really like. Prices (and price differences) tend to be
larger here as well. For example, an Intersil mil-rated 80286 is close
to $300 more than their 8086 with the same rating -- and if you want a
386, well...sorry, but they just don't have it. Likewise in rad-hard
processors, the last time I looked, your choices of modern 32-bit CPUs
could all be counted on one hand with fingers left over (and prices are
in the "if you have to ask, you can't afford it" range.)

The 386 was about the only x86 part to be used for embedded work as a
stand alone CPU (not in an ASIC) However it has died out now. For some
reason the SH3 and SH4 seem to have taken over that slot.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Ioannis Vranos]

size of executable in ROM.... no instanciating on the fly.

Most embedded systems *require* not dynamic memory useage. It all has to
be fixed.

int array[5]={1,2,3,4,5};

isn't fixed?

 

[Ioannis Vranos]

Yes they do. However life is more complex than that. In an embedded
system the computing part is part of something else. It is the something
less that people buy. Therefore the computing part is just a component
and has to be minimum cost.

Why go to the huge expense (comparatively) additional complexity and,
if you are using Pocket PC, lack of reliability of using a 32 bit
processor when an 8 bit one will do the job.

Processors that can run Pocket OC etc. make up about 10-20% of the total
MCU produced (this includes the x86 used in PC's). The rest are 4, 8 and
16 bit systems.

Yes 4 bit are still common tough the largest single group is the 8 bit
system (though the Z80 is a seldom used part comparatively. IT is a CPU
not MCU). Due to cost the 16 bit market is getting squeezed between the
8 and 32 bit markets.

Though Pocket PC is not usually an option for 95% of embedded systems.

[Noting that this is a separate subject from C++ vs C]


However we can say that the devices with high powered processors are not
uncommon. Consider cell phones, with emails, calendar etc stuff.


I remembered that because I just read this (from WinInfo Daily Update
14-02-2005):


"In the News
- Nokia Licenses Microsoft Technologies for Cell Phones
- Microsoft Signs Deal for Low-Cost Smartphone Platform

==== In the News ====
by Paul Thurrott, (e-mail address removed)

Nokia Licenses Microsoft Technologies for Cell Phones
In a deal that could mark the beginning of a less contentious
relationship between the companies, cell phone giant Nokia has licensed
key Microsoft technologies for digital media and email. Nokia has shown
little interest in Microsoft's wares in the past, largely because Nokia
saw the Windows Mobile platform as an up-and-coming competitor to its
successful cell phones.
Under terms of the agreement, Nokia will license various Microsoft
Windows Media technologies, including Windows Media Audio (WMA),
Windows Media Digital Rights Management (DRM) version 10, Media
Transfer Protocol (MTP), and a Windows Media Player (WMP) plug-in for
the MPEG Advanced Audio Coding (AAC) family of codecs. These
technologies will let Nokia cell phones more easily integrate with WMP-
based music on Windows XP-based PCs, the companies say.
"This agreement makes it easier for consumers to download the music
they want to listen to, without having to worry about whether or not
the file format is supported," Anssi Vanjoki, senior vice president and
general manager of Nokia's Multimedia Business Group, said. "It's all
about enabling choice without compromising compatibility. The broad
reaching popularity of Windows Media Player, its comprehensive feature
set, and its support for service integration made it a natural choice
for us when looking at the PC component of the mobile music solution we
are offering to mobile operators."
Nokia will also use Microsoft technology to help its users
wirelessly synchronize their email, calendar information, and address
books between high-end Nokia phones and Microsoft Exchange Server 2003.
"Nokia is committed to answering the broader needs of enterprises
across the world by giving them access to the widest possible choice of
email and personal information solutions on the market today and
tomorrow," Mary McDowell, senior vice president and general manager of
Nokia's Enterprise Solutions Business Group, said.

Microsoft Signs Deal for Low-Cost Smartphone Platform
Microsoft is attempting to drive the success of its Windows Mobile-
based Smartphones by creating a new, lower-cost platform, code-named
Peabody, that will be made by original device manufacturer Flextronics,
the company that manufacturers the Xbox. Flextronics will sell devices
based on the Peabody platform to cell phone makers.
"The significance of this partnership [is that we can now make]
extremely high-volume, low-cost devices that don't have any concessions
in terms of functionality," John Starkweather, a product manager in the
Mobile Devices division, said. The Peabody announcement came on the
first day of the 3GSM World Congress 2005, a major cell phone show in
Cannes, France.
Peabody is compatible with the Global System for Mobile
Communications (GSM) and General Packet Radio Service (GPRS) cellular
phone systems, but not with the Code Division Multiple Access (CDMA)
system that Sprint and Verizon use. The new platform includes a wide
range of functionality, including video, gaming, photos, and personal
information manager (PIM) synchronization with Microsoft Office
Outlook."



So in a sense, small/embedded devices are becoming more and more
powerful. Again this has nothing to do with C vs C++, since both
languages are suitable for the same jobs under severe space and time
constraints.

 

[Chris Hills]

Yes they do. However life is more complex than that. In an embedded
system the computing part is part of something else. It is the something
less that people buy. Therefore the computing part is just a component
and has to be minimum cost.

Why go to the huge expense (comparatively) additional complexity and,
if you are using Pocket PC, lack of reliability of using a 32 bit
processor when an 8 bit one will do the job.

Processors that can run Pocket OC etc. make up about 10-20% of the total
MCU produced (this includes the x86 used in PC's). The rest are 4, 8 and
16 bit systems.

Yes 4 bit are still common tough the largest single group is the 8 bit
system (though the Z80 is a seldom used part comparatively. IT is a CPU
not MCU). Due to cost the 16 bit market is getting squeezed between the
8 and 32 bit markets.

Though Pocket PC is not usually an option for 95% of embedded systems.

[Noting that this is a separate subject from C++ vs C]


However we can say that the devices with high powered processors are not
uncommon. Consider cell phones, with emails, calendar etc stuff.

They are not that common. Your car will have 50 to 150 embedded systems
in it. Most of them 8 bit. Every cell phone has a sim. the majority of
these are 8051 8 bit parts. (even the ARM versions are too small for
WINCE or Pocket PC and have no OS at all)

For every embedded system you can see there are several thousand you
can't. these have soemthing like 129 or 258 BYTES of RAM. and less than
64K of FLASH for code. (all code has to be static)

So in a sense, small/embedded devices are becoming more and more
powerful. Again this has nothing to do with C vs C++, since both
languages are suitable for the same jobs under severe space and time
constraints.

NOT so. Also C++ is not available for 80% of embedded platforms. They
are certainly NOT suitable for the same applications.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

size of executable in ROM.... no instanciating on the fly.

Most embedded systems *require* not dynamic memory useage. It all has to
be fixed.

int array[5]={1,2,3,4,5};

isn't fixed?

That's C


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Ioannis Vranos]

int array[5]={1,2,3,4,5};

isn't fixed?

That's C

No, that is the low level part of C++.

And in the place of C99s VLAs one can use valarray (which is also better
than C99 VLAs) for severely constrained situations (otherwise vector
would suffice).


Bottom line, both languages are suitable for embedded programming.

 

[Chris Hills]

int array[5]={1,2,3,4,5};

isn't fixed?

That's C

No, that is the low level part of C++.

And in the place of C99s VLAs one can use valarray (which is also better
than C99 VLAs) for severely constrained situations (otherwise vector
would suffice).


Bottom line, both languages are suitable for embedded programming.

but not practical. C++ is not available on the majority of embedded
platforms, not practical on others and not permitted on a lot of them.

Added to which, in practice C99 only exists as a standard not an
implementation.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Ioannis Vranos]

but not practical. C++ is not available on the majority of embedded
platforms,

Well of course we are talking about "where available". If in a platform
only a Fortran compiler exists, then naturally only Fortran can be used!

not practical on others

If there is a decent C++ compiler on a platform then it is practical to
use it.

and not permitted on a lot of them.

What do you mean with the above?

Added to which, in practice C99 only exists as a standard not an
implementation.

Actually last time I checked, GCC supports most part of C99 and I
suppose it will eventually support all of it (if it doesn't already).


Myself though doesn't see much future on C use, since it does not
provide much abstraction as C++ does, while C++ provides all the low
level capabilities of C.

 

[Chris Hills]

What do you mean with the above?

simple that there are areas where C++ is not permitted. Mainly safety
critical

Actually last time I checked, GCC supports most part of C99 and I
suppose it will eventually support all of it (if it doesn't already).

GCC is not suitable for some platforms

Myself though doesn't see much future on C use, since it does not
provide much abstraction as C++ does, while C++ provides all the low
level capabilities of C.

At the moment 80% of the embedded market uses C. the embedded market is
expanding. The majority of it is still 8 bit

C++ however is loosing "market share" to Java and c#. C++ will probably
go long before C

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[E. Robert Tisdale]

I'm writing an embedded application
and I'm trying to decide whether to do it in C or C++.

You should write it in C++ if a C++ compiler is available
for the target platform(s).

Does anyone know where I can find some statistic
data comparing the two languages (size and performance)?

Size and performance depend upon the Quality Of Implementation (QOI)
of the compiler and *not* the language.

 

[Ioannis Vranos]

simple that there are areas where C++ is not permitted. Mainly safety
critical

C++ however is loosing "market share" to Java and c#. C++ will probably
go long before C

I do not agree with any of your claims above.

 

[Mohd Hanafiah Abdullah]

I do not agree with any of your claims above.

To many people/organizations C is good enough for most things especially
embedded systems. And the pre-existing C code base is simply huge and needs
to be maintained, contributing to the longevity of C.

Napi

 

[Ioannis Vranos]

To many people/organizations C is good enough for most things especially
embedded systems. And the pre-existing C code base is simply huge and needs
to be maintained, contributing to the longevity of C.

I do not disagree with that. I disagree with the ones that I quoted.

More specifically, C++ code is more safe than C, and thus where safety
is critical it is more suitable and not the opposite.

An example:


#include <iostream>
#include <string>

int main()
{
using namespace std;

string s;

while(cin)
{
getline(cin,s);

/*Do things with s */;
}
}


Try to do this with C, and be careful to not introduce any buffer overflows.


C++ is not losing market share in comparison to C# or Java. With the
upcoming C++/CLI, C++ becomes the systems programming language of .NET
and the rest CLI managed environments.


Regarding Java, it is a language and a platform, so yes in Java platform
the Java language,which is the only language in the platform is the one
that is only used.


In the majority of the rest platforms however C++ is the dominant language.


I am not language-fanatic, after all after C#/CLI 2, I will probably
read and learn it in a day or two (the .NET API is the same for all .NET
languages so essentially the only thing I will have to learn from C#
will be its syntax - how to write loops etc, and given that it is a
subset of C++/CLI it will not take more than a couple of days), but why
shouldn't we tell the truth?

 

[Julie]

More specifically, C++ code is more safe than C, and thus where safety
is critical it is more suitable and not the opposite.

When you are talking about embedded development, it isn't the 'safety' of the
language, but the 'safety' of the tools/compiler.

Wrong code is wrong code no matter what the language. It is the tools the make
the difference.

 

[Chris Hills]

I do not agree with any of your claims above.

I got the figures from an extensive industry survey. However it is one
of the one you have to pay for so I can't quote it :-(

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

I do not disagree with that. I disagree with the ones that I quoted.

More specifically, C++ code is more safe than C, and thus where safety
is critical it is more suitable and not the opposite.

Can you supply any evidence for that claim?

I can probably dig out some for the opposing view but I am packing for a
week at Electronica in Nuremberg so I won't have the time to do it for a
week.

C++ is not losing market share in comparison to C# or Java. With the
upcoming C++/CLI, C++ becomes the systems programming language of .NET
and the rest CLI managed environments.

OK I agree. However in the (much larger) embedded and safety critical
market C is the language of choice. (appart from the 200 people who use
Forth

I am not language-fanatic, after all after C#/CLI 2, I will probably
read and learn it in a day or two (the .NET API is the same for all .NET
languages so essentially the only thing I will have to learn from C#
will be its syntax - how to write loops etc, and given that it is a
subset of C++/CLI it will not take more than a couple of days), but why
shouldn't we tell the truth?

What truth?

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

More specifically, C++ code is more safe than C, and thus where safety
is critical it is more suitable and not the opposite.

When you are talking about embedded development, it isn't the 'safety' of the
language, but the 'safety' of the tools/compiler.

Wrong code is wrong code no matter what the language. It is the tools the make
the difference.[/QUOTE]


As I work for a tools company I suppose I should agree with you but I
think a large part of it is process.

After process and tools you have language.

C++ is just not available on the majority of the common platforms.

C is small and compact and very efficient. Why change?

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Ioannis Vranos]

Can you supply any evidence for that claim?

I provided an example with std::string.

I can probably dig out some for the opposing view but I am packing for a
week at Electronica in Nuremberg so I won't have the time to do it for a
week.

OK, when you return we will be here.

OK I agree. However in the (much larger) embedded and safety critical
market C is the language of choice. (appart from the 200 people who use
Forth

As I said, "where available".

What truth?

That C++ will not diminish and replaced by C# or Java.

 

[Chris Hills]

I provided an example with std::string.

You said :-

More specifically, C++ code is more safe than C, and thus where safety
is critical it is more suitable and not the opposite.

Specifically C++ is safer than C. IT is more suitable than C for safety
critical.

I have Prof Les Hatton's Safer C. Do you have similar evidence for C++
being safer than C.

BTW We keep taunting Les to bring out the companion "Safer C++"
Apparently it will be his last work... something about over his dead
body

In what way is is C++ better for safety critical work. I don't expect an
example of C++ source as the answer. The answer is MUCH bigger than
that.

OK, when you return we will be here.

OK. Spend the time digging out the support for the use of C++ over C in
safety critical environments. I note C++ is not listed in 61508


BTW I have to take to some safety critical people and some compiler
writers so I will see what I can find out as well.

As I said, "where available".

That C++ will not diminish and replaced by C# or Java.

We will see. I am not sure either but it is more likely than C
disappearing.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/