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 5 of 5 — ← Prev page 1 2 3 4 [5]

#65069

On 09/07/2015 17:59, Rick C. Hodgin wrote:
> On Thursday, July 9, 2015 at 12:34:42 PM UTC-4, Rick C. Hodgin wrote:
>> On Thursday, July 9, 2015 at 12:29:55 PM UTC-4, pooja deshpande wrote:
>>> On Monday, July 6, 2015 at 9:34:47 PM UTC+5:30, 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?
>>>>
>>> hoping for no changes!!
>>
>> The only real change I would like to see is a memprintf() function
>> which does not automatically add a trailing null, but otherwise
>> behave like sprintf() functions.  And one more:  I would like to
>> see the format specifiers moved to their variable instance, like
>> this:
>>
>> Old way:
>>      printf("%s %p\n", ptr, ptr);
>>
>> New way:
>>      printf("% %\n", [s]ptr, [p]ptr);
>>
>> I think putting the specifiers by their variables would lend itself
>> to easier understanding and maintenance in code:
>>
>>      printf("% %\n",   [s]  ptr,   // Show content
>>                        [p]  ptr);  // Show address of content
>>
>> The eye can identify all of that.  And in this example it's not a
>> big deal, but when there are more types, or they are more complex,
>> then it will associate each.
>
> One other addition:  The ability to leave the specifier off if it
> follows its natural type:
>
>      int i = 5;
>      printf("i: %\n", i);

Perhaps the next step is to eliminate the "%" too, and the need to have 
a discrete format string. Then you can write:

  print("i:",i,"\n");

(Notice printf has lost its "f".) To make this form practical, you just 
need to sort out a policy on dealing with separators.

-- 
Bartc

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

#65077

Bartc <bc@freeuk.com> writes:
[...]
> Perhaps the next step is to eliminate the "%" too, and the need to have 
> a discrete format string. Then you can write:
>
>   print("i:",i,"\n");
>
> (Notice printf has lost its "f".) To make this form practical, you just 
> need to sort out a policy on dealing with separators.

Personally, I'd prefer not to have a separator at all, at least by
default.  If there's no default separator, I can add them myself if
needed:

    print("i = ", i, ", j = ", j, \n";

If arguments are automatically separated by spaces, I can't easily print
fields that *aren't* separated by spaces.

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

#65087

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

(snip)

> Personally, I'd prefer not to have a separator at all, at least by
> default.  If there's no default separator, I can add them myself if
> needed:
 
>    print("i = ", i, ", j = ", j, \n";
 
> If arguments are automatically separated by spaces, I can't easily print
> fields that *aren't* separated by spaces.

PL/I DATA directed I/O is very convenient for debugging.

I=10; J=20;
PUT DATA(I, J);

and you get something like:

I=      10, J=     20;

(The print widths are system dependent, and might depend on
the data type.)

Even more fun is the inverse:

GET DATA(I, J);  

(The PL/I compilers I used to use only knew upper case.)

with input data such as:

I=30;

it will change I and leave J.

Even more, you can do:

GET DATA;

which has an implied I/O list of all variables in scope.

Same for

PUT DATA;

-- glen

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

#65088

glen herrmannsfeldt wrote:

> Keith Thompson <kst-u@mib.org> wrote:
> 
> (snip)
> 
>> Personally, I'd prefer not to have a separator at all, at least by
>> default.  If there's no default separator, I can add them myself if
>> needed:
>  
>>    print("i = ", i, ", j = ", j, \n";
>  
>> If arguments are automatically separated by spaces, I can't easily print
>> fields that *aren't* separated by spaces.
> 
> PL/I DATA directed I/O is very convenient for debugging.
> 
> I=10; J=20;
> PUT DATA(I, J);
> 
> and you get something like:
> 
> I=      10, J=     20;
> 
> (The print widths are system dependent, and might depend on
> the data type.)
> 
> Even more fun is the inverse:
> 
> GET DATA(I, J);
> 
> (The PL/I compilers I used to use only knew upper case.)
> 
> with input data such as:
> 
> I=30;
> 
> it will change I and leave J.
> 
> Even more, you can do:
> 
> GET DATA;
> 
> which has an implied I/O list of all variables in scope.
> 
> Same for
> 
> PUT DATA;
> 
> -- glen

PL/I had a lot of features some of which get slowly reinvented again.
Multitasking (thread) support, good I/O i.e. picture attribute for 
formatting, data type specifications like "binary fixed(10, 0)" much finer 
control than this intNN_t stuff.

-- 
Reinhardt

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

#65032

On Thursday, July 9, 2015 at 9:34:42 AM UTC-7, Rick C. Hodgin wrote:
> On Thursday, July 9, 2015 at 12:29:55 PM UTC-4, pooja deshpande wrote:
> > On Monday, July 6, 2015 at 9:34:47 PM UTC+5:30, 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?
> > > 
> > hoping for no changes!!
> 
> The only real change I would like to see is a memprintf() function
> which does not automatically add a trailing null, but otherwise
> behave like sprintf() functions.  And one more:  I would like to
> see the format specifiers moved to their variable instance, like
> this:
> 
> Old way:
>     printf("%s %p\n", ptr, ptr);
> 
> New way:
>     printf("% %\n", [s]ptr, [p]ptr);
> 
> I think putting the specifiers by their variables would lend itself
> to easier understanding and maintenance in code:
> 
>     printf("% %\n",   [s]  ptr,   // Show content
>                       [p]  ptr);  // Show address of content
> 
> The eye can identify all of that.  And in this example it's not a
> big deal, but when there are more types, or they are more complex,
> then it will associate each.
 
Your suggestion is not in the spirit of C (whatever that is).

Perhaps

>     printf("% %\n", (char*) ptr, (void*) ptr);

That is - require each post-format argument to be type cast into
whatever type you want (I would worry about that "char*").

I don't see much point in this change. Consider it a joke.

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

#65035

On Thursday, July 9, 2015 at 1:03:00 PM UTC-4, David Kleinecke wrote:
> On Thursday, July 9, 2015 at 9:34:42 AM UTC-7, Rick C. Hodgin wrote:
> > On Thursday, July 9, 2015 at 12:29:55 PM UTC-4, pooja deshpande wrote:
> > > On Monday, July 6, 2015 at 9:34:47 PM UTC+5:30, 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?
> > > > 
> > > hoping for no changes!!
> > 
> > The only real change I would like to see is a memprintf() function
> > which does not automatically add a trailing null, but otherwise
> > behave like sprintf() functions.  And one more:  I would like to
> > see the format specifiers moved to their variable instance, like
> > this:
> > 
> > Old way:
> >     printf("%s %p\n", ptr, ptr);
> > 
> > New way:
> >     printf("% %\n", [s]ptr, [p]ptr);
> > 
> > I think putting the specifiers by their variables would lend itself
> > to easier understanding and maintenance in code:
> > 
> >     printf("% %\n",   [s]  ptr,   // Show content
> >                       [p]  ptr);  // Show address of content
> > 
> > The eye can identify all of that.  And in this example it's not a
> > big deal, but when there are more types, or they are more complex,
> > then it will associate each.
>  
> Your suggestion is not in the spirit of C (whatever that is).
> 
> Perhaps
> 
> >     printf("% %\n", (char*) ptr, (void*) ptr);
> 
> That is - require each post-format argument to be type cast into
> whatever type you want (I would worry about that "char*").
> 
> I don't see much point in this change. Consider it a joke.

My thinking is that in each case of its use, if it falls into the
natural type which it is, then the compiler would automatically
identify the type.  If, however, you want it into a specific
format other than its natural type, then the cast is required.

FWIW, I don't expect this to be added to C.  I am considering
it for support in RDC, and in my extensions added to my
implementation of the C standards.

Best regards,
Rick C. Hodgin

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

#65066

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> [...]  And one more:  I would like to
> see the format specifiers moved to their variable instance, like
> this:
>
> Old way:
>     printf("%s %p\n", ptr, ptr);
>
> New way:
>     printf("% %\n", [s]ptr, [p]ptr);

But note that that syntax ([s]ptr, and so on) already has a meaning, so
you need to take some steps to make this usage clearly recognisable.

<snip>
-- 
Ben.

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

#65072

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>
>> [...]  And one more:  I would like to
>> see the format specifiers moved to their variable instance, like
>> this:
>>
>> Old way:
>>     printf("%s %p\n", ptr, ptr);
>>
>> New way:
>>     printf("% %\n", [s]ptr, [p]ptr);
>
> But note that that syntax ([s]ptr, and so on) already has a meaning, so
> you need to take some steps to make this usage clearly recognisable.
>
> <snip>

It does?  The [] operator requires an expression before the [ and
another between the [ and ].  [s]ptr is a syntax error.

It is visually confusing, though.

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

#65075

On Thursday, July 9, 2015 at 6:05:13 PM UTC-4, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >
> >> [...]  And one more:  I would like to
> >> see the format specifiers moved to their variable instance, like
> >> this:
> >>
> >> Old way:
> >>     printf("%s %p\n", ptr, ptr);
> >>
> >> New way:
> >>     printf("% %\n", [s]ptr, [p]ptr);
> >
> > But note that that syntax ([s]ptr, and so on) already has a meaning, so
> > you need to take some steps to make this usage clearly recognisable.
> >
> > <snip>
> 
> It does?  The [] operator requires an expression before the [ and
> another between the [ and ].  [s]ptr is a syntax error.
> 
> It is visually confusing, though.

The idea I would foresee is the GUI.  It would use this syntax in
source code which may be confusing, rather like the (|cask|) is
confusing at first, especially when you start adding (oo|pips|).
But when translated from raw text into a graphical representation
using not just colors, but also other graphical quips, then it
becomes easier on the eyes.

A large percentage of our brain is dedicated to visual processing.
It's fool-hearty not to use it.

Best regards,
Rick C. Hodgin

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

#65082

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>>> [...]  And one more:  I would like to
>>> see the format specifiers moved to their variable instance, like
>>> this:
>>>
>>> Old way:
>>>     printf("%s %p\n", ptr, ptr);
>>>
>>> New way:
>>>     printf("% %\n", [s]ptr, [p]ptr);
>>
>> But note that that syntax ([s]ptr, and so on) already has a meaning, so
>> you need to take some steps to make this usage clearly recognisable.
>>
>> <snip>
>
> It does?

No, you are right -- it doesn't!  Don't know what I was thinking.

<snip>
-- 
Ben.

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

#65519

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Keith Thompson <kst-u@mib.org> writes:
> > Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >>
> >>> New way:
> >>>     printf("% %\n", [s]ptr, [p]ptr);
> >>
> >> But note that that syntax ([s]ptr, and so on) already has a meaning, so
> >> you need to take some steps to make this usage clearly recognisable.
> >
> > It does?
> 
> No, you are right -- it doesn't!  Don't know what I was thinking.

I suspect you were thinking of the semi-common trick of using

  index[ptr1] ... index[ptr2]

instead of

  ptr1[index] ... ptr2[index]

to do stylistic tricks with parallel arrays.

Richard

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

#65074

On Thursday, July 9, 2015 at 4:50:13 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > [...]  And one more:  I would like to
> > see the format specifiers moved to their variable instance, like
> > this:
> >
> > Old way:
> >     printf("%s %p\n", ptr, ptr);
> >
> > New way:
> >     printf("% %\n", [s]ptr, [p]ptr);
> 
> But note that that syntax ([s]ptr, and so on) already has a meaning, so
> you need to take some steps to make this usage clearly recognisable.

In such a case, I would have the compiler identify certain functions
like printf() and make them defined functions known to the standard
library, and when used that syntax would be recognized in its special
form here.

Best regards,
Rick C. Hodgin

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

#65076

On 09/07/2015 23:07, Rick C. Hodgin wrote:
> On Thursday, July 9, 2015 at 4:50:13 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>>> [...]  And one more:  I would like to
>>> see the format specifiers moved to their variable instance, like
>>> this:
>>>
>>> Old way:
>>>      printf("%s %p\n", ptr, ptr);
>>>
>>> New way:
>>>      printf("% %\n", [s]ptr, [p]ptr);
>>
>> But note that that syntax ([s]ptr, and so on) already has a meaning, so
>> you need to take some steps to make this usage clearly recognisable.
>
> In such a case, I would have the compiler identify certain functions
> like printf() and make them defined functions known to the standard
> library, and when used that syntax would be recognized in its special
> form here.

You could just make them statements, ones with function-like syntax.

Then you can forget about pretending they are ordinary functions like 
all others, because they're not. You don't need to make use of 
cumbersome techniques either (such as varargs and the new ones described 
in the thread to enable type info to be passed).

-- 
Bartc

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

#65078

On Thursday, July 9, 2015 at 6:17:02 PM UTC-4, Bart wrote:
> On 09/07/2015 23:07, Rick C. Hodgin wrote:
> > On Thursday, July 9, 2015 at 4:50:13 PM UTC-4, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >>
> >>> [...]  And one more:  I would like to
> >>> see the format specifiers moved to their variable instance, like
> >>> this:
> >>>
> >>> Old way:
> >>>      printf("%s %p\n", ptr, ptr);
> >>>
> >>> New way:
> >>>      printf("% %\n", [s]ptr, [p]ptr);
> >>
> >> But note that that syntax ([s]ptr, and so on) already has a meaning, so
> >> you need to take some steps to make this usage clearly recognisable.
> >
> > In such a case, I would have the compiler identify certain functions
> > like printf() and make them defined functions known to the standard
> > library, and when used that syntax would be recognized in its special
> > form here.
> 
> You could just make them statements, ones with function-like syntax.
> 
> Then you can forget about pretending they are ordinary functions like 
> all others, because they're not. You don't need to make use of 
> cumbersome techniques either (such as varargs and the new ones described 
> in the thread to enable type info to be passed).

There's a syntax in Visual FoxPro's XBASE language which I've always
liked.  It's called TEXTMERGE in the language, but its general concept
is you create text you want to display and then introduce sections
you want to replace with variable content using <<this>> syntax.

Example in VFP's XBASE syntax:

    lcDay    = CDOW(DATE())                && Monday...
    lnMonth  = MONTH(DATE())               && January...
    lnDayNum = PADL(DAY(DATE()), 2, "0")   && 09
    lnYear   = YEAR(DATE())                && 2015

    TEXTMERGE TO myVar
Today is <<lcDay>>, <<lnMonth>> <<lnDayum>>, <<lnYear>>
    ENDTEXTMERGE

The end result is this kind of operation:

    myVar = "Today is Thursday, July 09, 2015"

Something similar might work for RDC.  The compiler would parse the
<<var>> parts and then introduce them:

    int i = 5;
    printf("i: <<[03]i>>\n");

And automatically generate:

    int i = 5;
    printf("i: %03d\n", i);

Best regards,
Rick C. Hodgin

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

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

csiph-web