printf extensions for output of arrays

[jacob navia]

Has anyone here any information about how arrays can be
formatted with printf?

I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

Thanks

[kuyper]

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?

I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

Non-standard extension to C are not, in themselves, on-topic for
comp.std.c. You could bring it on-topic by suggesting that some such
extension be standardized, or by asking whether a conforming
implementation is allowed to provide such extensions, or any of a
number of other variations. As it stands, your inquiry should have been
posted only to comp.lang.c.

[Walter Roberson]

In article <11**********************@f14g2000cwb.googlegroups .com>,
<ku****@wizard.net> wrote:

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf? I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

Non-standard extension to C are not, in themselves, on-topic for
comp.std.c. You could bring it on-topic by suggesting that some such
extension be standardized, or by asking whether a conforming
implementation is allowed to provide such extensions, or any of a
number of other variations. As it stands, your inquiry should have been
posted only to comp.lang.c.

Over here in comp.lang.c we would have just said that such extensions
are not part of the C standard and so are not on topic here...

--
Chocolate is "more than a food but less than a drug" -- RJ Huxtable

[Kenny McCormack]

In article <11**********************@f14g2000cwb.googlegroups .com>,
<ku****@wizard.net> wrote:

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?

I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

Non-standard extension to C are not, in themselves, on-topic for
comp.std.c. You could bring it on-topic by suggesting that some such
extension be standardized, or by asking whether a conforming
implementation is allowed to provide such extensions, or any of a
number of other variations. As it stands, your inquiry should have been
posted only to comp.lang.c.

Funny on so many levels.
You have a career in comedy, to be sure.

[kuyper]

Kenny McCormack wrote:

In article <11**********************@f14g2000cwb.googlegroups .com>,
<ku****@wizard.net> wrote:

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?

I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

Non-standard extension to C are not, in themselves, on-topic for
comp.std.c. You could bring it on-topic by suggesting that some such
extension be standardized, or by asking whether a conforming
implementation is allowed to provide such extensions, or any of a
number of other variations. As it stands, your inquiry should have been
posted only to comp.lang.c.

Funny on so many levels.
You have a career in comedy, to be sure.

If you have a point, make it. That comment was too obscure to qualify.

[Malcolm]

<ku****@wizard.net> wrote

Has anyone here any information about how arrays can be
formatted with printf?

I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

Non-standard extension to C are not, in themselves, on-topic for
comp.std.c. You could bring it on-topic by suggesting that some such
extension be standardized, or by asking whether a conforming
implementation is allowed to provide such extensions, or any of a
number of other variations. As it stands, your inquiry should have been
posted only to comp.lang.c.

A question about whether it is possible to pass an array to printf() (as
some languages allow for their analgous output statements) would be topical.
However Jacob Navia knows C well enough not to need to ask this.
The question is therefore a proposal for an extension to the language, and
thus topical on comp.std.c, but not on comp.lang.c.

[Mark McIntyre]

On 6 Nov 2005 12:43:46 -0800, in comp.lang.c , ku****@wizard.net
wrote:

Kenny McCormack wrote:

Funny on so many levels.
You have a career in comedy, to be sure.

If you have a point, make it. That comment was too obscure to qualify.

Just ignore Kenny, he's one of the resident trolls over here in CLC.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Keith Thompson]

"Malcolm" <re*******@btinternet.com> writes:

<ku****@wizard.net> wrote

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?

I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

Non-standard extension to C are not, in themselves, on-topic for
comp.std.c. You could bring it on-topic by suggesting that some such
extension be standardized, or by asking whether a conforming
implementation is allowed to provide such extensions, or any of a
number of other variations. As it stands, your inquiry should have been
posted only to comp.lang.c.

A question about whether it is possible to pass an array to printf()
(as some languages allow for their analgous output statements) would
be topical. However Jacob Navia knows C well enough not to need to
ask this. The question is therefore a proposal for an extension to
the language, and thus topical on comp.std.c, but not on
comp.lang.c.

That's assuming that jacob was actually proposing an extension to the
language. That's the most reasonable interpretation, but he didn't
actually say so, and I'm hesitant to make any assumptions.

jacob, can you clarify your question? Are you asking about the
language as it's currently defined (topical for comp.lang.c, but the
answer is simply "no"), about non-standard extensions to the language
(off-topic), or about a proposed enhancement for the next version of
the standard (topical in comp.std.c)?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

Keith Thompson wrote:

"Malcolm" <re*******@btinternet.com> writes:

<ku****@wizard.net> wrote

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?

I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

Non-standard extension to C are not, in themselves, on-topic for
comp.std.c. You could bring it on-topic by suggesting that some such
extension be standardized, or by asking whether a conforming
implementation is allowed to provide such extensions, or any of a
number of other variations. As it stands, your inquiry should have been
posted only to comp.lang.c.

A question about whether it is possible to pass an array to printf()
(as some languages allow for their analgous output statements) would
be topical. However Jacob Navia knows C well enough not to need to
ask this. The question is therefore a proposal for an extension to
the language, and thus topical on comp.std.c, but not on
comp.lang.c.

That's assuming that jacob was actually proposing an extension to the
language. That's the most reasonable interpretation, but he didn't
actually say so, and I'm hesitant to make any assumptions.

jacob, can you clarify your question? Are you asking about the
language as it's currently defined (topical for comp.lang.c, but the
answer is simply "no"), about non-standard extensions to the language
(off-topic), or about a proposed enhancement for the next version of
the standard (topical in comp.std.c)?

As I said in comp.lang.c, I have a customer that wants that stuff.
I supposed that it is a common extension to printf and I just wanted
to know if other compilers have done this to be compatible with
them.

I will probably do as gcc, that implements a printf register
functionality :
http://docs.biostat.wustl.edu/cgi-bi...on%2520Example

but it is not specific to arrays, what could be better, I do not know.

It *could* be a useful extension to the printf function probably, but I
do not want to add yet another sin to my already long list of extensions
requests :-)

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.fr> writes:

Keith Thompson wrote:

[...]

<ku****@wizard.net> wrote
jacob navia wrote:
>Has anyone here any information about how arrays can be
>formatted with printf?
>
>I mean something besides the usual formatting of each element
>in a loop. I remember that Trio printf had some extensions but
>I do not recall exactly if they were meant for arrays.

[snip] That's assuming that jacob was actually proposing an extension to the
language. That's the most reasonable interpretation, but he didn't
actually say so, and I'm hesitant to make any assumptions.
jacob, can you clarify your question? Are you asking about the
language as it's currently defined (topical for comp.lang.c, but the
answer is simply "no"), about non-standard extensions to the language
(off-topic), or about a proposed enhancement for the next version of
the standard (topical in comp.std.c)?

As I said in comp.lang.c, I have a customer that wants that stuff.
I supposed that it is a common extension to printf and I just wanted
to know if other compilers have done this to be compatible with
them.

I will probably do as gcc, that implements a printf register
functionality :
http://docs.biostat.wustl.edu/cgi-bi...on%2520Example

but it is not specific to arrays, what could be better, I do not know.

It *could* be a useful extension to the printf function probably, but I
do not want to add yet another sin to my already long list of extensions
requests :-)

Ok, that's much clearer.

Topicality in this case is a tricky question. The C standard
specifically allows extensions, so extensions aren't *inherently*
off-topic. I suppose I'd argue that a general question about what
extensions are out there is topical (more in comp.lang.c than in
comp.std.c), but detailed discussions of a particular implementation
should be taken to a system-specific newsgroup.

That's just my opinion; others are likely to differ.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Douglas A. Gwyn]

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?
I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

It's not wise to extend print formatting, because code that
uses the extension won't be portable to other platforms.
Why in the world do you think printf should be looping
instead of the app that knows about the data structure?

[Robert Gamble]

Douglas A. Gwyn wrote:

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?
I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.
It's not wise to extend print formatting, because code that
uses the extension won't be portable to other platforms.

I think he was asking because he was considering adding it to his
implementation and wanted to know how others might have accomplished
this before, perhaps to avoid being incompatible with them, but I agree
with your premise.
Why in the world do you think printf should be looping
instead of the app that knows about the data structure?

Presumably to remove the overhead of calling printf many times. The
fact that printf already does this for arrays of characters via the 's'
conversion specifier make it logical for one to consider the
possibility of extending the functionality to other types. The
immediate difference one would notice is the fact that you would need
to know the exact number of items in the array since there is no analog
to strings for other types. The main issue I see however is telling
printf *how* to print an array of, for instance, integers. Do you
print the integers seperated by a single space, do you try and specify
the delimiters dynamically? How would you do this? It quickly becomes
obvious, at least to myself, that trying to provide a generalized
solution for this issue in the Standard library isn't worth much
thought, especially since it is easy enough to write a wrapper function
using vsprintf to better handle specialized needs.

Robert Gamble

[kuyper]

Douglas A. Gwyn wrote:

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?
I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

It's not wise to extend print formatting, because code that
uses the extension won't be portable to other platforms.
Why in the world do you think printf should be looping
instead of the app that knows about the data structure?

The conceptual issue you raise doesn't seem especially
language-specific. Several other languages I'm familiar with such as
APL, IDL, and perl all handle arrays much more conveniently than C's
printf() does. Even Fortran print formats are capable of handling
arrays; it's one of the few ways in which Fortran printing is more
convenient than C printing. Do you think the array-printing facilities
of those other languages represent bad design for that same reason?

[David R Tribble]

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?
I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.
Douglas A. Gwyn wrote: It's not wise to extend print formatting, because code that
uses the extension won't be portable to other platforms.
Robert Gamble wrote:

I think he was asking because he was considering adding it to his
implementation and wanted to know how others might have accomplished
this before, perhaps to avoid being incompatible with them, but I agree
with your premise.

It would be interesting to see if the symtax of the format specifier
string was a truly upward compatible extension to ISO C,
especially in light of some of the additions in C99.
Why in the world do you think printf should be looping
instead of the app that knows about the data structure?

Presumably to remove the overhead of calling printf many times. The
fact that printf already does this for arrays of characters via the 's'
conversion specifier make it logical for one to consider the
possibility of extending the functionality to other types. The
immediate difference one would notice is the fact that you would need
to know the exact number of items in the array since there is no analog
to strings for other types. The main issue I see however is telling
printf *how* to print an array of, for instance, integers. Do you
print the integers seperated by a single space, do you try and specify
the delimiters dynamically? How would you do this? It quickly becomes
obvious, at least to myself, that trying to provide a generalized
solution for this issue in the Standard library isn't worth much
thought, especially since it is easy enough to write a wrapper function
using vsprintf to better handle specialized needs.

My thoughts exactly. Provide an 'array_printf()' that takes all this
information as extra parameters. The overhead of calling printf
multiple times pales in comparison to the amount of overhead
required by the actual I/O (write) operations.

[jacob navia]

ku****@wizard.net wrote:

Douglas A. Gwyn wrote:

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?
I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.
It's not wise to extend print formatting, because code that
uses the extension won't be portable to other platforms.
Why in the world do you think printf should be looping
instead of the app that knows about the data structure?

The conceptual issue you raise doesn't seem especially
language-specific. Several other languages I'm familiar with such as
APL,

WOW!!!!

Another APL guy!

I remember Quad FMT. What a WONDERFUL printing function.

IDL, and perl all handle arrays much more conveniently than C's printf() does. Even Fortran print formats are capable of handling
arrays; it's one of the few ways in which Fortran printing is more
convenient than C printing. Do you think the array-printing facilities
of those other languages represent bad design for that same reason?

C and arrays doesn't mix very well. I never understood why.

jacob

[Douglas A. Gwyn]

ku****@wizard.net wrote:

... Even Fortran print formats are capable of handling
arrays; it's one of the few ways in which Fortran printing is more
convenient than C printing. Do you think the array-printing facilities
of those other languages represent bad design for that same reason?

It's convenient *if* you can live with the formatting details
imbedded in the PRINT feature. FORTRAN, for quite some time
at least, didn't have good support for other kinds of data
structures and thus singling out the one kind that it did
support was fairly natural. Also note that it didn't support
creation of output lines piece by piece, so the user would
really be stuck for printing matrices without built-in
support. There aren't enough similarities between the
languages to use that as a guide.

[Robert Gamble]

David R Tribble wrote:

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?
I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.
Douglas A. Gwyn wrote: It's not wise to extend print formatting, because code that
uses the extension won't be portable to other platforms.
Robert Gamble wrote:

I think he was asking because he was considering adding it to his
implementation and wanted to know how others might have accomplished
this before, perhaps to avoid being incompatible with them, but I agree
with your premise.

It would be interesting to see if the symtax of the format specifier
string was a truly upward compatible extension to ISO C,
especially in light of some of the additions in C99.
Why in the world do you think printf should be looping
instead of the app that knows about the data structure?

Presumably to remove the overhead of calling printf many times. The
fact that printf already does this for arrays of characters via the 's'
conversion specifier make it logical for one to consider the
possibility of extending the functionality to other types. The
immediate difference one would notice is the fact that you would need
to know the exact number of items in the array since there is no analog
to strings for other types. The main issue I see however is telling
printf *how* to print an array of, for instance, integers. Do you
print the integers seperated by a single space, do you try and specify
the delimiters dynamically? How would you do this? It quickly becomes
obvious, at least to myself, that trying to provide a generalized
solution for this issue in the Standard library isn't worth much
thought, especially since it is easy enough to write a wrapper function
using vsprintf to better handle specialized needs.

My thoughts exactly. Provide an 'array_printf()' that takes all this
information as extra parameters. The overhead of calling printf
multiple times pales in comparison to the amount of overhead
required by the actual I/O (write) operations.

Perhaps. On top of the overhead of calling the function though there
is also the time it takes to parse the format string and the fact that
in certain circumstances multiple "little" writes to a stream may take
considerably longer than a single "larger" write. If you are printing
to a character buffer the time to perform the write will probably be
much smaller than writing to an output stream making the proportion of
time spent elsewhere more significant.

Robert Gamble

[Robert Gamble]

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?

I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

The Trio had a lot of interesting extensions via its trio_printf family
of functions, you are probably referring to the trio_printfv (the v for
vector I suppose) function which takes an array of pointers to void as
its second argument. For example, "trio_printfv("%d %d %f\n", vp);"
would expect vp to be the address of the first void pointer in an array
of 3 void pointers that could be converted to pointers to int, int, and
double respectively. This doesn't sound like it accomplishes what you
are looking for, I haven't ever seen anything that does.

Here is what I came up with (I haven't put much thought into this, it
should probably be considered a testament to why this isn't a good
idea):

Example 1:
my_printf("%[10]d\n", int_array);

This would print out 10 integers from int_array, I use the the brackets
to indicate an array is the argument and specify the number of items
from the array to print. In this example, the integers would be
seperated by a single space, this would be the default.

Example 2:
my_printf("%[10%c]d\n", int_array, ",");

In this example we explicitly specify the delimiter by using a second
conversion specifier inside the brackets after the number of array
members, in this case 'c' for character. The argument corresponding to
the delimiter follows the array argument.

Example 3:
my_printf("%[10%s]d\n", int_array, "my delimiter string");

Same as above but specify a string as the delimiter.

Of course you can use field width, precision, etc. with this format:
my_printf("%6.2[10]f\n", double_array);

If this is not enough control over delimiter choices, you can specify a
list of delimiters as well:

Example 4:
my_printf("%[10%[5]c]d\n", (int []){1,2,3,4,5,6,7,8,9,10}, "abcde");

Specifies that we want to print an array of 10 integers delimited by an
array of 5 characters and that we want to iterate through the
characters as delimeters wrapping back to the first one after the last
one is used.

This would of course print:
1a2b3c4d5e6a7b8c9d10

Notice that there is no delimiter following the last member printed.

We won't allow any further nesting of conversion specifiers for
simplicity sake but we should allow multiple non-nesting conversion
specifiers in the delimeter string:
my_printf("%[3%c%[2]c]d\n", (int []){1,2,3}, "-", "*/");
would print:
1-*2-/3

Of course, you could also provide a pointer to a function that is
called after printing each value to return the delimiter for that
value, I'll spare you the semantics of that one.

I'd be interested to know what you come up with.

Robert Gamble

[Douglas A. Gwyn]

jacob navia wrote:

C and arrays doesn't mix very well. I never understood why.

Basically it's because in C pointer (to whatever type) is a
more fundamental concept, and an array name is converted to
pointer-to-first-element (thus losing the length information)
in most contexts. Arrays are *not* first-class objects in C,
as witness what happens when you try to assign one array to
another.

As of C99, there is a generally richer kind of array type,
under the name VLA (Variable-Length Array).

[Suman]

Robert Gamble wrote:

[replying to jacob navia]:

Has anyone here any information about how arrays can be
formatted with printf?

[...]
Example 2:
my_printf("%[10%c]d\n", int_array, ","); --^
In this example we explicitly specify the delimiter by using a second
conversion specifier inside the brackets after the number of array
members, in this case 'c' for character. The argument corresponding to
the delimiter follows the array argument.
Are you sure you meant a "," and not a ','?
Example 3:
my_printf("%[10%s]d\n", int_array, "my delimiter string");

Same as above but specify a string as the delimiter.

So much to support me.

Or did I, in some way fail to make sense of your post. It made for
a nice thought provoking read, though. Thanks.

[Robert Gamble]

Suman wrote:

Robert Gamble wrote:

[replying to jacob navia]:

Has anyone here any information about how arrays can be
formatted with printf?

[...]

Example 2:
my_printf("%[10%c]d\n", int_array, ",");

--^

In this example we explicitly specify the delimiter by using a second
conversion specifier inside the brackets after the number of array
members, in this case 'c' for character. The argument corresponding to
the delimiter follows the array argument.

You are correct, the third argument should be a character constant, not
a string.

Robert Gamble

[jacob navia]

Thanks for this specs Robert.

I will try them in the implementation

jacob

[Antoine Leca]

En news:ln************@nuthaus.mib.org, Keith Thompson va escriure:
[Reformatted]

Are you asking about the language as it's currently defined
(topical for comp.lang.c, but the answer is simply "no"),
about a proposed enhancement for the next version of the
standard (topical in comp.std.c),
Agreed so far.
or about non-standard extensions to the language (off-topic)?

Ahem. But then, where could it be on-topic to ask for existing extensions to
the language beyond the standard?

Particularly if someone is interested into things that could be used among
various platforms (which would disqualify
comp.os.nameyourmosthatredsystem.programming).
I believe comp.lang.c does not have any charter or RFD (probably because it
predates the formal procedures for the creation of a new newsgroup), yet it
seems to me it should be dealt with here (or there, since this is
cross-posted ;-)).
Particularly since the readership which does know about the answers is
following one or another group...
By the way, applying Keith's reasonning to the letter would mean that any
post mentionning long long would have been off-topic some years ago ;-), and
Google Groups have more than 400 threads mentionning it (in comp.lang.c
before 1999-12-01, that is)...
Antoine

[Mark McIntyre]

On Tue, 15 Nov 2005 10:43:04 +0100, in comp.lang.c , "Antoine Leca"
<ro**@localhost.invalid> wrote:

Ahem. But then, where could it be on-topic to ask for existing extensions to
the language beyond the standard?
comp.std.c, by proposing it as an enhancement.
I believe comp.lang.c does not have any charter or RFD (probably because it
predates the formal procedures for the creation of a new newsgroup), yet it
seems to me it should be dealt with here (or there, since this is
cross-posted ;-)).
Likely that if you do that, you'll get flamed.
By the way, applying Keith's reasonning to the letter would mean that any
post mentionning long long would have been off-topic some years ago ;-),
correct. But bear in mind the Standard was being revised for some
years before 1999, so discussion of likely directions could be
considered pseudotopical here.
and
Google Groups have more than 400 threads mentionning it (in comp.lang.c
before 1999-12-01, that is)...

There are also long threads about a drove of other, even less topical
things. We're not perfect, and we're susceptible to trolls just like
any other group
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[kuyper]

Antoine Leca wrote:

En news:ln************@nuthaus.mib.org, Keith Thompson va escriure:
[Reformatted]

Are you asking about the language as it's currently defined
(topical for comp.lang.c, but the answer is simply "no"),
about a proposed enhancement for the next version of the
standard (topical in comp.std.c),

.... By the way, applying Keith's reasonning to the letter would mean that any
post mentionning long long would have been off-topic some years ago ;-), and
Google Groups have more than 400 threads mentionning it (in comp.lang.c
before 1999-12-01, that is)...

I'm not sure I follow how his reasoning supports that conclusion. Prior
to it's inclusion in the 1999 standard, long long was a real, widely
supported non-standard extension, and as such I believe it's on-topic
for comp.lang.c. During that same time period, discussion of whether
or not "long long" should be standardized was entirely on-topic for
comp.std.c.

Ever since "long long" was added to the C99 standard, asking whether or
not it had been added is trivially on-topic for comp.std.c, and
discussions of how to (or how not to) use it should be on-topic for
comp.lang.c. And, like any other decision the committee has made, the
question of whether or not the decision to standardize "long long" was
made correctly will always be on-topic for comp.std.c, because the
answer to that question is very relevant to future decision making.

[Antoine Leca]

En news:11**********************@g49g2000cwa.googlegr oups.com,
James Kuyper va escriure:

Antoine Leca wrote:

En news:ln************@nuthaus.mib.org, Keith Thompson va escriure:
[Reformatted]

Are you asking about the language as it's currently defined
(topical for comp.lang.c, but the answer is simply "no"),
about a proposed enhancement for the next version of the
standard (topical in comp.std.c),

...

By the way, applying Keith's reasonning to the letter would mean
that any post mentionning long long would have been off-topic some
years ago ;-), and Google Groups have more than 400 threads
mentionning it (in comp.lang.c before 1999-12-01, that is)...

I'm not sure I follow how his reasoning supports that conclusion.
Prior to it's inclusion in the 1999 standard, long long was a real,
widely supported non-standard extension, and as such I believe it's
on-topic for comp.lang.c.

That is exactly my idea too.
Which is why I am asking whether _other_ "widely supported
[(]non-standard[)] extension[s]" could also be topical there.
Then we can engage a rough discussion about what "widely supported" could
mean, of course ;-).
Antoine

[kuyper]

Antoine Leca wrote:

En news:11**********************@g49g2000cwa.googlegr oups.com,
James Kuyper va escriure:

Antoine Leca wrote:

En news:ln************@nuthaus.mib.org, Keith Thompson va escriure:
[Reformatted]
Are you asking about the language as it's currently defined
(topical for comp.lang.c, but the answer is simply "no"),
about a proposed enhancement for the next version of the
standard (topical in comp.std.c),

...

By the way, applying Keith's reasonning to the letter would mean
that any post mentionning long long would have been off-topic some
years ago ;-), and Google Groups have more than 400 threads
mentionning it (in comp.lang.c before 1999-12-01, that is)...

I'm not sure I follow how his reasoning supports that conclusion.
Prior to it's inclusion in the 1999 standard, long long was a real,
widely supported non-standard extension, and as such I believe it's
on-topic for comp.lang.c.

That is exactly my idea too.
Which is why I am asking whether _other_ "widely supported
[(]non-standard[)] extension[s]" could also be topical there.
Then we can engage a rough discussion about what "widely supported" could
mean, of course ;-).

Any extension to C, widely implemented or not, is on-topic for
comp.std.c if what's being expressed is an opinion about whether or not
it should be standardized, or if you're discussing whether or not it's
a legal extension for a conforming implementation (some extensions are
permitted for conforming implementations; other extensions inherently
render an implementation non-conforming, and must be turned off in any
mode that the implementation claims is fully conforming). If you're
just talking about the extension itself, without making any connection
to the standard, then it's off-topic for comp.std.c, no matter how
widely it is implemented.

I'm don't know what the rules for comp.lang.c are, since I normally
post there only as a side-effect of responding to messages that are
cross-posted to both newsgroups. I'd guess that widely-supported
extensions to C might be on-topic, but that it matters quite a bit just
how widely they are supported.

[kishore_mca330]

jacob navia wrote:

Has anyone here any information about how arrays can be
formatted with printf?

I mean something besides the usual formatting of each element
in a loop. I remember that Trio printf had some extensions but
I do not recall exactly if they were meant for arrays.

Thanks

kishore wrote:
arrays concept is its name tself is a address which represents its
staring element.
and in a printf if we r using arrays other than chraracter arrays,we
must put a loop to repeat until all elements are printed.
like following

for(i=0;i<n/*no of elements*/;i++)
printf("%d\t",array[i]);

and array of characters are called strings.
in string mechanism the array name itself is a address to represent the
string.then printf prints the characters from starting address of array
until it finds a terminating character'\0' which is store in th ending
of string.
like foolowing

printf("%s"/*represents %s is for printing strins*/,array);

this is kishore.i think my answer is sufficient to ur doubt.if ur
required answer is not this pls send me the question in detail to me
for my address as
ki************@yahoo.com
urs friendly,
kishore.
bye.