By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,797 Members | 1,794 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,797 IT Pros & Developers. It's quick & easy.

C++ vs C

P: n/a
Hello,
I'm writing an embedded application and I'm trying to decide whether to
do it in C or C++. Does anyone know where I can find some statistic
data comparing the two languages (size and performance)?

Thanks,
Nataly

Jul 23 '05 #1
Share this Question
Share on Google+
42 Replies


P: n/a
natush wrote:
Hello,
I'm writing an embedded application and I'm trying to decide whether to
do it in C or C++. Does anyone know where I can find some statistic
data comparing the two languages (size and performance)?

Thanks,
Nataly


Hi Nataly,

I don't think that you can make a comparison between the two languages
(in term of size or performance). Generally speaking they're both usable.

Perhaps you should take into account the performance you can get with
the compiler you're going to use.

Anyway, they're both efficient (if well compiled).
Probably you'd need a library or something similar and you should see if
it's available in C or C++.

Bye

Andrea

Jul 23 '05 #2

P: n/a
natush wrote:
Hello,
I'm writing an embedded application and I'm trying to decide whether to
do it in C or C++. Does anyone know where I can find some statistic
data comparing the two languages (size and performance)?


http://www.research.att.com/~bs/esc99.html

http://www23.brinkster.com/noicys/do...eaking-cpp.pdf


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #3

P: n/a
natush wrote:
Hello,
I'm writing an embedded application and I'm trying to decide whether to
do it in C or C++. Does anyone know where I can find some statistic
data comparing the two languages (size and performance)?

Thanks,
Nataly


If you head for more abstraction in your code, then C++ is probably your
choice. As for code size and performance, this depends mostly on:

1. Your skill with the language
2. The quality of your compiler

If I were you, I'd check out what you really need in terms of code
complexity. Do you only need data abstraction and procedures? Then C is
probably what you're looking for.
Do you need a higher level of abstraction (classes)? Do you need highly
flexible code (generics)? Then C++ is probably the language of choice.

--
Regards,
Matthias
Jul 23 '05 #4

P: n/a

Ioannis Vranos wrote:
natush wrote:
Hello,
I'm writing an embedded application and I'm trying to decide whether to do it in C or C++. Does anyone know where I can find some statistic
data comparing the two languages (size and performance)?


http://www.research.att.com/~bs/esc99.html

http://www23.brinkster.com/noicys/do...eaking-cpp.pdf


Not bad sources :-) but for more solid information see the ISO C++
committee's technical report on performance:
http://www.research.att.com/~bs/performanceTR.pdf

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Jul 23 '05 #5

P: n/a
In article <1108242187.52790@athnrd02>,
Ioannis Vranos <iv*@remove.this.grad.com> wrote:
natush wrote:
Hello,
I'm writing an embedded application and I'm trying to decide whether to
do it in C or C++. Does anyone know where I can find some statistic
data comparing the two languages (size and performance)?


http://www.research.att.com/~bs/esc99.html

http://www23.brinkster.com/noicys/do...eaking-cpp.pdf


You can see:
http://www.tiobe.com/tpci.htm

for an index on programming languages in terms of popularity.

Napi

--
http://www.axiomsol.com
http://www.cs.indiana.edu/hyplan/napi.html
Jul 23 '05 #6

P: n/a
Mohd Hanafiah Abdullah wrote:
You can see:
http://www.tiobe.com/tpci.htm

for an index on programming languages in terms of popularity.

This seems to agree in the general notion that C/C++ is no 1, however it
looks strange that C is number 1 and C++ number 2, since the opposite is
known to be generally true (for example IDC developer report of 2001
where it was mentioned that C/C++ was number 1 worldwide with C++ being
the most percent of it).


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #7

P: n/a
Mohd Hanafiah Abdullah wrote:

[ ... ]
You can see:
http://www.tiobe.com/tpci.htm

for an index on programming languages in terms of popularity.


This appears highly suspect to me. Ignoring C and C++ for the moment,
they show Verilog as being behind VHDL -- yet even the staunchest
advocates of VHDL generally agree that Verilog has a much larger market
share (probably 5 times as large).

Ultimately, they're measuring one thing, but reporting it as something
else entirely. What they're measuring seems to be mostly the number of
_posts_ about a language. Unfortunately, they're _reporting_ this as
indicating the number of lines of code written in that language.
TTBOMK, nobody has ever shown a direct relationship between the two. At
least IME, the relationship is mostly inverse -- when I'm cranking out
a lot of code, I rarely have time to post much.

Likewise, revisions to a language (contemplated or recent) tend to
generate a great deal of discussion. The code is written later, after
the language is (again) well understood and the discussion has largely
died down.

Personally, I think we can do quite a bit better by searching for
strings that are likely to occur once (and only once) per source file
to get at least a vague notion of the number of files in each language:

string hits
"import java.io" 902,000
"include <stdio.h>" 879,000
"include <iostream>" 404,000
"include <iostream.h>" 154,000

[Note: these numbers varied over even a short period of time -- maybe
Google was doing a crawl, or updating results from its last one, while
I was doing the searches. If you re-do the searches, expect results to
vary, but only slightly, at least if you re-do them soon.]

This has to be done carefully to produce meaningful results though.
Just for example, searching for "import java" produces over 2 million
hits, but a single Java source file will often start off three or four
import lines. Likewise this ignores the length of each piece of source
code (which probably varies with language), the percentage of code
written in that language that's visible to Google (e.g. probably a LOT
lower for COBOL than for C, C++ or Java), etc. Finally, I've made no
attempt to isolate particular dates like they're doing.

Even with all these shortcomings, I suspect it's still a better measure
of quantity of source code than looking for mentions of the language.

As mentioned above, I'm fairly sure some languages generate a higher
ratio of discussion to source code than others. For example, searching
for "java.io" instead of "import java.io" more than triples the number
of hits. By contrast, searching for 'iostream' without the 'include'
only increases the number of hits by about 50%. I, at least, would tend
to assume that in both cases the "extra" hits are mostly in
documentation, discussions, etc.

In the end, I'm a bit surprised that the results don't differ even more
greatly.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jul 23 '05 #8

P: n/a
Jerry Coffin wrote:

This appears highly suspect to me. Ignoring C and C++ for the moment,
they show Verilog as being behind VHDL -- yet even the staunchest
advocates of VHDL generally agree that Verilog has a much larger market
share (probably 5 times as large).

Ultimately, they're measuring one thing, but reporting it as something
else entirely. What they're measuring seems to be mostly the number of
_posts_ about a language. Unfortunately, they're _reporting_ this as
indicating the number of lines of code written in that language.
TTBOMK, nobody has ever shown a direct relationship between the two. At
least IME, the relationship is mostly inverse -- when I'm cranking out
a lot of code, I rarely have time to post much.

Likewise, revisions to a language (contemplated or recent) tend to
generate a great deal of discussion. The code is written later, after
the language is (again) well understood and the discussion has largely
died down.

Personally, I think we can do quite a bit better by searching for
strings that are likely to occur once (and only once) per source file
to get at least a vague notion of the number of files in each language:

string hits
"import java.io" 902,000
"include <stdio.h>" 879,000
"include <iostream>" 404,000
"include <iostream.h>" 154,000

[Note: these numbers varied over even a short period of time -- maybe
Google was doing a crawl, or updating results from its last one, while
I was doing the searches. If you re-do the searches, expect results to
vary, but only slightly, at least if you re-do them soon.]

This has to be done carefully to produce meaningful results though.
Just for example, searching for "import java" produces over 2 million
hits, but a single Java source file will often start off three or four
import lines. Likewise this ignores the length of each piece of source
code (which probably varies with language), the percentage of code
written in that language that's visible to Google (e.g. probably a LOT
lower for COBOL than for C, C++ or Java), etc. Finally, I've made no
attempt to isolate particular dates like they're doing.

Even with all these shortcomings, I suspect it's still a better measure
of quantity of source code than looking for mentions of the language.

As mentioned above, I'm fairly sure some languages generate a higher
ratio of discussion to source code than others. For example, searching
for "java.io" instead of "import java.io" more than triples the number
of hits. By contrast, searching for 'iostream' without the 'include'
only increases the number of hits by about 50%. I, at least, would tend
to assume that in both cases the "extra" hits are mostly in
documentation, discussions, etc.

In the end, I'm a bit surprised that the results don't differ even more
greatly.


Actually google contains hits of web sites that are portals/index
Usenet, and from that you may conclude how accurate these things are in
relation to jobs. Absolutely none.

For example we may reach the conclusion that photographers are the 70%
of the population jobs. :-)


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #9

P: n/a
Jerry Coffin wrote:
Unfortunately, they're _reporting_ this as
indicating the number of lines of code written in that language.


No, read again:

"Observe that the TPC index is not about the best programming language
or the language in which most lines of code have been written."

But overall I tend to agree that this index should be interpreted with
care, leave alone taking it as an accurate measurement for popularity of
programming languages.

--
Regards,
Matthias
Jul 23 '05 #10

P: n/a
Matthias wrote:

[ ... ]
No, read again:

"Observe that the TPC index is not about the best programming
language or the language in which most lines of code have been
written."


Oops -- you're quite right, I misread it.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jul 23 '05 #11

P: n/a
natush wrote:
Hello,
I'm writing an embedded application and I'm trying to decide whether to
do it in C or C++. Does anyone know where I can find some statistic
data comparing the two languages (size and performance)?


In my personal embedded development experience, compared to C++, C is the
preferred language: smaller code and less buggy compilers
Jul 23 '05 #12

P: n/a
Julie wrote:
In my personal embedded development experience, compared to C++, C is
the preferred language: smaller code and less buggy compilers

I have no experience of embedded programming, and just from curiosity,
what kind of embedded devices do you have in mind? (For example I have
in mind mainly Pocket PC handhelds with Windows CE and compact .net
framework).


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #13

P: n/a

Julie wrote:
natush wrote:
Hello,
I'm writing an embedded application and I'm trying to decide whether to do it in C or C++. Does anyone know where I can find some statistic
data comparing the two languages (size and performance)?
In my personal embedded development experience, compared to C++, C is

the preferred language: smaller code and less buggy compilers


Julie touches on one of the major points. Often choice of language for
an embedded application has to do with the available tools for the
platform. Having a better or more complete compiler/debugger/analyzer
for one OS/language combination can drive that selection regardless of
other factors.

Brian

Jul 23 '05 #14

P: n/a
In article <1108412893.697653@athnrd02>, Ioannis Vranos
<iv*@remove.this.grad.com> writes
Julie wrote:
In my personal embedded development experience, compared to C++, C is
the preferred language: smaller code and less buggy compilers

I have no experience of embedded programming, and just from curiosity,
what kind of embedded devices do you have in mind? (For example I have
in mind mainly Pocket PC handhelds with Windows CE and compact .net
framework).

Most embedded engineers would see a Pocket PC as a small PC not an
embedded system. For serious embedded work WIN CE and .net is not an
option. Many embedded systems have a MTBF of 20 years. re-boots are not
an option.

The vast majority of embedded systems use 8 bit processors and have no
OS. About 60% of all processors produced are 8 bit I think. The average
car has over 50 embedded processors in it. Also virtually anything with
electric power on it usually has an embedded MCU (or two) in it.
Washing machines, microwaves, phones, hi-fi, missiles, torpedoes, locks,
elevators, any control or monitoring system, alarms,


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #15

P: n/a
Chris Hills wrote:
Most embedded engineers would see a Pocket PC as a small PC not an
embedded system. For serious embedded work WIN CE and .net is not an
option. Many embedded systems have a MTBF of 20 years. re-boots are not
an option.

The vast majority of embedded systems use 8 bit processors and have no
OS. About 60% of all processors produced are 8 bit I think. The average
car has over 50 embedded processors in it. Also virtually anything with
electric power on it usually has an embedded MCU (or two) in it.
Washing machines, microwaves, phones, hi-fi, missiles, torpedoes, locks,
elevators, any control or monitoring system, alarms,

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?


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #16

P: n/a
Ioannis Vranos wrote:
Chris Hills wrote:
So if such processors are relatively cheap, how should one use 20 years
old technology?


Relatively cheap? My PocketPC has a 300MHz Intel CPU, and it was like
500. Not really an option for a washing machine, not to mention that a
washing machine doesn't need a 300MHz CPU. Well, except of it could
stream videos, play my mp3s, read my PDF files, etc... ;-D

I think this is all a matter of cost.

--
Regards,
Matthias
Jul 23 '05 #17

P: n/a
Matthias wrote:
Relatively cheap? My PocketPC has a 300MHz Intel CPU, and it was like
500. Not really an option for a washing machine, not to mention that a
washing machine doesn't need a 300MHz CPU. Well, except of it could
stream videos, play my mp3s, read my PDF files, etc... ;-D

I think this is all a matter of cost.

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. :-)


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #18

P: n/a
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?


A few of the obvious reasons: first, even though prices on 32-bit
processors are fairly reasonable, prices on 8-bit processors are still
quite a bit lower as a rule. Second, 8-bit processors usually use a lot
less power, which can be quite important, especially in things like
battery-powered portable devices. Third, processor cores are often
embedded into things like FPGAs and ASICs. In this case, the size of
the processor is often a serious concern. For example, a T80 (8080/Z80
based) uses about 10,000 gates. A Plasma (MIPS based) uses about 70,000
gates. The exact number of gates will vary somewhat with the target
technology (e.g. ASIC vs. FPGA) but the ratio is fairly close to
constant. Smaller processors also typically have tighter code, allowing
smaller ROMs as well.

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.)

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jul 23 '05 #19

P: n/a
In article <1108430011.239457@athnrd02>, Ioannis Vranos
<iv*@remove.this.grad.com> writes
Chris Hills wrote:
Most embedded engineers would see a Pocket PC as a small PC not an
embedded system. For serious embedded work WIN CE and .net is not an
option. Many embedded systems have a MTBF of 20 years. re-boots are not
an option.

The vast majority of embedded systems use 8 bit processors and have no
OS. About 60% of all processors produced are 8 bit I think. The average
car has over 50 embedded processors in it. Also virtually anything with
electric power on it usually has an embedded MCU (or two) in it.
Washing machines, microwaves, phones, hi-fi, missiles, torpedoes, locks,
elevators, any control or monitoring system, alarms,

Yes I suppose you have something like Z80 CPU in mind,


No. The 8051. over 600 variants from 30 manufacturers with virtually
every peripheral possible on them.

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.
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.
So if such processors are relatively cheap, how should one use 20 years
old technology?


For the same reason you use a QWERTY keyboard. "everybody" can program
the 8 bit systems.

Also these processors that can run Pocket PC whilst "cheap" are
expensive compared to the 8 bit systems. Pocket PC is complex, large and
not reliable enough.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #20

P: n/a
In article <1108459366.170664@athnrd02>, Ioannis Vranos
<iv*@remove.this.grad.com> writes
Matthias wrote:
Relatively cheap? My PocketPC has a 300MHz Intel CPU, and it was like
500€. Not really an option for a washing machine, not to mention that a
washing machine doesn't need a 300MHz CPU. Well, except of it could
stream videos, play my mp3s, read my PDF files, etc... ;-D

I think this is all a matter of cost.

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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #21

P: n/a
In article <11*********************@z14g2000cwz.googlegroups. com>, Jerry
Coffin <jc*****@taeus.com> writes
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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #22

P: n/a
Chris Hills wrote:
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

http://www23.brinkster.com/noicys
Jul 23 '05 #23

P: n/a
Chris Hills wrote:
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, th******@windowsitpro.com

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.


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #24

P: n/a
In article <1108545813.251381@athnrd02>, Ioannis Vranos
<iv*@remove.this.grad.com> writes
Chris Hills wrote:
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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #25

P: n/a
In article <1108545157.346198@athnrd02>, Ioannis Vranos
<iv*@remove.this.grad.com> writes
Chris Hills wrote:
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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #26

P: n/a
Chris Hills wrote:
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.


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #27

P: n/a
In article <1108554966.466217@athnrd02>, Ioannis Vranos
<iv*@remove.this.grad.com> writes
Chris Hills wrote:
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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #28

P: n/a
Chris Hills wrote:
Bottom line, both languages are suitable for embedded programming.

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.


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #29

P: n/a
In article <1108594041.863983@athnrd02>, Ioannis Vranos
<iv*@remove.this.grad.com> writes
Chris Hills wrote:
and not permitted on a lot of them.

What do you mean with the above?


simple that there are areas where C++ is not permitted. Mainly safety
critical
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).

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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #30

P: n/a
natush wrote:
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.
Jul 23 '05 #31

P: n/a
Chris Hills wrote:
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.


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #32

P: n/a
In article <1108771390.659221@athnrd02>,
Ioannis Vranos <iv*@remove.this.grad.com> wrote:
Chris Hills wrote:
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.


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
--
http://www.axiomsol.com
http://www.cs.indiana.edu/hyplan/napi.html
Jul 23 '05 #33

P: n/a
Mohd Hanafiah Abdullah wrote:
Chris Hills wrote:

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.

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?


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #34

P: n/a
Ioannis Vranos wrote:
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.
Jul 23 '05 #35

P: n/a
In article <8yxRd.32157$xt.12472@fed1read07>, Julie <ju***@nospam.com>
writes
Ioannis Vranos wrote:
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.

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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #36

P: n/a
In article <1108778659.420472@athnrd02>, Ioannis Vranos
<iv*@remove.this.grad.com> writes
Mohd Hanafiah Abdullah wrote:
Chris Hills wrote:
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.

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.


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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #37

P: n/a
In article <1108771390.659221@athnrd02>, Ioannis Vranos
<iv*@remove.this.grad.com> writes
Chris Hills wrote:
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.


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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #38

P: n/a
Chris Hills wrote:
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.


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #39

P: n/a
In article <1108812774.901459@athnrd02>, Ioannis Vranos
<iv*@remove.this.grad.com> writes
Chris Hills wrote:
Can you supply any evidence for that claim?

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.
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. 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.
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.


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

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jul 23 '05 #40

P: n/a
Chris Hills wrote:
In article <8yxRd.32157$xt.12472@fed1read07>, Julie <ju***@nospam.com>
writes
Ioannis Vranos wrote:
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.


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?


Which is exactly my point(s). If you find an embedded C++ compiler, it will
(highly likely) be new (comparatively), buggy, and inefficient. Hence, you
don't find embedded development done w/ C++, and probably never will. When and
if C++ ever makes it to 'embedded' development, it will no longer be
/embedded/, but more like mini-OS development, such as WinCE.

For the foreseeable future, embedded will be dominated by asm, C and 8-bit
microprocessors. Ed Nisley in DDJ has covered this topic in previous issues of
his regular column. According to his numbers, sub-32-bit processors
_far_and_away_ outnumber 32+bit processors.
Jul 23 '05 #41

P: n/a
Ioannis Vranos wrote:
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.


C++ _will_ lose 'market' share as determined by the primary programming
interface of Windows. There is no disagreement that Window programming makes
up a major portion of programming population, someone else can nitpick about
what portion that is...

Regardless, as soon as the traditional C-style Win32 API is deprecated, C++
will lose market share to the accepted Win API, which currently appears to be
the .Net API.

Regardless, all of this discussion is completely irrelevant. Vehemently
sticking to a particular language is tantamount to belonging to the flat-Earth
society. Use the language(s) and tool(s) that are best suited for the project
at hand. And back to whenever the embedded thread started, currently the best
language for embedded development is _not_ C++, and in my estimation, never
will be (see other reply for additional comments if you care).
Jul 23 '05 #42

P: n/a
Julie wrote:
C++ _will_ lose 'market' share as determined by the primary programming
interface of Windows. There is no disagreement that Window programming
makes up a major portion of programming population, someone else can
nitpick about what portion that is...

Regardless, as soon as the traditional C-style Win32 API is deprecated,
C++ will lose market share to the accepted Win API, which currently
appears to be the .Net API.

Is this what you are thinking, or what you wish? :-)

Because I am currently learning Windows programming, and guess what, I
am doing it with C++ and .NET. I will not learn the old Win32, MFC, etc
APIs of course because they are going to be soon obsolete (or deprecated
if you wish).
Also as I have mentioned many times, with the upcoming C++/CLI standard
(due to March), C++ becomes the systems programming language of .NET.

Take a look at these:
http://msdn.microsoft.com/msdnmag/is...s/default.aspx

http://pluralsight.com/blogs/hsutter...0/05/2672.aspx

http://blogs.msdn.com/branbray/archi.../07/51007.aspx

http://www.accu.org/conference/prese...keynote%29.pdf
And a page of mine:

http://www23.brinkster.com/noicys/cppcli.htm

Regardless, all of this discussion is completely irrelevant. Vehemently
sticking to a particular language is tantamount to belonging to the
flat-Earth society. Use the language(s) and tool(s) that are best
suited for the project at hand.

I completely agree with that. However there are much more specialised
things you can do with C++ and special purpose libraries than you
probably think.


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #43

This discussion thread is closed

Replies have been disabled for this discussion.