RE: [Dev-C++] itoa - atoi : another implementation

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...]=20
> Sent: Thursday, April 03, 2003 2:42 AM
> To: Ioannis Vranos
> Cc: 'Dev-C++'
> Subject: RE: [Dev-C++] itoa - atoi : another implementation=20
>=20
>=20
> I just tried to say that a itoa() with memory allocation is not of
> much value. It consumes a lot of CPU-time in allocation/release, it
> requires extra clean-up code, and a failure to clean will=20
> result in memory
> leaks.


Yes, if we are not good coders we can't depend on the library to do our
work. The library is responsible for its work only, and if it fails it
signals failure in case we know how to handle the problem or to abort =
under
control.

So "don't use memory on the free store because the user needs clean  up =
code
and may have memory leaks"  is not a problem of the library coder.


Regarding time cost, I prefer thread safety to time cost. If time cost =
of
malloc()/free() is considered huge you can provide a special itoa() or =
work
with a default parameter in C++ which would be nice.


char *itoa(int number, char *buffer=3D0);


For usual systems I would use an std::string.



> A itoa(int,char*[,int]) may even be used in a ISR with a deterministic
> behaviour, i.e. the answer will always be available in a fixed maximum
> time (with a fixed maximum stack use), and there is no way any running
> task may have locked a mutex. Code using malloc()/free() are extremely
> vulnerable for mutex locks. Good implementations of sprintf() is


Sorry, I have no idea what mutex locks are (and I don't want to bother =
to
searh in google, my current priority are PCs).



> mutex-free, but most of the time the supplier doesn't specify=20
> it in the
> documentation, so you don't know.
>=20
> Never any intention of embarrassing anyone. To make you=20
> really happy, I
> just noticed something really embarrasing. The ltoa()=20
> implementation for
> the RTOS I'm using will fail for a radix < 10 because the guy=20
> implementing
> it forgot that a smaller radix requires a bigger buffer. The=20
> code assumes
> wort-case buffer use for radix 10...
>=20
> I always consider dynamic heap usage as expensive.



Because you work for microcontrollers. On the other hand my major =
concern is
.NET. :)


> It's=20
> (almost) always ok
> in bread-and-butter programs but in drivers, servers, embedded
> environments and where the cude must support very long uptime=20
> with high
> memory utilization (constantly being close to the limit of available
> memory where heap fragmentation gets extra dangerous) great care is
> needed.


I understand. Well if you do bare metal programming you cann allocate =
the
entire free store and use it in a defragmented way (=3Dtime cost). But =
if you
do not use the free store, all that memory will go useless? The best
approach is use memory on the free store and if it gets too fragmented =
use
the automatic storage/stack.


C++ provides the ability to define the "placement operator new" which is
very nice since you can program it to use the stack instead of the heap =
or a
combination of them!


=20
> A NIC driver that allocates all packets when they arrive=20
> might easily get
> half transfer speed compared to a driver using a packet pool.=20
> This is a
> bit of problem with object-oriented languages, since extra=20
> allocations are
> so easily hidden somewhere in a base class=20
> constructor/destructor etc, and
> if you don't know what speed you should expect from your=20
> code, you don't
> notice the hidden slowdown.


OK.


Ioannis Vranos
=20
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys