The microsoft guy might have been talking about managed c++, which us a somewhat different language.
On Mar 17, 2011 11:47 PM, "David Favro" <
lua@meta-dynamic.com> wrote:
> On 03/16/2011 11:58 AM, Tim Johnson wrote:
>> When I began transitioning from C to C++, I experimented with
>> writing small applications compiled/linked in both C and C++ and
>> noted that C++ source generated much larger binaries. By examining
>> the binaries, I could see that a lot of the extra bytes in the C++
>> binaries were the result of munging for overloaded functions.
>
> man strip
> That's not what I call "binaries."
>
>> I am related to a developer for Microsoft. He says that the use of
>> C++ is favored by higher-ups because the greater OOP approach of
>> C++ translates better to team development, but assets that both C
>> and assembler are used in bottlenecks.
>
> Assembler might make sense, but using C rather than C++ for "bottlenecks"
> makes no sense since C++ is (essentially) a superset of C, i.e. any C
> program is itself (almost) a C++ program, and typically if C code is
> compiled with a C++ compiler rather than a C compiler (with the same
> code-generation/optimization back-end, e.g. cfront+cc vs. cc alone, or g++
> vs. gcc) will generate essentially the same (or, more often, exactly the
> same) object code, modulo symbols. This was, in fact, one of the design
> goals of the language.
>
> So maybe your MS friend should have said that he uses a different C++ coding
> style (perhaps avoiding certain higher-level abstractions, virtual methods,
> exceptions) for performance-critical routines or inside that inner inner
> loop. Switching compilers is not going to make any difference at all.
>
> Furthermore, in many (but not all) cases that I see people reverting to "C
> style" or assembler code rather than C++ "because I needed the efficiency,"
> they could have accomplished far better performance gains by avoiding really
> stupid choice of algorithms, data structures, and coding practices, in favor
> of more efficient ones. I see a lot of atrociously inefficient C code with
> the developer bragging about how efficient it is "because it's in C."
>
> -- David
>
