Regan Heath wrote:
> 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);

What if we have more than 9 arguments? "$10" is the 10th argument or the 1st argument followed by a zero?

We may also need aditional information on the format codes:
- number of characters to reserve (strings, integer, etc);
- max number of character before trunc (strings mostly);
- how to print thousands separator (localizable; integers and floats);
- hex char case (0X1EF vs 0x1ef) (integers only);
- how to decorate octals and hexadecimals (localizable; integers only);
- precision and significant digits (floats);
- full representation or scientific notation (floats).

And some of the above information may also appear among the arguments (for example, if you want to dynamic calculate column sizes, the number of characters to reserve would be better placed among the arguments).

-- 
Miles

"Threat Eliminated." - Tio

On Fri, 02 Jul 2004 18:00:09 -0700, Sean Kelly <sean@f4.ca> wrote:

> 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.

I was wondering the same thing, however, do you ever need to differentiate? What are you going to print in either case, an address right? or..

> 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.

True, e, f and g and also d, i, o and x behave differently. We could incorporate this information into the format string another way, more like the width and precision specifiers. I am struggling to come up with a nice compact way to do it...

Regan

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

On Sat, 03 Jul 2004 14:16:49 -0300, Juliano Ravasi Ferraz <contact@write-my-first-name-here.info> wrote:

> Regan Heath wrote:
>> 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);
>
> What if we have more than 9 arguments? "$10" is the 10th argument or the 1st argument followed by a zero?

The way the original printf avoids this problem is that when it uses numbers i.e. for width/precison etc it always follows them with either a . or the type character.  So in this case we'd have to use another $ char i.e.

printf("$1$0 $10$");

the first is param 1 followed by a 0, the second is param 10.

The other alternative is to use letters, that gives a slightly higher limit of 26, which only delays the problem.

> We may also need aditional information on the format codes:
> - number of characters to reserve (strings, integer, etc);
> - max number of character before trunc (strings mostly);
> - how to print thousands separator (localizable; integers and floats);
> - hex char case (0X1EF vs 0x1ef) (integers only);
> - how to decorate octals and hexadecimals (localizable; integers only);
> - precision and significant digits (floats);
> - full representation or scientific notation (floats).
>
> And some of the above information may also appear among the arguments (for example, if you want to dynamic calculate column sizes, the number of characters to reserve would be better placed among the arguments).

We want to try and do these things similarly to the orginal, so dynamic sizes would use the * symbol, width and precision would remain the same.. perhaps..

printf("$5.3,1$");

width of 5, '.' to seperate, precision of 3, ',' to seperate, then param number.

That leaves the differences between d, o, and x and also f, g and e which we can add as flags eg.

Existing flags
–
+
0
blank (' ')
#

New flags
o   - octal representation
x/X - hex representation
e   - scientific   (floats)
g   - most compact (floats)

eg.

printf(" $x,5.3,1$ ");  - in hex
printf(" $ x,5.3,1$ "); - in hex pad with spaces
printf(" $0x,5.3,1$ "); - in hex pad with zeroes
printf(" $#x,5.3,1$ "); - in hex prefix with 0x

printf(" $0o,*.*,1$ "); - in octal prefix with zeroes, dynamic width and precision

Regan

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

Regan Heath wrote:
> On Fri, 02 Jul 2004 18:00:09 -0700, Sean Kelly <sean@f4.ca> wrote:
> 
>> 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.
> 
> I was wondering the same thing, however, do you ever need to differentiate? What are you going to print in either case, an address right? or..

How each type is handled is different.  D arrays have a length specifier and are not null terminated (indeed, they may legally contain multiple nulls) while C arrays have no length specifier and are null terminated.  So the routine to find the end of each type will be different.  This turned out to be a problem for me with scanf.  I've added %S as the D alternative to %s and %C as the D alternative to %C but that leaves me with no good solution for scansets (%[a-b]).  I'm currently defaulting to D-style arrays in this case but the code will crash if a C-style array is passed.

>> 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.
> 
> True, e, f and g and also d, i, o and x behave differently. We could incorporate this information into the format string another way, more like the width and precision specifiers. I am struggling to come up with a nice compact way to do it...

Possibly something like this $[1f].  The braces could enclose all needed information about type formatting.  Or if consistency with scanf is desired then perhaps a different brace type: %{1f}.  Still not ideal, but it's something.


Sean

On Sat, 03 Jul 2004 16:05:08 -0700, Sean Kelly <sean@f4.ca> wrote:

> Regan Heath wrote:
>> On Fri, 02 Jul 2004 18:00:09 -0700, Sean Kelly <sean@f4.ca> wrote:
>>
>>> 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.
>>
>> I was wondering the same thing, however, do you ever need to differentiate? What are you going to print in either case, an address right? or..
>
> How each type is handled is different.  D arrays have a length specifier and are not null terminated (indeed, they may legally contain multiple nulls) while C arrays have no length specifier and are null terminated.   So the routine to find the end of each type will be different.  This turned out to be a problem for me with scanf.  I've added %S as the D alternative to %s and %C as the D alternative to %C but that leaves me with no good solution for scansets (%[a-b]).  I'm currently defaulting to D-style arrays in this case but the code will crash if a C-style array is passed.

Ahh.. I see.. you were talking about the value of the array, not the reference itself.
What typeinfo does it give for a D array? and what for a char *?

I suspect eventually the typeinfo will be different, and you will be able to treat them as you need to. Walter has mentioned several times that TypeInfo will get better. I dont think we can write this new printf variant until the TypeInfo updates/changes are complete.

>>> 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.
>>
>> True, e, f and g and also d, i, o and x behave differently. We could incorporate this information into the format string another way, more like the width and precision specifiers. I am struggling to come up with a nice compact way to do it...
>
> Possibly something like this $[1f].  The braces could enclose all needed information about type formatting.  Or if consistency with scanf is desired then perhaps a different brace type: %{1f}.  Still not ideal, but it's something.

See my post to Juliano, I came up with some ideas.

Regan

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

In 0.93, the code:

int main()
{
    char c;
    printf( "%i %i\n", char.init, c.init );
    printf( "%i %i\n", char.min, c.min );
    printf( "%i %i\n", char.max, c.max );
    return 0;
}

prints:

255 255
0 0
255 255

And in 0.94 it prints:

-1 255
0 0
-1 -1

I'm not sure offhand if this is a bug with properties returning signed numbers sometimes or if it's just a problem with printf.  If I change the code to this:

int main()
{
    char c;
    printf( "%u %u\n", char.init, c.init );
    printf( "%u %u\n", char.min, c.min );
    printf( "%u %u\n", char.max, c.max );
    return 0;
}

This is the output in 0.94:

4294967295 255
0 0
4294967295 4294967295


Sean

In article <ccarcn$jsl$1@digitaldaemon.com>, Sean Kelly says...
>
>In 0.93, the code:
>
>int main()
>{
>     char c;
>     printf( "%i %i\n", char.init, c.init );
>     printf( "%i %i\n", char.min, c.min );
>     printf( "%i %i\n", char.max, c.max );
>     return 0;
>}

Why are you using "%i"? What does it mean? (Maybe it needs to be added to our specifier list: http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/printf)

I'd think you want either "%u" for decimal or %x for hex.

>
>prints:
>
>255 255
>0 0
>255 255
>
>And in 0.94 it prints:
>
>-1 255
>0 0
>-1 -1
>
>I'm not sure offhand if this is a bug with properties returning signed numbers sometimes or if it's just a problem with printf.  If I change the code to this:
>
>int main()
>{
>     char c;
>     printf( "%u %u\n", char.init, c.init );
>     printf( "%u %u\n", char.min, c.min );
>     printf( "%u %u\n", char.max, c.max );
>     return 0;
>}
>
>This is the output in 0.94:
>
>4294967295 255

That's odd. I thought they'd both be 255.

Well, I've never completely understood printf (and I don't think I'll be sad when if it becomes obsolete).

>0 0
>4294967295 4294967295

Again, I thought they'd both be 255.

>
>
>Sean

jcc7

On Mon, 5 Jul 2004 06:36:46 +0000 (UTC), J C Calvarese <jcc7@cox.net> wrote:
> In article <ccarcn$jsl$1@digitaldaemon.com>, Sean Kelly says...
>>
>> In 0.93, the code:
>>
>> int main()
>> {
>>     char c;
>>     printf( "%i %i\n", char.init, c.init );
>>     printf( "%i %i\n", char.min, c.min );
>>     printf( "%i %i\n", char.max, c.max );
>>     return 0;
>> }
>
> Why are you using "%i"? What does it mean? (Maybe it needs to be added to our
> specifier list: http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/printf)

It's identical to %d. (according to MSDN)

  type | output format
--------------------
d int  | Signed decimal integer.
i int  | Signed decimal integer.
o int  | Unsigned octal integer.
u int  | Unsigned decimal integer.
x int  | Unsigned hexadecimal integer, using “abcdef.”
X int  | Unsigned hexadecimal integer, using “ABCDEF.”

(from MSDN)

> I'd think you want either "%u" for decimal or %x for hex.
>
>> prints:
>>
>> 255 255
>> 0 0
>> 255 255
>>
>> And in 0.94 it prints:
>>
>> -1 255
>> 0 0
>> -1 -1
>>
>> I'm not sure offhand if this is a bug with properties returning signed
>> numbers sometimes or if it's just a problem with printf.  If I change
>> the code to this:
>>
>> int main()
>> {
>>     char c;
>>     printf( "%u %u\n", char.init, c.init );
>>     printf( "%u %u\n", char.min, c.min );
>>     printf( "%u %u\n", char.max, c.max );
>>     return 0;
>> }
>>
>> This is the output in 0.94:
>>
>> 4294967295 255
>
> That's odd. I thought they'd both be 255.

As would I, I think however, something stranger is going on, this code:

void main() {
	int v;
	v = char.init;
	printf("%i %i\n",char.init,v);
}

prints:
255 255

yet this code:

void main() {
	int v;
	//v = char.init;
	printf("%i %i\n",char.init,v);
}

prints:
-1 0

err.. weird.

> Well, I've never completely understood printf (and I don't think I'll be sad
> when if it becomes obsolete).

printf is just so useful...

>> 0 0
>> 4294967295 4294967295
>
> Again, I thought they'd both be 255.

Regan

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

In article <opsanm6fgc5a2sq9@digitalmars.com>, Regan Heath says...
>> Well, I've never completely understood printf (and I don't think I'll be
>> sad
>> when if it becomes obsolete).
>
>printf is just so useful...

Right, so the only way it can ever become obsolete is if something even better comes along. So if that happens, I won't be sad either.

You wouldn't exactly be losing a function - just gaining another one.

Jill

On Mon, 5 Jul 2004 21:04:23 +0000 (UTC), Arcane Jill <Arcane_member@pathlink.com> wrote:

> In article <opsanm6fgc5a2sq9@digitalmars.com>, Regan Heath says...
>>> Well, I've never completely understood printf (and I don't think I'll be
>>> sad
>>> when if it becomes obsolete).
>>
>> printf is just so useful...
>
> Right, so the only way it can ever become obsolete is if something even better
> comes along. So if that happens, I won't be sad either.
>
> You wouldn't exactly be losing a function - just gaining another one.

Yeah, I know.. the posts on the new printf seem promising. IMO TypeInfo deficiencies are all that are holding it back.

Regan.

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