printf extensions for output of arrays

[Robert Gamble]

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

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

 

[kuyper]

En 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 James Kuyper va escriure:

En 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" could also be topical there.


Then we can engage a rough discussion about what "widely supported" could
mean, of course ;-).


Antoine

 

[kuyper]

En James Kuyper va escriure:

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

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);

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
(e-mail address removed)
urs friendly,
kishore.
bye.