Standard Template Library or C?
Johnson
program requires high efficiency, high data safety, and good portability
(for both PC and ARM hardware platform, Windows and Linux OS). Now I
have two options to do the job, either using pure C (with pointers and
dynamic allocated memory) or STL.
With pure C, I believe the efficiency is better, and the portability
might be better too, while the data safety will be worse, since I need
to take care of the memory management and wild pointers.
With STL, life becomes much easier for me, but I worried about its
efficiency. I actually don't need most of the algorithms and iterators
provided by the STL. I am not sure if the performance of STL is close to
that of C. I will be happy if it is only 10 or 20 percents slower. I
don't dream it will be faster than C. I also care about the portability.
I am not sure how well the concurrent ARM processor and free compilers
like gcc will support STL.
Could anybody please be kind to give some advice and insight?
Thank you very much!
Johnson
Victor Bazarov
C++ was developed to overcome certain drawbacks of C and to introduce
new concepts that make large-scale software development easy while
keeping the portability and efficiency. What you should do is trust the
tool you know to do the job for/with you. That trust seems to be
missing judging from your post.
Efficiency of languages cannot be adequately compared by comparing the
resulting executables. You have to factor in such elements like length
of development, debugging, quality of the resulting product from the
maintainability point of view. Also, in every language it is possible
to write inefficient programs, so you have to use the most efficient
algorithms.
The usual advice given here is, use what you know. If it's C that
you're most comfortable with, use C and leave STL (or whatever) alone
for the time when you get more time to learn it. If it's C++, go with
it and don't look back (at C), you're getting more out of it than you think.
Performance is important, especially when there are lots of data to
process. However, it doesn't matter how fast you do it if you don't do
it right. Make it work first, then measure and see whether you can make
your program run faster. There are tools for that. They are called
"profilers". Learn them and use them. After you got your program
working, that is.
Good luck!
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Johnson
Great. Thank you for your advice.
Michael Oswald
> Great. Thank you for your advice.
In addition to Victors comments, there was a thread longer ago (about
half a year?) where somebody implemented a queue in C, optimised it as
much as possible and then compared it to an STL implementation (I think
from g++). It turned out that the STL implementation was faster no
matter how much he optimized the C queue. I don't remember the outcome
of the thread (and I don't have a msg ID at hand now), but I think it
was about that the C++ compiler could perform a better inlining of the
templated queue.
Anyway, this was a special case. For general, I second Victors solution,
first get it right and then if you need more performance, measure first.
If it's large data to process the IO could be more of a bottleneck than
the difference between a C and a C++ container.
lg,
Michael
Marcel Müller
Johnson wrote:
> With pure C, I believe the efficiency is better, and the portability
> might be better too, while the data safety will be worse, since I need
> to take care of the memory management and wild pointers.
I would strongly recommend to avoid pure C wherever possible, since you
will avoid many of the typical C bugs with undefined behavior too.
> With STL, life becomes much easier for me, but I worried about its
> efficiency. I actually don't need most of the algorithms and iterators
> provided by the STL. I am not sure if the performance of STL is close to
> that of C.
It depends. If you need all the features of the STL container you use
there will be almost no difference. However, STL does not provide a
minimalistic solution for each problem.
Choosing the right container types and data structures will mostly
determine the efficiency.
> I am not sure how well the concurrent ARM processor and free compilers
> like gcc will support STL.
gcc supports STL very well for years. So also if you have no recent gcc
version you will not run into problems with most of the common features
of STL.
> Could anybody please be kind to give some advice and insight?
You have another two options.
First, you may look for further platform independent class libraries
like boost. They provide additional classes for certain purposes. E.g.
bost::array if the size of your container is fixed after construction.
And last but not least, you may include your own optimal matching
container classes in you application. This is portable too. And if you
are smart enough there is no performance impact in comparison to a
portable C application at all. In fact you may have low level functions
with all tricks available in the C language and wrap them by a template
class for type safety.
To give you an example: some time ago I wrote a non-mutable string class
(Java like) that is binary compatible to constant C style strings. It
provides copy by reference with reference counting. This is mostly more
efficient than strdup. The memory layout is:
reference_count (size_t)
length (size_t)
mystring -> char array (null terminated)
The string reference does not point to the beginning of the internal
storage structure but to the value of the string. Since mystring is non
polymorphic and contains exactly one member of type const char* a
reinterpret_cast from mystring to const char* is valid (including NULL
values). The class mystring wraps this safely and provides access to the
embedded length too. Furthermore, even a cast from
std::vector<mystring>.begin() to const char*const* is defined behavior
for the same reason. This makes the adaption of old C libraries quite
easy and fast.
The additional 2 integers of storage are usually overcompensated by the
storage sharing by far.
And even more the class mystring makes reads and writes to volatile
references atomic, i.e. it provides strong thread safety - but only
where needed. (This part is no longer 100% portable since std::atomic is
not yet that common.)
All of that works on a very old C++ compiler from '96 as well as with
gcc 4.3.
I don't know the special needs of your application, but I am almost sure
that there is a highly efficient solution in C++. There is almost
nothing you can do with C that you can't do with C++ too. And in most
cases the latter is more safe.
Marcel
Juha Nieminen
> but I think it
> was about that the C++ compiler could perform a better inlining of the
> templated queue.
It's the same as with sorting. C's qsort() cannot beat C++'s
std::sort() no matter how much effort is put into it. The reason is
simple: The compiler cannot inline anything nor make any type-specific
optimizations with qsort(), while it can with std::sort() (for example,
if you are sorting a vector of ints, the compiler can optimize the
less-than comparison directly to machine code register comparisons, inline).
Sometimes templates have efficiency advantages over C, not only
generic programming advantages.
Johnson
Thank you, Michael. Now I believe the STL might be even faster than the
ANSI C solution. However, I don't understand why the C++ compiler could
perform a better inlining of the queue than the C compiler. Can I
inlining the queue in C if I want to?
Bo Persson
Yes, you can do the inlining in C, if you want to, but you have to do
it separately for each type queued.
With a C++ template, the compiler does it for you, from a single set
of source code.
Bo Persson
James Kanze
> Michael Oswald wrote:
> > but I think it was about that the C++ compiler could perform
> > a better inlining of the templated queue.
> It's the same as with sorting. C's qsort() cannot beat C++'s
> std::sort() no matter how much effort is put into it. The
> reason is simple: The compiler cannot inline anything nor make
> any type-specific optimizations with qsort(), while it can
> with std::sort() (for example, if you are sorting a vector of
> ints, the compiler can optimize the less-than comparison
> directly to machine code register comparisons, inline).
Technically, that's not really true, but it is several orders of
magnitude more difficult for the compiler to do so. Even if it
is theoretically possible, very, very few compilers do it.
Whereas I don't know of any compiler which won't use registers
(instead of a temporary variable) when doing the swap in
std::sort.
> Sometimes templates have efficiency advantages over C, not
> only generic programming advantages.
The more the compiler knows, the better it can optimize. When
the compiler instantiates a copy of std::sort, it knows exactly
what the data type is, and how to do the compares. A C compiler
would have to examine the entire program, find every call to
qsort, evaluate its arguments, etc., etc., in order to find
similar optimizations.
--
James Kanze
Jorgen Grahn
On Wed, 2009-10-21, Johnson wrote:
> I am writing a cross-platform program that deals with huge data set. The
> program requires high efficiency, high data safety, and good portability
> (for both PC and ARM hardware platform, Windows and Linux OS). Now I
> have two options to do the job, either using pure C (with pointers and
> dynamic allocated memory) or STL.
Or some other library, or write "pure C++" instead of "pure C".
> 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).
Hand-written data structures in C or C++, versus STL containers:
it depends entirely on what your problem is. We only know you have
huge data sets, presumably in memory. Will it need huge arrays, huge
search trees, or huge linked lists?
The standard library has code written by experts, and the templates
tune it to your application.
> 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.
> while the data safety will be worse, since I need
> to take care of the memory management and wild pointers.
>
> With STL, life becomes much easier for me, but I worried about its
> efficiency. I actually don't need most of the algorithms and iterators
> provided by the STL.
To use an STL container properly, you *will* need to use its
iterators.
As far as algorithms are concerned, *noone* needs all of them. But if
you stop to think about it, you'll realize that you lose no efficiency
just because someone has defined std::set_difference or
std::lexicographical_compare_3way. They are typically generic;
the containers do not even know they exist.
> I am not sure if the performance of STL is close to
> that of C. I will be happy if it is only 10 or 20 percents slower. I
> don't dream it will be faster than C.
I think you mean "I know people claim it's faster than the C equivalent,
but they are just dreaming". I don't know ... see above.
> 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.
- 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.
- In terms of speed, a vendor's processor-compiler seems to often
outsmart gcc, but not by much I believe. I don't see that this
has any impact on your problem, though -- unless you manage to
find a vendor who has a state-of-the-art C compiler, but no
half-decent C++ compiler. I don't think such a vendor exists.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Rune Allnor
I started out a few years ago in exactly the same spot you
are now: I knew some close-to-the-silicone C, and distrusted
the C++ STL because of a percieved overhead. My C basic traning
had conditioned me to regard anything that was not obviously
useful as highly suspicious, from a performance POV.
The key to change my mind was to realize that the STL uses
templates.
My problem was that I did not know anything about templates,
or how they work. Templates are 90% complete code (type
info is missing). The crux is that - this might be an over-
simplification, but leave that for now - the compiler needs
to see *all* the relevant template code *all* the time, to
be able to produce executable code at compile time.
Because the compiler sees all the template code all the time,
it is in a far better position to optimize the whole program
than a C compiler that only sees one translation unit at the
time. And you as programmer can actually *both* code up
readable, comprehensable, maintainable code *and* get run-time
performance only marginally worse than cryptic almost-assembly
C code.
Only last week the optimizing compiler sped up my code by
a factor 50-100 from the debug build (which follows the
source code in minute detail) to the optimized release
build. I doubt a C compiler would be able to anything close.
Rune
Nick Keighley
> I knew some close-to-the-silicone C
silcon is for chips, silicone is for breast enhancement
James Kanze
> > 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
Victor Bazarov
Silicon is for chips. Note the second 'i'.
Puppet_Sock
> I am writing a cross-platform program that deals with huge data set. The
> program requires high efficiency, high data safety, and good portability
> (for both PC and ARM hardware platform, Windows and Linux OS). Now I
> have two options to do the job, either using pure C (with pointers and
> dynamic allocated memory) or STL.
I would suggest that, at least as presented, your spec if inadequate.
You say you need high efficiency. This is literally of no meaning.
High compared to what? By what scale? You need to specify some kind
of numerical value you can test. Then you need to do some prototype
testing to see if this numerical value is in fact achievable by
any means. If you can't get there from here no matter what you do,
then you need to go back to your client sooner rather than later and
re-set the spec.
The spec might be something like "convert 1000 records from external
to internal in not more than 43 seconds." If, with a representative
sample of records, nothing you can do can convert them in less than
400 seconds, you are toast from the start and need to re-do the spec.
Or, if you can't renegotiate, then punt on the project. Possibly
by quitting and finding a new job.
All of your spec needs to be in objective, clear, testable format.
Otherwise it's just going to turn into a big shoving match with
the client over whether you have satisfied the spec. Numbers or
conditions for everything, along with specific limits or tests.
Regarding portability: The primary thing there is likely to be the
special purpose libraries you add onto whatever language you use.
The language itself is unlikely to restrict you too badly, as long
as you restrict to the core parts of the language, and stay away
from stuff that is flaky on some compilers.
If your database libs can be called from either C or C++, then it's
likely to be indifferent. If you are doing window-interface type
stuff, then again, those libs are going to be a choke point.
If you can use those libs in all your platforms with either language,
then again, it's a wash. And so on. If you can only use one language
to easily do any part of that, then that's a push for that language.
Regarding what you talked about as "data safety" the primary thing
is going to be familiarity with the language. If your developer
team is loaded up with one language and less familiar with the
other, then that is a possible guide to what language to use.
Or you can get developers for one language but not the other.
Socks