Ok Enough Which is faster C or C++
Minti
> "Minti" <mintisp...@yahoo.com> wrote in message
> news:51d20cd0.02031...@posting.google.com...
> > >
> > > Losing speed by using the high level C++ facilities is a myth. Check
> > > http://users.forthnet.gr/ath/jvr/c++faq.htm
> >
> > Without reading from that article I can surely say that using
> > containers rather that this type of variable sized arrays is slower.
> > Because I believe for containers you are also asking for the
> > unnecessary functions like checking if any overflow has occured but
> > What if I don't need them and simply bring in variable sized array.
> > Frankly speaking I haven't used any of these features but I don't
> > think that it would take a Newton to realize that using small and
> > compact and having less featured things can bring in speed. BTW if
> > you don't think that using int_fast16_t can help you why do you think
> > that C++ standard Commitie is considering adopting them.
>
> Now although i am in love with C++ ( :) ) i have started feeling
> uncomfortable talking about C++ in here...
>
> In a vector you can do for example:
>
> vector<int>array;
>
> ...
>
> array.push_back(7);
>
> without checking the size
>
> etc etc.
Now there are many genius minds around here and I am ready to
contradict myself that C is faster because of it's small size because
if a person wants a particular funtionalty and he uses his own
implementation it can be slower than the one provided by the compiler.
But What about the other things like the variables of an object, they
occupy space even if I don't need all of them. And what about try and
catch which can make the code slower. When someone says that C is
faster than C++ is it only a myth.
My answer is that it depends.
Phlip
> Now there are many genius minds around here and I am ready to
> contradict myself that C is faster because of it's small size because if
> a person wants a particular funtionalty and he uses his own
> implementation it can be slower than the one provided by the compiler.
> But What about the other things like the variables of an object, they
> occupy space even if I don't need all of them. And what about try and
> catch which can make the code slower. When someone says that C is faster
> than C++ is it only a myth.
>
> My answer is that it depends.
Programs I write in any language are faster than ones you write in any
language. ;-)
--
Phlip
http://www.greencheese.org/LucidScheming
-- Whoever dies with the most features wins --
Ioannis Vranos
> contradict myself that C is faster because of it's small size because
> if a person wants a particular funtionalty and he uses his own
> implementation it can be slower than the one provided by the compiler.
> But What about the other things like the variables of an object, they
> occupy space even if I don't need all of them. And what about try and
> catch which can make the code slower. When someone says that C is
> faster than C++ is it only a myth.
>
> My answer is that it depends.
Now you know it is a "religious" war but write a program using
containers in C-style then i shall write one myself using c++ standard
library and lets play with timings. :)
What about sorting an array or something? I let you find some idea.
--
Ioannis
* Ioannis Vranos
* Programming pages: http://www.noicys.d2g.com
* Alternative URL: http://run.to/noicys
Keith Brafford
Here's a great book for people who think that C++ is necessarily
slower. The authors show how to write C++ code that is as fast
as equivalent C code...
--Keith Brafford
Phlip
Oookay. The Blitz++ expression metatemplate package, by pushing as much
calculations as possible back into compile time, creates executables that
crunch numbers faster than FORTRAN.
(For those not in on the joke, FORTRAN is such a stoopid language that,
between when it was invented during the Model T era of computing and now,
implementors were able to squeeze on its compiler until it produced the
fastest math and array operations possible. Expression Metatemplates
overcome modern languages' issues with aliasing to squeeze executables
down the same way.)
--
Phlip
http://www.greencheese.org/SonseOne
-- The plasma signature at the end of the
wormhole is an approaching warbird --
Ioannis Vranos
news:pan.2002.03.10.19....@yahoo.com...
>
> (For those not in on the joke, FORTRAN is such a stoopid language
that,
Also Fortran obviously was the ideal of the C committee for C99. Imagine
what would happen if the committee was full of vb programmers (we would
have variant type etc crap).
Paul Keinanen
>Oookay. The Blitz++ expression metatemplate package, by pushing as much
>calculations as possible back into compile time, creates executables that
>crunch numbers faster than FORTRAN.
FORTRAN (at least up to FORTRAN IV) was a nice language, with no local
variables on the stack, no recursion and no pointers or dynamic
memory. Thus, practically all addresses could be calculated at
compile or link time and thus, practically all CPU cycles could be
used for some useful calculations. "Modern" languages spend a lot of
time (and space) for runtime address calculations. The only address
calculations you had to do in FORTRAN was array indexing (some shifts
and one addition) and subroutine parameter access (indirect access).
Unfortunately, more recent versions of Fortran have been polluted by
other languages :-).
To be fair, modern processors usually have instructions and addressing
modes to effectively access local variables on the stack (which the
old processors did not have).
However, the instruction set of some small 8 bit embedded processors
is not very efficient to handle stack based languages (such as C or
Pascal), thus, the situation is comparable with 16 bit minicomputers
from the 1960's and 1970's. A language similar to Fortran IV with some
bitwise operations could produce quite effective code on these
embedded processors.
A special feature of these 8 bit embedded processors is that they
usually have quite a lot (several kilobytes) of code memory (E)PROM,
while the data storage (RAM) might be a few tens or hundreds of bytes.
These days it would be quite easy for a crosscompiler to assign local
variables to constant RAM addresses by simply analysing the call tree.
In the old days with Fortran IV, if a large amount of local variables
were needed, they were assigned to a COMMON area, used as a local
storage for many subroutines and you had to be very careful not to
call a subroutine using the same common area as you were using.
Paul
jd
following that ADA [the disaster language of the U.S. govt] developed.
It is based the fundamentally mistaken belief that processes can replace
people. Its corollary is this: "If you can only find the right paradigm
then all errors resulting from programming error can be prevented."
Alwyn
Paul Keinanen <kein...@sci.fi> wrote:
>
> To be fair, modern processors usually have instructions and addressing
> modes to effectively access local variables on the stack (which the
> old processors did not have).
There is no requirement for local variables to be held on a stack in
main memory. Some processors have a large register file that can be used
for this purpose, and some also implement a register stack. So, in
theory, a language that allows automatically allocated local variables
need be no slower than older Fortran.
Alwyn
Minti
> Minti sez:
>
> > Now there are many genius minds around here and I am ready to
> > contradict myself that C is faster because of it's small size because if
> > a person wants a particular funtionalty and he uses his own
> > implementation it can be slower than the one provided by the compiler.
> > But What about the other things like the variables of an object, they
> > occupy space even if I don't need all of them. And what about try and
> > catch which can make the code slower. When someone says that C is faster
> > than C++ is it only a myth.
> >
> > My answer is that it depends.
>
> Programs I write in any language are faster than ones you write in any
> language. ;-)
In C/C++ can you write this faster
int main(){}
Would be glad :)
Dave Mikesell
> C++ unfortunately has developed the same type of pedagogic cult like
> following that ADA [the disaster language of the U.S. govt] developed.
> It is based the fundamentally mistaken belief that processes can replace
> people. Its corollary is this: "If you can only find the right paradigm
> then all errors resulting from programming error can be prevented."
No, all we said is that it will eliminate world hunger, cure cancer,
and put men on Saturn. Get your strawman straight next time...
Sergio Masci
In general yes, C++ programs are slower than the equivalent C programs. It
takes a lot of effort to write decent C++ code. Because it also tends to
take longer to write a C++ program the presure is to finish the project not
optimise it for speed. However it is possible to give a C++ compiler much
more information about a program than you can with C, therefor it is
possible to write C++ programs that run much faster than the equivalent C
program.
Regards
Sergio Masci
http://www.xcprod.com
Grant Edwards
>
> --------------090103060304090804060406
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
>
> C++ unfortunately has developed the same type of pedagogic cult like
> following that ADA [the disaster language of the U.S. govt] developed.
I've only used Ada a little, but I didn't think it was that
bad. At least you don't have to write everything a second time
in HTML when using Ada.
--
Grant Edwards grante Yow! ... I have read the
at INSTRUCTIONS...
visi.com
Paul Keinanen
wrote:
Until you run out of registers :-).
This will easily happen when you have a few functions in the call
stack.
Any local tables will quickly consume the register stack.
If the subroutine needs to access some upper level parameters through
pointers, these upper level variables must still be in the stack.
Paul
Ioannis Vranos
news:7Q2j8.25200$yc2.2...@news2-win.server.ntlworld.com...
>
>
> In general yes, C++ programs are slower than the equivalent C
programs.
That is a myth.
> It
> takes a lot of effort to write decent C++ code. Because it also tends
to
In fact it is a lot easier in C++ than C although it may be in clash
with "common sense" (it is a new language and many people "know" much
misinformation).
> take longer to write a C++ program the presure is to finish the
project not
> optimise it for speed.
This is a myth too. It takes shorter time.
> However it is possible to give a C++ compiler much
> more information about a program than you can with C, therefor it is
> possible to write C++ programs that run much faster than the
equivalent C
> program.
Consider the code:
#include <iostream>
#include <string>
#include <vector>
int main()
{
using namespace std;
vector<string>names(5);
cout << "Enter "<< names.size() << " names: "<< endl;
for (vector<string>::size_type i = 0; i <names.size(); i++)
cin>>names[i];
for (vector<string>::size_type i = 0; i <names.size(); i++)
cout<<names[i]<<endl;
}
and it's C equivallent (without removing the '\n' from the string):
#include <stdio.h>
#include <stddef.h>
int main(void)
{
char names[5][100];
size_t i;
puts("Enter 5 names: ");
for(i=0; i<5; i++)
fgets(names[i], 100, stdin);
for(i=0; i<5; i++)
printf("%s", names[i]);
return 0;
}
The second has more code in it, it is more unsafe, it needs lot of work
in case of a change and it has limits to the size of the string. And it
can be more late than the first.
The first has shorter source code, it is bullet-proof, it doesn't have
the limits of the second and it can be easily updated without the danger
of the macros. Also it has at least the same speed with the second. Also
C++ provides valarray for numeric intensive operations (i am still
studying C++ and haven't used them yet).
Tauno Voipio
And ...
The C++ code is much longer with the run-time libraries, as is necessary in
embedded systems. Do not estimate the size or speed of a piece of code from
the length of the source code - check the translated machine code, libraries
included.
Besides, both for object-oriented code and procedural code, C++ is a bloody
bastard. Reference:
Bertrand Meyer, Object-Oriented Software Construction, Prentice-Hall, ISBN
0-13-629155-4.
Tauno Voipio
tauno voipio @ iki fi
domi
runs faster: both, if you use them the way they're supposed to be used
(don't use vector if you don't need random access, but a (s)list...)
domi
grelbr
> Also Fortran obviously was the ideal of the C committee for C99. Imagine
> what would happen if the committee was full of vb programmers (we would
> have variant type etc crap).
Hey, don't knock VB. The rich obfuscatory powers in VB
have been generating programmer-centuries of work since it was
first invented. Why, the GNP might be noticeably smaller if it
was not for all the people getting rich debugging VB code.
grelbr
Gergo Barany
> "Phlip" <phli...@yahoo.com> wrote in message
> news:pan.2002.03.10.19....@yahoo.com...
> > (For those not in on the joke, FORTRAN is such a stoopid language
>
Would you care to tell us what you know about Fortran and why it is
"obvious" that the C committee chose to copy it?
Gergo
--
"... we define the quality factor Q_p as the ratio of the resistance
to the reactance of the inductance at resonance."
-- Allan R. Hambley, "Electrical Engineering: Principles and Applications"
Donald Gillies
>Here's a great book for people who think that C++ is necessarily
>slower. The authors show how to write C++ code that is as fast
>as equivalent C code...
With a couple of exceptions, C++ is a pure superset of C. however,
there are a few things in C++, like exceptions and constructors and
destructors that place additional restrictions on the types of
optimizations that can performed on procedure calls in C++.
For example, because C++ may invoke constructors or destructors for
objects stacked in the local frame of a function, most compiliers
would choose to have all function calls exit through common exit code.
This can potentially slow down each function by a few instruction
times to jump to the exit code, verses simply returning.
Some compilers such at ATT CFront construct all objects in the same
location and then copy them to their rightful destination. This can
be slower than a typical C function that would simply allocate storage
on the heap and fill it in directly.
Since C++ is such a complex language (185 EBNF rules vs. C's 130 EBNF
rules), C++ compiler writers generally don't have as much time left
over to work on optimizations verses typical C compiler writers.
For these reasons, C++ compilers are imho, marginally slower, and i'd
guess that C++ code run about 1% - 5% slower in most cases.
Don Gillies - dgil...@graviton.com - Network Architect, Graviton, Inc.
EE Faculty, University of British Columbia, Vancouver, B.C. V6T 1Z4,
http://www.ece.ubc.ca/~gillies
Donald Gillies
"Keith Brafford" <kbra...@nc.rr.com> writes:
>Here's a great book for people who think that C++ is necessarily
>slower. The authors show how to write C++ code that is as fast
>as equivalent C code...
With a couple of exceptions, C++ is a pure superset of C. however,
there are a few things in C++, like exceptions and constructors and
destructors that place additional restrictions on the types of
optimizations that can be performed on procedure calls in C++.
For example, because C++ may invoke constructors or destructors for
objects stacked in the local frame of a function, most compiliers
would choose to have all function returns exit through a common exit
handler. This can potentially slow down each function by a few
instruction times to jump to the exit code, verses simply returning.
Some C++ compilers such at early versions of ATT CFront constructed
all objects in the same location and then copied them to their
rightful destination. This is slower than a typical C function that
would simply allocate storage on the heap and fill it in directly.
Since C++ is such a complex language (185 EBNF rules vs. C's 130 EBNF
rules), C++ compiler writers generally don't have as much time left
over to work on optimizations verses typical C compiler writers.
For these reasons, C++ compilers are imho, marginally slower, and i'd
guess that equivalent C++ code runs about 1% - 5% slower in many cases.
Ron Natalie
Donald Gillies wrote:
>
> For example, because C++ may invoke constructors or destructors for
> objects stacked in the local frame of a function, most compiliers
> would choose to have all function calls exit through common exit code.
> This can potentially slow down each function by a few instruction
> times to jump to the exit code, verses simply returning.
Of course, if there are no destructors to exit, the compilers need
not do such a jump. Second, even C implementations need to do something
to restore the stack if there are temporaries or automatic variables
in play. Finally, a unconditional short branch on most platforms is
pretty negligable in performance time.
> Some compilers such at ATT CFront construct all objects in the same
> location and then copy them to their rightful destination.
You can have a sucky C compiler as well. Lets compare modern technology
to modern technology.
> Since C++ is such a complex language (185 EBNF rules vs. C's 130 EBNF
> rules), C++ compiler writers generally don't have as much time left
> over to work on optimizations verses typical C compiler writers.
Bullsquat. Most C++ compiler implementers are also C compiler impelementers.
The time for optimization comes all out of the same pool, and most of these
impelementations share a common code generator anyhow, so you might argue
that C++ is slowing down the C compiler :-)
> For these reasons, C++ compilers are imho, marginally slower, and i'd
> guess that C++ code run about 1% - 5% slower in most cases.
Prove it.
Joona I Palaste
not only which language it was written in, but also on:
- What the code actually does
- Which platform the code was written on
- Which tools the code was compiled with (or is being interpreted with)
- How efficient the hardware running the code is
and possibly other aspects as well.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Shh! The maestro is decomposing!"
- Gary Larson
Peter Pichler
news:a6j4eu$mo8$1...@oravannahka.helsinki.fi...
> Languages aren't fast or slow. Code is. How fast or slow code is depends
> not only which language it was written in, but also on:
> - What the code actually does
> - Which platform the code was written on
> - Which tools the code was compiled with (or is being interpreted with)
> - How efficient the hardware running the code is
> and possibly other aspects as well.
- Who wrote the code
- Who wrote the compiler
Peter, wrote some code once
Daniel Fox
"Donald Gillies" <gil...@cs.ubc.ca> wrote in message
news:a6j35i$66d$1...@cascade.cs.ubc.ca...
>
> "Keith Brafford" <kbra...@nc.rr.com> writes:
>
> >Here's a great book for people who think that C++ is necessarily
> >slower. The authors show how to write C++ code that is as fast
> >as equivalent C code...
>
> With a couple of exceptions, C++ is a pure superset of C. however,
If there are exceptions, it isn't a pure superset, now is it?
-Daniel
Ioannis Vranos
news:k_5j8.275$un1....@read2.inet.fi...
>
>
> And ...
>
> The C++ code is much longer with the run-time libraries, as is
necessary in
> embedded systems. Do not estimate the size or speed of a piece of code
from
> the length of the source code - check the translated machine code,
libraries
> included.
A good C++ compiler compiles only the member functions of a template
that are being used. E.g. in the string is used only the member function
cin::operator>>(). In a few words the cost is kept minimal.
> Besides, both for object-oriented code and procedural code, C++ is a
bloody
> bastard. Reference:
That is your personal (incorrect) opinion. :)
Jos A. Horsmeier
news:a6j35i$66d$1...@cascade.cs.ubc.ca...
> Since C++ is such a complex language (185 EBNF rules vs. C's 130 EBNF
> rules), C++ compiler writers generally don't have as much time left
> over to work on optimizations verses typical C compiler writers.
This is ludicrous. The number of grammar rules, which simply describe
the syntactic structure of a language, has almost nothing to do with
the semantic complexity of a language. Lisp 1.5 needs just a couple of
syntactic rules (less than 10 will do), but the semantic complexicity
of this language borders Turing completeness by that >.< much.
OTOH adding more grammar rules helps the compiler (or any translator)
optimizing whatever it has to optimze. Recall the funky 'for' statement
syntax, present since K&R1:
for_statement:
for ( ; ; ) statement
for ( expression ; ; ) statement
for ( ; expresssion ; ) statement
for ( expression ; expression ; ) statement
for ( ; ; expression) statement
for ( expression ; ; expression ) statement
for ( ; expresssion ; expression) statement
for ( expression ; ; expression) statement
*eight* syntax rules, where just *one* simple rule could've done the
job of syntax description. But these eight rules were a compiler aid for
(code generation) jump optimization.
Bjarne Stroustrup was so modest; he didn't want to introduce a lot of
syntactic structure on top of the C syntax (originally C++ was supposed (*)
to be a 'better C' remember?). Adding a couple of syntax rules doesn't
necessarily add 'runtime overhead', as a matter of fact, they can
help parts of the compiler producing more efficient code which we all
love so much. Syntax rules simply define the syntactical structure of a
language and they can be a big help for that darn code optimizing module
present in every self respecting compiler.
kind regards,
Jos aka j...@gen.nl
(*) I wished he'd been a lot less modest, for one thing this silly
'> >' notation (mind the space here) wouldn't have been such a
lexical issue of debate. Lack of verbosity killed the cat here.
Ben Pfaff
> OTOH adding more grammar rules helps the compiler (or any translator)
> optimizing whatever it has to optimze. Recall the funky 'for' statement
> syntax, present since K&R1:
>
> for_statement:
> for ( ; ; ) statement
> for ( expression ; ; ) statement
> for ( ; expresssion ; ) statement
> for ( expression ; expression ; ) statement
> for ( ; ; expression) statement
> for ( expression ; ; expression ) statement
> for ( ; expresssion ; expression) statement
> for ( expression ; ; expression) statement
>
> *eight* syntax rules, where just *one* simple rule could've done the
> job of syntax description. But these eight rules were a compiler aid for
> (code generation) jump optimization.
Where have you seen the for statement expressed this way, and how
does it aid code generation?
Ioannis Vranos
> "Tauno Voipio" <tauno....@iki.fi.SPAMBAIT_REMOVE> wrote in message
> news:k_5j8.275$un1....@read2.inet.fi...
> >
> >
> > And ...
> >
> > The C++ code is much longer with the run-time libraries, as is
> necessary in
> > embedded systems. Do not estimate the size or speed of a piece of
code
> from
> > the length of the source code - check the translated machine code,
> libraries
> > included.
>
> A good C++ compiler compiles only the member functions of a template
> that are being used. E.g. in the string is used only the member
function
> cin::operator>>(). In a few words the cost is kept minimal.
cin::operator>>(const string &).
Andreas Klimas
how well the design was done. probably one could
remove problems at designtime or at least at
compiletime.
Andreas Klimas
Sergio Masci
> "Sergio Masci" <ser...@NO.SPAM.xcprod.com> wrote in message
> news:7Q2j8.25200$yc2.2...@news2-win.server.ntlworld.com...
> >
> >
> > In general yes, C++ programs are slower than the equivalent C
> programs.
>
> That is a myth.
>
No fact. As a Systems Consultant working for many big companies and
organisations (for many years now) I have observed this to be the case.
>
> > It
> > takes a lot of effort to write decent C++ code. Because it also tends
> to
>
>
> In fact it is a lot easier in C++ than C although it may be in clash
> with "common sense" (it is a new language and many people "know" much
> misinformation).
>
I have been using C++ for over 10 years now.
>
>
> > take longer to write a C++ program the presure is to finish the
> project not
> > optimise it for speed.
>
> This is a myth too. It takes shorter time.
>
I stand by my original statement based on extensive experience and
observation of large systems written and maintained in both C and C++
Ah yes templates. Maybe you should have a look at the STL (standard template
library) source. It is full of special cases (wrapped in conditional compile
statements -- #if / #else / #endif) trying to cope with incompatibilites
between different platforms (compilers and OS'). So compile and test your
code on one platform then pray it works the same on all the others.
Just because one statement in C++ looks cleaner and simpler than the
equivalent block of statements in C does not mean that it runs faster.
Sometimes the price for such clarity is a mountaine of compiler generated
machine code. Writing the code by hand in C emphasises the problem and the
programmer is forced to deal with it (e.g. rewrite it).
C++ does sometimes do a lot of unexpected things behind the scenes. e.g.
coersing objects between types in an unexpected and expensive manor. On
large projects where each member of a team has a reasonable but not excelent
understanding of the classes in the system, programmers use objects as black
boxes to get a job done (in all fairness as they are suposed to do) and the
compiler has a field day generating code. Sometimes a programmer needs to
modify the interface to a class. This can suddenly impact on everyone elses
existing use of the class (e.g. making a method virtual).
Consider in C
float j;
int arr[100];
for (j=0; j<10; j+=1)
{ arr[j] = j+1;
}
You can immediatly see all the needless coersion that is going on between
float and int
In C++, using complex objects, things are not so obvious.
Ioannis Vranos
>
> Ioannis Vranos <noi...@yahoo.com> wrote in message
> news:10158672...@athprx02.forthnet.gr...
> > "Sergio Masci" <ser...@NO.SPAM.xcprod.com> wrote in message
> > news:7Q2j8.25200$yc2.2...@news2-win.server.ntlworld.com...
> > >
> > >
> > > In general yes, C++ programs are slower than the equivalent C
> > programs.
> >
> > That is a myth.
> >
>
> No fact. As a Systems Consultant working for many big companies and
> organisations (for many years now) I have observed this to be the
case.
Then either you code C++ in bad style ir you have been using bad
implementations. Also keep in mind that the official C++ standard was
ratified in 1998.
> I have been using C++ for over 10 years now.
I would prefer an example.
>
> >
> >
> > > take longer to write a C++ program the presure is to finish the
> > project not
> > > optimise it for speed.
> >
> > This is a myth too. It takes shorter time.
> >
>
> I stand by my original statement based on extensive experience and
> observation of large systems written and maintained in both C and C++
What exactly is "slower"?
> Ah yes templates. Maybe you should have a look at the STL (standard
template
> library) source. It is full of special cases (wrapped in conditional
compile
> statements -- #if / #else / #endif) trying to cope with
incompatibilites
> between different platforms (compilers and OS'). So compile and test
your
> code on one platform then pray it works the same on all the others.
Not now that there is the official ANSI C++ 1998 standard. The code i
posted above is guaranteed to work in any C++ conforming compiler.
>
> Just because one statement in C++ looks cleaner and simpler than the
> equivalent block of statements in C does not mean that it runs faster.
> Sometimes the price for such clarity is a mountaine of compiler
generated
> machine code. Writing the code by hand in C emphasises the problem and
the
> programmer is forced to deal with it (e.g. rewrite it).
When you use the C++ standard library the code that gets generated is
usually smaller than our low level C-style code in functions that get
variables and manipulate their bits.
>
> C++ does sometimes do a lot of unexpected things behind the scenes.
e.g.
> coersing objects between types in an unexpected and expensive manor.
On
> large projects where each member of a team has a reasonable but not
excelent
> understanding of the classes in the system, programmers use objects as
black
> boxes to get a job done (in all fairness as they are suposed to do)
and the
> compiler has a field day generating code. Sometimes a programmer needs
to
> modify the interface to a class. This can suddenly impact on everyone
elses
> existing use of the class (e.g. making a method virtual).
>
> Consider in C
>
> float j;
> int arr[100];
>
> for (j=0; j<10; j+=1)
> { arr[j] = j+1;
> }
>
> You can immediatly see all the needless coersion that is going on
between
> float and int
>
> In C++, using complex objects, things are not so obvious.
If it is not obvious then it is the case of bad decisions on design.
Perhaps there is no need for classes in the case and you should choose
another supported programming paradigm.
Tony Finch
>
> I wished he'd been a lot less modest, for one thing this silly
> '> >' notation (mind the space here) wouldn't have been such a
> lexical issue of debate. Lack of verbosity killed the cat here.
Using angle brackets for templates without considering the clash with
the shifting operators was one of the most braindead decisions in the
history of programming language design.
Tony.
--
f.anthony.n.finch <d...@dotat.at>
THAMES DOVER WIGHT PORTLAND PLYMOUTH: VARIABLE 3 BECOMING NORTHEASTERLY 4 OR
5. OCCASIONAL RAIN. GOOD BECOMING MODERATE.
CBFalconer
>
> In C++, using complex objects, things are not so obvious.
Why is this inane thread cluttering four newsgroups. PLONKED in
c.a.e.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
Al Dunbar
"Minti" <mintiSP...@yahoo.com> wrote in message
news:e87fc4b0.02031...@posting.google.com...
I thought the thread was about execution speed. Note that a null program in
VBSCRIPT would be:
a=0
which I think I could type even faster. Does this prove that VBSCRIPT is
four times as fast as C/C++ - I think not.
/Al
Nick Keighley
> "Sergio Masci" <ser...@NO.SPAM.xcprod.com> wrote in message
> news:7Q2j8.25200$yc2.2...@news2-win.server.ntlworld.com...
<snip argument about whether C is better than C++>
> Consider the code:
>
> #include <iostream>
> #include <string>
> #include <vector>
>
> int main()
> {
> using namespace std;
>
> vector<string>names(5);
>
>
> cout << "Enter "<< names.size() << " names: "<< endl;
>
> for (vector<string>::size_type i = 0; i <names.size(); i++)
> cin>>names[i];
>
> for (vector<string>::size_type i = 0; i <names.size(); i++)
> cout<<names[i]<<endl;
>
> }
I count 11 lines of source
> and it's C equivallent (without removing the '\n' from the string):
>
> #include <stdio.h>
> #include <stddef.h>
>
> int main(void)
> {
> char names[5][100];
> size_t i;
>
> puts("Enter 5 names: ");
>
> for(i=0; i<5; i++)
> fgets(names[i], 100, stdin);
>
> for(i=0; i<5; i++)
> printf("%s", names[i]);
>
> return 0;
> }
I count 11 lines of source
> The second has more code in it,
no it doesn't
<snip>
--
Nick Keighley
This is not the same as a proof of correctness,
but proofs of correctness can only be constructed by computer
scientists with fancy degrees, not by mere clever programmers.
Ben Pfaff
Nick Keighley
I havn't got K&R handy but neither X3.159 nor Harbison & Steele do it as
above.
> and how does it aid code generation?
--
Nick Keighley
Jos A. Horsmeier
Code generation for a for loop is a jumpy business, especially for
compilers that generate code on the fly (while parsing the input), e.g.
the code fragment for ( <init> ; <cond> ; <inc> ) <stat> compiles to
something like:
<init>
lab1: <cond>
btrue lab3
jump lab4
lab2: <inc>
jump lab1
lab3: <stat>
jump lab2
lab4:
If, say, the first syntactical rule can be reduced by the parser, a simple:
lab1: <stat>
jump lab1
could have been generated by the code generator. This optimization is
completely controled by the syntax of the language, no post-code-generation
optimization need to be performed here. The other grammar rule alternatives
offer similar 'syntax directed' code optimizations.
BTW, these 8 rules were listed in K&R1 if memory serves me right.
kind regards,
Jos aka j...@gen.nl
ps. the 8th rule (see above) is wrong of course; it should've read:
for ( <expression> ; <expression> ; <expression> ) statement
Tim Sinkins
Ioannis Vranos wrote:
>
> "Sergio Masci" <ser...@NO.SPAM.xcprod.com> wrote in message
> news:Zmcj8.29192$y76.3...@news6-win.server.ntlworld.com...
> >
> > Ioannis Vranos <noi...@yahoo.com> wrote in message
> > news:10158672...@athprx02.forthnet.gr...
> > > "Sergio Masci" <ser...@NO.SPAM.xcprod.com> wrote in message
> > > news:7Q2j8.25200$yc2.2...@news2-win.server.ntlworld.com...
> > > >
> > > >
> > > > In general yes, C++ programs are slower than the equivalent C
> > > programs.
> > >
> > > That is a myth.
> > >
> >
> > No fact. As a Systems Consultant working for many big companies and
> > organisations (for many years now) I have observed this to be the
> case.
>
> Then either you code C++ in bad style ir you have been using bad
> implementations.
No, it's all to do with the fact that most development is done by teams.
Whilst it may (easily) be possible for one individual who fully
understands the whole system to code C++ with the single aim of making
it as run-time efficient as possible this requirement goes out of the
window when the 'real' project requirement [1] of making the code as
understandable to the project novice (i.e. someone with little knowledge
of the application in hand, not the language) as possible. IME these
two 'requirements' are mutually exclusive in any language and, whilst
I have no personal experiences, I would guess that it is worse in C++
than others.
[1] If run-time efficiency was a 'real' project requirement, all work
would be done in assembler, that fact that it isn't proves that run-
time efficiency is never an overriding factor on commercial projects
whatever anyone claims.
Tim
CBFalconer
>
> Sergio Masci wrote:
> >
> > Ioannis Vranos <noi...@yahoo.com> wrote in message
> > > >
> ... snip ...
> >
> > In C++, using complex objects, things are not so obvious.
>
> Why is this inane thread cluttering four newsgroups. PLONKED in
> c.a.e.
And in c.l.c.
CBFalconer
>
> CBFalconer wrote:
> >
> > Sergio Masci wrote:
> > >
> > > Ioannis Vranos <noi...@yahoo.com> wrote in message
> > > > >
> > ... snip ...
> > >
> > > In C++, using complex objects, things are not so obvious.
> >
> > Why is this inane thread cluttering four newsgroups. PLONKED in
> > c.a.e.
>
> And in c.l.c.
This is getting tiresome. Stomp it out one place and it pops up
in the next. Now PLONKED in comp.programming.
Ioannis Vranos
news:3C8DCCFC...@alcatel-ke.de...
> >
> > Then either you code C++ in bad style ir you have been using bad
> > implementations.
>
> No, it's all to do with the fact that most development is done by
teams.
> Whilst it may (easily) be possible for one individual who fully
> understands the whole system to code C++ with the single aim of making
> it as run-time efficient as possible this requirement goes out of the
> window when the 'real' project requirement [1] of making the code as
> understandable to the project novice (i.e. someone with little
knowledge
> of the application in hand, not the language) as possible. IME these
> two 'requirements' are mutually exclusive in any language and, whilst
> I have no personal experiences, I would guess that it is worse in C++
> than others.
Portable code efficiency has nothing to do with the knowledge of an
application as a whole. But if you code in C++ like:
class something
{
int *p;
public:
something(unsigned n) { p=malloc(sizeof(n)); memset(p, 0, n); }
void increase(unsigned n) { p=realloc(p, sizeof(n)); }
// ...
};
instead of
claass something
{
vector<int>p;
public:
something(const vector<int>::size_type &n) { p(n); }
void increase(const vector<int>::size_type &n) { p.reserve(n); }
// ...
};
then it is bad style C++ coding, not problem of the language. If C++
code is written in the proper way it is far more understood than C style
mess and in many cases faster. This given that the man who reads the
code knows C++ (really, not "i know how to write classes etc" only).
>
> [1] If run-time efficiency was a 'real' project requirement, all work
> would be done in assembler, that fact that it isn't proves that run-
> time efficiency is never an overriding factor on commercial projects
> whatever anyone claims.
No that fact proves that portability/understanding/easier debugging
provided by high level constructs is the first priority and speed is the
second.
Ioannis Vranos
news:8ad2cfb3.02031...@posting.google.com...
>
> I count 11 lines of source
>
> > The second has more code in it,
>
> no it doesn't
Ok about code length about the particular example but all the others
(bullet-proof code, extensibility and easier updating) are true.
Adam Petersen
"Ioannis Vranos" <noi...@yahoo.com> wrote
>
> claass something
> {
> vector<int>p;
> public:
> something(const vector<int>::size_type &n) { p(n); }
> void increase(const vector<int>::size_type &n) { p.reserve(n); }
> // ...
> };
This must mean the end to this (useless) discussion, because this
code is actually the fastest I have seen in this thread:
It does not even have an execution time, due to the fact that it does not
even compile:-))).
/Adam
Tim Sinkins
Ioannis Vranos wrote:
>
> "Tim Sinkins" <timothy...@alcatel-ke.de> wrote in message
> news:3C8DCCFC...@alcatel-ke.de...
> > >
> > > Then either you code C++ in bad style ir you have been using bad
> > > implementations.
> >
>
> class something
> {
> int *p;
> public:
> something(unsigned n) { p=malloc(sizeof(n)); memset(p, 0, n); }
> void increase(unsigned n) { p=realloc(p, sizeof(n)); }
> // ...
> };
>
> instead of
>
> claass something
> {
> vector<int>p;
> public:
> something(const vector<int>::size_type &n) { p(n); }
> void increase(const vector<int>::size_type &n) { p.reserve(n); }
> // ...
> };
>
> then it is bad style C++ coding, not problem of the language. If C++
> code is written in the proper way it is far more understood than C style
> mess and in many cases faster. This given that the man who reads the
> code knows C++ (really, not "i know how to write classes etc" only).
I'm afraid I have no interest in specific code samples, I have no idea
why one is better than the other nor which runs faster. What I do know
is that by attempting to make your code more efficient for a specific
problem you lose something.
I work in telecommes and write real-time embedded code (it wasn't me who
copied this to cae but now it's here I see no reason why it is OT enough
to justify not continuing with it). In what I do, word size is a
critical
factor as is the processor endien-ness. If I try and write code that is
run-time efficient for a specific word size and endienness it will (a)
be less understandable to the next person who comes along and tries
to read it, (b) not work on a different processor.
If I write a generic solution this will almost certainly not use the
language's most efficient syntax. Try this in C++ and see what you get
> > [1] If run-time efficiency was a 'real' project requirement, all work
> > would be done in assembler, that fact that it isn't proves that run-
> > time efficiency is never an overriding factor on commercial projects
> > whatever anyone claims.
>
> No that fact proves that portability/understanding/easier debugging
> provided by high level constructs is the first priority and speed is the
> second.
No, run-time speed is about number 17 on ths list. It is an
insigificant
consideration in the real world.
Tim
Ioannis Vranos
news:a6kv6e$alj$1...@newstoo.ericsson.se...
>
>
> This must mean the end to this (useless) discussion, because this
> code is actually the fastest I have seen in this thread:
> It does not even have an execution time, due to the fact that it does
not
> even compile:-))).
Yes, here is the correct sample (i thought you could understand it):
class something
{
vector<int>p;
public:
something(const vector<int>::size_type &n) { p[n]; }
void increase(const vector<int>::size_type &n) { p.reserve(n); }
// ...
};
Ioannis Vranos
> "Adam Petersen" <adam.p...@sea.ericsson.se> wrote in message
> news:a6kv6e$alj$1...@newstoo.ericsson.se...
> >
> >
> > This must mean the end to this (useless) discussion, because this
> > code is actually the fastest I have seen in this thread:
> > It does not even have an execution time, due to the fact that it
does
> not
> > even compile:-))).
>
> Yes, here is the correct sample (i thought you could understand it):
>
> class something
> {
> vector<int>p;
> public:
> something(const vector<int>::size_type &n) { p[n]; }
> void increase(const vector<int>::size_type &n) { p.reserve(n); }
> // ...
> };
>
Damn! Here is the correct one:
class something
{
vector<int>p;
public:
something(const vector<int>::size_type &n):p(n) { }
Richard Heathfield
> "Sergio Masci" <ser...@NO.SPAM.xcprod.com> wrote...
> > Ioannis Vranos <noi...@yahoo.com> wrote...
> > > "Sergio Masci" <ser...@NO.SPAM.xcprod.com> wrote...
> > > >
> > > > In general yes, C++ programs are slower than the equivalent C
> > > programs.
> > >
> > > That is a myth.
> > >
> >
> > No fact. As a Systems Consultant working for many big companies and
> > organisations (for many years now) I have observed this to be the
> case.
>
> Then either you code C++ in bad style ir you have been using bad
> implementations.
Or, just *maybe*, he's been using C++ for something a tad bigger than
"hello world".
> Also keep in mind that the official C++ standard was
> ratified in 1998.
Right. And?
>
> > I have been using C++ for over 10 years now.
>
> I would prefer an example.
Here's the problem. C++ performance problems tend to manifest themselves
in large projects with many programmers working on them. Nobody with any
sense would post a realistic example to Usenet, because it would be an
abuse of bandwidth.
> > > > take longer to write a C++ program the presure is to finish the
> > > project not
> > > > optimise it for speed.
> > >
> > > This is a myth too. It takes shorter time.
> > >
> >
> > I stand by my original statement based on extensive experience and
> > observation of large systems written and maintained in both C and C++
>
> What exactly is "slower"?
The heavy modularisation typical of a large C++ project has a
performance cost. It can also have organisational benefits, of course,
and the trade-off is an important one.
>
> > Ah yes templates. Maybe you should have a look at the STL (standard
> template
> > library) source. It is full of special cases (wrapped in conditional
> compile
> > statements -- #if / #else / #endif) trying to cope with
> incompatibilites
> > between different platforms (compilers and OS'). So compile and test
> your
> > code on one platform then pray it works the same on all the others.
>
> Not now that there is the official ANSI C++ 1998 standard. The code i
> posted above is guaranteed to work in any C++ conforming compiler.
Note, however, that there are precious few of those around. For example,
the Spirit parser library is written in ISO C++ - and yet neither Visual
C++ 6 nor VS.NET can compile it, because it uses partial template
specialisation (see ISO/IEC 14882:1998 [14.5.4] for details), and
Microsoft has not, apparently, seen fit to support this part of the
Standard. Bye-bye code re-use, hello write-a-new-one.
> > Just because one statement in C++ looks cleaner and simpler than the
> > equivalent block of statements in C does not mean that it runs faster.
> > Sometimes the price for such clarity is a mountaine of compiler
> generated
> > machine code. Writing the code by hand in C emphasises the problem and
> the
> > programmer is forced to deal with it (e.g. rewrite it).
(Right.)
>
> When you use the C++ standard library the code that gets generated is
> usually smaller than our low level C-style code in functions that get
> variables and manipulate their bits.
On what percentage of platforms is this true?
<text re-flowed a bit>
> > C++ does sometimes do a lot of unexpected things behind the
> > scenes. e.g. coersing objects between types in an unexpected
> > and expensive manor. On large projects where each member of
> > a team has a reasonable but not excelent understanding of
> > the classes in the system, programmers use objects as black
> > boxes to get a job done (in all fairness as they are suposed to
> > do) and the compiler has a field day generating code. Sometimes
> > a programmer needs to modify the interface to a class. This can
> > suddenly impact on everyone elses existing use of the class
> > (e.g. making a method virtual).
> >
> > Consider in C
> >
> > float j;
> > int arr[100];
> >
> > for (j=0; j<10; j+=1)
> > { arr[j] = j+1;
> > }
> >
> > You can immediatly see all the needless coersion that is going on
> between
> > float and int
> >
> > In C++, using complex objects, things are not so obvious.
>
> If it is not obvious then it is the case of bad decisions on design.
Quite so. And that's why it's risky to opt for the willy-nilly use of
templates without considering the consequences of that choice.
> Perhaps there is no need for classes in the case and you should choose
> another supported programming paradigm.
Let's not throw the baby out with the bathwater. There is a place for
templates. There is a place for classes. There is a place, in fact, for
C++. But the reality is that there is no silver bullet. You can't have
everything for nothing and the moon on a stick. If you want the benefits
of modularisation that C++ brings to large projects, then you have to
face the performance issues, and set your trade-off point appropriately.
For example, consider a class for modelling a chair. Do we make the
chair inherit from a "physical_object" class, because a chair "is-a"
physical_object? Do we insist that we get the chair's location by asking
the "physical_object" class for that information? Or can we bite the
bullet, store the location information in the chair class, and get rid
of the "physical_object" class altogether, thus reducing the number of
interfaces by one?
Both ways make sense. Which one you choose depends on how complex a
universe you need to model. And the more complex your object model, the
bigger the cumulative performance hit is going to be. This tends to be
more noticeable on large projects. Choosing whether to inherit a chair
from a physical_object isn't going to make much more than a ha'penny of
difference to the end performance - but when you add layer after layer
after layer after layer of interface and hierarchy, at some point it
starts to matter.
The C++ project I'm currently working on only has a few thousand lines
at present, and very few interfaces between classes. Very few classes,
in fact. (I just counted them - a couple of dozen.) It makes heavy use
of templates. Performance is acceptable at present. I suspect that I
could get slightly better performance by ripping out some of the
templates and replacing them with custom void *-based data structures.
At present, however, the performance isn't slack enough to justify it.
My belief is that, if we manage to keep the class hierarchy as simple as
it currently is, the performance will remain acceptable, and the
templates will therefore probably be allowed to stay.
>From a comparative performance point of view, the only way I can really
find out whether a C version would be faster is to /write/ a C version.
Clearly, my client is not going to be overly happy to foot the bill for
two programs when he only asked for one. Significant performance
differences are only likely to be encountered in large projects, and
nobody is going to implement the same design of the same large
(expensive) project twice just to settle a Usenet dispute.
So - which is faster, C or C++? The only meaningful answer - for program
sizes where the difference is enough to matter - must be "nobody knows".
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Minti
Thank you.. It was about the execution speed however.
Bart Kowalski
news:a6j35i$66d$1...@cascade.cs.ubc.ca...
>
> Since C++ is such a complex language (185 EBNF rules vs. C's 130 EBNF
> rules), C++ compiler writers generally don't have as much time left
> over to work on optimizations verses typical C compiler writers.
>
> guess that equivalent C++ code runs about 1% - 5% slower in many cases.
What kind of silly distorted logic is that? There is no correspondence
between grammar complexity and code optimization. In fact, C and C++
compilers generate intermediate code representations that can be
optimized by the *same* optimizer.
If you're going to troll at least find better arguments.
Bart.
Dan Pop
>"Ben Pfaff" <b...@cs.stanford.edu> wrote in message
>news:87u1rmo...@pfaff.stanford.edu...
>> "Jos A. Horsmeier" <j.a.ho...@wanadoo.nl> writes:
>>
>> > OTOH adding more grammar rules helps the compiler (or any translator)
>> > optimizing whatever it has to optimze. Recall the funky 'for' statement
>> > syntax, present since K&R1:
>> >
>> > for_statement:
>> > for ( ; ; ) statement
>> > for ( expression ; ; ) statement
>> > for ( ; expresssion ; ) statement
>> > for ( expression ; expression ; ) statement
>> > for ( ; ; expression) statement
>> > for ( expression ; ; expression ) statement
>> > for ( ; expresssion ; expression) statement
>> > for ( expression ; ; expression) statement
>> >
>> > *eight* syntax rules, where just *one* simple rule could've done the
>> > job of syntax description. But these eight rules were a compiler aid for
>> > (code generation) jump optimization.
>>
>> Where have you seen the for statement expressed this way, and how
>> does it aid code generation?
>
>BTW, these 8 rules were listed in K&R1 if memory serves me right.
It doesn't. Being a master of conciseness, Ritchie preferred to merge
them into a single rule:
for ( expression-1 ; expression-2 ; expression-3 ) statement
opt opt opt
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Minti
> Languages aren't fast or slow. Code is. How fast or slow code is depends
> not only which language it was written in, but also on:
> - What the code actually does
> - Which platform the code was written on
> - Which tools the code was compiled with (or is being interpreted with)
> - How efficient the hardware running the code is
> and possibly other aspects as well.
And I agree to this rather than a one sided opinion. Also what about
Priorities the priority of the program can be increased to bring in
faster execution.
Ioannis Vranos
news:3C8DDB18...@eton.powernet.co.uk...
> >
> > Then either you code C++ in bad style ir you have been using bad
> > implementations.
>
> Or, just *maybe*, he's been using C++ for something a tad bigger than
> "hello world".
:) Well this is your word against mine.
> Here's the problem. C++ performance problems tend to manifest
themselves
> in large projects with many programmers working on them. Nobody with
any
> sense would post a realistic example to Usenet, because it would be an
> abuse of bandwidth.
In the contrary i can post you a realistic example on how C sorting code
using qsort() is slower than equivalent C++ code and code in the C-style
that uses the C++'s sort() routine and has the same speed with its
equivallent C++ code (C code cannot be faster than equivallent C++ in
any scenario).
> > What exactly is "slower"?
>
> The heavy modularisation typical of a large C++ project has a
> performance cost. It can also have organisational benefits, of course,
> and the trade-off is an important one.
With modularisation you mean OO programming?
> > Not now that there is the official ANSI C++ 1998 standard. The code
i
> > posted above is guaranteed to work in any C++ conforming compiler.
>
> Note, however, that there are precious few of those around. For
example,
> the Spirit parser library is written in ISO C++ - and yet neither
Visual
> C++ 6 nor VS.NET can compile it, because it uses partial template
> specialisation (see ISO/IEC 14882:1998 [14.5.4] for details), and
> Microsoft has not, apparently, seen fit to support this part of the
> Standard. Bye-bye code re-use, hello write-a-new-one.
Now i never expected you to use as an example broken ms software. :)
Anyway i consider MINGW32 and BC++ Builder better than MS. ANSI C++ is
more widely implemented than C99 anyway. But i do not compare languages,
i just do not accept the argument that C code is "faster" than C++.
> > When you use the C++ standard library the code that gets generated
is
> > usually smaller than our low level C-style code in functions that
get
> > variables and manipulate their bits.
>
> On what percentage of platforms is this true?
In most of them who are ANSI C++ compliant. But the proper use plays as
always an important role. For example since i recall that we had
discussed a similar matter, when you want to make a function accepting
every type and you are space concerned, you do not define it as
accepting void * and use casting 1 million times in the places you call
the function, but instead you define a (thin) template interface. For
example:
// The baby
void *inc(void *p)
{
// ...
return p;
}
// Our type safe interface
template <class T>
inline T *inc(T *p)
{
return static_cast<T *>(inc(p));
}
int main()
{
int x=1;
int *p=inc(&x);
// ...
}
In this way you do not lose space and you preserve the type-safety. The
equivalent (messy) C code cannot be any faster.
> > If it is not obvious then it is the case of bad decisions on design.
>
> Quite so. And that's why it's risky to opt for the willy-nilly use of
> templates without considering the consequences of that choice.
See above.
>
> > Perhaps there is no need for classes in the case and you should
choose
> > another supported programming paradigm.
>
> Let's not throw the baby out with the bathwater. There is a place for
> templates. There is a place for classes. There is a place, in fact,
for
> C++. But the reality is that there is no silver bullet. You can't have
> everything for nothing and the moon on a stick. If you want the
benefits
> of modularisation that C++ brings to large projects, then you have to
> face the performance issues, and set your trade-off point
appropriately.
I agree that there is no perfect language. But i consider C++ better
than C99 (but i love C89).
> For example, consider a class for modelling a chair. Do we make the
> chair inherit from a "physical_object" class, because a chair "is-a"
> physical_object? Do we insist that we get the chair's location by
asking
> the "physical_object" class for that information? Or can we bite the
> bullet, store the location information in the chair class, and get rid
> of the "physical_object" class altogether, thus reducing the number of
> interfaces by one?
You should use polymorphism (abstract interface). With virtual member
functions you do not lose more space than store-keeping the information
yourself. In fact usually your method wastes more space so it is a bad
design decision in terms of space concerns (this doesn't mean however
that i act the smart guy since you are programming for years and me for
merely 2 years and i *totally* respect you recognising my previous
b***sh*t behavior of mine 2 years ago).
> Both ways make sense. Which one you choose depends on how complex a
> universe you need to model. And the more complex your object model,
the
> bigger the cumulative performance hit is going to be. This tends to be
> more noticeable on large projects. Choosing whether to inherit a chair
> from a physical_object isn't going to make much more than a ha'penny
of
> difference to the end performance - but when you add layer after layer
> after layer after layer of interface and hierarchy, at some point it
> starts to matter.
No if you code in the right way in C++.
> The C++ project I'm currently working on only has a few thousand lines
> at present, and very few interfaces between classes. Very few classes,
> in fact. (I just counted them - a couple of dozen.) It makes heavy use
> of templates. Performance is acceptable at present. I suspect that I
> could get slightly better performance by ripping out some of the
> templates and replacing them with custom void *-based data structures.
void * again. See my above paragraph concerning void *. The answer
probably is thin template interfaces.
> At present, however, the performance isn't slack enough to justify it.
> My belief is that, if we manage to keep the class hierarchy as simple
as
> it currently is, the performance will remain acceptable, and the
> templates will therefore probably be allowed to stay.
:)) I do not code much OO myself, only when i feel it "natural".
>
> >From a comparative performance point of view, the only way I can
really
> find out whether a C version would be faster is to /write/ a C
version.
> Clearly, my client is not going to be overly happy to foot the bill
for
> two programs when he only asked for one. Significant performance
> differences are only likely to be encountered in large projects, and
> nobody is going to implement the same design of the same large
> (expensive) project twice just to settle a Usenet dispute.
My strong belief is that on large scale programs *C* code is slower than
C++.
> So - which is faster, C or C++? The only meaningful answer - for
program
> sizes where the difference is enough to matter - must be "nobody
knows".
I believe (in contrary of what many think) that C++ is faster.
Donald Gillies
>Bart.
C++ is the language with ambiguities that are turing-undecideable.
The same is not true about the C programming language. The gcc
compiler is not the only compiler on earth. Just because gcc uses the
same optimizer for both C and C++, doesn't mean that there aren't some
optimizations appropriate for C that would not work for C++. A C++
compiler is more than twice as large (in source code) as a C compiler.
If you have not learned that software quality is inversely
proportional to software system size, then you haven't learned much in
your professional career.
Don Gillies - dgil...@graviton.com - Network Architect, Graviton, Inc.
EE Faculty, University of British Columbia, Vancouver, B.C. V6T 1Z4,
http://www.ece.ubc.ca/~gillies
Minti
> "Keith Brafford" <kbra...@nc.rr.com> writes:
>
.
>
> Since C++ is such a complex language (185 EBNF rules vs. C's 130 EBNF
> rules), C++ compiler writers generally don't have as much time left
> over to work on optimizations verses typical C compiler writers.
What is this EBNF? I could only find something like Extended Backus
Normal form. But, is || "how is" it linked here?.
Ioannis Vranos
> "Richard Heathfield" <bin...@eton.powernet.co.uk> wrote in message
> news:3C8DDB18...@eton.powernet.co.uk...
Some additions...
> > The C++ project I'm currently working on only has a few thousand
lines
> > at present, and very few interfaces between classes. Very few
classes,
> > in fact. (I just counted them - a couple of dozen.) It makes heavy
use
> > of templates. Performance is acceptable at present. I suspect that I
> > could get slightly better performance by ripping out some of the
> > templates and replacing them with custom void *-based data
structures.
>
>
> void * again. See my above paragraph concerning void *. The answer
> probably is thin template interfaces.
If you are not space concerned you will not gain any speed benefit if
you replace templates with void *s. The function:
template <class T>
T *something(T *p)
{
...
}
is not slower than
void *something(void *)
You preserve only space. If you are space concerned however you can use
a thin template interface above one such function to maintain
type-safety and to save space.
>
>
> > At present, however, the performance isn't slack enough to justify
it.
> > My belief is that, if we manage to keep the class hierarchy as
simple
> as
> > it currently is, the performance will remain acceptable, and the
> > templates will therefore probably be allowed to stay.
>
> :)) I do not code much OO myself, only when i feel it "natural".
If you refer to abstract interfaces (virtual member functions), the cost
of the function call is the same regardless the depth of the
abstraction!
For example:
class graph
{
public:
virtual void something() const=0;
virtual ~graph {}
};
class graph_a: public graph
{
// ...
public:
void something() { // ...}
};
...
class graph_z: public graph_y
{
// ...
public:
void something() { // ... }
};
int main()
{
graph_z gz;
graph_a ga;
graph *gp=&gz;
gp->something();
gp=&ga;
// The function call has the same time cost
// as in the case of graph_a::something().
// It is independent of the abstraction depth
gp->something();
So in this case you do not gain anything in time from restricting the
hierarchy to few classes only.
Ben Pfaff
Rules in a syntax similar to EBNF define the syntax of C and C++.
--
"IMO, Perl is an excellent language to break your teeth on"
--Micah Cowan
Bart Kowalski
>
> C++ is the language with ambiguities that are turing-undecideable.
> The same is not true about the C programming language. The gcc
> compiler is not the only compiler on earth. Just because gcc uses the
> same optimizer for both C and C++, doesn't mean that there aren't some
> optimizations appropriate for C that would not work for C++.
Well, somebody needs to learn how compilers work, and it sure ain't
me. First, of all, the part that handles the language grammar is the
parser, which has *utterly* nothing to do with code generation.
The parts of a compiler are:
Parser -> Checks the syntax, generates some tree representation
Semantic analyzer -> Checks the semantics using the parse tree
Code generator -> Generates intermediate code
Optimizer -> Optimizes the intermediate code and generates machine-
specific code
The additional complexities of the language are handled at the parser
and semantic analyzer level, well before the optimizer even looks at
the code. Also, the intermediate code that the optimizer looks at is
*language-independent*. It's even machine-independent. It's just a
sequential representation of the abstract operations of the machine;
like a hypothetical assembly language.
The optimizer looks at this intermediate code and follows more or less
these steps:
- Use dependency analysis to find basic blocks
- Reorganize things inside basic blocks
- Use data flow analysis to perform global optimizations
- Generate machine-dependent code
- Perform machine-specific code optimization
In this analysis there are no language-specific optimizations, because
there is no need for them. The analysis can be done much better by
using a sequence of abstract operations than using a parse tree.
And BTW, this is not just GCC. Modern commercial compilers *do* work
like this.
> A C++
> compiler is more than twice as large (in source code) as a C compiler.
I see that your basic logic skills are lacking. Scheme compilers are
100 smaller in source code (Scheme has something like 2 grammar
rules). Does that mean that Scheme code runs faster than anything
else?
> If you have not learned that software quality is inversely
> proportional to software system size, then you haven't learned much in
> your professional career.
The same could be said about breaking the system down into modules.
Bart.
Dave Mikesell
> optimizations appropriate for C that would not work for C++. A C++
> compiler is more than twice as large (in source code) as a C compiler.
>
> If you have not learned that software quality is inversely
> proportional to software system size, then you haven't learned much in
> your professional career.
That's suspicious logic. If two programs exhibit exactly the same
functionality but one has twice the source code, then you might have a
point. Otherwise, you're comparing apples and oranges.
Keith Brafford
> Code generation for a for loop is a jumpy business, especially for
> compilers that generate code on the fly (while parsing the input), e.g.
> the code fragment for ( <init> ; <cond> ; <inc> ) <stat> compiles to
> something like:
>
> <init>
> lab1: <cond>
> btrue lab3
> jump lab4
> lab2: <inc>
> jump lab1
> lab3: <stat>
> jump lab2
> lab4:
>
In the compilers I've written I've put the test (the <cond>) at the bottom:
<init>
jmp test
loop: <stat>
<inc>
test: <cond>
branch loop
That way, after the sunk cost of an initial branch, each loop
iteration only has one branch, as opposed to three in your case.
This works in on-the-fly cases, too.
--Keith Brafford
Andreas Klimas
are you sure ?
what when this program is the only one which consume CPU.
or what when this program runs in many instances (like
apache Webserver does).
this probably is the latest 'optimization' switch.
Andreas
Sergio Masci
Joona I Palaste <pal...@cc.helsinki.fi> wrote in message
news:a6j4eu$mo8$1...@oravannahka.helsinki.fi...
> Languages aren't fast or slow. Code is. How fast or slow code is depends
> not only which language it was written in, but also on:
> - What the code actually does
> - Which platform the code was written on
> - Which tools the code was compiled with (or is being interpreted with)
> - How efficient the hardware running the code is
> and possibly other aspects as well.
>
I beg to differ.
Depending on how well you can describe a problem in a language determines
how well the compiler can re-arrange the description to provide an optimal
execution path.
Consider the following simple example:
for (j=0; j<10; j++)
{
arr[j] = fred(k) + j;
}
if the compiler can determin that fred() has no side effects it can
re-arrange the above code to:
tmp_fred_result = fred(k);
for (j=0; j<10; j++)
{
arr[j] = tmp_fred_result + j;
}
Taking this a step further. Lanuages that understand more complex constructs
can have better optimising compilers.
Consider:
for (j=0; j<10; j++)
{
arr[j] = malloc(100);
sprintf(arr[j], "fred%d", j);
}
now a version of C that understands builtin dynamic strings
for (j=0; j<10; j++)
{
arr[j] = "fred" + string(j);
}
Can you see that an optimising compiler that understands this could generate
the equivalent as
buff = malloc((4+8)*10);
sptr = buff;
for (j=0; j<10; j++)
{
arr[j] = sptr;
sptr[0] = 'f';
sptr[1] = 'r';
sptr[2] = 'e';
sptr[3] = 'd';
sptr += sprintf(sptr+4, "%d", j) + 4 + 1;
}
Here the malloc overhead has been greatly reduced from 10 calls to only 1.
The flip side to this is that a language can obscure a complex operation
making it look simple and optimised.
Consider
int j, k;
j = k * 0.5;
A C compiler should firstly coerce k to a float, then multiply it by 0.5
then coerce the result back to an int before storing the value in j. (many
modern C compilers would optimise this directly into j = k>>1, but that it
completely besides the point what we need to consider here is hidden
coercion).
C++ is full of this behind the scenes coercion, but not just on basic types,
it does this on non-trivial objects as well. This can have a dramatic impact
on execution speed and often there is no indication in the source that it is
taking place.
As I stated in my original post, you can write C++ programs that will run
faster than their equivalents written in C BUT this requires a lot of
effort. In general
programs written in C++ execute slower than the equivalent programs written
in C.
Regards
Sergio Masci
http://www.xcprod.com
Bob Bell
> The same is not true about the C programming language. The gcc
> compiler is not the only compiler on earth. Just because gcc uses the
> same optimizer for both C and C++, doesn't mean that there aren't some
> optimizations appropriate for C that would not work for C++.
Name one.
On the other hand, I can think of lots of optimizations that are
appropriate for C++ that would not work for C, simply because those
optimizations apply to constructs that don't exist in C.
> A C++
> compiler is more than twice as large (in source code) as a C compiler.
What does that have to do with the speed of the compiled code?
Bob Bell
Andreas Klimas
agreed. this is the reason why I believe in human optimization.
a compiler probably could take such advantages only inside of one
function, or probably in one source file, but never will get a
glue about what the author was intendend to do. BTW the more
complex the compiler the more the chance to get hard to find
compiler errors.
so I like it to show peoples how to solve problems simple
and efficient, like you did :-)
the other problem you mentioned is the 'user illusion'. there
are many things hidden in C++ where nobody takes care of. a
programmer get the illusion to work with the interfaces (API,
STL whatever) instead of the real computer.
it's easy for a human to write
void foo(void) {
char *buffer = malloc(xx);
...
free(buffer);
}
but it's more simple for the computer to deal with
void foo(void) {
char buffer[xx];
}
or, to remove the usage of buffer simply by redesigning
the solution.
best wishes
Andreas
Tim Sinkins
Ioannis Vranos wrote:
>
> "Richard Heathfield" <bin...@eton.powernet.co.uk> wrote in message
> news:3C8DDB18...@eton.powernet.co.uk...
> > >
> In the contrary i can post you a realistic example on how C sorting code
> using qsort() is slower than equivalent C++ code and code in the C-style
> that uses the C++'s sort() routine and has the same speed with its
> equivallent C++ code (C code cannot be faster than equivallent C++ in
> any scenario).
How on earth can such a statement be true. Whether code for such an
example is faster or not depends upon how well the compiler optimises
the code. A library sort routine example is not a valid test, as any
HLL generic sort routine is likely to be much less efficient than a hand
crafted ASM one, taylored for the specific target considering such
things
as how many registers are free for the task, whether the ASM has a SWAP
function, how many instruction the processor caches, so that tight loop
becomes relatively efficient etc). A HLL routine cannot be written to
be efficient by taking account of things that exist on one processor but
don't on another and I defy any complier to get 100% optimisation for
this
particular function. You are looking at this issue with a blinkered
'small world' view.
> > > What exactly is "slower"?
> >
> > The heavy modularisation typical of a large C++ project has a
> > performance cost. It can also have organisational benefits, of course,
> > and the trade-off is an important one.
>
> With modularisation you mean OO programming?
No, it's the overhead associated with stacking variables everytime you
change context. A modular solution is always slower than a monolithic
one. I will guarentee you that I can make any program written in a
modular way significantly faster by removing *every* procedure call but
I wouldn't want to have to maintain it. Of course you can get the
compiler
to do this for you by 'inlining' functions. AIUI this feature is not in
the 'C' standard (but most compilers have it) so in this respect the
same
code written in C++ will be more efficient than the Standard C version
but this is not a language issue it is a compiler issue.
Tim
Richard Heathfield
>
<snip>
>
> If you are not space concerned you will not gain any speed benefit if
> you replace templates with void *s.
This is really an implementation issue, but the speed cost comes from
the fact that the template code is effectively duplicated for each new
parameterised type you use in your program, thus increasing the code
size and thus increasing the likely frequency with which the operating
system will have to swap out parts of your program so that it can fit
other parts into memory. This is a general cost of inlining, and applies
just as much to C as it does to C++. Consider this (horrible) macro:
#define is_odd(t, n) int n(t i) { return i % 2 == 1; }
is_odd(unsigned char, odduc)
is_odd(char, oddc)
is_odd(unsigned short, oddus)
is_odd(short, odds)
is_odd(unsigned int, oddui)
is_odd(int, oddi)
.
.
.
Not a terribly useful macro, as macros go, but I hope it illustrates the
point that code bloat is not limited to C++ - it's perfectly doable in C
too.
<snip>
Richard Heathfield
>
> "Richard Heathfield" <bin...@eton.powernet.co.uk> wrote in message
> news:3C8DDB18...@eton.powernet.co.uk...
> > >
> > > Then either you code C++ in bad style ir you have been using bad
> > > implementations.
> >
> > Or, just *maybe*, he's been using C++ for something a tad bigger than
> > "hello world".
>
> :) Well this is your word against mine.
No, it's his word against yours. I only said "maybe".
>
> > Here's the problem. C++ performance problems tend to manifest
> themselves
> > in large projects with many programmers working on them. Nobody with
> any
> > sense would post a realistic example to Usenet, because it would be an
> > abuse of bandwidth.
>
> In the contrary i can post you a realistic example on how C sorting code
> using qsort() is slower than equivalent C++ code and code in the C-style
> that uses the C++'s sort() routine and has the same speed with its
> equivallent C++ code (C code cannot be faster than equivallent C++ in
> any scenario).
You appear to have misunderstood on two levels. Firstly, not all C
programs sort using qsort(), and not all C++ programs sort using sort(),
and indeed neither all C programs nor all C++ programs necessarily do
any sorting whatsoever. Secondly, you say "C code cannot be faster than
equivallent [sic] C++ in any scenario", yet I can easily conjure up a
myriad cases when it can. I'm going to give you an example which, I
think, the clc and clc++ people will understand perfectly, although I
agree c.p and c.a.e might be a bit puzzled by it.
The Zog C++ compiler (which runs on the DeathStation 9000) inserts a
system call into the object code between every source-related machine
instruction. This system call simply sends the program to sleep for 1
second. Thus, all primitive operations take at least one effective CPU
second to execute. The performance of Zog C++ programs is *dire*. The
Zog C compiler *doesn't* do this. There is nothing in either ISO 9899 or
ISO 14882 to forbid this kind of implementation.
Conclusion: performance is not a language issue. It's an implementation
issue. I happen to think there are certain performance costs associated
with the high level of organisation typical of well-written large C++
projects. I can't prove it because to prove it would involve writing a
large (by which I mean somewhere in the 500KLOC area, although for
obvious reasons that's a somewhat nebulous number) application *twice*
in two different languages, IMHO a rather foolish investment in time and
money if the intent is simply to win a point on Usenet.
>
> > > What exactly is "slower"?
> >
> > The heavy modularisation typical of a large C++ project has a
> > performance cost. It can also have organisational benefits, of course,
> > and the trade-off is an important one.
>
> With modularisation you mean OO programming?
By "heavy modularisation" I mean OO programming, yes.
>
> > > Not now that there is the official ANSI C++ 1998 standard. The code
> i
> > > posted above is guaranteed to work in any C++ conforming compiler.
> >
> > Note, however, that there are precious few of those around. For
> example,
> > the Spirit parser library is written in ISO C++ - and yet neither
> Visual
> > C++ 6 nor VS.NET can compile it, because it uses partial template
> > specialisation (see ISO/IEC 14882:1998 [14.5.4] for details), and
> > Microsoft has not, apparently, seen fit to support this part of the
> > Standard. Bye-bye code re-use, hello write-a-new-one.
>
> Now i never expected you to use as an example broken ms software. :)
> Anyway i consider MINGW32 and BC++ Builder better than MS.
I don't know MINGW32. I agree that BCB is better, but of course in the
contract world the usual situation is to use the software the client
asks you to use. Picking and choosing is not a luxury for everybody.
> ANSI C++ is
> more widely implemented than C99 anyway.
Really? I only know of one conforming ANSI C++ implementation - Comeau
C++. I also know of only one conforming C99 implementation - Comeau C
(with Dinkumware libc). That seems to me to be a 50/50 split. What
conforming ANSI C++ implementation do you know about that I appear to
have missed?
> But i do not compare languages,
> i just do not accept the argument that C code is "faster" than C++.
<shrug> By not accepting the argument, you are comparing languages. By
accepting the argument, you are comparing languages. The only way to win
this game is not to play.
>
> > > When you use the C++ standard library the code that gets generated
> is
> > > usually smaller than our low level C-style code in functions that
> get
> > > variables and manipulate their bits.
> >
> > On what percentage of platforms is this true?
>
> In most of them who are ANSI C++ compliant.
You're not getting it. You made a specific claim, and I'd like you to
provide some actual hard evidence to support that claim. Please either
do that, or retract the claim, or re-badge it as an opinion.
> But the proper use plays as
> always an important role. For example since i recall that we had
> discussed a similar matter, when you want to make a function accepting
> every type and you are space concerned, you do not define it as
> accepting void * and use casting 1 million times in the places you call
> the function,
You appear to have forgotten that the casting of void * is rarely
necessary in C.
> but instead you define a (thin) template interface. For
> example:
>
> // The baby
> void *inc(void *p)
> {
> // ...
>
> return p;
> }
>
> // Our type safe interface
> template <class T>
> inline T *inc(T *p)
> {
> return static_cast<T *>(inc(p));
> }
>
> int main()
> {
> int x=1;
>
> int *p=inc(&x);
>
> // ...
>
> }
>
> In this way you do not lose space and you preserve the type-safety. The
> equivalent (messy) C code cannot be any faster.
Here's the equivalent C code:
void *inc(void *p)
{
return p;
}
int main(void)
{
int x = 1;
int *p = inc(&x);
return 0;
}
I think we must have different ideas of what is meant by the word
"messy".
>
> > > If it is not obvious then it is the case of bad decisions on design.
> >
> > Quite so. And that's why it's risky to opt for the willy-nilly use of
> > templates without considering the consequences of that choice.
>
> See above.
I'm not sure how your example illustrates your point. If anything, it
illustrates mine.
>
> >
> > > Perhaps there is no need for classes in the case and you should
> choose
> > > another supported programming paradigm.
> >
> > Let's not throw the baby out with the bathwater. There is a place for
> > templates. There is a place for classes. There is a place, in fact,
> for
> > C++. But the reality is that there is no silver bullet. You can't have
> > everything for nothing and the moon on a stick. If you want the
> benefits
> > of modularisation that C++ brings to large projects, then you have to
> > face the performance issues, and set your trade-off point
> appropriately.
>
> I agree that there is no perfect language. But i consider C++ better
> than C99 (but i love C89).
I prefer C90, but I know what you mean. :-)
>
> > For example, consider a class for modelling a chair. Do we make the
> > chair inherit from a "physical_object" class, because a chair "is-a"
> > physical_object? Do we insist that we get the chair's location by
> asking
> > the "physical_object" class for that information? Or can we bite the
> > bullet, store the location information in the chair class, and get rid
> > of the "physical_object" class altogether, thus reducing the number of
> > interfaces by one?
>
> You should use polymorphism (abstract interface). With virtual member
> functions you do not lose more space than store-keeping the information
> yourself. In fact usually your method wastes more space so it is a bad
> design decision in terms of space concerns (this doesn't mean however
> that i act the smart guy since you are programming for years and me for
> merely 2 years and i *totally* respect you recognising my previous
> b***sh*t behavior of mine 2 years ago).
Whether it's a bad design decision in terms of space concerns depends on
how general the base class is. If it's *too* general and only a small
amount of it is actually useful to the derived class, the overhead of
using it may outweigh the abstraction benefits. This sort of problem
tends to rear its head only in larger projects, though.
>
> > Both ways make sense. Which one you choose depends on how complex a
> > universe you need to model. And the more complex your object model,
> the
> > bigger the cumulative performance hit is going to be. This tends to be
> > more noticeable on large projects. Choosing whether to inherit a chair
> > from a physical_object isn't going to make much more than a ha'penny
> of
> > difference to the end performance - but when you add layer after layer
> > after layer after layer of interface and hierarchy, at some point it
> > starts to matter.
>
> No if you code in the right way in C++.
Well, nobody deliberately sets out to code in the /wrong/ way, do they?
(Except in IOC++CC, if there is such a thing. I hope so, since it would
clearly be insane fun.) I'm talking about the real world of large
projects, big but insufficient budgets, grand but inadequate timescales,
and a mixed bunch of programming ability levels.
>
> > The C++ project I'm currently working on only has a few thousand lines
> > at present, and very few interfaces between classes. Very few classes,
> > in fact. (I just counted them - a couple of dozen.) It makes heavy use
> > of templates. Performance is acceptable at present. I suspect that I
> > could get slightly better performance by ripping out some of the
> > templates and replacing them with custom void *-based data structures.
>
> void * again. See my above paragraph concerning void *.
The one where you showed that the necessary C++ code is more complicated
than the C code?
> The answer
> probably is thin template interfaces.
Actually, the answer probably isn't thin template interfaces at all. The
most likely answer is that I won't need to do anything special at all.
If I do, though, I won't replace templates with templates.
<snip>
> >
> > >From a comparative performance point of view, the only way I can
> really
> > find out whether a C version would be faster is to /write/ a C
> version.
> > Clearly, my client is not going to be overly happy to foot the bill
> for
> > two programs when he only asked for one. Significant performance
> > differences are only likely to be encountered in large projects, and
> > nobody is going to implement the same design of the same large
> > (expensive) project twice just to settle a Usenet dispute.
>
> My strong belief is that on large scale programs *C* code is slower than
> C++.
Please write a carefully crafted, well-designed, 500,000 line C program
to do something time-critical. Then write the same application, using
the same algorithms, in C++. Then profile them and publish the results
(and the source code) on your Web site. Then, maybe, you'll have some
hard data to support your belief.
>
> > So - which is faster, C or C++? The only meaningful answer - for
> program
> > sizes where the difference is enough to matter - must be "nobody
> knows".
>
> I believe (in contrary of what many think) that C++ is faster.
And I believe that belief is all you /can/ have, if you don't have the
evidence.
Ioannis Vranos
:)) That is a theoretical experiment.
> Conclusion: performance is not a language issue. It's an
implementation
> issue. I happen to think there are certain performance costs
associated
> with the high level of organisation typical of well-written large C++
> projects. I can't prove it because to prove it would involve writing a
> large (by which I mean somewhere in the 500KLOC area, although for
> obvious reasons that's a somewhat nebulous number) application *twice*
> in two different languages, IMHO a rather foolish investment in time
and
> money if the intent is simply to win a point on Usenet.
> >
> >
> > Now i never expected you to use as an example broken ms software. :)
> > Anyway i consider MINGW32 and BC++ Builder better than MS.
>
> I don't know MINGW32. I agree that BCB is better, but of course in the
> contract world the usual situation is to use the software the client
> asks you to use. Picking and choosing is not a luxury for everybody.
MINGW32 is a GCC port for windows (supports win32 api).
Using broken implementations as an example is not any proof at all. If i
had to do with a person/company who want to use broken implementations
then i would adjust my code to work in the supported subset (or even in
broken standard mode as in case of VC++ 6). But this can't be an
argument.
> > ANSI C++ is
> > more widely implemented than C99 anyway.
>
> Really? I only know of one conforming ANSI C++ implementation - Comeau
> C++. I also know of only one conforming C99 implementation - Comeau C
> (with Dinkumware libc). That seems to me to be a 50/50 split. What
> conforming ANSI C++ implementation do you know about that I appear to
> have missed?
MINGW32/GCC & BC++ are compliant ANSI C++ in a very high degree. The
last is only for C. Anyway my main point is to not use as an example a
broken implementation!
> > > > When you use the C++ standard library the code that gets
generated
> > is
> > > > usually smaller than our low level C-style code in functions
that
> > get
> > > > variables and manipulate their bits.
> > >
> > > On what percentage of platforms is this true?
> >
> > In most of them who are ANSI C++ compliant.
>
> You're not getting it. You made a specific claim, and I'd like you to
> provide some actual hard evidence to support that claim. Please either
> do that, or retract the claim, or re-badge it as an opinion.
What i am saying is that a compiler which doesn't do this is a poor
implementation. Consider the example of std::string (which is typedef
basic_string<char> type).
When you write the code:
string s="Richard is the best\n";
cout<<s;
Then only the string::operator=(const char * const) and the
operator<<.(const string &) should get compiled thus having no more
space/time cost than the equivallent C code. The main rule is: "What you
do not use, you do not pay for" (i am still learning C++ and i do not
know what type cout belongs to, i guess ostream). Also the standard
library is written in such a way to be inlined, so you do not pay the
time cost of a function call so in most cases we have a performance gain
in comparison to our equivallent C code separated in functions. Also the
member functions are written in the most efficient way and is
faster/smaller than our C code (it can't be larger/slower). So another,
when we do std::cout<<"Hello World"; only the cout.operator<<(const char
*) should get compiled (in GCC this happens with version 3 and above i
think). In summary as the compilers get more ANSI C++ conformant things
are getting better (as is probably the case of BC++ 6 which i haven't
seen yet).
> > But the proper use plays as
> > always an important role. For example since i recall that we had
> > discussed a similar matter, when you want to make a function
accepting
> > every type and you are space concerned, you do not define it as
> > accepting void * and use casting 1 million times in the places you
call
> > the function,
>
> You appear to have forgotten that the casting of void * is rarely
> necessary in C.
Here i was talking about C-style C++.
Yes. C++ code is more bullet-proof, type-safe and does not lack in speed
(in many cases it is faster).
>
> >
> > > > If it is not obvious then it is the case of bad decisions on
design.
> > >
> > > Quite so. And that's why it's risky to opt for the willy-nilly use
of
> > > templates without considering the consequences of that choice.
> >
> > See above.
>
> I'm not sure how your example illustrates your point. If anything, it
> illustrates mine.
My example had the same time & space cost with your C equivallent and
templates had not any "consequence".
> > I agree that there is no perfect language. But i consider C++ better
> > than C99 (but i love C89).
>
> I prefer C90, but I know what you mean. :-)
Yes...
> > You should use polymorphism (abstract interface). With virtual
member
> > functions you do not lose more space than store-keeping the
information
> > yourself. In fact usually your method wastes more space so it is a
bad
> > design decision in terms of space concerns (this doesn't mean
however
> > that i act the smart guy since you are programming for years and me
for
> > merely 2 years and i *totally* respect you recognising my previous
> > b***sh*t behavior of mine 2 years ago).
>
> Whether it's a bad design decision in terms of space concerns depends
on
> how general the base class is. If it's *too* general and only a small
> amount of it is actually useful to the derived class, the overhead of
> using it may outweigh the abstraction benefits. This sort of problem
> tends to rear its head only in larger projects, though.
As i said the time overhead is the same independently of the abstraction
depth.
> > No if you code in the right way in C++.
>
> Well, nobody deliberately sets out to code in the /wrong/ way, do
they?
> (Except in IOC++CC, if there is such a thing. I hope so, since it
would
> clearly be insane fun.) I'm talking about the real world of large
> projects, big but insufficient budgets, grand but inadequate
timescales,
> and a mixed bunch of programming ability levels.
Yes. In real word i have seen bad C code but this doesn't prove that C
is inefficient. :)
> > void * again. See my above paragraph concerning void *.
>
> The one where you showed that the necessary C++ code is more
complicated
> than the C code?
:) I showed that templates aren't bad. They do not produce necessarily
bloated code. Their use can be.
>
> > The answer
> > probably is thin template interfaces.
>
> Actually, the answer probably isn't thin template interfaces at all.
The
> most likely answer is that I won't need to do anything special at all.
> If I do, though, I won't replace templates with templates.
As i said use the void 8 thing with a thin template interface if you are
*space* concerned only.
> > My strong belief is that on large scale programs *C* code is slower
than
> > C++.
>
> Please write a carefully crafted, well-designed, 500,000 line C
program
> to do something time-critical. Then write the same application, using
> the same algorithms, in C++. Then profile them and publish the results
> (and the source code) on your Web site. Then, maybe, you'll have some
> hard data to support your belief.
:) At least C++ code can not have larger space/time costs (it is assumed
that one knows what he is doing).
> And I believe that belief is all you /can/ have, if you don't have the
> evidence.
You too. :)
Ioannis Vranos
My main point is that C++ code can not be slower or larger than
equivallent C code in a decent ANSI C++ standard compliant compiler.
> Of course you can get the
> compiler
> to do this for you by 'inlining' functions. AIUI this feature is not
in
> the 'C' standard (but most compilers have it) so in this respect the
> same
> code written in C++ will be more efficient than the Standard C version
> but this is not a language issue it is a compiler issue.
Yes.
Tim Sinkins
Ioannis Vranos wrote:
>
> My main point is that C++ code can not be slower or larger than
> equivallent C code in a decent ANSI C++ standard compliant compiler.
Why not? If for example you write a solution in C++ that nests to
a depth of 17 but the C solution happens to nest to a depth of 16 the
C++ implementation will be slower because you'll have one extra context
save every iteration. It may, of course, be smaller. I defy you to
*prove* that the problem for which the above condition using optimal
solutions does not exist. This is what you have to do to prove your
assertion that the C++ answer can NEVER be slower.
> > Of course you can get the
> > compiler
> > to do this for you by 'inlining' functions. AIUI this feature is not
> in
> > the 'C' standard (but most compilers have it) so in this respect the
> > same
> > code written in C++ will be more efficient than the Standard C version
> > but this is not a language issue it is a compiler issue.
>
> Yes.
Yes what?
Tim
Richard Heathfield
>
> "Richard Heathfield" <bin...@eton.powernet.co.uk> wrote in message
> news:3C8F114D...@eton.powernet.co.uk...
> > >
> >
> > The Zog C++ compiler (which runs on the DeathStation 9000) inserts a
> > system call into the object code between every source-related machine
> > instruction. This system call simply sends the program to sleep for 1
> > second. Thus, all primitive operations take at least one effective CPU
> > second to execute. The performance of Zog C++ programs is *dire*. The
> > Zog C compiler *doesn't* do this. There is nothing in either ISO 9899
> > or ISO 14882 to forbid this kind of implementation.
>
> :)) That is a theoretical experiment.
Quite so. But then, any discussion of C++ has to be on the theoretical
level, unless you're using Comeau C++.
<snip>
> > >
> > > Now i never expected you to use as an example broken ms software. :)
> > > Anyway i consider MINGW32 and BC++ Builder better than MS.
> >
> > I don't know MINGW32. I agree that BCB is better, but of course in the
> > contract world the usual situation is to use the software the client
> > asks you to use. Picking and choosing is not a luxury for everybody.
>
> MINGW32 is a GCC port for windows (supports win32 api).
<shrug>
> Using broken implementations as an example is not any proof at all.
I don't think anyone is talking about proof here. But either we're
talking about the real world, or we're talking about the theoretical
world. In the theoretical world, BCB++ and MINGW32 are not conforming
C++ implementations. In the real world, they might be considered "good
enough", but then, in that same real world, we can't always choose our
compilers and we must consider the portability implications of certain
features which are not supported by compilers such as Microsoft's.
> If i
> had to do with a person/company who want to use broken implementations
> then i would adjust my code to work in the supported subset (or even in
> broken standard mode as in case of VC++ 6).
Right.
> But this can't be an argument.
I'm not sure what you mean here.
>
> > > ANSI C++ is
> > > more widely implemented than C99 anyway.
> >
> > Really? I only know of one conforming ANSI C++ implementation - Comeau
> > C++. I also know of only one conforming C99 implementation - Comeau C
> > (with Dinkumware libc). That seems to me to be a 50/50 split. What
> > conforming ANSI C++ implementation do you know about that I appear to
> > have missed?
>
> MINGW32/GCC & BC++ are compliant ANSI C++ in a very high degree.
Either they're conforming or they're not. Do they support partial
template specialisation, which MSVC and VS.NET apparently don't? Do they
support the export keyword?
> The
> last is only for C. Anyway my main point is to not use as an example a
> broken implementation!
But that's precisely what you've been doing throughout.
>
> > > > > When you use the C++ standard library the code that gets
> generated
> > > is
> > > > > usually smaller than our low level C-style code in functions
> that
> > > get
> > > > > variables and manipulate their bits.
> > > >
> > > > On what percentage of platforms is this true?
> > >
> > > In most of them who are ANSI C++ compliant.
> >
> > You're not getting it. You made a specific claim, and I'd like you to
> > provide some actual hard evidence to support that claim. Please either
> > do that, or retract the claim, or re-badge it as an opinion.
>
> What i am saying is that a compiler which doesn't do this is a poor
> implementation.
But that doesn't mean anything, particularly. If I've understood your
argument correctly, you appear to be saying that the code generation
phase of a C++ compiler is, a priori, more efficient than the code
generation phase of a C compiler. I don't see any evidence to support
this position.
> Consider the example of std::string (which is typedef
> basic_string<char> type).
>
> When you write the code:
>
> string s="Richard is the best\n";
>
> cout<<s;
>
> Then only the string::operator=(const char * const) and the
> operator<<.(const string &) should get compiled thus having no more
> space/time cost than the equivallent C code.
Okay, let's try this. I'll compare these two programs:
#include <iostream>
#include <string>
using std::cout;
using std::endl;
using std::string;
int main()
{
string s = "Richard is the best";
cout << s << endl;
return 0;
}
#include <stdio.h>
int main(void)
{
char s[] = "Richard is the best";
puts(s);
return 0;
}
I used bcc32 - the Borland C++ Builder command line compiler - to
compile and link both of them, without any switches for optimisation or
anything like that.
C program:
Object file: 585 bytes
Executable : 55296 bytes (ouch!)
C++ program:
Object file: 16135 bytes
Executable : 143360 bytes (ouch!!!)
(I think the object file is more critical to this discussion than the
executable, by the way.)
Okay, so maybe bcc32 is crap at compiling. I don't believe that, but
let's pretend. So I tried gcc.
C program:
Object file: 583 bytes
Executable : 18198 bytes
C++ program:
Object file: 20193 bytes
Executable : 211634 bytes
Hmmm - seems like both Borland and gcc produce smaller code for the C
program.
> The main rule is: "What you
> do not use, you do not pay for"
This is clearly not true. I suspect that one reason for the huge
difference cited above is the overhead of your string class.
> (i am still learning C++
We all are.
> and i do not
> know what type cout belongs to, i guess ostream).
Yes, it's ostream.
> Also the standard
> library is written in such a way to be inlined, so you do not pay the
> time cost of a function call so in most cases we have a performance gain
> in comparison to our equivallent C code separated in functions.
I know what inlining does. But "in most cases" is clearly not true. If
you inline most code, your program ends up being swapped out more often,
and the performance suffers.
> Also the
> member functions are written in the most efficient way and is
> faster/smaller than our C code (it can't be larger/slower).
I have already shown that it can* be larger.
> So another,
> when we do std::cout<<"Hello World"; only the cout.operator<<(const char
> *) should get compiled (in GCC this happens with version 3 and above i
> think).
Okay, let's try that modification to the program. It does make a big
difference. (Note: I made the same mod to the C program - i.e. got rid
of the temporary storage for the string literal.) I just used bcc32 this
time.
C program:
Object file: 562 bytes
Executable : 55296 bytes
C++ program:
Object file: 8159 bytes
Executable : 143360 bytes
So that optimisation saved the C++ version about 8KB, and it's /still/
about 15 times bigger than the C version.
> In summary as the compilers get more ANSI C++ conformant things
> are getting better (as is probably the case of BC++ 6 which i haven't
> seen yet).
They would appear to have a long way to go yet.
<snip>
> > You appear to have forgotten that the casting of void * is rarely
> > necessary in C.
>
> Here i was talking about C-style C++.
<shrug> C-style C++ is still C++. When I talk about C, I talk about C.
<snip C++ code>
> >
> > Here's the equivalent C code:
> >
> > void *inc(void *p)
> > {
> > return p;
> > }
> >
> > int main(void)
> > {
> > int x = 1;
> > int *p = inc(&x);
> > return 0;
> > }
> >
> > I think we must have different ideas of what is meant by the word
> > "messy".
>
> Yes. C++ code is more bullet-proof,
Where are the bullet-holes in the C code I just showed you?
> type-safe
<shrug> I don't care, really - I'm used to rolling my own type-safety as
and when required.
> and does not lack in speed
> (in many cases it is faster).
Evidence? Hard data?
> > > > > If it is not obvious then it is the case of bad decisions on
> design.
> > > >
> > > > Quite so. And that's why it's risky to opt for the willy-nilly use
> of
> > > > templates without considering the consequences of that choice.
> > >
> > > See above.
> >
> > I'm not sure how your example illustrates your point. If anything, it
> > illustrates mine.
>
> My example had the same time & space cost with your C equivallent
Evidence, please.
> and
> templates had not any "consequence".
Sure they did, even in such a tiny example. For a start, they made the
code a lot harder to read and understand than the C equivalent, for no
apparent gain.
<snip>
> > Whether it's a bad design decision in terms of space concerns depends
> on
> > how general the base class is. If it's *too* general and only a small
> > amount of it is actually useful to the derived class, the overhead of
> > using it may outweigh the abstraction benefits. This sort of problem
> > tends to rear its head only in larger projects, though.
>
> As i said the time overhead is the same independently of the abstraction
> depth.
You're right with respect to virtual member functions (although of
course you do need the space to store the vtable, and the time to create
and dispose of it). I don't think that's the whole story, though.
<snip>
>
> In real word i have seen bad C code but this doesn't prove that C
> is inefficient. :)
Right.
>
> > > void * again. See my above paragraph concerning void *.
> >
> > The one where you showed that the necessary C++ code is more
> complicated
> > than the C code?
>
> :) I showed that templates aren't bad.
I don't recall your doing that. I do recall your attempt to do that. I
think the attempt failed.
> They do not produce necessarily bloated code.
Right - not *necessarily* bloated.
> Their use can be.
Right.
<snip>
> > > My strong belief is that on large scale programs *C* code is slower
> than
> > > C++.
> >
> > Please write a carefully crafted, well-designed, 500,000 line C
> program
> > to do something time-critical. Then write the same application, using
> > the same algorithms, in C++. Then profile them and publish the results
> > (and the source code) on your Web site. Then, maybe, you'll have some
> > hard data to support your belief.
>
> :) At least C++ code can not have larger space/time costs
Yes, it can. See above.
> (it is assumed
> that one knows what he is doing).
That can be a very dangerous assumption, can it not?
>
> > And I believe that belief is all you /can/ have, if you don't have the
> > evidence.
>
> You too. :)
See above.
michael brown
--
Michael Brown
Instant Net Solutions
www.KillerPCs.net
"In the land of the blind, he who has one eye is king"
"Adam Petersen" <adam.p...@sea.ericsson.se> wrote in message
news:a6kv6e$alj$1...@newstoo.ericsson.se...
>
> "Ioannis Vranos" <noi...@yahoo.com> wrote
> >
> > claass something
> > {
> > vector<int>p;
> > public:
> > something(const vector<int>::size_type &n) { p(n); }
> > void increase(const vector<int>::size_type &n) { p.reserve(n); }
> > // ...
> > };
>
> This must mean the end to this (useless) discussion, because this
> code is actually the fastest I have seen in this thread:
> It does not even have an execution time, due to the fact that it does not
> even compile:-))).
>
> /Adam
>
>
Ioannis Vranos
>
> MINGW32/GCC & BC++ are compliant ANSI C++ in a very high degree. The
> last is only for C. Anyway my main point is to not use as an example a
The last is only for ANSI C++ and not C99.
> broken implementation!
Sandeep
perspective.
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.htm
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance2.htm
Sandeep
--
www.EventHelix.com
Distributed, Realtime and Embedded Software Development
michael brown
> functions you do not lose more space than store-keeping the information
> yourself. In fact usually your method wastes more space so it is a bad
> design decision in terms of space concerns (this doesn't mean however
> that i act the smart guy since you are programming for years and me for
> merely 2 years and i *totally* respect you recognising my previous
> b***sh*t behavior of mine 2 years ago).
There is no offense intended here. I have been programming for over 25
years (no brag, just fact). There is absolutely no way that C++ can solve a
problem more efficiently (in terms of code and data space, and execution
time) than plain ordinary C can. I have developed code on a lot of
platforms (from mainframes(Honeywell/Bull, IBM down to micro-controllers
(8052, PIC etc..) There is no C++ compiler in the world (AFAIK) that could
generate code to run on an 8052 w/256 bytes of internal RAM, yet there are
dozens of C compilers doing it. Granted, maintainability might be better on
C++ (once you understand the crazy syntax) and type-protection is higher
(because with bloated code and OOP it becomes more necessary). The bigger
the beast, the harder to reign it in. I have seen small device C compilers
generate tighter/faster code than a seasoned assembly programmer does. Of
course the seasoned vet writes assembly code to be somewhat
maintainable/understandable. Compilers never do. ;-)
As far as your "completely/guaranteed" code portability goes, you obviously
have not developed on many platforms. ANSI standards do not make portable
code. No language (and certainly not any program written by a human) is
100% portable. I respect your knowledge of theory, and your obvious
education level, but the real world will set in on you in time. C++ has a
place in the world, right along with assembler, COBOL, Fortran and even VB.
It is NOT the perfect language. Everyone already knows that PERL is the
king. ;-D
michael brown
Ioannis Vranos
> >
> > :)) That is a theoretical experiment.
>
> Quite so. But then, any discussion of C++ has to be on the theoretical
> level, unless you're using Comeau C++.
No it can be discussed in a practical level by not using as an example
the most broken implementation (VC++).
> > Using broken implementations as an example is not any proof at all.
>
> I don't think anyone is talking about proof here. But either we're
> talking about the real world, or we're talking about the theoretical
> world. In the theoretical world, BCB++ and MINGW32 are not conforming
> C++ implementations. In the real world, they might be considered "good
> enough", but then, in that same real world, we can't always choose our
> compilers and we must consider the portability implications of certain
> features which are not supported by compilers such as Microsoft's.
We are talking about the real world using good compilers. GCC 3.x and
BC++ 6 for example. I have the strong impression that BC++B 6 is 100%
ANSI C++ compliant but i have not played with it. But even BC++B 5 is in
a very much high level ANSI C++ conforming. Anyway we discuss about code
compliant with the ANSI standard as in the case of C99.
>
> > If i
> > had to do with a person/company who want to use broken
implementations
> > then i would adjust my code to work in the supported subset (or even
in
> > broken standard mode as in case of VC++ 6).
>
> Right.
>
> > But this can't be an argument.
>
> I'm not sure what you mean here.
This can't be used as a proof.
>
> >
> > > > ANSI C++ is
> > > > more widely implemented than C99 anyway.
> > >
> > > Really? I only know of one conforming ANSI C++ implementation -
Comeau
> > > C++. I also know of only one conforming C99 implementation -
Comeau C
> > > (with Dinkumware libc). That seems to me to be a 50/50 split. What
> > > conforming ANSI C++ implementation do you know about that I appear
to
> > > have missed?
> >
> > MINGW32/GCC & BC++ are compliant ANSI C++ in a very high degree.
>
> Either they're conforming or they're not. Do they support partial
> template specialisation, which MSVC and VS.NET apparently don't? Do
they
> support the export keyword?
The code:
template <class T>
class A
{
T x;
public:
A(const T &y):x(y) {}
};
template <class T>
class A<T *>
{
T *x;
public:
A(T * const &y): x(y) {}
};
int main()
{
int x=2;
A<int *> a(&x);
}
compiles successfully on the last version of MINGW32. I can't test the
code yet in BC++ because i have formatted my HDD (the usual ms stuff)
and hadn't the time to reinstall it. But i am pretty sure it compiles
there too. I do not care if MS VC++ 7 is not a high standard compiler.
It is their problem. If they want to damage their VC++ so as everyone to
use C# then it is a ridicoulous attempt (to try to channel every
programmer to a single language is futile).
The export keyword is not supported yet in both my compilers but it is
recognised (and ignored). I assume that in GCC 3.x and BC++ 6 it is
probably recognised.
> But that's precisely what you've been doing throughout.
What i have been doing is discussing about ANSI C++ 1998 compliant
code.
> But that doesn't mean anything, particularly. If I've understood your
> argument correctly, you appear to be saying that the code generation
> phase of a C++ compiler is, a priori, more efficient than the code
> generation phase of a C compiler. I don't see any evidence to support
> this position.
No. I was saying how a decent C++ compiler should behave regarding
templates. It should compile only those template member functions that
are being used. Also the member functions of the STL are written in the
smaller and most efficient possible way so as to be easily inlined. This
means that our C-style code written in functions and accepting data to
manipulate their bits can't be any faster (but usually slower) or
smaller.
Well this is because they compile the entire classes. :) I know you will
say i am talking theoretically now, and yes in this case i am (the
size), but i expect better results with GCC 3.x and BC++6B.
>
>
> > The main rule is: "What you
> > do not use, you do not pay for"
>
> This is clearly not true. I suspect that one reason for the huge
> difference cited above is the overhead of your string class.
Yes, it probably compiles the entire basic_string<char> class and not
only the member functions used. This shouldn't happen though, and i
expect it to be improved with every new compiler release.
In summary in real world you are still correct about the space cost but
it is a new language and when we will have 100% compliant compilers then
anything will be ok i assume.
> > Also the standard
> > library is written in such a way to be inlined, so you do not pay
the
> > time cost of a function call so in most cases we have a performance
gain
> > in comparison to our equivallent C code separated in functions.
>
> I know what inlining does. But "in most cases" is clearly not true. If
> you inline most code, your program ends up being swapped out more
often,
> and the performance suffers.
What do you mean?
>
> > Also the
> > member functions are written in the most efficient way and is
> > faster/smaller than our C code (it can't be larger/slower).
>
> I have already shown that it can* be larger.
Yes you did. But i expect this to change.
>
> > So another,
> > when we do std::cout<<"Hello World"; only the cout.operator<<(const
char
> > *) should get compiled (in GCC this happens with version 3 and above
i
> > think).
>
> Okay, let's try that modification to the program. It does make a big
> difference. (Note: I made the same mod to the C program - i.e. got rid
> of the temporary storage for the string literal.) I just used bcc32
this
> time.
>
> C program:
> Object file: 562 bytes
> Executable : 55296 bytes
>
> C++ program:
> Object file: 8159 bytes
> Executable : 143360 bytes
>
> So that optimisation saved the C++ version about 8KB, and it's /still/
> about 15 times bigger than the C version.
Here it probably compiles all the member functions of cout too.
> >
> > Yes. C++ code is more bullet-proof,
>
> Where are the bullet-holes in the C code I just showed you?
I am talking about all C++ constructs. Consider the following:
// class supporting "resource aquisition is initialization" technique
class A
{
FILE *fp;
public:
A(const string &filename, const string &mode)
{
fp=fopen(filename.c_str(), mode.c_str();
if(!fp)
throw something();
}
~A() { fclose(fp);
};
With the "Resource aquistion is initialization" technique you can manage
*safely* any resource (ip connection,
memory, e.t.c.) without any possibility of any loss in any scenario. If
some exception is thrown the object dies and clears itself automatically
with no resource loss (that's why C++ doesn't need any garbage
collection, it supports this technique).
This should not be any slower than fopening and fclosing manually your
files. Also there is only one place for updating and not 100s of lines.
Almost all the C++ standard libraries support this technique (vectors
etc).
So as you can see in C++ you can write easily code that is bullet proof
(all the std facilities are bullet proof). Consider the code:
vector<int>array(5, 2); // array of 5 elements initiliazed to 2
for(vector<int>::size_type i=0; i<array.size(); i++)
array[i]++;
// ...
cout<<"Your array has "<<array.size()<<" elements which are:\n";
for(vector<int>::size_type i=0; i<array.size(); i++)
array[i];
This code can never fail (assuming enough resources) and if you want to
change the initial size of the array you do that in one place.
>
> > type-safe
>
> <shrug> I don't care, really - I'm used to rolling my own type-safety
as
> and when required.
>
> > and does not lack in speed
> > (in many cases it is faster).
>
> Evidence? Hard data?
In speed?
see my http://users.forthnet.gr/ath/jvr/c++faq.htm
> > and
> > templates had not any "consequence".
>
> Sure they did, even in such a tiny example. For a start, they made the
> code a lot harder to read and understand than the C equivalent, for no
> apparent gain.
It was not harder for me.
> > :) I showed that templates aren't bad.
>
> I don't recall your doing that. I do recall your attempt to do that. I
> think the attempt failed.
? Why.
// The baby
void *inc(void *p)
{
// ...
return p;
}
// Our type safe interface
template <class T>
inline T *inc(T *p)
{
return static_cast<T *>(inc(p));
}
int main()
{
int x=1;
int *p=inc(&x);
// ...
}
It has the same cost both in space both in time with using plain void *s
(and casts in C++ at every line you use it).
>
> > They do not produce necessarily bloated code.
>
> Right - not *necessarily* bloated.
>
> > Their use can be.
>
> Right.
> > (it is assumed
> > that one knows what he is doing).
>
> That can be a very dangerous assumption, can it not?
Yes, the language can't protect anyone from his ignorance.
Tim
news:IlIj8.27$KY6....@typhoon.austin.rr.com...
Amen, Michael!
Like you, I, too, am a seasoned veteran of over 25 years (no brag, just
fact; well, maybe a little brag too.) And like you I have developed a lot
of code, all the way from mainframe stuff (IBM, PR1ME), to minicomputers
(DEC PDP-8e, PDP-11, DG NOVA), to early hobbyist computers such as the
Apple, Commodore VIC-20 and Radio Shack Trash-80, to many, many embedded
microprocessors and microcontrollers (8/16/32 bitters, mostly Intel and
Motorola architectures, including 8048, 8051, 8085, 8086, 80186, 486, 6809,
68000, PowerPC, etc., also DEC LSI-11, ARM, StrongARM, DSPs such as the
TMS320C25, etc.) I have worked with dozens of cross-compilers and
assemblers over the years. I have worked with the earliest versions of both
the C and C++ compilers (even helped debug the Telecon C cross-compiler,
hosted on the PDP-11, targeting 8086; by the way, does anyone remember that
the first Microsoft C compiler was based on the earlier Lattice C compiler,
the first really acceptable C compiler?; and does anyone remember playing
with TinyC from DDJ? DecusC? the plethora of other early "experimental" C
compilers I can't even remember the name of right now? I played with all of
these, too, and all of the early cross-assemblers, too.) Did a lot of
Windows development with Visual C/C++, also worked with the Borland C++,
etc. Not to mention excursions into CassetteBASIC, VisualBASIC, Fortran,
Pascal, Focal, MUMPS, even Cobol (ugh!)
Right now, I'm back to doing embedded programming, where space is at a
premium, and couldn't agree more with your statements above. (Well, maybe
not about Perl. ;-)
BTW, are you the same Mike Brown who was at Nicolet (in Madison, WI) for a
while, and who ran the NicBul BBS back in the early 80s? If so, "hi!" :-)
I'm over at Nicolet myself now.
-- Tim
michael brown
I've worked on a bunch (not all, but some others like 1802) of the stuff you
listed. Remember the magnificent PDP UNI-BUS (like that was something to
brag about)
> Right now, I'm back to doing embedded programming, where space is at a
> premium, and couldn't agree more with your statements above. (Well, maybe
> not about Perl. ;-)
Aw, come on man, it rocks! It's what C++ should have been. I like the
built in table handling and string/expression and hashing abilities.
Although I probably couldn't code anything in it at the moment. It's hard
keeping things straight with all the differect arch's. I haven't written
any PERL for a few years.
> BTW, are you the same Mike Brown who was at Nicolet (in Madison, WI) for a
> while, and who ran the NicBul BBS back in the early 80s? If so, "hi!"
:-)
> I'm over at Nicolet myself now.
Nope, sorry. Back then, I was in Belleville, IL (at Scott AFB writing COBOL
and GMAP) on teletypes (man they sucked), even used punched cards (those
were the days).
>
> -- Tim
>
>
>
Tim
>
> I've worked on a bunch (not all, but some others like 1802) of the stuff
you
> listed. Remember the magnificent PDP UNI-BUS (like that was something to
> brag about)
Oh yeah, UNIBUS. :-) Worked with those a lot; we even developed some cards
of our own design for data acquisition. To work on these, we also had to
develop a UNIBUS extender card, if you can imagine. Speaking of old DEC
systems; I've still got my old RL01 disk drive in my personal "museum" at
home, along with old paper tapes, 8" floppies, etc. You remember when those
came out? That was back when 10MB seemed huge, even though it was on a
platter more than a foot in diameter. Now 10GB on a 3-1/2" seems like
nothing. And as for the software on those old DEC systems -- do you
remember programming in MACRO-11? How about Decus C? Remember "Martin
Minow"?
>
> Nope, sorry. Back then, I was in Belleville, IL (at Scott AFB writing
COBOL
> and GMAP) on teletypes (man they sucked), even used punched cards (those
> were the days).
Oh yes, punched cards -- did my time with them on a cranky old IBM 1310
doing Cobol programming, too. And Teletypes; you probably remember the
paper tapes (on spools) we used with those, right? What a joy when high
speed paper tape readers (with fanfold tape that could be stored neatly in
trays) came out. I'm often tempted to suggest that you're not a "real"
programmer unless you remember using punched cards and/or paper tape on the
old ASR-33 teletype. ;-) For that matter, you probably remember how to
splice paper tapes and manually punch holes in them and/or punch cards, if
you're a "real" programmer, no?
Thanks for the stroll.
-- Tim
michael brown
> Minow"?
I never really programmed on a PDP, I just did a bunch of textbook type
training and then got reassigned to work on Honeywell (GE) mainframes before
I actually got a chance to touch a PDP. I even knew how to bootstrap it,
even though I never did it. ;-D
> >
> > Nope, sorry. Back then, I was in Belleville, IL (at Scott AFB writing
> COBOL
> > and GMAP) on teletypes (man they sucked), even used punched cards (those
> > were the days).
>
> Oh yes, punched cards -- did my time with them on a cranky old IBM 1310
> doing Cobol programming, too. And Teletypes; you probably remember the
> paper tapes (on spools) we used with those, right? What a joy when high
> speed paper tape readers (with fanfold tape that could be stored neatly in
I never really kept much paper-tape around, the tty was always out of it and
connected to a mainframe anyway. I did read allot of that stupid yellow
paper (paper towell predecessor?) with blue ink on it.
> trays) came out. I'm often tempted to suggest that you're not a "real"
> programmer unless you remember using punched cards and/or paper tape on
the
> old ASR-33 teletype. ;-) For that matter, you probably remember how to
> splice paper tapes and manually punch holes in them and/or punch cards, if
> you're a "real" programmer, no?
Splicing tape is a joy. ;-) Dropping a COBOL punched deck is real fun,
especially with no sequence numbers. I used to be able to *read* card
punches, but not paper tape. You used to have to run a machine punched deck
through a transliterator to print text accross the top. Burroughs used to
have a transliterator that printed 60 chars accross the top and then another
line of 20 chars. Try to line that up by eye some time. I've seen punched
cards folded into japanese paper fans by a card reader before. ;-D
> Thanks for the stroll.
> -- Tim
Take care
michael brown
Aaron Isotton
> Ioannis Vranos wrote:
> >
>
> > My main point is that C++ code can not be slower or larger than
> > equivallent C code in a decent ANSI C++ standard compliant compiler.
>
> Why not? If for example you write a solution in C++ that nests to
> a depth of 17 but the C solution happens to nest to a depth of 16 the
> C++ implementation will be slower because you'll have one extra context
> save every iteration. It may, of course, be smaller. I defy you to
> *prove* that the problem for which the above condition using optimal
> solutions does not exist. This is what you have to do to prove your
> assertion that the C++ answer can NEVER be slower.
It's quite easy to prove. Most (standard) C code will compile fine
using a C++ compiler with no or only minor changes, and will be
optimized just about the same. (Of course some compilers optimize more
than others, but that's not the point). *But* in C++ you can probably
write it another way as well, using classes, the standard library,
exceptions, templates and/or whatever else C++ has which C
doesn't. And that code might be faster than the original C code,
because (for example) the standard library has some hand-optimized
assembler routines doing just what you need.
[snip]
> Tim
Aaron
Peter Pichler
> Peter Pichler wrote:
> > "Joona I Palaste" <pal...@cc.helsinki.fi> wrote:
> > > Languages aren't fast or slow. Code is. How fast or slow code is
depends
> > > not only which language it was written in, but also on:
> > - Who wrote the code
> > - Who wrote the compiler
>
> how well the design was done.
That's what I said, isn't it? ;-)
Peter P.
Ioannis Vranos
>
> I am talking about all C++ constructs. Consider the following:
>
>
> // class supporting "resource aquisition is initialization" technique
> class A
> {
> FILE *fp;
> public:
> A(const string &filename, const string &mode)
> {
>
> if(!fp)
> throw something();
> }
>
~A() { fclose(fp); }
> };
Sorry for the syntax errors...
--
Ioannis Vranos
Well i accept you are right but i think that C being standardiwed one
decade earlier than C++ has of course some advantage in the quality of
the compilers. I expect that as time passes C++ will have 0-overhead
both in space and time compared to C code. The only thing that obviously
is not implemented widely yet is the philosophy that in templates only
the meber functions that are being used should be compiled. In terms of
speed i believe C++ has nowadays 0 overhead. For an example take a look
at my http://users.forthnet.gr/ath/jvr/c++faq.htm
> As far as your "completely/guaranteed" code portability goes, you
obviously
> have not developed on many platforms. ANSI standards do not make
portable
> code. No language (and certainly not any program written by a human)
is
> 100% portable.
The standard guarantees what cane be considered portable. for example
the code:
#include <iostream>
int main()
{
std::cout<<"Hello new world!\n";
}
should compile to every ANSI C++ conforming compiler.
> I respect your knowledge of theory, and your obvious
> education level, but the real world will set in on you in time.
Ioannis puffs up like a peacock.
> C++ has a
> place in the world, right along with assembler, COBOL, Fortran and
even VB.
> It is NOT the perfect language. Everyone already knows that PERL is
the
> king. ;-D
:)) I thought the king is C#. :P
Ioannis Vranos
Ioannis remains silent and listens the discussion of the ancient ones.
:) I am dealing with computers (PC's) since 1989 DOS 3.30 / Windows 3.0
era and i understand the good older days. :)
Donald Gillies
> There is no offense intended here. I have been programming for over
> 25 years (no brag, just fact). There is absolutely no way that C++
> can solve a problem more efficiently (in terms of code and data space,
> and execution time) than plain ordinary C can. I have developed code
> on a lot of platforms (from mainframes(Honeywell/Bull, IBM down to
> micro-controllers (8052, PIC etc..) There is no C++ compiler in the
> world (AFAIK) that could generate code to run on an 8052 w/256 bytes
> of internal RAM, yet there are dozens of C compilers doing it.
> Granted, maintainability might be better on C++ (once you understand
> the crazy syntax) and type-protection is higher (because with bloated
> code and OOP it becomes more necessary). The bigger the beast, the
> harder to reign it in. I have seen small device C compilers generate
> tighter/faster code than a seasoned assembly programmer does. Of
> course the seasoned vet writes assembly code to be somewhat
> maintainable/understandable. Compilers never do. ;-)
I like this post. I believe it is true. I have also been programming
for 25 years too, but I probably didn't improve after the first 5
years of my career. However, i have learned to steal good ideas
judiciously in the ensuing 20 years. Do I write C and C++ ?? I have
written both kernels and network protocols in both languages. My
software, even the stuff written 25 years ago, still gets used.
Unfortunately, when you criticize C++ in any way, in any forum, you
are preaching christianity to the muslims. Then you can sit back and
watch the sparks fly as these muslim C++ programmers impale themselves
on unsupportable statements about software engineering, compilers,
languages, complexity of large systems, etc.
michael brown
> :) I am dealing with computers (PC's) since 1989 DOS 3.30 / Windows 3.0
> era and i understand the good older days. :)
I remember PC's (from IBM) being delivered to the govt. with no OS.
Because, as usual, MS was late with DOS 1.0. People put 8" floppy drives
and ran a hacked version of CPM on them. Bet you never heard that before.
;-) My first computer (and I still have it) was based on an RCA 1802
running at 1.8 Mhz (roughly, actually 3.579545 / 2). It has 256 bytes of
memory. To see one, go to www.cosmacelf.com
michael brown
Ioannis Vranos
> > Ioannis remains silent and listens the discussion of the ancient
ones.
> > :) I am dealing with computers (PC's) since 1989 DOS 3.30 / Windows
3.0
> > era and i understand the good older days. :)
>
> I remember PC's (from IBM) being delivered to the govt. with no OS.
> Because, as usual, MS was late with DOS 1.0. People put 8" floppy
drives
> and ran a hacked version of CPM on them. Bet you never heard that
before.
I have read something, somewhere about these but yes i miss the whole
point.
> ;-) My first computer (and I still have it) was based on an RCA 1802
> running at 1.8 Mhz (roughly, actually 3.579545 / 2). It has 256 bytes
of
> memory. To see one, go to www.cosmacelf.com
:)) Mine was an 8088 /10 mhz. I enjoyed decreasing it sometimes at 4.77
MHz through the keyboard using ctrl/alt/-. I remember the first time i
saw it blinking after i booted with my 5 1/4 in DOS 3.30, and i was
feeling something sacred. I do not think this happens nowadays with our
tv-looking crap, i mean, PCs. :)
I was feeling that sacred feeling and to a friend's commodore 64 before
i get my pc. Probably the command line produces that feeling in a
newcomer. :)
Then you know the story. Windows 3.0 arrived, we all were saying "DOS
never dies" and "men do it in keyboard only" and Windows will never
replace DOS, then in dos 6 (or 5?) dosshell was created and i considered
it as a strong point towards the direction that ms will not sacrifice
dos for win. Then Windows 95 and a 32-bit DOS got under development,
then after win95 some months later, billg said that there will never be
a 32-bit stand alone dos, so we kept windows running on dos16 hunging
all the time...
I remember having more fun with my cga and later vga-256 colours. That
time our 3D accelerator was the brain. I was looking at microprose
F-15II and i was thinking "damn i am flying!". Unfortunately the old
stories will remain to those who lived them only and the newcomers will
not have our space/time efficiency concerns at the >1gb/1ghz era. And i
think their difficulty to adjust to low level programming will increase.
For example in the era of K&R people were upgrading memory by themselves
(they made it). When you do it yourself then you can understand
everything. :)
S. Ramirez
"Donald Gillies" <gil...@cs.ubc.ca> wrote in message
news:a6ohei$4ve$1...@cascade.cs.ubc.ca...
> I like this post. I believe it is true. I have also been programming
> for 25 years too, but I probably didn't improve after the first 5
> years of my career. However, i have learned to steal good ideas
> judiciously in the ensuing 20 years. Do I write C and C++ ?? I have
> written both kernels and network protocols in both languages. My
> software, even the stuff written 25 years ago, still gets used.
>
> Unfortunately, when you criticize C++ in any way, in any forum, you
> are preaching christianity to the muslims. Then you can sit back and
> watch the sparks fly as these muslim C++ programmers impale themselves
> on unsupportable statements about software engineering, compilers,
> languages, complexity of large systems, etc.
I like this post!
Simon Ramirez
John W. Krahn
>
> As far as your "completely/guaranteed" code portability goes, you obviously
> have not developed on many platforms. ANSI standards do not make portable
> code. No language (and certainly not any program written by a human) is
> 100% portable. I respect your knowledge of theory, and your obvious
> education level, but the real world will set in on you in time. C++ has a
> place in the world, right along with assembler, COBOL, Fortran and even VB.
> It is NOT the perfect language. Everyone already knows that PERL is the
> king. ;-D
What is this "PERL" you speak of? :-(
http://www.perldoc.com/perl5.6/pod/perlfaq1.html#What's-the-difference-between--perl--and--Perl--
John
--
use Perl;
program
fulfillment
michael brown
--
Michael Brown
Instant Net Solutions
www.KillerPCs.net
"In the land of the blind, he who has one eye is king"
"John W. Krahn" <kra...@acm.org> wrote in message
news:3C900E1D...@acm.org...
Bart Kowalski
news:a6ohei$4ve$1...@cascade.cs.ubc.ca...
> Unfortunately, when you criticize C++ in any way, in any forum, you
> are preaching christianity to the muslims. Then you can sit back and
> watch the sparks fly as these muslim C++ programmers impale themselves
> on unsupportable statements about software engineering, compilers,
> languages, complexity of large systems, etc.
You have just made the public confession of being a troll. Expect many
people to ignore you permanently.
Bart.
Richard Heathfield
>
> "Richard Heathfield" <bin...@eton.powernet.co.uk> wrote in message
> news:3C8F40F5...@eton.powernet.co.uk...
> > >
> > > :)) That is a theoretical experiment.
> >
> > Quite so. But then, any discussion of C++ has to be on the theoretical
> > level, unless you're using Comeau C++.
>
> No it can be discussed in a practical level by not using as an example
> the most broken implementation (VC++).
I'm no fan of Microsoft, but I don't agree that we can ostentatiously
ignore one of the most widespread implementations of the language in
existence when discussing practical C++ programming.
As a proof, by the way, that MSVC++ is /not/ the most broken C++
implementation, here's an even more broken C++ implementation:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char ibuf[32];
while(fgets(ibuf, sizeof ibuf, stdin))
{
}
fprintf(stderr, "LameC++ (c) Lamesoft 2002. All rights reserved.\n");
fprintf(stderr, "An error occurred during compilation.\n");
return EXIT_FAILURE;
}
This implementation doesn't bootstrap well, of course.
>
> > > Using broken implementations as an example is not any proof at all.
> >
> > I don't think anyone is talking about proof here. But either we're
> > talking about the real world, or we're talking about the theoretical
> > world. In the theoretical world, BCB++ and MINGW32 are not conforming
> > C++ implementations. In the real world, they might be considered "good
> > enough", but then, in that same real world, we can't always choose our
> > compilers and we must consider the portability implications of certain
> > features which are not supported by compilers such as Microsoft's.
>
> We are talking about the real world using good compilers.
Almost a contradiction. In the real world, many people aren't allowed to
use good C++ compilers. They have to use the Microsoft compiler instead.
A few fortunate souls get to play with Borland and gcc.
> GCC 3.x and
> BC++ 6 for example. I have the strong impression that BC++B 6 is 100%
> ANSI C++ compliant but i have not played with it. But even BC++B 5 is in
> a very much high level ANSI C++ conforming. Anyway we discuss about code
> compliant with the ANSI standard as in the case of C99.
<shrug> There's only one C99 compiler AFAIK. Hardly a real world
Standard, yet.
> > > If i
> > > had to do with a person/company who want to use broken
> implementations
> > > then i would adjust my code to work in the supported subset (or even
> in
> > > broken standard mode as in case of VC++ 6).
> >
> > Right.
> >
> > > But this can't be an argument.
> >
> > I'm not sure what you mean here.
>
> This can't be used as a proof.
In theory, no, it can't. In practice, yes, we must look at real world
implementations when discussing real world implementation issues.
Performance is not a language issue.
<snip>
> > But that doesn't mean anything, particularly. If I've understood your
> > argument correctly, you appear to be saying that the code generation
> > phase of a C++ compiler is, a priori, more efficient than the code
> > generation phase of a C compiler. I don't see any evidence to support
> > this position.
>
> No. I was saying how a decent C++ compiler should behave regarding
> templates. It should compile only those template member functions that
> are being used. Also the member functions of the STL are written in the
> smaller and most efficient possible way so as to be easily inlined. This
> means that our C-style code written in functions and accepting data to
> manipulate their bits can't be any faster (but usually slower) or
> smaller.
And yet the evidence points the other way.
I wasn't expecting there to be any significant difference on such small
programs. And yet the difference exists even there. I suspect the
difference will increase with project size.
> > > The main rule is: "What you
> > > do not use, you do not pay for"
> >
> > This is clearly not true. I suspect that one reason for the huge
> > difference cited above is the overhead of your string class.
>
> Yes, it probably compiles the entire basic_string<char> class and not
> only the member functions used. This shouldn't happen though, and i
> expect it to be improved with every new compiler release.
Well, I hope you're right, but I'm not holding my breath.
>
> In summary in real world you are still correct about the space cost but
> it is a new language and when we will have 100% compliant compilers then
> anything will be ok i assume.
No, because "100% compliant compiler" doesn't necessarily imply
"efficient code generator".
>
> > > Also the standard
> > > library is written in such a way to be inlined, so you do not pay
> the
> > > time cost of a function call so in most cases we have a performance
> gain
> > > in comparison to our equivallent C code separated in functions.
> >
> > I know what inlining does. But "in most cases" is clearly not true. If
> > you inline most code, your program ends up being swapped out more
> often,
> > and the performance suffers.
>
> What do you mean?
I mean that you end up with a huge program that can't all fit in memory
at once, so the operating system has to keep some of it on disk (virtual
memory). Then, when it needs that bit of the program, it has to save
another part of the program to disk. This can have a serious performance
cost.
>
> >
> > > Also the
> > > member functions are written in the most efficient way and is
> > > faster/smaller than our C code (it can't be larger/slower).
> >
> > I have already shown that it can* be larger.
>
> Yes you did. But i expect this to change.
I hope it does, but I doubt it'll be any time soon.
<snip>
> > >
> > > Yes. C++ code is more bullet-proof,
> >
> > Where are the bullet-holes in the C code I just showed you?
>
> I am talking about all C++ constructs. Consider the following:
>
> // class supporting "resource aquisition is initialization" technique
> class A
> {
> FILE *fp;
> public:
> A(const string &filename, const string &mode)
> {
> fp=fopen(filename.c_str(), mode.c_str();
>
> if(!fp)
> throw something();
> }
>
> ~A() { fclose(fp);
> };
>
> With the "Resource aquistion is initialization" technique you can manage
> *safely* any resource (ip connection,
> memory, e.t.c.) without any possibility of any loss in any scenario. If
> some exception is thrown the object dies and clears itself automatically
> with no resource loss (that's why C++ doesn't need any garbage
> collection, it supports this technique).
<shrug> I can write bullet-proof fopen code in C as well as in C++. I
still don't see your point.
> This should not be any slower than fopening and fclosing manually your
> files. Also there is only one place for updating and not 100s of lines.
What's to update? All you've done is hack in an exception. I don't see
that you've gained any particular advantage. Rather, you've nailed
yourself to a single exception handler, which isn't a very flexible way
to go IMHO.
> Almost all the C++ standard libraries support this technique (vectors
> etc).
>
> So as you can see in C++ you can write easily code that is bullet proof
Yes, but I can do that in C too. I don't see why you think C++ is more
bullet-proof than C.
> (all the std facilities are bullet proof). Consider the code:
>
> vector<int>array(5, 2); // array of 5 elements initiliazed to 2
>
> for(vector<int>::size_type i=0; i<array.size(); i++)
> array[i]++;
>
> // ...
>
> cout<<"Your array has "<<array.size()<<" elements which are:\n";
>
> for(vector<int>::size_type i=0; i<array.size(); i++)
> array[i];
>
> This code can never fail (assuming enough resources)
Assuming enough resources, the C equivalent could never fail either. I
understand that you like C++. So do I. But I really don't see what point
you are making. Are you just trying to advocate C++? If so, perhaps we
should stop here and move the discussion to an advocacy group.
> and if you want to
> change the initial size of the array you do that in one place.
Right. Same as in C.
<snip>
> > > and does not lack in speed
> > > (in many cases it is faster).
> >
> > Evidence? Hard data?
>
> In speed?
>
> see my http://users.forthnet.gr/ath/jvr/c++faq.htm
When I get a minute, I'll check it out. (I do Usenet offline.)
>
> > > and
> > > templates had not any "consequence".
> >
> > Sure they did, even in such a tiny example. For a start, they made the
> > code a lot harder to read and understand than the C equivalent, for no
> > apparent gain.
>
> It was not harder for me.
It would be alarming if the author of the code found it hard to read.
>
> > > :) I showed that templates aren't bad.
> >
> > I don't recall your doing that. I do recall your attempt to do that. I
> > think the attempt failed.
>
> ? Why.
Because I showed that your example resulted in bigger code than the
equivalent C program. I haven't bothered profiling it, but my colleague
(an expert C++ programmer who is following this conversation, on and
off, with much interest and amusement) assures me that the C program
would be faster. (If anyone cares enough to test this claim, feel free.)
<snip>
>
> It has the same cost both in space both in time with using plain void *s
> (and casts in C++ at every line you use it).
Try it, with your favourite compiler, and find out whether your claim is
true. Then try it with another compiler.
<snip>
> > > (it is assumed
> > > that one knows what he is doing).
> >
> > That can be a very dangerous assumption, can it not?
>
> Yes, the language can't protect anyone from his ignorance.
Actually, APL can do precisely that. :-)
Tim Sinkins
And here you are continually missing the point. Inefficiencies in
library files don't count. The optimum solution in a language
requires that the library files are the most efficient possible and if
a particular 'c' function that you require happens to be slow then
you don't use it. Suggesting that C++ code is faster than C code
because a library routine has been provided better in one language
than the other is just plain silly
Tim
Jason A. Kozak
<n5...@nospam.earthlink.net> wrote:
>There is no offense intended here. I have been programming for over 25
>years (no brag, just fact). There is absolutely no way that C++ can solve a
>problem more efficiently (in terms of code and data space, and execution
>time) than plain ordinary C can.
Sure there is: use a better compiler, or if one can't be found, wait
till one arrives. Or better yet, those with the free time can
contribute to gcc if they'd like.
>There is no C++ compiler in the world (AFAIK) that could
>generate code to run on an 8052 w/256 bytes of internal RAM, yet there are
>dozens of C compilers doing it.
So? It could be done if there was a market for it.
The OP wanted to know which is faster, well, here's your answer if
you're still around:
1. Decide on your development platform
2. Determine whether you even have a choice
3. Study compilers for that platform to determine which produces the
best output, and use whatever language it compiles.
Unfortunately, there's no definite answer. Theoretically, since C++
doesn't actually add any runtime overhead onto C code, it shouldn't be
any slower (assuming near identical code... this is C vs. C++, not
procedural vs. OO, not the C standard library vs. the C++ standard
library & STL), but actual compilers may disagree.
Jason Kozak
--
"I think you've lost your head." - LShaping
Keith Brafford
> Almost a contradiction. In the real world, many people aren't allowed to
> use good C++ compilers. They have to use the Microsoft compiler instead.
> A few fortunate souls get to play with Borland and gcc.
Don't you mean g++ ? :-)
--Keith Brafford
Richard Heathfield
Um, yes and no (and yes!). :-)
Yes, I ought to have said g++. No, I'd rather play with gcc than g++.
Yes, I would be much happier to play with g++ than to be lumped with
MSVC.
michael brown
> >years (no brag, just fact). There is absolutely no way that C++ can
solve a
> >problem more efficiently (in terms of code and data space, and execution
> >time) than plain ordinary C can.
>
> Sure there is: use a better compiler, or if one can't be found, wait
> till one arrives. Or better yet, those with the free time can
> contribute to gcc if they'd like.
So you are saying that a better C++ compiler can always be found, but a
better C compiler cannot. Interesting. I have complete respect for gcc,
it's g++ that I'm not to sure about.
> >There is no C++ compiler in the world (AFAIK) that could
> >generate code to run on an 8052 w/256 bytes of internal RAM, yet there
are
> >dozens of C compilers doing it.
>
> So? It could be done if there was a market for it.
Are you aware of how many micro-controller based systems are built every
year? Apparantly not. Sorry, I keep forgetting that the only "important"
computers in the world are PC's with megabytes of RAM running at thousands
of Mhz.
> The OP wanted to know which is faster, well, here's your answer if
> you're still around:
> 1. Decide on your development platform
> 2. Determine whether you even have a choice
> 3. Study compilers for that platform to determine which produces the
> best output, and use whatever language it compiles.
Picking the correct tool for a job is a given. The OP wanted to know which
was "faster". In general, higher level languages are more abstract and more
removed from the underlying hardware. This has the unavoidable effect of
making the generated code less than optimal for the hardware(optimizing
after generating code doesn't count here). This makes the code larger and
slower, in general. Excepting the most contrived examples, the C++ compiler
is always going to generate a bigger object file than a C compiler. Neither
of which will be as large as a COBOL executable, in general. The important
thing here is the "in general" part. The biggest impact on the size of the
code generated is probably due to the programmer and his (or her) abilities,
and knowledge of how the "innards" of the compiler work.
> Unfortunately, there's no definite answer. Theoretically, since C++
> doesn't actually add any runtime overhead onto C code, it shouldn't be
Really, constructors and destructors are free??? Do you guys ever look at
the generated assembly code from the compiler? I really feel that if more
people did, debates like this wouldn't take place.
> any slower (assuming near identical code... this is C vs. C++, not
> procedural vs. OO, not the C standard library vs. the C++ standard
> library & STL), but actual compilers may disagree.
Run some tests and see. We have already seen (proof to me) that the C++
compiler generates MUCH larger objects and executables. Unless there is
just a bunch of wasted space (not a good compiler then anyway) in the
objects/executables, the C++ code HAS to run somewhat slower (since there is
more of it). Since PC type hardware is so fast anyway, it really makes no
difference in the macro world. In the world of RTOS's, interrupt latency
and micro-controllers, it makes all the difference.
Richard Heathfield
"unfinished business" to sort out...]
Richard Heathfield wrote:
>
> Ioannis Vranos wrote:
> >
<huge snip>
>
> > > > and does not lack in speed
> > > > (in many cases it is faster).
> > >
> > > Evidence? Hard data?
> >
> > In speed?
> >
> > see my http://users.forthnet.gr/ath/jvr/c++faq.htm
>
> When I get a minute, I'll check it out. (I do Usenet offline.)
I've checked it now. It's an isolated example (which you have posted to
this newsgroup before, BTW) of one algorithm being faster in C++ (on one
particular implementation on one particular platform on one particular
machine) than in C. Do you have any evidence of a slightly more
rigorously scientific nature?
<snip>
Dave Mikesell
> Unfortunately, when you criticize C++ in any way, in any forum, you
> are preaching christianity to the muslims.
Nice generalizations, w.r.t both C++ programmers and muslims. There
are zealots for every language, religion, football team, soap opera,
caramel-colored carbonated beverage, and political cause under the
sun. If you don't realize that they represent a small (albeit vocal)
minority of their particular cause, then you haven't learned much in
your professional career.
Now where have I heard that before...