«

wrote:

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

The amount of time/money spent on maintenance and extending the
software.

Shoddy code begets more shoddy code because improving it would take a
lot of time and everyone wants to get fingers off the program asap.

(Obviously I put more importance on elegance than on raw performance
although there is a strong correspondence between the two in non-toy
projects. As a rule of thumb, the lower-level a programming language is,
the better small programs can be made to perform, and the higher-level a
language, the easier it is to write well-performing large-scale
programs, where I go with Alan Perlis' definition of "level" that a
language is low-level if its programs need to pay attention to
irrelevant details.)

Malcolm McLean wrote:

> For instance frequently you know from the
> program logic that an array bounds error cannot happen.

If the compiler would just trust programmers, we wouldn't have any
segfaults. Oh, wait a minute...

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

For the few cases where it matters, one can use a profiler to identify
these and, if needed, write some more specialized code.

On Nov 9, 9:17 pm, Generic Usenet Account <use...@sta.samsung.com>
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.
[snip]

Look at C/C++ Program Perfometer
http://groups.google.com/group/perfo?lnk=sg

Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

On Nov 14, 3:29 am, Alex Vinokur <ale...@users.sourceforge.net> wrote:
> On Nov 9, 9:17 pm, Generic Usenet Account <use...@sta.samsung.com>
> 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.
>
> [snip]
>
> Look at C/C++ Program Perfometerhttp://groups.google.com/group/perfo?lnk=sg

In this bit of code:

template <typename T>
static T templated_foo (const T&) { T t; return t; }

static int ordinary_foo (int) { int t; return t; }

Uninitialized data is returned:
q:\perfo-2-9-0--1-19\src\t_call.cpp(60) : warning C4700: uninitialized
local variable 't' used
q:\perfo-2-9-0--1-19\src\t_call.cpp(62) : warning C4700: uninitialized
local variable 't' used

I cannot find a clear answer in the C++ standard, but I think that
this may be a case of undefined behavior.

I do not understand how this code is supposed to compare C and C++
because the code is 100% C++ and so there is nothing to compare
against.

On Nov 14, 6:41 pm, user923005 <dcor...@connx.com> wrote:
> On Nov 14, 3:29 am,AlexVinokur<ale...@users.sourceforge.net> wrote:
>
> > On Nov 9, 9:17 pm, Generic Usenet Account <use...@sta.samsung.com>
> > 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.
>
> > [snip]
>
> > Look at C/C++ Program Perfometerhttp://groups.google.com/group/perfo?lnk=sg
>
> In this bit of code:
>
> template <typename T>
> static T templated_foo (const T&) { T t; return t; }
>
> static int ordinary_foo (int) { int t; return t; }
>
> Uninitialized data is returned:
> q:\perfo-2-9-0--1-19\src\t_call.cpp(60) : warning C4700: uninitialized
> local variable 't' used
> q:\perfo-2-9-0--1-19\src\t_call.cpp(62) : warning C4700: uninitialized
> local variable 't' used
>
> I cannot find a clear answer in the C++ standard, but I think that
> this may be a case of undefined behavior.

Those local variable can uninitialized as follows

template <typename T>
static T templated_foo (const T&) { T t = T(); return t; }

static int ordinary_foo (int) { int t (0); return t; }


>
> I do not understand how this code is supposed to compare C and C++
> because the code is 100% C++ and so there is nothing to compare
> against.

The Perfometer is supposed to compare different construction
* in C++ (i.e., C++ vs. C++); for instance, file t_call.cpp
* in C and C++ (i.e., C vs. C++); for instance, file t_string.cpp


Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

On Nov 9, 3:48 pm, edie...@rcn.com wrote:
> On Nov 9, 2:48 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>
> > 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 **** 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?

Embedded software. Try programming a micro running at 1Mhz, with 32Kb
flash and 256 bytes(yes bytes) RAM.

On Sun, 11 Nov 2007 13:03:05 +1300, Ian Collins <ian->
wrote:

> Malcolm McLean wrote:
> > "Ian Collins" <ian-> wrote in message
<snip: OO vs 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

That's true. Although C++ _also_ has builtin C-style arrays. And C++
allows (in practice, nearly demands) that methods written in the class
declaration are inlined when used, and code specialized to an inline
context often optimizes better, sometimes to nothing.

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

Unless, as above, it's done in the language -- and thus the compiler.

PL/I and Ada have (standard, documented) syntax to turn on or off
certain categories of checks, one of which is array bounds.

Fortran definitely doesn't have syntax, and AFAIR neither does
standard Pascal, but I have seen compilers for each with such options.

- formerly david.thompson1 || achar(64) || worldnet.att.net

In article <>, Malcolm McLean
<> writes
>"moschops" <> wrote in message
>> 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.

Most cars are run by embedded systems as are elevators, all industrial
plant, aircraft, ships, missiles, satellites, mobile phones,
communications systems, the internet smart cards, etc... in fact
almost anything with electrical power "near" it that is not a PC.....

I know of many embedded systems with several millions lines of code in
them

If all the worlds PC's stop it would be inconvenient. If all the worlds
embedded systems stop the world would stop and it would be fatal to
millions.

BTW since a PC is nothing but a collection of embedded systems you might
be surprised to know, last time I looked, the x86 family made up about
5% of the processors in the world... the other 95% are embedded from 8
bit to 128 bit..... The embedded world had 32 and 64 bit systems years
before they got into PC's

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <Kt->, Malcolm McLean
<> writes
>
>"red floyd" <> wrote in message
>news:ZH5Zi.6702$ t...
>> 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.

There are more counter examples there you think.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article < .com>, Tim
H <> writes
>
>There are more ARM processors deployed in the world than any other
>CPU.

Really where did you get that from? Last time I looked (about 3 years
ago) 30% of the worlds MCU were 8051's I know that ARM is selling well
but that is a LOT of MCU to shift to overtake the 8051 in that space of
time.


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/