Jim,
I just use libstd++ coming with gnu g++, it's not too big (shared ~300k)
compared to glibc (shared ~1.2 M)
when linking statically, the linker normally only takes what you need,
so this will be less.
Jaap-Jan
Hello,
I have currently have some applications running with glibc/ulibc ...
For porting purposes I would find it nice if there were some nice and
small C++ libs supporting basic STL features (sets, vectors, lists) and
things like iosstreams ...
Anyone have any recommendations ...
I believe last time I checked most C++ libs are rather large ??
Any advice would be great ... thanks ...
Jim
---
J.G.J. Boor
Lucent Technologies Nederland b.v. Room: BE-525
Optical Networking Group TMS Data Phone: +31 (0)35 687 4721
Larenseweg 50, P.O. Box 1168, Fax: +31 (0)35 687 5976
1200 BD, Hilversum, The Netherlands mailto:jjboor@lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Jaap-Jan Boor wrote:
I just use libstd++ coming with gnu g++, it's not too big (shared ~300k)
compared to glibc (shared ~1.2 M)
problem is that the STL is a template library, so a lot of code is
produced when using these tamplates.
i highly recommend to use normal lists and cast pointers (like in good
old C times) again, even with the need of allocating two chunks per list
item (pointer and data itself).
Using STL makes your application MUCH bigger, and, often slower.
STL is optimized for huge data structures, but for most things
memcpy'ing (and using for example an array/vector) is much faster than
using a list or hash, which has optimal - for example linear or even log
- complexity. The thing the STL guy forgot is to keep in mind than
1000*linear (list insertions... ) is still worse than 1*exp (memcpy when
doing vector insertions... but take this only as an example) when your
list has, for example, 5 entries.
and most of the lists are NOT accessed ten thousand times, do NOT have
one million entries where 1000*linear is a LOT more than 1*exp complexity.
just my 2 cent...
felix
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Felix> The thing the STL guy forgot is to keep in mind than
Felix> 1000*linear (list insertions... ) is still worse than 1*exp
Felix> (memcpy when doing vector insertions... but take this only
Felix> as an example) when your list has, for example, 5 entries.
This isn't really on topic for the linuxppc list, but anyway...
What you say isn't really true. The STL is generally quite efficient,
and provides both vector<> and list<> data structures (in addition to
slist<> and deque<>).
In fact, since a good implementation of vector<> will double the size
of its memory allocation each time it needs to grow it, the cost of
adding elements to the vector<> is still linear when amortized.
Best,
Roland
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/