What Am I Missing?

[Mike Copeland]

I have a lot of C-based code that I'm (slowly) converting to C++,
STL, and what I hope to be code that's easier to manage. I'd also like
to gain performance increases and reduced code - but I'm not really
seeing the latter improvements. 8<{{
As I think about it, there appear to be some trade-offs with either
type of coding:
1. C-based strings require fixed (max) size declarations and runtime
code to scan these character strings to determine size - so that
operations can be made on them. There's overhead in both object file
size and execution processing to deal with such data.
2. STL strings, on the other hand, are instantiated as object pointers
that require runtime memory allocation(s), which might be done over and
over as the data values change throughout execution. (That is, checks
must determine if currently allocated data sizes are adequate, and
deallocation/reallocation done if not. This might require substantial
runtime logic to do for each and every string object.)
Thus, program object sizes should probably be smaller for C++
programs, but C-based programs should generally be larger than
corresponding C++ executables. I'm not seeing this phenomenon at all -
in fact, the opposite seems true.
I don't know if C++ programs execute any faster than C programs (I
suspect they don't), and I don't know if any of my applications would
expose this fact, either way.
I do know that my C++ programs are invariably larger than their C-
based versions.
If there's no other factor in what I'm seeing, I guess the only real
benefit to C++ and STL is ease of coding, debugging and maintenance.
<sigh> Any thoughts?

 

[Ian Collins]

I have a lot of C-based code that I'm (slowly) converting to C++,
STL, and what I hope to be code that's easier to manage. I'd also like
to gain performance increases and reduced code - but I'm not really
seeing the latter improvements. 8<{{
As I think about it, there appear to be some trade-offs with either
type of coding:
1. C-based strings require fixed (max) size declarations and runtime
code to scan these character strings to determine size - so that
operations can be made on them. There's overhead in both object file
size and execution processing to deal with such data.
2. STL strings, on the other hand, are instantiated as object pointers
that require runtime memory allocation(s), which might be done over and
over as the data values change throughout execution. (That is, checks
must determine if currently allocated data sizes are adequate, and
deallocation/reallocation done if not. This might require substantial
runtime logic to do for each and every string object.)

C++ strings (STL isn't an appropriate prefix) can also have a fixed size
reservation, just as C strings would have to be dynamically managed if
the initial size wasn't known. So there's no additional cost with C++
strings, but considerable savings in programmer effort!

Thus, program object sizes should probably be smaller for C++
programs, but C-based programs should generally be larger than
corresponding C++ executables. I'm not seeing this phenomenon at all -
in fact, the opposite seems true.

Define size. Fully optimised and stripped binary? Debug binary?

I don't know if C++ programs execute any faster than C programs (I
suspect they don't), and I don't know if any of my applications would
expose this fact, either way.
I do know that my C++ programs are invariably larger than their C-
based versions.
If there's no other factor in what I'm seeing, I guess the only real
benefit to C++ and STL is ease of coding, debugging and maintenance.
<sigh> Any thoughts?

Those are big benefits.

 

[Jorgen Grahn]

I have a lot of C-based code that I'm (slowly) converting to C++,
STL, and what I hope to be code that's easier to manage. I'd also like
to gain performance increases and reduced code - but I'm not really
seeing the latter improvements. 8<{{ ....
I don't know if C++ programs execute any faster than C programs (I
suspect they don't), and I don't know if any of my applications would
expose this fact, either way.

So you don't know, and it's not important to you. Why complain
about it, then?

I do know that my C++ programs are invariably larger than their C-
based versions.
If there's no other factor in what I'm seeing, I guess the only real
benefit to C++ and STL is ease of coding, debugging and maintenance.
<sigh> Any thoughts?

Seems to me your only remaining complaint is code size, of some kind,
but you're very vague about that too. Can you be more precise, and
also explain why it matters to you?

In general, I expect a good C++ executable solving problem Foo to be
comparable in size to a C executable solving problem Foo. I don't
expect it to be smaller, although I wouldn't be surprised if it was.

The two non-trivial programs I'm working on right now are 56 kB and 43
kB, respectively (but a megabyte each if I choose to include debug
information).

/Jorgen

 

[Öö Tiib]

I have a lot of C-based code that I'm (slowly) converting to C++,
STL, and what I hope to be code that's easier to manage. I'd also like
to gain performance increases and reduced code - but I'm not really
seeing the latter improvements. 8<{{

Efficiency is a tricky thing. It is possible to have speed gain by paying
with memory and memory gain by paying with speed and safety/debugging ease
gain by paying with other two. Usually you have to tell to compiler what
you favor currently, since you can't get everything. Sometimes the code can
optimized manually too however first one should learn to use the language
and then to profile it and optimize to efficiency.

As I think about it, there appear to be some trade-offs with either
type of coding:

1. C-based strings require fixed (max) size declarations and runtime
code to scan these character strings to determine size - so that
operations can be made on them. There's overhead in both object file
size and execution processing to deal with such data.

2. STL strings, on the other hand, are instantiated as object pointers
that require runtime memory allocation(s), which might be done over and
over as the data values change throughout execution. (That is, checks
must determine if currently allocated data sizes are adequate, and
deallocation/reallocation done if not. This might require substantial
runtime logic to do for each and every string object.)

Almost for any special case there can be slightly more efficient solution
than standard library offers (if that case matters) and often it is
freely available.

For example if you mean string literals by "C-based strings" then
std::string is fine enough but not ultimately efficient wrapper of
string literals. std::string is like char buffer allocated with malloc
in C. That is most efficient for cases when string's size is not known
compile time. When your program is handling mostly string literals
instead then there are freely available specialized classes for that
case like:
http://sourceforge.net/p/boost-log/...oost-log/boost/log/utility/string_literal.hpp

Thus, program object sizes should probably be smaller for C++
programs, but C-based programs should generally be larger than
corresponding C++ executables. I'm not seeing this phenomenon at all -
in fact, the opposite seems true.

I don't know if C++ programs execute any faster than C programs (I
suspect they don't), and I don't know if any of my applications would
expose this fact, either way.

The most important factor in software development is always located
between keyboard and chair. Novice can write lot less efficient program
in Assembler than expert writes in Python.

I do know that my C++ programs are invariably larger than their C-
based versions.

You need to be more specific here. What platform, what compiler, what
compilation options and what code. We have not observed major difference
in well written results and there are no certain trends either direction.

Generally C is still competitive but C++ is about as good on embedded
systems (if you only have C++ compiler for the target). The only certain
trend is that C++ compiles invariably longer than C. That matters less
since it is often possible to cloud-compile larger projects.

If there's no other factor in what I'm seeing, I guess the only real
benefit to C++ and STL is ease of coding, debugging and maintenance.
<sigh> Any thoughts?

Output of debugging builds is usually large and slow indeed. No one
ships these debugging builds to end users. Optimized builds are deployed
to end users.

 

[Johann Klammer]

I have a lot of C-based code that I'm (slowly) converting to C++,
STL, and what I hope to be code that's easier to manage. I'd also like
to gain performance increases and reduced code - but I'm not really
seeing the latter improvements. 8<{{
As I think about it, there appear to be some trade-offs with either
type of coding:
1. C-based strings require fixed (max) size declarations and runtime
code to scan these character strings to determine size - so that
operations can be made on them. There's overhead in both object file
size and execution processing to deal with such data.
2. STL strings, on the other hand, are instantiated as object pointers
that require runtime memory allocation(s), which might be done over and
over as the data values change throughout execution. (That is, checks
must determine if currently allocated data sizes are adequate, and
deallocation/reallocation done if not. This might require substantial
runtime logic to do for each and every string object.)
Thus, program object sizes should probably be smaller for C++
programs, but C-based programs should generally be larger than
corresponding C++ executables. I'm not seeing this phenomenon at all -
in fact, the opposite seems true.
I don't know if C++ programs execute any faster than C programs (I
suspect they don't), and I don't know if any of my applications would
expose this fact, either way.
I do know that my C++ programs are invariably larger than their C-
based versions.
If there's no other factor in what I'm seeing, I guess the only real
benefit to C++ and STL is ease of coding, debugging and maintenance.
<sigh> Any thoughts?

Avoid templates. They'll create bloat if used the wrong way. And it is
not always faster either.

 

[Johann Klammer]

Efficiency is a tricky thing. It is possible to have speed gain by paying
with memory and memory gain by paying with speed and safety/debugging ease
gain by paying with other two. Usually you have to tell to compiler what
you favor currently, since you can't get everything. Sometimes the code can
optimized manually too however first one should learn to use the language
and then to profile it and optimize to efficiency.


Almost for any special case there can be slightly more efficient solution
than standard library offers (if that case matters) and often it is
freely available.

For example if you mean string literals by "C-based strings" then
std::string is fine enough but not ultimately efficient wrapper of
string literals. std::string is like char buffer allocated with malloc
in C. That is most efficient for cases when string's size is not known
compile time. When your program is handling mostly string literals
instead then there are freely available specialized classes for that
case like:
http://sourceforge.net/p/boost-log/...oost-log/boost/log/utility/string_literal.hpp


The most important factor in software development is always located
between keyboard and chair. Novice can write lot less efficient program
in Assembler than expert writes in Python.


You need to be more specific here. What platform, what compiler, what
compilation options and what code. We have not observed major difference
in well written results and there are no certain trends either direction.

Generally C is still competitive but C++ is about as good on embedded
systems (if you only have C++ compiler for the target). The only certain
trend is that C++ compiles invariably longer than C. That matters less
since it is often possible to cloud-compile larger projects.

I suspect debians blender compile(for mips) to routinely get killed by
linux's oom-killer. They use a distributed build system thingy. Some
boxen just barf if a g++ or ld process gets larger than 800 MiB...

 

[woodbrian77]

I think that you have a slight misconception. Converting code from
a typical C style to C++ style isn't going to somehow magically make
it more efficient. There are *some* situations that do (eg. using
std::sort() instead of qsort()), but in most cases the advantages of
C++ is shorter, cleaner and especially *safer* code than the equivalent
C implementation, not necessarily efficiency.

I agree about the magically part, but the shorter form
makes it easier to think about the code and spot things
like copying that can sometimes be eliminated.

You have to understand what the standard library containers are doing
inside, and always choose the right tool for the job.

OK, but right tool may not be in the standard. There are a
number of quality containers not in the standard. Depending
on the context, you may not be able to use the tool you would
like to use.

Brian
Ebenezer Enterprises
http://webEbenezer.net

 

[goran.pusic]

I have a lot of C-based code that I'm (slowly) converting to C++,

STL, and what I hope to be code that's easier to manage. I'd also like

to gain performance increases and reduced code - but I'm not really

seeing the latter improvements. 8<{{

As I think about it, there appear to be some trade-offs with either

type of coding:

1. C-based strings require fixed (max) size declarations and runtime

code to scan these character strings to determine size - so that

operations can be made on them. There's overhead in both object file

size and execution processing to deal with such data.

2. STL strings, on the other hand, are instantiated as object pointers

that require runtime memory allocation(s), which might be done over and

over as the data values change throughout execution. (That is, checks

must determine if currently allocated data sizes are adequate, and

deallocation/reallocation done if not. This might require substantial

runtime logic to do for each and every string object.)

That is correct. If you think a bit further, you'll realize that it is hardfor c++ string code to be faster - it is using dynamic memory where c string code uses naked pointers to fixed-size buffers, and likely much less reallocation.

However, what c++ string code gives is better overall memory use, as with fixed-size arrays, one is likely to overshoot for contingency. Also, c++ string code allows you to think much less about those sizes. This is not mere programmer convenience - this is literally code flexibility. So you need previous max * 2? No problem! (Provided dynamic memory, of course).

Thus, program object sizes should probably be smaller for C++

programs, but C-based programs should generally be larger than

corresponding C++ executables. I'm not seeing this phenomenon at all -

in fact, the opposite seems true.

Likely a consequence of a bigger standard lib (if linked statically) and much more copying around - where you used to pass pointers to character buffers, you now copy string objects around.

Hth,

Goran

 

[Gerhard Fiedler]

I agree about the magically part, but the shorter form makes it
easier to think about the code and spot things like copying that can
sometimes be eliminated.

This "shorter, cleaner and safer" part normally requires quite some
refactoring; only moving from C to C++ by replacing char* with
std::string and arrays with std::vector or std::array (for example)
doesn't really give you much of this.

Gerhard