Author: Bo Persson
Date: 15:06:20 06/12/02
Go up one level in this thread
On June 12, 2002 at 17:11:27, Dann Corbit wrote: >On June 12, 2002 at 17:02:48, Russell Reagan wrote: > >>On June 12, 2002 at 16:08:47, Bo Persson wrote: >> >>>For MSVC++ 7.0, The code for f() looks like this >> >>When did 7.0 come out? Or are you using a beta version? > >He means .net > Yes. It was called 7.0 for several years until MS marketing settled for .NET instead... It is actually the Visual Studio that is ver 7.0 (not meaning the 7th version). The compiler itself is ver 13.0 (which is the 11th main release, counting the earlier C-only compilers!). Who's confused... ;-) BTW, the next release is now called 7.1, until the marketing dept tells us its *real* name... >>>I especially notice that line 20 doesn't generate any code at all except for the >>>stack space allocation (sub esp,520). >> >>So there is still a function call being made by the constructor? Or is that by >>the function f()? > >That's a single assembly language instruction. It means subtract 520 from the >stack because there is automatic data there. > >>And what do you mean by "C++ code bloat"? I assume it has something to do with >>the ASM that was generated? > >It's a rumor. It's a rumor nasty enough that it seemed to scare Russell away from using C++ classes. My point was that the supposedly "dangerous" construct actually didn't generate any code at all! > It does not happen in properly written programs. Like anything >else, you can do it badly. For instance, if you write assignment operators and >don't make a reference version or if you always pass huge objects by value >instead of reference or rely heavily on RTTI or many of a large list of evil >sins then you can get into trouble. Does anyone know of a useful computer >language that you can't get into trouble with? > [...] >Well written C++ code will be about the same size and about the same speed of >the equivalent C code. In the cases where there is some small performance hit >(for instance heavy use of virtual member functions) the gain in abstraction is >so valuable we would want to do it anyway. The extra abstraction often (in my experience) leads to more readable code, that in turn gives more opportunities for simplifying the code. C++ code is sometimes even *much* faster than plain C code. You might want to read Bjarne Stroustrups paper "Learning Standard C++ as a New Language" which explains, among other things, why C++ std::sort() is *much* faster than C's qsort(). http://www.research.att.com/~bs/new_learning.pdf Bo Persson bop2@telia.com
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.