Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #64771 > unrolled thread

printf format specifier changes

Back to article view | Back to comp.lang.c

Contents

  printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 09:04 -0700
    Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 17:50 +0100
      Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 11:34 -0700
        Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 19:47 +0100
          Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 19:53 +0100
            Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 11:57 -0700
        Re: printf format specifier changes "James Harris" <james.harris.1@gmail.com> - 2015-09-06 10:53 +0100
          Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 04:21 -0700
          Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 13:41 +0100
      Re: printf format specifier changes Richard Heathfield <rjh@cpax.org.uk> - 2015-07-06 19:44 +0100
        Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 22:14 +0100
          Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-07-06 22:43 -0500
          Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-06 23:01 -0700
            Re: printf format specifier changes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-07 06:43 +0000
            Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 10:52 +0300
              Re: printf format specifier changes Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 09:26 +0100
                Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 12:56 +0300
                  Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-12 06:12 -0700
          Re: printf format specifier changes Rosario19 <Ros@invalid.invalid> - 2015-07-07 10:22 +0200
            Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 10:10 +0100
        Re: printf format specifier changes Philip Lantz <prl@canterey.us> - 2015-07-07 00:54 -0700
      Re: printf format specifier changes Nobody <nobody@nowhere.invalid> - 2015-07-07 15:08 +0100
        Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 16:12 +0100
          Re: printf format specifier changes raltbos@xs4all.nl (Richard Bos) - 2015-07-09 10:34 +0000
            Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-09 12:25 +0100
              Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 13:02 +0300
                Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-12 11:23 +0100
      Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-07 11:50 -0700
        Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-07 12:14 -0700
      Re: printf format specifier changes Les Cargill <lcargill99@comcast.com> - 2015-07-07 21:52 -0500
        Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-07 20:42 -0700
          Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 11:12 +0300
            Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 05:03 -0700
              Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 13:10 -0500
            Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-09 08:58 -0400
            Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-09 08:10 -0700
              Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 12:58 +0300
                Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-12 12:57 -0400
                Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-12 11:14 -0700
                  Re: printf format specifier changes gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-12 18:26 +0000
        Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-08 13:09 +0100
        Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-08 08:10 -0400
          Re: printf format specifier changes Les Cargill <lcargill99@comcast.com> - 2015-07-08 08:12 -0500
            Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-08 08:38 -0700
            Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-08 12:00 -0400
              Re: printf format specifier changes Les Cargill <lcargill99@comcast.com> - 2015-07-08 17:20 -0500
        Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 11:08 +0300
      Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-08 20:30 +0300
        Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-08 18:56 +0100
          Re: printf format specifier changes gordonb.lmwiv@burditt.org (Gordon Burditt) - 2015-07-09 11:09 -0500
            Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 14:05 -0500
        Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-08 11:27 -0700
          Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-08 15:07 -0500
    Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-06 23:39 -0500
      Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 10:19 +0100
        Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 07:57 -0500
          Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 14:15 +0100
            Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 14:46 +0100
            Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 09:37 -0500
          Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 11:24 +0300
            Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 09:55 -0500
              Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-09 11:53 -0700
                Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-09 13:48 -0700
                Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 17:01 -0500
      Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 10:59 +0100
        Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 07:48 -0500
          Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 14:30 +0100
            Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 10:05 -0500
              Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 23:16 +0100
                Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 20:29 -0500
                Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-08 00:43 -0700
                Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-07-09 02:29 -0500
                  Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 10:34 +0100
                    Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 09:35 -0500
            Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-07 08:37 -0700
              Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-07 08:45 -0700
            Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-07 12:12 -0700
    Re: printf format specifier changes pooja deshpande <namitadeshpande25@gmail.com> - 2015-07-09 09:29 -0700
      Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 09:34 -0700
        Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 09:59 -0700
          Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-09 22:33 +0100
            Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-09 15:17 -0700
              Re: printf format specifier changes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 00:30 +0000
                Re: printf format specifier changes Reinhardt Behm <rbehm@hushmail.com> - 2015-07-10 09:17 +0800
        Re: printf format specifier changes David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 10:02 -0700
          Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 10:19 -0700
        Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 21:50 +0100
          Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-09 15:05 -0700
            Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 15:09 -0700
            Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-10 00:28 +0100
              Re: printf format specifier changes raltbos@xs4all.nl (Richard Bos) - 2015-07-13 20:39 +0000
          Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 15:07 -0700
            Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-09 23:16 +0100
              Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 15:25 -0700

Page 1 of 5  [1] 2 3 4 5  Next page →

#64771 — printf format specifier changes

In 2015, what suggestions would you have for changing anything about
the format specifiers used in the printf functions?  Leave them as
they are?  Or change this or that about them?

Best regards,
Rick C. Hodgin

[toc] | [next] | [standalone]

#64778

On 06/07/2015 17:04, Rick C. Hodgin wrote:
> In 2015, what suggestions would you have for changing anything about
> the format specifiers used in the printf functions?  Leave them as
> they are?  Or change this or that about them?

In 2015, the whole notion of having to tell a compiler what it already 
knows - the type of the values it's printing - is outdated.

But working out alternatives is not so easy either, as sometimes you do 
need precise formatting control, but it is irrevocably tied, with the 
current system, to the type specifiers.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#64784

On Monday, July 6, 2015 at 12:50:42 PM UTC-4, Bart wrote:
> On 06/07/2015 17:04, Rick C. Hodgin wrote:
> > In 2015, what suggestions would you have for changing anything about
> > the format specifiers used in the printf functions?  Leave them as
> > they are?  Or change this or that about them?
> 
> In 2015, the whole notion of having to tell a compiler what it already 
> knows - the type of the values it's printing - is outdated.
> 
> But working out alternatives is not so easy either, as sometimes you do 
> need precise formatting control, but it is irrevocably tied, with the 
> current system, to the type specifiers.
> 
> -- 
> Bartc

I think I'm remembering an old discussion here.  It was a different
syntax, something like:

    char* ptr = "cabinet";

    printf("% dishes in the %", count, ptr);

Using only % allowed it to self-identify the type and auto-insert
the correct formatting.  I think I also proposed something like
format specifiers near the parameters:

    printf("$ dishes in the (0x$) $", (d)count, (x)ptr, (s)ptr);

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#64786

On 06/07/2015 19:34, Rick C. Hodgin wrote:
> On Monday, July 6, 2015 at 12:50:42 PM UTC-4, Bart wrote:

>> In 2015, the whole notion of having to tell a compiler what it already
>> knows - the type of the values it's printing - is outdated.

> I think I'm remembering an old discussion here.  It was a different
> syntax, something like:
>
>      char* ptr = "cabinet";
>
>      printf("% dishes in the %", count, ptr);
>
> Using only % allowed it to self-identify the type and auto-insert
> the correct formatting.  I think I also proposed something like
> format specifiers near the parameters:
>
>      printf("$ dishes in the (0x$) $", (d)count, (x)ptr, (s)ptr);

There's a million ways of doing this. However your examples are still 
denoting type information.

This is how I might do your first example elsewhere (not in C, not even 
in a compiled language, but this approach is still viable):

print count, "dishes in the", ptr

(where "," normally inserts a space separator"). Or using:

fprint "# dishes in the #", count, ptr

No type info needed. Your examples aren't very challenging however. When 
a specific width/precision/etc is required, then my examples also get 
cluttered enough that there is not much difference over the C equivalent.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#64787

On 06/07/2015 19:47, Bartc wrote:
> On 06/07/2015 19:34, Rick C. Hodgin wrote:
>> On Monday, July 6, 2015 at 12:50:42 PM UTC-4, Bart wrote:
>
>>> In 2015, the whole notion of having to tell a compiler what it already
>>> knows - the type of the values it's printing - is outdated.
>
>> I think I'm remembering an old discussion here.  It was a different
>> syntax, something like:
>>
>>      char* ptr = "cabinet";
>>
>>      printf("% dishes in the %", count, ptr);
>>
>> Using only % allowed it to self-identify the type and auto-insert
>> the correct formatting.  I think I also proposed something like
>> format specifiers near the parameters:
>>
>>      printf("$ dishes in the (0x$) $", (d)count, (x)ptr, (s)ptr);
>
> There's a million ways of doing this. However your examples are still
> denoting type information.

Oh, correction: the first example does dispense with type info. Maybe 
you should call it something different from "printf"! And use a 
different symbol from "%". Or (this have been proposed a few times), 
have a special format specifier that follows % that is then translated 
to the actual format code that is needed to match the types.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#64788

On Monday, July 6, 2015 at 2:53:57 PM UTC-4, Bart wrote:
> On 06/07/2015 19:47, Bartc wrote:
> > On 06/07/2015 19:34, Rick C. Hodgin wrote:
> >>      char* ptr = "cabinet";
> >>
> >>      printf("% dishes in the %", count, ptr);
> >>
> Oh, correction: the first example does dispense with type info. Maybe 
> you should call it something different from "printf"! And use a 
> different symbol from "%". Or (this have been proposed a few times), 
> have a special format specifier that follows % that is then translated 
> to the actual format code that is needed to match the types.

I'm thinking that was your example from back then.  But, I'm not sure.
I can't remember for sure.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#69594

(Going back to an old thread)

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote in message 
news:1fe6466f-8b9c-40e6-8ce3-a5209c08fa7a@googlegroups.com...
> On Monday, July 6, 2015 at 12:50:42 PM UTC-4, Bart wrote:
>> On 06/07/2015 17:04, Rick C. Hodgin wrote:
>> > In 2015, what suggestions would you have for changing anything 
>> > about
>> > the format specifiers used in the printf functions?  Leave them as
>> > they are?  Or change this or that about them?

The biggest problem with printf specifiers, IMO, is that they only work 
with a fixed set of data types, those which are defined by the 
specification. That's fine if you want to print one of those but not for 
user-defined types.

I would make a similar comment about formatting. The inbuilt formatting 
options may not cover how you want the value to be rendered.

Of course, you could use a function to render a value into a malloc'd 
buffer and then print it with %s. But then you'd need to remember to 
free the buffer, and it is unusual in C to have a function return an 
allocated buffer. So how about a conversion specifier which printed as 
%s but then called free() on the result? Would that be feasible?

Example:

  printf("Values = %M, %i\n", mydatatype_render(p), i);

That could possibly be used for *any* printing that was not supplied by 
the standard format specifiers.

Is it worth the addition over %s? I think so, yes. It keeps the somewhat 
anomalous return to a single statement, makes it obvious in the source 
what is intended, and it would probably quickly be found in testing if 
%M were incorrectly used on a routine which did not return a new 
allocation. %M could have normal modifiers so that the returned string 
could still be left- or right-aligned in a certain size of field.

>> In 2015, the whole notion of having to tell a compiler what it 
>> already
>> knows - the type of the values it's printing - is outdated.

As others said, the printf family is more flexible in allowing the 
specifying string to be generated as the program runs. I agree with you 
that that facility is not used often but it is used occasionally and in 
the normal case where it is a string constant the compiler can check the 
types.

IMO the standard library printf approach is very C'ish in that it is 
fast and flexible and a bit dangerous. Another language may have 
something which is safer and a little more flexible but slower.

>> But working out alternatives is not so easy either, as sometimes you 
>> do
>> need precise formatting control, but it is irrevocably tied, with the
>> current system, to the type specifiers.

Re formatting control would the %M suggestion, above, cover it? You 
could call a routine to format the value the way you wanted it, e.g.

  mytype_render(value, "my format string");

Whatever your format string rendered could still be printed on return to 
printf.

> I think I'm remembering an old discussion here.  It was a different
> syntax, something like:
>
>    char* ptr = "cabinet";
>
>    printf("% dishes in the %", count, ptr);
>
> Using only % allowed it to self-identify the type and auto-insert
> the correct formatting.

Not sure if this has already been mentioned but that wouldn't work for 
user-defined types, nor would it allow for formatting controls such as 
number of digits after the decimal point, field width or field 
alignment.

>  I think I also proposed something like
> format specifiers near the parameters:
>
>    printf("$ dishes in the (0x$) $", (d)count, (x)ptr, (s)ptr);

Interesting. Though it seems that it requires the format string to be a 
literal.

James

[toc] | [prev] | [next] | [standalone]

#69596

On Sunday, September 6, 2015 at 10:53:25 AM UTC+1, James Harris wrote:
>
> Of course, you could use a function to render a value into a malloc'd 
> buffer and then print it with %s. But then you'd need to remember to 
> free the buffer, and it is unusual in C to have a function return an 
> allocated buffer. So how about a conversion specifier which printed as 
> %s but then called free() on the result? Would that be feasible?
> 
> Example:
> 
>   printf("Values = %M, %i\n", mydatatype_render(p), i);
> 
> That could possibly be used for *any* printing that was not supplied by 
> the standard format specifiers.
> 
That's a nice idea.
You can implement a myprintf() using that format specifier without needing
any language extensions, and since you can call any function, you don't need
a "tostring" method which makes it difficult to specify different functions for
different contexts - you might have a short form and a long form for
printing out an employee, for example.
>
> As others said, the printf family is more flexible in allowing the 
> specifying string to be generated as the program runs. I agree with you 
> that that facility is not used often but it is used occasionally and in 
> the normal case where it is a string constant the compiler can check the 
> types.
> 
The Baby X spinner has a caller-defined format string so you can specify how
many digits of a float you want to print out, padding, units and so forth.
>
> IMO the standard library printf approach is very C'ish in that it is 
> fast and flexible and a bit dangerous. Another language may have 
> something which is safer and a little more flexible but slower.
> 
Speed doesn't normally matter much for this type of string handling, unless
you're spewing out vast quantities of data for automatic parsing. If the 
output is intended for human reading, or the input represents measurements
of some type taken by a human, then on any halfway modern computer the
time to format the string will be negligible.
But safety isn't much of an issue either. A bug in a  call to printf() will usually
be very quickly found because it's only one step away from the faulty output.
The exception is where you pass a dynamic format string and someone embeds 
the wrong conversion types in it, often by falling to escape %.

[toc] | [prev] | [next] | [standalone]

#69605

"James Harris" <james.harris.1@gmail.com> writes:

> (Going back to an old thread)
>
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote in message
> news:1fe6466f-8b9c-40e6-8ce3-a5209c08fa7a@googlegroups.com...
>> On Monday, July 6, 2015 at 12:50:42 PM UTC-4, Bart wrote:
>>> On 06/07/2015 17:04, Rick C. Hodgin wrote:
>>> > In 2015, what suggestions would you have for changing anything >
>>> about
>>> > the format specifiers used in the printf functions?  Leave them as
>>> > they are?  Or change this or that about them?
>
> The biggest problem with printf specifiers, IMO, is that they only
> work with a fixed set of data types, those which are defined by the
> specification. That's fine if you want to print one of those but not
> for user-defined types.
>
> I would make a similar comment about formatting. The inbuilt
> formatting options may not cover how you want the value to be
> rendered.
>
> Of course, you could use a function to render a value into a malloc'd
> buffer and then print it with %s. But then you'd need to remember to
> free the buffer, and it is unusual in C to have a function return an
> allocated buffer. So how about a conversion specifier which printed as
> %s but then called free() on the result? Would that be feasible?
>
> Example:
>
>  printf("Values = %M, %i\n", mydatatype_render(p), i);
>
> That could possibly be used for *any* printing that was not supplied
> by the standard format specifiers.
>
> Is it worth the addition over %s? I think so, yes.

Maybe.  The alternatives are not awful:

  const char *rep = mydatatype_render(p);
  printf("Values = %s, %i\n", rep ? rep : "<out of memory!>", i);
  free(rep);

is not that much more complicated, and gives more control when handling
allocation failures.  Similarly

  char buf[get_rep_size(p)];
  printf("Values = %M, %i\n", mydatatype_render(buf, p), i);

is also sometimes suitable and involves no malloc at all.

I think a better solution would be to standardise a mechanism to extend
printf formats.  You could then write your own %M but also more
type-specific formats.  Of course that's more complicated to it also
raises the question of whether it's worth the addition.  Whilst I like
both ideas, I am not well-placed to evaluate the costs and benefits of
standardising wither.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#64785

On 06/07/15 17:50, Bartc wrote:
> On 06/07/2015 17:04, Rick C. Hodgin wrote:
>> In 2015, what suggestions would you have for changing anything about
>> the format specifiers used in the printf functions?  Leave them as
>> they are?  Or change this or that about them?
>
> In 2015, the whole notion of having to tell a compiler what it already
> knows - the type of the values it's printing - is outdated.

Although it's not required by the Standard (AFAICR), members of the 
*printf family of functions are generally implemented using the varargs 
mechanism. At the point of compilation, a varargs function /doesn't/ 
magically know the types of the arguments in its arglist, and so it has 
to be told by the caller.

It would be possible to devise a new "language" for formatted printing, 
one that could perhaps do a better job of working out types, but would 
that really move us any further forward? C would then have to support 
both mini-languages, and a very significant number of developers would 
stick to the old way simply because that's the way they already know and 
it's the way their maintenance programmers already know.

> But working out alternatives is not so easy either, as sometimes you do
> need precise formatting control, but it is irrevocably tied, with the
> current system, to the type specifiers.

There is prior art for an alternative system that allows precise format 
control without requiring you to work /quite/ so hard on the types - the 
iostream model used by C++. It may not be a good example, but it is at 
least a horrible warning.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#64803

On 06/07/2015 19:44, Richard Heathfield wrote:
> On 06/07/15 17:50, Bartc wrote:
>> On 06/07/2015 17:04, Rick C. Hodgin wrote:
>>> In 2015, what suggestions would you have for changing anything about
>>> the format specifiers used in the printf functions?  Leave them as
>>> they are?  Or change this or that about them?
>>
>> In 2015, the whole notion of having to tell a compiler what it already
>> knows - the type of the values it's printing - is outdated.
>
> Although it's not required by the Standard (AFAICR), members of the
> *printf family of functions are generally implemented using the varargs
> mechanism. At the point of compilation, a varargs function /doesn't/
> magically know the types of the arguments in its arglist, and so it has
> to be told by the caller.

How many calls to the printf-family won't have a string literal as the 
format string? Nearly all of them do. And the odd time that the format 
string isn't known at compile-time, then people can just do what they 
have to do now.

> It would be possible to devise a new "language" for formatted printing,
> one that could perhaps do a better job of working out types, but would
> that really move us any further forward?

You don't need much of a change to make significant progress. Take my 
idea of using the new "?" format specifier. Since compilers are already 
capable of checking specifiers against argument types, it wouldn't take 
much to replace a "%...?" specifier when encountered into the proper 
format code needed for the argument type. For example:

Argument       Format    Mapped to:
char            ?        d or u, or c
short           ?        d or u
int             ?        d or u
long            ?        ld or lu
long long       ?        lld or llu
float           ?        f (or e or g)
double          ?        f
char*           ?        s
T*              ?        p

It's not perfect: you might want to print an integer type as hex, but if 
you directly use the X specifier, you now need to embed the correct 
number of l's to match the number of longs. That's what you're trying to 
get away from.

But the idea can be refined a bit more and it still couldn't be called a 
mini-language.

> There is prior art for an alternative system that allows precise format
> control without requiring you to work /quite/ so hard on the types - the
> iostream model used by C++. It may not be a good example, but it is at
> least a horrible warning.

It looks awful.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#64826

On Mon, 06 Jul 2015 22:14:08 +0100, Bartc <bc@freeuk.com> wrote:

>On 06/07/2015 19:44, Richard Heathfield wrote:
>> On 06/07/15 17:50, Bartc wrote:
>>> On 06/07/2015 17:04, Rick C. Hodgin wrote:
>>>> In 2015, what suggestions would you have for changing anything about
>>>> the format specifiers used in the printf functions?  Leave them as
>>>> they are?  Or change this or that about them?
>>>
>>> In 2015, the whole notion of having to tell a compiler what it already
>>> knows - the type of the values it's printing - is outdated.
>>
>> Although it's not required by the Standard (AFAICR), members of the
>> *printf family of functions are generally implemented using the varargs
>> mechanism. At the point of compilation, a varargs function /doesn't/
>> magically know the types of the arguments in its arglist, and so it has
>> to be told by the caller.
>
>How many calls to the printf-family won't have a string literal as the 
>format string? Nearly all of them do. And the odd time that the format 
>string isn't known at compile-time, then people can just do what they 
>have to do now.


FWIW, around here, it's very common.


>> It would be possible to devise a new "language" for formatted printing,
>> one that could perhaps do a better job of working out types, but would
>> that really move us any further forward?
>
>You don't need much of a change to make significant progress. Take my 
>idea of using the new "?" format specifier. Since compilers are already 
>capable of checking specifiers against argument types, it wouldn't take 
>much to replace a "%...?" specifier when encountered into the proper 
>format code needed for the argument type. For example:
>
>Argument       Format    Mapped to:
>char            ?        d or u, or c
>short           ?        d or u
>int             ?        d or u
>long            ?        ld or lu
>long long       ?        lld or llu
>float           ?        f (or e or g)
>double          ?        f
>char*           ?        s
>T*              ?        p
>
>It's not perfect: you might want to print an integer type as hex, but if 
>you directly use the X specifier, you now need to embed the correct 
>number of l's to match the number of longs. That's what you're trying to 
>get away from.
>
>But the idea can be refined a bit more and it still couldn't be called a 
>mini-language.
>
>> There is prior art for an alternative system that allows precise format
>> control without requiring you to work /quite/ so hard on the types - the
>> iostream model used by C++. It may not be a good example, but it is at
>> least a horrible warning.
>
>It looks awful.


I can't argue that iostreams aren't ugly (I certainly think they are),
but they're extensible and type safe.  That makes up for a lot.

[toc] | [prev] | [next] | [standalone]

#64833

Bartc <bc@freeuk.com> writes:
> On 06/07/2015 19:44, Richard Heathfield wrote:
[...]
> But the idea can be refined a bit more and it still couldn't be called a 
> mini-language.
>
>> There is prior art for an alternative system that allows precise format
>> control without requiring you to work /quite/ so hard on the types - the
>> iostream model used by C++. It may not be a good example, but it is at
>> least a horrible warning.
>
> It looks awful.

Tastes differ.  Personally, I have no esthetic problem with C++'s
use of overloaded >> and << operators for I/O; in that context,
I just don't think of them as shifts, and they do visually indicate
the direction in which the information flows.  (The same technique
couldn't be used in C without adding operator overloading to the
language.)

What I find annoying is that the constructs used to control formatting
(setting precision, width, base, etc) *change the state of the stream*.

In C, I can write:

    printf("x = 0x%x\n", x);

to print a value in hexadecimal, and it doesn't affect the next thing I
print.  In C++, if I write:

    std::cout << "x = 0x" << std::hex << x << "\n";

then the next integer I print will be in hexadecimal -- and if there's a
clean idiom to restore a stream to its previous state, I'm not familiar
with it.

If anybody designs a new formatted I/O system for C, please don't do
that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#64834

Keith Thompson <kst-u@mib.org> wrote:

(snip)

> Tastes differ.  Personally, I have no esthetic problem with C++'s
> use of overloaded >> and << operators for I/O; in that context,
> I just don't think of them as shifts, and they do visually indicate
> the direction in which the information flows.  (The same technique
> couldn't be used in C without adding operator overloading to the
> language.)

I am not so sure why, but the << and >> operators were the big
reason I never got interested in C++.  It wasn't until Java that
I got more interested in OO languages. Seems to me that Java was
designed to be easy for C programmers to learn, and C++ wasn't.
 
(snip)

> to print a value in hexadecimal, and it doesn't affect the next thing I
> print.  In C++, if I write:
 
>    std::cout << "x = 0x" << std::hex << x << "\n";
 
> then the next integer I print will be in hexadecimal -- and if there's a
> clean idiom to restore a stream to its previous state, I'm not familiar
> with it.

Yes, I wouldn't like that either.

Have you looked at Java's System.out.format?

-- glen

[toc] | [prev] | [next] | [standalone]

#64969

Keith Thompson <kst-u@mib.org> writes:

> Bartc <bc@freeuk.com> writes:
> > On 06/07/2015 19:44, Richard Heathfield wrote:
> [...]
> > But the idea can be refined a bit more and it still couldn't be called a 
> > mini-language.
> >
> >> There is prior art for an alternative system that allows precise format
> >> control without requiring you to work /quite/ so hard on the types - the
> >> iostream model used by C++. It may not be a good example, but it is at
> >> least a horrible warning.
> >
> > It looks awful.
> 
> Tastes differ.  Personally, I have no esthetic problem with C++'s
> use of overloaded >> and << operators for I/O; in that context,
> I just don't think of them as shifts, and they do visually indicate
> the direction in which the information flows. 

NIMNSHO.

Imagine a piece of string with a bell, a sausage, and a worm on it.
Put that piece of string in a bucket, complete with the three objects.
Now, starting with the worm end, pull the piece of string, and the
three objects, out of the bucket. You pull out the worm, then the 
sausage, then the bell:

Now compare that with extracting a class worm, a class sausage and a
class bell from a class iobucket in C++.

Visually:

/-------
|bucket --- bell -- sausage -- worm --
\-------

iobucket >> worm >> sausage >> bell;

So I'm going for "not a visual indication of the direction in which
the information flows".

[SNIP - stuff with which I'm in complete agreement. However, I'd have
used stronger terms, including the verb "puke", and the noun "bollocks",
though not in the same sentence.]

Phil
-- 
A well regulated militia, being necessary to the security of a free state,
the right of the people to keep and bear arms, shall be well regulated.

[toc] | [prev] | [next] | [standalone]

#64973

On 09/07/15 08:52, Phil Carmody wrote:
> Keith Thompson <kst-u@mib.org> writes:
>
<snip>

>> Personally, I have no esthetic problem with C++'s
>> use of overloaded >> and << operators for I/O; in that context,
>> I just don't think of them as shifts, and they do visually indicate
>> the direction in which the information flows.
>
> NIMNSHO.
>
> Imagine a piece of string with a bell, a sausage, and a worm on it.

What was that I said (elseNet) about visualising algorithms? :-)

Okay, I think (and I could end up proving myself wrong) that you have 
this exactly the wrong way round. [Later edit: it turns out that I 
proved myself half-wrong: you have half of this exactly the wrong way 
round.]

> Put that piece of string in a bucket, complete with the three objects.
> Now, starting with the worm end, pull the piece of string, and the
> three objects, out of the bucket. You pull out the worm, then the
> sausage, then the bell:
>
> Now compare that with extracting a class worm, a class sausage and a
> class bell from a class iobucket in C++.
>
> Visually:
>
> /-------
> |bucket --- bell -- sausage -- worm --
> \-------
>
> iobucket >> worm >> sausage >> bell;

Firstly, we're taking stuff out, not putting it in, so we should be 
<<ing, not >>ing (iostream output uses << rather than >>). Secondly, 
where is the stuff going? It's not going into the iobucket. It's coming 
*out* of the iobucket, and (since I'm not overly fond of worms) I'm 
going to drop it onto the ioground, and since the orientation of the 
chevrons should be consistent with the flow of the objects and since the 
ioobject has to be on the left, for output we have to spec the 
destination rather than the source, so we have:

ioground << worm << sausage << bell;

which is exactly right. In goes the worm, then the sausage, then the 
bell. (Note that the iobucket doesn't get a mention.)

I think, though, that you have a point when it comes to input. We want 
to put stuff into the bucket, so we're >>ing, not <<ing. The >> should 
indicate the direction of flow, so this time we're talking about where 
the worm, sausage, and bell are coming /from/ (because of course the 
ioobject has to be on the left). Alas for those of us with wormophobia, 
these objects are coming from the iohand (the iohand in which one iobird 
is worth two iobirds in the iobush), so, to keep them in the right order 
(worm going in first), we must do this:

iohand >> worm >> sausage >> bell;

(Again, note that the iobucket doesn't get a mention.)

And *now* it looks wrong, because the visual image would be:

                                      \-------+
hand -- bell -- sausage -- worm ----> bucket |
                                      /-------+

So now it's exactly the wrong way round.

(How do you like the bucket art? I worked hard on it. Took me, ooh, no 
it was longer than that.)

> So I'm going for "not a visual indication of the direction in which
> the information flows".

Will you settle for half-right?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#65398

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 09/07/15 08:52, Phil Carmody wrote:
> > Visually:
> >
> > /-------
> > |bucket --- bell -- sausage -- worm --
> > \-------
> >
> > iobucket >> worm >> sausage >> bell;
> 
> Firstly, we're taking stuff out, not putting it in, so we should be
> <<ing, not >>ing

Disagree. Taking = extracting = >>. Putting = inserting = <<.

> (iostream output uses << rather than >>). Secondly,
> where is the stuff going? 

into the instance variables of class bell, sausage, and worm.

[SNIP]

> I think, though, that you have a point when it comes to input.

I was only talking about input. Taking stuff from a source. Use
of '>>', the clues were all there.

> We want
> to put stuff into the bucket, so we're >>ing, not <<ing.

No.

"""
Now, starting with the worm end, pull the piece of string, and the
three objects, *out of the bucket*. You pull out the worm, then the 
sausage, then the bell:

Now compare that with *extracting* a class worm, a class sausage and a
class bell from a class iobucket in C++.
"""

As said elsenet, I think we're speaking a different language.

Phil
-- 
A well regulated militia, being necessary to the security of a free state,
the right of the people to keep and bear arms, shall be well regulated.

[toc] | [prev] | [next] | [standalone]

#65407

On Sunday, July 12, 2015 at 10:56:44 AM UTC+1, Phil Carmody wrote:
> 
> Now, starting with the worm end, pull the piece of string, and the
> three objects, *out of the bucket*. You pull out the worm, then the 
> sausage, then the bell:
> 
> Now compare that with *extracting* a class worm, a class sausage and a
> class bell from a class iobucket in C++.
> 
You need JSON.
Via duck typing, anything with wings and a quack is a duck, anything
with a wriggle parameter is a worm. So your classes don't have to
precisely match those defined by the serialiser. 
With conventional C++ serialisation, there's no good way of tagging
the worm with "worm" as a class ID and resolving that at runtime.

[toc] | [prev] | [next] | [standalone]

#64838

On Mon, 06 Jul 2015 22:14:08 +0100, Bartc <bc@freeuk.com> wrote:
>On 06/07/2015 19:44, Richard Heathfield wrote:
>> On 06/07/15 17:50, Bartc wrote:
>>> On 06/07/2015 17:04, Rick C. Hodgin wrote:
>>>> In 2015, what suggestions would you have for changing anything about
>>>> the format specifiers used in the printf functions?  Leave them as
>>>> they are?  Or change this or that about them?
>>>
>>> In 2015, the whole notion of having to tell a compiler what it already
>>> knows - the type of the values it's printing - is outdated.
>>
>> Although it's not required by the Standard (AFAICR), members of the
>> *printf family of functions are generally implemented using the varargs
>> mechanism. At the point of compilation, a varargs function /doesn't/
>> magically know the types of the arguments in its arglist, and so it has
>> to be told by the caller.
>
>How many calls to the printf-family won't have a string literal as the 
>format string? Nearly all of them do. And the odd time that the format 
>string isn't known at compile-time, then people can just do what they 
>have to do now.
>
>> It would be possible to devise a new "language" for formatted printing,
>> one that could perhaps do a better job of working out types, but would
>> that really move us any further forward?
>
>You don't need much of a change to make significant progress. Take my 
>idea of using the new "?" format specifier. Since compilers are already 
>capable of checking specifiers against argument types, it wouldn't take 
>much to replace a "%...?" specifier when encountered into the proper 
>format code needed for the argument type. For example:
>
>Argument       Format    Mapped to:

>char            ?        d or u, or c

>short           ?        d or u
>int             ?        d or u
>long            ?        ld or lu
>long long       ?        lld or llu
>float           ?        f (or e or g)
>double          ?        f
>char*           ?        s
>T*              ?        p
what would be the format for intxx_t?
%typesize
as
%I32, %U32  %I8 etc
for double
%D64
?

there is a way for define types and its routines for show using printf
like functions?

>It's not perfect: you might want to print an integer type as hex, but if 
>you directly use the X specifier, you now need to embed the correct 
>number of l's to match the number of longs. That's what you're trying to 
>get away from.
>
>But the idea can be refined a bit more and it still couldn't be called a 
>mini-language.
>
>> There is prior art for an alternative system that allows precise format
>> control without requiring you to work /quite/ so hard on the types - the
>> iostream model used by C++. It may not be a good example, but it is at
>> least a horrible warning.
>
>It looks awful.

[toc] | [prev] | [next] | [standalone]

#64839

On 07/07/2015 09:22, Rosario19 wrote:
> On Mon, 06 Jul 2015 22:14:08 +0100, Bartc <bc@freeuk.com> wrote:

>> Argument       Format    Mapped to:
>
>> char            ?        d or u, or c
>
>> short           ?        d or u
>> int             ?        d or u
>> long            ?        ld or lu
>> long long       ?        lld or llu
>> float           ?        f (or e or g)
>> double          ?        f
>> char*           ?        s
>> T*              ?        p
> what would be the format for intxx_t?
> %typesize
> as
> %I32, %U32  %I8 etc
> for double
> %D64
> ?

Actually, I don't know! I think I just assume that 8, 16, or 32-bit 
widths are %d or %u, while I just use %lld or %llu for 64-bit.

This is the extra advantage of letting the compiler sort it out because 
it will know for sure.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web