Re: Standard Template Library or C?
Hi,
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