Przemek,
stdint.h is C99, Does not exist in many compilers as BCC 5.5
As far I know hbmisc/spd.c is 100% compatible with sprintf() C99 and adds new
features.
It was allowed me, move C/C++ solutions to Harbour applications.
Of course, using C RTL snprintf().
Best regards,
Xavi
Przemyslaw Czerpak escribió:
On Fri, 23 Jan 2009, Mindaugas Kavaliauskas wrote:
Hi,
Hi,
I've wrote some basic version of the function.
Implemented:
- specifiers: c (char), s (string), d (decimal), f (float);
- flags: - (left align), + (print + sign), space (print space sign), 0
(zero padding);
- width;
- decimals;
- parameter numbers;
% [<param>$] [+|-|space|0] [<width>][.<dec>][c|s|d|f]
The goal was to be C compatible, i.e.:
- do not print STR() style '*' for to short width numbers;
- do not convert types (see below, for exceptions).
Harbour has different types than C, and full C compatibility is impossible,
or function behaviour will look weird, without any adaption to Harbour. So,
There are also some small differences to original print behavior, f.e.:
%012d in C printf() is 0 padded 12 length 'd' formatting and in this code
it's parameter 12-th 'd' formatting. I also do not see support for string
cutting, f.e.:
printf( "[%.3s]", "ABCDEF" );
Month ago I crated for my friend sprintf() implementation to use in embedded
system. It should be fully ANSI C compatible though some things like double
, long long support or positional parameters can be disabled to reduce the
code size, external dependencies and memory/stack usage and such reduced
version is used.
If does not support A, a, E, e, G, g conversions and simply redirect them
to F or f and conversions which needs locale setting. See notes in the code.
They were not necessary in this project and also they are not necessary for
us.
Now this code is strongly GCC related and will have to be updated for
other compilers but it can be easy done and it can be used as our own
hb_snprintf() implementation (of course I'll update copyright notice).
I'm attaching it. It should quite well show how different flags are
interpreted and their precedence in different conversions.
I've made a few small exceptions/extensions to strict C compatible
implementation:
- %d allows to take LOGICAL parameter type, and function prints "1" and
"0", for .T. and .F.. In C true/false is represented by integer values (of
some width) 1 and 0, so, introducing this extension for LOGICAL type, I
feel more C compatible.
It's OK for me.
- %f In C language %f uses 6 decimal places, but harbour has <decimal>
format inside numeric item, so, I've used this value for default. Without
this, we will need to show explicit <decimal> format for many things like
FIELD values, to get result we usually expect. However, I've not used
default default value for <width>, because nature of sprintf() is to print
numbers without left padding, using default <width> will do most numeric
print left padded and very incompatible to C.
OK
For discussion: I've implemented character %c printing using numeric values
(in C char type is numeric type), but it is common in Harbour to represent
character as strings on length 1. Maybe, we should extend %c, to accept
string type and use first character of string.
I think it's good idea.
For discussion: what function name should be used? Since the goal is to be
C compatible, I guess HB_SPRINTF() is better than HB_STRFORMAT().
If the formatting will be C compatible then I vote for HB_SPRINTF()
otherwise HB_STRFORMAT().
best regards,
Przemek
------------------------------------------------------------------------
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
