C++ vs C

N

natush

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
 
A

Andrea Sini

natush said:
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
 
M

Matthias

natush said:
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.
 
I

Ioannis Vranos

Mohd said:
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).
 
J

Jerry Coffin

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

Ioannis Vranos

Jerry said:
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. :)
 
M

Matthias

Jerry said:
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.
 
J

Jerry Coffin

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

Julie

natush said:
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
 
I

Ioannis Vranos

Julie said:
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).
 
D

Default User

Julie said:
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
 
C

Chris Hills

Ioannis Vranos said:
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 /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
 
I

Ioannis Vranos

Chris said:
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?
 
M

Matthias

Ioannis said:
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.
 
I

Ioannis Vranos

Matthias said:
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. :)
 
J

Jerry Coffin

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

Chris Hills

Ioannis Vranos said:
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 /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,776
Messages
2,569,603
Members
45,196
Latest member
ScottChare

Latest Threads

Top