Re: Standard Template Library or C?
On Oct 25, 3:11 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
With pure C, I believe the efficiency is better,
C compared to C++: no, that is obviously untrue. (Although C
code written for speed can naturally be a lot faster than
badly written C++, or C++ written for safety or rapid
prototyping).
And badly written C is a lot slower than well written C++. And
it's a lot easier and a lot more natural to write C++ well, with
good encapsulation, than it is C. In the past, I've worked on a
couple of projects where data was handled both in C and in C++,
and the C++ has always been faster. The key to speed is
encapsulation, so that you can easily tune the bottlenecks
later, once they've been identified, and good encapsulation, in
C, is difficult (and expensive in run-time)
[...]
and the portability might be better too,
Why? C++ and its standard library is the same on both Linux
and Windows. Your ARM system is apparently powerful enough to
run Linux, so it folds into the same category.
The C++ standard library tends to favor speed over space, so it
might not be appropriate in cases where memory is very tight.
[...]
I also care about the portability. I am not sure how well
the concurrent ARM processor and free compilers like gcc
will support STL.
- It's gcc's job to support this ARM.
Recent versions (since about 3.1 or 3.2, I think) have one of
the best implementations of the standard library around.
(Dinkumware's still seems a little better, but the difference
isn't anywhere near as large as it used to be.)
- There are no specific gcc/STL issues that should worry you.
- "Free compilers" used to worry people in the 1990s, but
gcc hasn't had real problems with C++ since gcc 2.95, ten
years ago.
Unless you were writing multithreaded code:-). G+ didn't start
supporting mutlithreaded code officially until 3.0 (and of
course, the earliest support was pretty buggy), long after
everyone else did. (And of course, g++ 2.95 came with the
"traditional" library, rather than the standard one.)
All of which is very much in the past, however, and shouldn't be
a concern today.
--
James Kanze