Back from a computerless week-end, I feel like to have some:
Digression Time
Before starting my considerations, I'd like to thank all the guys who
are contributing to this thread with code, suggestions, links, whatever.
I'm not going, for the time being, to reply your last posts, but I'll
do, sooner or later.
As we know, when we use standard C functions we deal with an
abstract machine, and this very fact gives us the degree of portability
we can need if we code for cross-platform software systems.
In some occasions we code just for fun, like myself, or code for
a single platform [Mac, Linux, Windows, whatever] and the degree of
portability of our code is not our first concern.
So far we have seen that a very simple task like putting a thousand separator in a
number, for readability purpose, gives us a few choices and quite a lot of thinking.
But when I look at what my Win7 OS does when I ask it to display
some info about my testpad.c guess what I get?
Code:
C:\>dir *.c
Il volume nell'unità C è WIN7-64
Numero di serie del volume: 24E7-E258
Directory di C:\
09/07/2010 22:00 5.493 testpad.c
1 File 5.493 byte
0 Directory 26.987.839.488 byte disponibili
C:\>
As you can see my OS speaks italian and displays DATE and numbers
well formatted and localized. The same happens with the GUI properties
dialog box.
I am not sure about that, but I guess any modern OS does the same.
From a didactical point of view I need to know how I can solve the problem
using standard C functions but, at the same time, I need to know my
real machine as well. So while I have intention to carry on this experiment
of building a standard function for the given task, in a few weeks I'm going
to move towards the real machine I'm using, and have a look at the APIs
already doing what I need, and [why not] if this is more or less efficient than
the functions we built so far.
But the very next step is going to be:
The slowest but still reliable standard C99 formatting function you can dream about
A last consideration: I think a good name for the function we are building
should be itoas() = integer to ASCII with thousand separator.
Attached the slowest version I could manage to code and the output:
Code:
Testing version : frk_slow
------------------------------
Testing on Intel Core 2 Duo E6600 2.4 Ghz // IA32
OS = Windows 7 Ultimate 64 bit -- Compiler = Pelles C 6.00.4
Elapsed time: 4.883 ms to format 10.000.000 random numbers
----------------------------------------------------------
handling 0 ---> 0
handling 12 ---> 12
handling -12 ---> -12
handling 256 ---> 256
handling -256 ---> -256
handling 1000 --> 1.000
handling -1000 --> -1.000
handling 1000000 ---> 1.000.000
handling -1000000 ---> -1.000.000
handling 1000000000 ---> 1.000.000.000
handling -1000000000 ---> -1.000.000.000
handling 2147483647 -> 2.147.483.647
handling -2147483648 -> -2.147.483.648
And here we have the whole integer range performed with iMalc's itoas():
Code:
Testing version : iMalc
------------------------------
Testing on Intel Core 2 Duo E6600 2.4 Ghz // IA32
OS = Windows 7 Ultimate 64 bit -- Compiler = Pelles C 6.00.4
Testing the numbers from: -2147483648 to 2147483647
The formatting process has taken: 105,818 ms to perform the whole cycle
Now we need a second version, fast enough, and already pre-tested
to compare the whole integer range generated strings to confirm they
are doing the same thing.
If I correctly remember the only pre-tested and fast enough second
itoas() should be Elysia's version. The next test should take some 9-10'.
Let me know if there is a faster pre-tested version that I don't remember.