Time and memory performance of C versus C++

[Generic Usenet Account]

A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a
myth. My posting pertains to a slightly different aspect of this
debate. Here are my two questions:

1) Does anyone have any information on comparison of C and C++
software written for the ARM processor?

2) Are there any compiler and CPU dependencies that have to be
factored in while debating this issue? Or, is the issue more or less
settled for all compilers and all CPUs?

Thanks,
Kandregula Anil K.

[Victor Bazarov]

Generic Usenet Account wrote:

A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a
myth.

I'll take your word for it.

My posting pertains to a slightly different aspect of this
debate. Here are my two questions:

1) Does anyone have any information on comparison of C and C++
software written for the ARM processor?

2) Are there any compiler and CPU dependencies that have to be
factored in while debating this issue?

No. There is no point in debating this "issue" whatsoever. I am
sure that among my brethren in 'comp.lang.c' there will be somebody
with a different opinion, of course.

Or, is the issue more or less
settled for all compilers and all CPUs?

http://www.research.att.com/~bs/bs_faq.html#C-is-better Do you see
any mention of a platform or CPU?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Ian Collins]

Generic Usenet Account wrote:

A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a
myth. My posting pertains to a slightly different aspect of this
debate. Here are my two questions:

1) Does anyone have any information on comparison of C and C++
software written for the ARM processor?

One can write piss poor inefficient code in either language, or one can
write elegant efficient code in either. Programmers write code, not
compilers, so there isn't anything to study or discuss.

--
Ian Collins.

[ediebur]

On Nov 9, 2:48 pm, Ian Collins <[e-mail]:

Generic Usenet Account wrote:

A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a
myth. My posting pertains to a slightly different aspect of this
debate. Here are my two questions:

1) Does anyone have any information on comparison of C and C++
software written for the ARM processor?

One can write piss poor inefficient code in either language, or one can
write elegant efficient code in either. Programmers write code, not
compilers, so there isn't anything to study or discuss.

--
Ian Collins.

These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

[jameskuyper]

[e-mail] wrote:
....

These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

As our computers get more powerful, the problems we try to solve with
them get more difficult. If you have a program which takes 10 days to
run on a 3-GHz machine with 1GB RAM, an algorithm change that causes a
speed-up by a factor of 2 is going to look pretty sweet.

Truly elegant code is easier to understand and maintain; with
programmer time costing so much more than CPU time, elegance is
getting steadily more important, not less.

[Tor Rustad]

Generic Usenet Account wrote:

A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a
myth. My posting pertains to a slightly different aspect of this
debate. Here are my two questions:

1) Does anyone have any information on comparison of C and C++
software written for the ARM processor?

Platform or C++ specific questions, are off-topic in c.l.c

2) Are there any compiler and CPU dependencies that have to be
factored in while debating this issue? Or, is the issue more or less
settled for all compilers and all CPUs?

Compiler or CPU specific questions, are off-topic in c.l.c
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

[Ian Collins]

ed*****@rcn.com wrote:

On Nov 9, 2:48 pm, Ian Collins <[e-mail]:

>Generic Usenet Account wrote:

>>A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a
myth. My posting pertains to a slightly different aspect of this
debate. Here are my two questions:
1) Does anyone have any information on comparison of C and C++
software written for the ARM processor?

One can write piss poor inefficient code in either language, or one can
write elegant efficient code in either. Programmers write code, not
compilers, so there isn't anything to study or discuss.

*Please* don't quote signatures

>
These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Do you have any pride in your work?

--
Ian Collins.

[moschops]

ed*****@rcn.com wrote:

>
These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Hey, that's great! Where can I pick up one of these 3ghz 1GB RAM
computers? I need it to be about 3 cm by 3 cm all in, drawing no more
than one amp of current and using about 10W of power, with a JTAG port
on board.

What's that, you say? There's no such thing? Well then, I guess I'll
have to use whatever I can get in that size, current and power
limitations and just do some damned elegant coding to get it to do what
I need.

Lift your head from the keyboard once in a while, chum. There's more to
computing that desktop PCs.

'Chops

[jacob navia]

moschops wrote:

ed*****@rcn.com wrote:

>>
These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Hey, that's great! Where can I pick up one of these 3ghz 1GB RAM
computers? I need it to be about 3 cm by 3 cm all in, drawing no more
than one amp of current and using about 10W of power, with a JTAG port
on board.

What's that, you say? There's no such thing? Well then, I guess I'll
have to use whatever I can get in that size, current and power
limitations and just do some damned elegant coding to get it to do what
I need.

Lift your head from the keyboard once in a while, chum. There's more to
computing that desktop PCs.

'Chops

Even in desktop's PCs that philosophy is utterly WRONG and leads to
software that takes gigabytes to do the simplest thing. Of course if you
have 2GB or 4GB of memory it doesn't matter... UNTIL YOU WANT TO RUN
A DOZEN OF THOSE!

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Malcolm McLean]

"moschops" <mo*****@madasafish.comwrote in message

ed*****@rcn.com wrote:

>>
These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Hey, that's great! Where can I pick up one of these 3ghz 1GB RAM
computers? I need it to be about 3 cm by 3 cm all in, drawing no more than
one amp of current and using about 10W of power, with a JTAG port on
board.

What's that, you say? There's no such thing? Well then, I guess I'll have
to use whatever I can get in that size, current and power limitations and
just do some damned elegant coding to get it to do what I need.

Lift your head from the keyboard once in a while, chum. There's more to
computing that desktop PCs.

Yes, but typically embedded processors do jobs which are utterly trivial.
Like turn on a few lights in a washing machine.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Flash Gordon]

ed*****@rcn.com wrote, On 09/11/07 20:48:

On Nov 9, 2:48 pm, Ian Collins <[e-mail]:

>Generic Usenet Account wrote:

>>A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a
myth. My posting pertains to a slightly different aspect of this
debate. Here are my two questions:
1) Does anyone have any information on comparison of C and C++
software written for the ARM processor?

One can write piss poor inefficient code in either language, or one can
write elegant efficient code in either. Programmers write code, not
compilers, so there isn't anything to study or discuss.

--
Ian Collins.

Please don't quote sigs, the bit typically after the "-- ".

These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

You have a 3GHz processor with 1GB RAM in your microwave oven? Do you
think efficiency does not matter if you have a few hundred simultaneous
users on your server? Just to name two of the many reasons why
needlessly inefficient code is a problem.
--
Flash Gordon

[moschops]

Malcolm McLean wrote:

"moschops" <mo*****@madasafish.comwrote in message

>ed*****@rcn.com wrote:

>>>
These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Hey, that's great! Where can I pick up one of these 3ghz 1GB RAM
computers? I need it to be about 3 cm by 3 cm all in, drawing no more
than one amp of current and using about 10W of power, with a JTAG port
on board.

What's that, you say? There's no such thing? Well then, I guess I'll
have to use whatever I can get in that size, current and power
limitations and just do some damned elegant coding to get it to do
what I need.

Lift your head from the keyboard once in a while, chum. There's more
to computing that desktop PCs.

Yes, but typically embedded processors do jobs which are utterly
trivial. Like turn on a few lights in a washing machine.

Typically. But, of course, some of them do things that are far from
trivial. Hacks who make comments about how there's no need for elegance
in coding can do the washing machines, and the rest of us can do the
non-trivial stuff.

'Chops

[Stephen Sprunk]

"Generic Usenet Account" <us****@sta.samsung.comwrote in message
news:11*********************@y27g2000pre.googlegro ups.com...

A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++
code is a myth.

Of course it's a myth. If you write equivalent code, the performance will
be nearly identical, since AFAIK all interesting compilers share the code
generation engine across both C and C++ modes.

OTOH, C++ allows you to write a different style of code that can't (easily
or efficiently) be written in C. C++'s additional features to support that
style also tend to be the features that are either particularly slow to
execute or encourage programmers to write slow code -- but they also tend to
make the code code faster to write and easier to understand and debug.
Depending on the purpose and use of the code, that may or may not be a smart
trade-off.

(Specifically, templates and classes can save massive amounts of programmer
time -- but they also hide from the programmer what's going on under the
hood so that he/she may not realize that a simple-looking statement may be
hundreds of times more complex than a slightly more-complex-looking
statement.)

My posting pertains to a slightly different aspect of this debate.
Here are my two questions:

1) Does anyone have any information on comparison of C and C++
software written for the ARM processor?

The processor type has nothing to do with it.

2) Are there any compiler and CPU dependencies that have to be
factored in while debating this issue? Or, is the issue more or less
settled for all compilers and all CPUs?

The latter, at least in the sense it's "settled" that your question is
either nonsensical or irrelevant.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[ediebur]

On Nov 9, 5:10 pm, moschops <[e-mail]:

Malcolm McLean wrote:

"moschops" <[e-mail] in message

[e-mail] wrote:

>These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Hey, that's great! Where can I pick up one of these 3ghz 1GB RAM
computers? I need it to be about 3 cm by 3 cm all in, drawing no more
than one amp of current and using about 10W of power, with a JTAG port
on board.

What's that, you say? There's no such thing? Well then, I guess I'll
have to use whatever I can get in that size, current and power
limitations and just do some damned elegant coding to get it to do
what I need.

Lift your head from the keyboard once in a while, chum. There's more
to computing that desktop PCs.

Yes, but typically embedded processors do jobs which are utterly
trivial. Like turn on a few lights in a washing machine.

Typically. But, of course, some of them do things that are far from
trivial. Hacks who make comments about how there's no need for elegance
in coding can do the washing machines, and the rest of us can do the
non-trivial stuff.

'Chops

Jeez, I just brought it up as a topic for discussion, didn't mean for
anyone to get nasty

[Flash Gordon]

Malcolm McLean wrote, On 09/11/07 21:54:

"moschops" <mo*****@madasafish.comwrote in message

>ed*****@rcn.com wrote:

>>>
These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Hey, that's great! Where can I pick up one of these 3ghz 1GB RAM
computers? I need it to be about 3 cm by 3 cm all in, drawing no more
than one amp of current and using about 10W of power, with a JTAG port
on board.

What's that, you say? There's no such thing? Well then, I guess I'll
have to use whatever I can get in that size, current and power
limitations and just do some damned elegant coding to get it to do
what I need.

Lift your head from the keyboard once in a while, chum. There's more
to computing that desktop PCs.

Yes, but typically embedded processors do jobs which are utterly
trivial. Like turn on a few lights in a washing machine.

Or image recognition in real time, of performing 42 simultaneous
correlation calculations to detect signals well below the noise
threshold and extract information off them that is encoded in variations
of the bit width and simultaneously calculate the relative velocity of
the receiver and transmitter based on the dopler shift. Or perform real
time MPEG compression. Or...

Well, suffice to say that vast numbers of embedded processors, including
embedded processors in the computer I am using, the TV I am watching, my
DVD player and my surround sound decoder are doing complex tasks
involving a lot of computation.
--
Flash Gordon

[red floyd]

Malcolm McLean wrote:

>>

Yes, but typically embedded processors do jobs which are utterly
trivial. Like turn on a few lights in a washing machine.

To quote Pauli.... This isn't right. It isn't even wrong.

Lets see.... avionics, video codec, audio codec, other multimedia,
printer engine....

Yeah, those are just turning on a few lights.

[Juha Nieminen]

ed*****@rcn.com wrote:

These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Ever played a modern computer game with millions of polygons per
level, even tens of thousands of polygons visible at the same time,
complex physics, etc? Do you want to play that kind of game at 0.5
frames per second or at 30 frames per second in your 3GHz computer?

[Ivar Rosquist]

On Fri, 09 Nov 2007 15:03:41 -0800, red floyd wrote:

Malcolm McLean wrote:

>Yes, but typically embedded processors do jobs which are utterly
trivial. Like turn on a few lights in a washing machine.

To quote Pauli.... This isn't right. It isn't even wrong.

Lets see.... avionics, video codec, audio codec, other multimedia,
printer engine....

Yeah, those are just turning on a few lights.

Well, what can you expect from McLean, one who is so incompetent
that he does not know that he does not know?

[James Kuyper]

ed*****@rcn.com wrote:
....

>>>[e-mail] wrote:
These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

....

Jeez, I just brought it up as a topic for discussion, didn't mean for
anyone to get nasty

You're getting a nasty response because a lot of us have been victims of
programmers who felt exactly the same way you do. We use applications
that run too slow and take up too much memory, for no particularly good
reason, just because somebody thought there was no point to worrying
about efficiency. We update programs written by other people that are
maintenance nightmares because the original author thought that there
was no importance to writing code elegantly.

[acehreli]

On Nov 9, 12:48 pm, [e-mail] wrote:

On Nov 9, 2:48 pm, Ian Collins <[e-mail]:

One can write piss poor inefficient code in either language, or one can
write elegant efficient code in either. Programmers write code, not
compilers, so there isn't anything to study or discuss.

These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Efficient code has more than one meaning:

1) If you mean fast program produced from that "efficient code," those
fast computers don't help at all with this simple problem: user
interfaces are not responsive. I click, nothing happens... I select a
pull-down menu, it is empty for a while. No matter how fast your
computer is.

2) If you mean code that is easy to maintain and alter, then I
completely disagree with you that fast computers can help. If there
are 14 files to modify to add one property to some component, then
your code is inefficient no matter what.

3) Some other meaning?

Ali

[Duane Hebert]

These days with 3ghz computers with more than 1 gbyte RAM what is so

important about elegant, efficient code?

Missed the bit from the OP about Arm did you? Sort of topical
for me since I've spent the last two days trying to crowbar Chinese
fonts into an XScale Arm product.

[Duane Hebert]

"red floyd" <no*****@here.dudewrote in message
news:ZH****************@newssvr19.news.prodigy.net ...

Malcolm McLean wrote:

>>>

Yes, but typically embedded processors do jobs which are utterly trivial.
Like turn on a few lights in a washing machine.

To quote Pauli.... This isn't right. It isn't even wrong.

Lets see.... avionics, video codec, audio codec, other multimedia, printer
engine....

Yeah, those are just turning on a few lights.

Some of the lights are gigantic furnaces filled with
dnh3 and h2 at extremely high temperatures.

[Malcolm McLean]

"Juha Nieminen" <no****@thanks.invalidwrote in message

ed*****@rcn.com wrote:

>These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Ever played a modern computer game with millions of polygons per
level, even tens of thousands of polygons visible at the same time,
complex physics, etc? Do you want to play that kind of game at 0.5
frames per second or at 30 frames per second in your 3GHz computer?

That rate-limiting step in such a game is probably the rasteriser rather
than the main processor.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Malcolm McLean]

"red floyd" <no*****@here.dudewrote in message
news:ZH****************@newssvr19.news.prodigy.net ...

Malcolm McLean wrote:

>>>

Yes, but typically embedded processors do jobs which are utterly trivial.
Like turn on a few lights in a washing machine.

To quote Pauli.... This isn't right. It isn't even wrong.

Lets see.... avionics, video codec, audio codec, other multimedia, printer
engine....

Yeah, those are just turning on a few lights.

"Typically" means there will be a few counter-examples.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ian Collins]

Malcolm McLean wrote:

>
"red floyd" <no*****@here.dudewrote in message
news:ZH****************@newssvr19.news.prodigy.net ...

>Malcolm McLean wrote:

>>>>
Yes, but typically embedded processors do jobs which are utterly
trivial. Like turn on a few lights in a washing machine.

To quote Pauli.... This isn't right. It isn't even wrong.

Lets see.... avionics, video codec, audio codec, other multimedia,
printer engine....

Yeah, those are just turning on a few lights.

"Typically" means there will be a few counter-examples.

I bet there's more cell phones shipped a year than washing machines.

--
Ian Collins.

[lovecreatesbea...]

On Nov 10, 3:17 am, Generic Usenet Account <[e-mail]>
wrote:

A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a
myth.

C++ is slower than C for the first one may call three functions:
cpp.constructor(), cpp.function() and cpp.destructor(). If it doesn't
call the constructor and destructor, it's C.

[cr88192]

"Malcolm McLean" <re*******@btinternet.comwrote in message
news:Ia******************************@bt.com...

"Juha Nieminen" <no****@thanks.invalidwrote in message

>ed*****@rcn.com wrote:

>>These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Ever played a modern computer game with millions of polygons per
level, even tens of thousands of polygons visible at the same time,
complex physics, etc? Do you want to play that kind of game at 0.5
frames per second or at 30 frames per second in your 3GHz computer?

That rate-limiting step in such a game is probably the rasteriser rather
than the main processor.

maybe if the game is heavily loaded with shaders...

but, at least for fairly basic rendering (no shaders, no stenciling, ...), I
suspect it is actually the case that a lot more often ends up going into
stuff going on in the main processor, than in the video card itself.

it may not seem like it, but the main engine has a hard time keeping up,
even when doing bunches of vertex-level calculations.

the speed of the graphics card should not be so easily discounted.

(of course, use shaders or enable stenciling, and the thing typically slows
way down...).

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Flash Gordon]

Malcolm McLean wrote, On 10/11/07 08:58:

>
"red floyd" <no*****@here.dudewrote in message
news:ZH****************@newssvr19.news.prodigy.net ...

>Malcolm McLean wrote:

>>>>
Yes, but typically embedded processors do jobs which are utterly
trivial. Like turn on a few lights in a washing machine.

To quote Pauli.... This isn't right. It isn't even wrong.

Lets see.... avionics, video codec, audio codec, other multimedia,
printer engine....

Yeah, those are just turning on a few lights.

"Typically" means there will be a few counter-examples.

Those "few counter-example" include within sight of me at least 7
embedded processors, the GPS I use in my car, and a minimum of one other
processor in my car. In fact, it will include at least one processor in
every DVD player, digital TV, DTV receiver, satalite decoder, cable TV
decoder, GPS, car and computer being sold as well as a lot of other kit.
Yes, computers *do* have embedded processors in them. I think you will
be hard pressed to find a household in the UK without a few of those
items. So this is NOT a small number of counter-examples, rather it is
several large industries.
--
Flash Gordon

[Malcolm McLean]

"Ian Collins" <ia******@hotmail.comwrote in message

>
I bet there's more cell phones shipped a year than washing machines.

Little 8-bit embedded processors outsell others by a wide margin.

I'd agree, however, the market is changing. Digital tellies and mobile
phones are getting so sophisticated that they are blurring the line between
embedded devices and computers in their own right. We shouldn't fear for our
jobs.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Pete Becker]

On 2007-11-10 04:31:02 -0500, "[e-mail]"
<lo***************@gmail.comsaid:

On Nov 10, 3:17 am, Generic Usenet Account <[e-mail]>
wrote:

>A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a
myth.

C++ is slower than C for the first one may call three functions:
cpp.constructor(), cpp.function() and cpp.destructor(). If it doesn't
call the constructor and destructor, it's C.

If an object needs to manage resources, then it needs to manage
resources. In C++ that's what the constructor and destructor do. In C
that's done explicitly by calling init and cleanup functions. Either
way, the speed of correct code is in large part determined by what has
to be done, not by the language that's being used to do it.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[EventHelix.com]

On Nov 9, 2:17 pm, Generic Usenet Account <[e-mail]>
wrote:

A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a
myth. My posting pertains to a slightly different aspect of this
debate. Here are my two questions:

1) Does anyone have any information on comparison of C and C++
software written for the ARM processor?

2) Are there any compiler and CPU dependencies that have to be
factored in while debating this issue? Or, is the issue more or less
settled for all compilers and all CPUs?

Thanks,
Kandregula Anil K.

The following links map C++ code to it's equivalent C. This will let
you judge the performance impact of C++.

http://www.eventhelix.com/RealtimeMa...erformance.htm

http://www.eventhelix.com/RealtimeMa...rformance2.htm

--
EventStudio - http://www.Eventhelix.com/Eventstudio/
Sequence diagram based systems engineering tool

[Flash Gordon]

Malcolm McLean wrote, On 10/11/07 10:07:

"Ian Collins" <ia******@hotmail.comwrote in message

>>
I bet there's more cell phones shipped a year than washing machines.

Little 8-bit embedded processors outsell others by a wide margin.

The little 8-bit processors are often doing a heck of a lot more than
turning on a few lights. One of those little 8-bit processors that I
know about is doing a lot of trig, another I know about is doing massive
amounts of comms processing and so on.

I'd agree, however, the market is changing. Digital tellies and mobile
phones are getting so sophisticated that they are blurring the line
between embedded devices and computers in their own right.

Mobile phones and PDAs act like computers, but the TVs, cars, set to
boxes etc are all definitely embedded devices.

We shouldn't
fear for our jobs.

No one has said they do.
--
Flash Gordon

[Tim H]

On Nov 10, 1:15 am, Flash Gordon <[e-mail]:

>Yes, but typically embedded processors do jobs which are utterly
trivial. Like turn on a few lights in a washing machine.

Lets see.... avionics, video codec, audio codec, other multimedia,
printer engine....

Yeah, those are just turning on a few lights.

"Typically" means there will be a few counter-examples.

Those "few counter-example" include within sight of me at least 7
embedded processors, the GPS I use in my car, and a minimum of one other
processor in my car. In fact, it will include at least one processor in
every DVD player, digital TV, DTV receiver, satalite decoder, cable TV
decoder, GPS, car and computer being sold as well as a lot of other kit.
Yes, computers *do* have embedded processors in them. I think you will
be hard pressed to find a household in the UK without a few of those
items. So this is NOT a small number of counter-examples, rather it is
several large industries.

Don't forget your computer keyboard, your optical mouse, very likely
your wristwatch, your microwave, your stove, your refrigerator, and
basically most anything that has electronics these days.

There are more ARM processors deployed in the world than any other
CPU.

Tim

[Ian Collins]

EventHelix.com wrote:

>
The following links map C++ code to it's equivalent C. This will let
you judge the performance impact of C++.

http://www.eventhelix.com/RealtimeMa...erformance.htm

The concluding statement concerning static member functions "Thus they
are accessed without indirection of the object. This can be useful in
defining methods which need C level function call conventions." is wrong.

Static member functions a not C functions, they have C++ linkage. The
only correct technique for providing a C linkage function from C++ is to
use a function declares as extern "C".

--
EventStudio - http://www.Eventhelix.com/Eventstudio/
Sequence diagram based systems engineering tool

Your sig is missing the space after the '--'.

--
Ian Collins.

[Malcolm McLean]

"Pete Becker" <pe**@versatilecoding.comwrote in message

If an object needs to manage resources, then it needs to manage resources.
In C++ that's what the constructor and destructor do. In C that's done
explicitly by calling init and cleanup functions. Either way, the speed of
correct code is in large part determined by what has to be done, not by
the language that's being used to do it.

But object-oriented languages often throw away cycles for the convenience of
the programmer. For instance frequently you know from the program logic that
an array bounds error cannot happen. However many languages will check each
access anyway. Since the vast majority of code is not in the inner loop, and
thus not time critical, that's often a reasonable trade off. But not always.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Malcolm McLean]

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message

Malcolm McLean wrote, On 10/11/07 10:07:

>"Ian Collins" <ia******@hotmail.comwrote in message

>>>
I bet there's more cell phones shipped a year than washing machines.

Little 8-bit embedded processors outsell others by a wide margin.

The little 8-bit processors are often doing a heck of a lot more than
turning on a few lights. One of those little 8-bit processors that I know
about is doing a lot of trig, another I know about is doing massive
amounts of comms processing and so on.

Mobile phones and PDAs act like computers, but the TVs, cars, set to boxes
etc are all definitely embedded devices.

For every glamorous processor doing frequency transforms to run an MPEG
codec or something there are probably several doing humble jobs.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ian Collins]

Malcolm McLean wrote:

>
"Pete Becker" <pe**@versatilecoding.comwrote in message

>If an object needs to manage resources, then it needs to manage
resources. In C++ that's what the constructor and destructor do. In C
that's done explicitly by calling init and cleanup functions. Either
way, the speed of correct code is in large part determined by what has
to be done, not by the language that's being used to do it.

But object-oriented languages often throw away cycles for the
convenience of the programmer. For instance frequently you know from the
program logic that an array bounds error cannot happen. However many
languages will check each access anyway. Since the vast majority of code
is not in the inner loop, and thus not time critical, that's often a
reasonable trade off. But not always.

What does any of the above have to do with OO? The first language I
used that uses automatic array bounds checking was Pascal. C++, even
when used for OO programming, does not perform array bounds checking.

--
Ian Collins.

[Malcolm McLean]

"Ian Collins" <ia******@hotmail.comwrote in message

Malcolm McLean wrote:

>>
"Pete Becker" <pe**@versatilecoding.comwrote in message

>>If an object needs to manage resources, then it needs to manage
resources. In C++ that's what the constructor and destructor do. In C
that's done explicitly by calling init and cleanup functions. Either
way, the speed of correct code is in large part determined by what has
to be done, not by the language that's being used to do it.

But object-oriented languages often throw away cycles for the
convenience of the programmer. For instance frequently you know from the
program logic that an array bounds error cannot happen. However many
languages will check each access anyway. Since the vast majority of code
is not in the inner loop, and thus not time critical, that's often a
reasonable trade off. But not always.

What does any of the above have to do with OO? The first language I
used that uses automatic array bounds checking was Pascal. C++, even
when used for OO programming, does not perform array bounds checking.

If you treat arays as "objects" it becomes natural for an access to cause
code to be executed. C++ even allows overloading of the subscript operator
to permit this. You can have bounds checking in non-OO languages, but it
implies special compiler tricks and / or hidden variables.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ian Collins]

Malcolm McLean wrote:

"Ian Collins" <ia******@hotmail.comwrote in message

>Malcolm McLean wrote:

>>>
"Pete Becker" <pe**@versatilecoding.comwrote in message
If an object needs to manage resources, then it needs to manage
resources. In C++ that's what the constructor and destructor do. In C
that's done explicitly by calling init and cleanup functions. Either
way, the speed of correct code is in large part determined by what has
to be done, not by the language that's being used to do it.

But object-oriented languages often throw away cycles for the
convenience of the programmer. For instance frequently you know from the
program logic that an array bounds error cannot happen. However many
languages will check each access anyway. Since the vast majority of code
is not in the inner loop, and thus not time critical, that's often a
reasonable trade off. But not always.

What does any of the above have to do with OO? The first language I
used that uses automatic array bounds checking was Pascal. C++, even
when used for OO programming, does not perform array bounds checking.

If you treat arays as "objects" it becomes natural for an access to
cause code to be executed. C++ even allows overloading of the subscript
operator to permit this. You can have bounds checking in non-OO
languages, but it implies special compiler tricks and / or hidden
variables.

Exactly, in OO languages, you can opt to bounds check or not to bounds
check, or even both for debug/non-debug builds. With non-OO languages,
you don't have that choice. So the former gives the programmer the
choice of safety or speed, throwing away cycles is an option, not
something imposed by the language.

It's the programmer's choice to "throw away cycles", not the language's.

--
Ian Collins.

[CBFalconer]

Ian Collins wrote:

Malcolm McLean wrote:

>>

.... snip ...

>>
But object-oriented languages often throw away cycles for the
convenience of the programmer. For instance frequently you know
from the program logic that an array bounds error cannot happen.
However many languages will check each access anyway. Since the
vast majority of code is not in the inner loop, and thus not time
critical, that's often a reasonable trade off. But not always.

What does any of the above have to do with OO? The first language
I used that uses automatic array bounds checking was Pascal. C++,
even when used for OO programming, does not perform array bounds
checking.

The better Pascal systems will do very little run-time checking
WHEN THINGS ARE PROPERLY TYPED. That typing sets limits for all
variables, and that knowledge can be used to ensure that range
calculations are only performed when the run-time calculation could
create an error. This has been shown to reduce run-time check time
by about 80%.

This is not available for C, because there is no sub-range typing
available.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Ian Collins]

CBFalconer wrote:

Ian Collins wrote:

>Malcolm McLean wrote:

.... snip ...

>>But object-oriented languages often throw away cycles for the
convenience of the programmer. For instance frequently you know
from the program logic that an array bounds error cannot happen.
However many languages will check each access anyway. Since the
vast majority of code is not in the inner loop, and thus not time
critical, that's often a reasonable trade off. But not always.

What does any of the above have to do with OO? The first language
I used that uses automatic array bounds checking was Pascal. C++,
even when used for OO programming, does not perform array bounds
checking.

The better Pascal systems will do very little run-time checking
WHEN THINGS ARE PROPERLY TYPED. That typing sets limits for all
variables, and that knowledge can be used to ensure that range
calculations are only performed when the run-time calculation could
create an error. This has been shown to reduce run-time check time
by about 80%.

I wonder how often this (correct typing) is used? One can do the same
in C++, but I seldom see the technique used.

--
Ian Collins.

[RoS]

In data Fri, 09 Nov 2007 12:48:59 -0800, ed*****@rcn.com scrisse:

>These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

because short code is beautiful

[Sherman Pendley]

RoS <Ro*@not.existwrites:

In data Fri, 09 Nov 2007 12:48:59 -0800, ed*****@rcn.com scrisse:

>>These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

because short code is beautiful

Elegant code does tend to be short, but brevity shouldn't be a goal in
and of itself - that way lies obfuscation and maintenance nightmares.

True code beauty is a balance of brevity and clarity.

sherm--

--
WV News, Blogging, and Discussion: http://wv-www.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

[James Kanze]

On Nov 10, 2:34 pm, Pete Becker <[e-mail]:

On 2007-11-10 04:31:02 -0500, "[e-mail]"
<[e-mail]:

On Nov 10, 3:17 am, Generic Usenet Account <[e-mail]>
wrote:

A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a
myth.

C++ is slower than C for the first one may call three functions:
cpp.constructor(), cpp.function() and cpp.destructor(). If it doesn't
call the constructor and destructor, it's C.

If an object needs to manage resources, then it needs to manage
resources. In C++ that's what the constructor and destructor do. In C
that's done explicitly by calling init and cleanup functions. Either
way, the speed of correct code is in large part determined by what has
to be done, not by the language that's being used to do it.

When I first shifted to C++, I found that my programs became a
lot bigger (although not necessarily slower). They also did a
lot more---features that represented a lot of work in C were
often very simple to implement in C++, and so got added, where
they'd never gotten added to the C program.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Chris Dollin]

ed*****@rcn.com wrote:

These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

/My/ code can be as inefficient as it likes -- if I don't like
it, I change it, and I'm the one paying the cost & receiving
the benefit of the "inefficiency".

/Your/ code, running on /my/ machine, had better be as efficient
as you & your compiler can make it, because those are /my cycles/
you're burning, and I have better things to do with them than
make life easier for /you/.

Now boil with lots of symmetry.

--
Cooking Hedgehog
A rock is not a fact. A rock is a rock.

[Pete Becker]

On 2007-11-10 16:50:17 -0500, "Malcolm McLean" <re*******@btinternet.comsaid:

>
"Pete Becker" <pe**@versatilecoding.comwrote in message

>If an object needs to manage resources, then it needs to manage
resources. In C++ that's what the constructor and destructor do. In C
that's done explicitly by calling init and cleanup functions. Either
way, the speed of correct code is in large part determined by what has
to be done, not by the language that's being used to do it.

But object-oriented languages often throw away cycles for the
convenience of the programmer. For instance frequently you know from
the program logic that an array bounds error cannot happen. However
many languages will check each access anyway. Since the vast majority
of code is not in the inner loop, and thus not time critical, that's
often a reasonable trade off. But not always.

Regardless of what "many languages will check", C++ does not check
array access. Array access does not affect the speed or memory usage of
C++ versus C.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Pete Becker]

On 2007-11-11 08:45:22 -0500, Pete Becker <pe**@versatilecoding.comsaid:

On 2007-11-10 16:50:17 -0500, "Malcolm McLean" <re*******@btinternet.comsaid:

>>
"Pete Becker" <pe**@versatilecoding.comwrote in message

>>If an object needs to manage resources, then it needs to manage
resources. In C++ that's what the constructor and destructor do. In C
that's done explicitly by calling init and cleanup functions. Either
way, the speed of correct code is in large part determined by what has
to be done, not by the language that's being used to do it.

But object-oriented languages often throw away cycles for the
convenience of the programmer. For instance frequently you know from
the program logic that an array bounds error cannot happen. However
many languages will check each access anyway. Since the vast majority
of code is not in the inner loop, and thus not time critical, that's
often a reasonable trade off. But not always.

Regardless of what "many languages will check", C++ does not check
array access. Array access does not affect the speed or memory usage of
C++ versus C.

That is, C++ does not require checking array access. Nor does C.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Tor Rustad]

Malcolm McLean wrote:

"Ian Collins" <ia******@hotmail.comwrote in message

>>
I bet there's more cell phones shipped a year than washing machines.

Little 8-bit embedded processors outsell others by a wide margin.

Pray tell, first you try to educate us on financial calculations, now
the time has come to embedded processors?! <g>
Has Malcolm McLean ever worked professionally with (8-bit) embedded
processors?
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

[CBFalconer]

Ian Collins wrote:

CBFalconer wrote:

.... snip ...

>

>The better Pascal systems will do very little run-time checking
WHEN THINGS ARE PROPERLY TYPED. That typing sets limits for all
variables, and that knowledge can be used to ensure that range
calculations are only performed when the run-time calculation could
create an error. This has been shown to reduce run-time check time
by about 80%.

I wonder how often this (correct typing) is used? One can do the
same in C++, but I seldom see the technique used.

Probably not too often. How many C users actually use the full
abilities of the language?

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Charles Richmond]

CBFalconer wrote:

Ian Collins wrote:

>CBFalconer wrote:

... snip ...

>>The better Pascal systems will do very little run-time checking
WHEN THINGS ARE PROPERLY TYPED. That typing sets limits for all
variables, and that knowledge can be used to ensure that range
calculations are only performed when the run-time calculation could
create an error. This has been shown to reduce run-time check time
by about 80%.

I wonder how often this (correct typing) is used? One can do the
same in C++, but I seldom see the technique used.

Probably not too often. How many C users actually use the full
abilities of the language?

"Real Programmers know every nuance of every instruction
and use them *all* in every Real Program."
-- "Real Programmers Don't Write Specs" ;-)
http://ifaq.wap.org/computers/realprogrammers.html
Thinking back, the only ability of C that I have *not*
used is the "onexit()" callback facility. I am gratified
to say that once I actually found a way to use "setjmp/longjmp"
profitably. (Well, some of the new features introduced
in C99 I have *not* used *yet*.)

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+