You probably already know these, but I thought I'd report them anyway.  The code:

# long i = 1;
# double d = 1.0;
# real r = 2.0;
# printf( "%i %f %f\n", i, d, r );
# printf( "%f\n", d );
# printf( "%f\n", r );
# if( r == 2.0 )
#     printf( "real == 2.0\n" );
# else
#     printf( "real != 2.0\n" );
# printf( "real %s 2.0\n", r == 2.0 ? "==" : "!=" );

prints:

1 0.000000 0.000000
1.000000
-0.000000
real == 2.0
real Error: Access Violation

There are a few things going on here.  Real always prints as -0.0, floats print as 0.0 if they aren't the first element in the format string, and strings are a tad broken :)

well... these aren't really bugs since printf is doing exactly what it is supposed to do. Maybe I'm being too picky about the word "bug" (for example %f is only for type "float" not "double" or "real"). Walter said he is writing a printf replacement and since vararg functions can detect the types of the inputs the format strings will presumably become much simpler - if there are format strings at all.

"Sean Kelly" <sean@f4.ca> wrote in message news:cc1qqb$2dq7$1@digitaldaemon.com...
> You probably already know these, but I thought I'd report them anyway.
The
> code:
>
> # long i = 1;
> # double d = 1.0;
> # real r = 2.0;
> # printf( "%i %f %f\n", i, d, r );
> # printf( "%f\n", d );
> # printf( "%f\n", r );
> # if( r == 2.0 )
> #     printf( "real == 2.0\n" );
> # else
> #     printf( "real != 2.0\n" );
> # printf( "real %s 2.0\n", r == 2.0 ? "==" : "!=" );
>
> prints:
>
> 1 0.000000 0.000000
> 1.000000
> -0.000000
> real == 2.0
> real Error: Access Violation
>
> There are a few things going on here.  Real always prints as -0.0, floats
print
> as 0.0 if they aren't the first element in the format string, and strings
are a
> tad broken :)
>
>

In article <cc1suk$2gkq$1@digitaldaemon.com>, Ben Hinkle says...
>
>well... these aren't really bugs since printf is doing exactly what it is supposed to do. Maybe I'm being too picky about the word "bug" (for example %f is only for type "float" not "double" or "real"). Walter said he is writing a printf replacement and since vararg functions can detect the types of the inputs the format strings will presumably become much simpler - if there are format strings at all.

Good point.  I just downloaded 0.94 and floating point has completely changed for this input set.  The bad news is that it doesn't work at all now :)  I think I'm going to roll back to a previous version of the compiler and wait until printf is finished before moving forward.  Is there a place where old builds are stored?  I couldn't find one on the FTP site.


Sean

In article <cc1suk$2gkq$1@digitaldaemon.com>, Ben Hinkle says...
>
>well... these aren't really bugs since printf is doing exactly what it is supposed to do. Maybe I'm being too picky about the word "bug" (for example %f is only for type "float" not "double" or "real").

Just to be picky, %f is actually for type "double," at least according to the C99 standard.  But if D had been calling the Windows version of printf then it's quite possible their version just has different/older rules.  I know I've found quite a few discrepancies with scanf.

Sean

Sean Kelly wrote:

> In article <cc1suk$2gkq$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>well... these aren't really bugs since printf is doing exactly what it is supposed to do. Maybe I'm being too picky about the word "bug" (for example %f is only for type "float" not "double" or "real").
> 
> Just to be picky, %f is actually for type "double," at least according to
> the
> C99 standard.

oh yeah. duh. for some reason I was thinking of scanf. maybe because of the recent scanf + complex question. oh well!

> But if D had been calling the Windows version of printf
> then it's
> quite possible their version just has different/older rules.  I know I've
> found quite a few discrepancies with scanf.
> 
> Sean

Reals in D correspond to long doubles in C, which means you need to be using %Lf, not %f, to print them. Next, for strings use %.*s, not %s.

"Sean Kelly" <sean@f4.ca> wrote in message news:cc1qqb$2dq7$1@digitaldaemon.com...
> You probably already know these, but I thought I'd report them anyway.
The
> code:
>
> # long i = 1;
> # double d = 1.0;
> # real r = 2.0;
> # printf( "%i %f %f\n", i, d, r );
> # printf( "%f\n", d );
> # printf( "%f\n", r );
> # if( r == 2.0 )
> #     printf( "real == 2.0\n" );
> # else
> #     printf( "real != 2.0\n" );
> # printf( "real %s 2.0\n", r == 2.0 ? "==" : "!=" );
>
> prints:
>
> 1 0.000000 0.000000
> 1.000000
> -0.000000
> real == 2.0
> real Error: Access Violation
>
> There are a few things going on here.  Real always prints as -0.0, floats
print
> as 0.0 if they aren't the first element in the format string, and strings
are a
> tad broken :)
>
>

In article <cc3782$1idh$1@digitaldaemon.com>, Walter says...
>
>Reals in D correspond to long doubles in C, which means you need to be using %Lf, not %f, to print them. Next, for strings use %.*s, not %s.

Thanks.  Talking to Ben made me realize the problem with reals.  But thanks to the nifty new _arguments stuff, I suspect it won't be a problem for long :)  I'm having issues with normal doubles in 0.94, but I suspect this is because the new version of printf is incomplete, since the version in 0.93 worked just fine.

This is a related issue I ran into writing scanf.  The %s parameter currently accepts both C strings and D strings.  I had tried this to differentiate between them:

if( _arguments[arg] == typeid( char[]* ) )
// D string
else if( _arguments[arg] == typeid( char** ) )
// C string

But both typeids are equivalent--the first condition is called for both D and C strings.  And if I reverse them then the new first condition (char**) is called for both.  Is there any way to tell the difference between D and C strings using the typeid code (or really pointers to D and C strings, since I can't deref a void pointer)?  Assuming there isn't, I propose adding an extension to printf (%S) that corresponds to D strings.  I've already added this to scanf, since the %.*s syntax doesn't make sense in this context.


Sean

On Fri, 2 Jul 2004 18:56:40 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:

> In article <cc3782$1idh$1@digitaldaemon.com>, Walter says...
>>
>> Reals in D correspond to long doubles in C, which means you need to be using
>> %Lf, not %f, to print them. Next, for strings use %.*s, not %s.
>
> Thanks.  Talking to Ben made me realize the problem with reals.  But thanks to
> the nifty new _arguments stuff, I suspect it won't be a problem for long :)  I'm
> having issues with normal doubles in 0.94, but I suspect this is because the new
> version of printf is incomplete, since the version in 0.93 worked just fine.
>
> This is a related issue I ran into writing scanf.  The %s parameter currently
> accepts both C strings and D strings.  I had tried this to differentiate between
> them:
>
> if( _arguments[arg] == typeid( char[]* ) )
> // D string
> else if( _arguments[arg] == typeid( char** ) )
> // C string
>
> But both typeids are equivalent--the first condition is called for both D and C
> strings.  And if I reverse them then the new first condition (char**) is called
> for both.  Is there any way to tell the difference between D and C strings using
> the typeid code (or really pointers to D and C strings, since I can't deref a
> void pointer)?  Assuming there isn't, I propose adding an extension to printf
> (%S) that corresponds to D strings.  I've already added this to scanf, since the
> %.*s syntax doesn't make sense in this context.

The new printf would not necessarily have to even use %s %S %d %l etc.. in fact why should you need to tell it what type the arguments are at all? it already knows!

IMO the new printf should work something like this...

int a;
long b;
real c;

printf("my int is $1 my long is $2 and my real is $3",a,b,c);
printf("my long is $2 my real is $3 and my int is $1",a,b,c);

or similar, basically you specify the position of the arg to use, this allows this also:

printf("regan was $1 and also $1 again",a);

*if* you/walter are worried about compatibilty, then lets have a printf that works like the C one, but also a new variant that works something like I have described, simply call it 'print' perhaps.

the above proposal would be incomplete without the ability to print a type like another type, so for example if you want to print a char like an int, then you can use a cast i.e.

char c;
printf("regan was $1",cast(int)c);

Something just occured to me, if you say

printf("regan was $1",&c);
(like in C printf("%p",&c) or printf("%x",&c);

what TypeInfo does printf get? it's the address of a char, is that ever going to be handled differently to the address of a long or real or.. so should the TypeInfo be "char *" or should it simply tell you it's an "l-value"?

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Now that would make quick and dirty printf programs really fun to write :-)
and the translator folks would love it!

Regan Heath wrote:
> 
> IMO the new printf should work something like this...
> 
> int a;
> long b;
> real c;
> 
> printf("my int is $1 my long is $2 and my real is $3",a,b,c);
> printf("my long is $2 my real is $3 and my int is $1",a,b,c);
> 
> or similar, basically you specify the position of the arg to use, this allows this also:
> 
> printf("regan was $1 and also $1 again",a);
> 
> *if* you/walter are worried about compatibilty, then lets have a printf that works like the C one, but also a new variant that works something like I have described, simply call it 'print' perhaps.
> 
> the above proposal would be incomplete without the ability to print a type like another type, so for example if you want to print a char like an int, then you can use a cast i.e.
> 
> char c;
> printf("regan was $1",cast(int)c);
> 
> Something just occured to me, if you say
> 
> printf("regan was $1",&c);
> (like in C printf("%p",&c) or printf("%x",&c);
> 
> what TypeInfo does printf get? it's the address of a char, is that ever going to be handled differently to the address of a long or real or.. so should the TypeInfo be "char *" or should it simply tell you it's an "l-value"?
> 
> Regan.
> 

Regan Heath wrote:
> 
> The new printf would not necessarily have to even use %s %S %d %l etc.. in fact why should you need to tell it what type the arguments are at all? it already knows!
> 
> IMO the new printf should work something like this...
> 
> int a;
> long b;
> real c;
> 
> printf("my int is $1 my long is $2 and my real is $3",a,b,c);
> printf("my long is $2 my real is $3 and my int is $1",a,b,c);
> 
> or similar, basically you specify the position of the arg to use, this allows this also:
> 
> printf("regan was $1 and also $1 again",a);

I see two problems with this.  First, as per my post I don't know if there's any way to differentiate between a dynamic D array and a pointer to a sequence of the same type.  Hopefully Walter can suggest a method that may work.  Second, printf specifiers contain not only type information but formatting information as well.  This is really only an issue with floating point types, but in that case the user may want to specify whether they want scientific notation, decimal notation, etc.


Sean