function sprintf

[Michele]

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean? And what does the function sprintf do?
Thanks
michele

 

[Leor Zolman]

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean? And what does the function sprintf do?
Thanks
michele

Have you got a library reference book handy? If not, how about a browser?
You can get all the info you need on library facilities online. I like the
Dinkumware site:
http://dinkumware.com/manuals/reader.aspx?lib=cpp
(It's the "C++" lib, but that includes the C headers. You'll find sprintf
in sdio.h)
-leor

 

[Malcolm]

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean? And what does the function sprintf do?

You need to look up the function. sprintf() formats characters to a string.
If you've used C at all you'll be familiar with the printf() function.
sprintf() is very similar, but characters are stored instead of being passed
to the output.

buf is the destination string. It must be a char * pointing to enough memory
to hold the output.
"%20g" is the format string. %g tells the computer to print a floating-point
vlaue, and the 20 is the field width specifier.
*(liftPtr++) means take what liftPtr points to, here a floating-point
number, and then increment the pointer as a size effect. Your are obviously
looking at some code which is printing out a list of floating point numbers.

 

[Leor Zolman]

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean? And what does the function sprintf do?

Oh sorry, I did mean to help you with the pointer expression part.

This code implies that liftPtr is a pointer to float or double (presumably
a pointer to somewhere within an array of them.) Let's just call it double,
since there isn't much to go on (I'm assuming it is a floating point type
because of the %g format conversion being used to display a value).

The value of the expression (liftPtr++) is the present ("old") value of
that pointer; the indirection operator (*) is applied to that value,
yielding the value of the double that the pointer goes into that statement
pointing to.

Before the next line of code executes (I'm simplifying here), the value of
liftPtr will have been incremented to point to the /next/ double in
sequence. That's what the ++ does, and its position on the right of its
operand ("postfix" notation) is what "delays" the incrementing until after
the old value has been sampled for use as the operand to *.

Make sense?
-leor

 

[Neil Cerutti]

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean?

It means it's time to read some documentation. ;-)

 

[pete]

The value of the expression (liftPtr++) is the present
("old") value of that pointer;
the indirection operator (*) is applied to that value,
yielding the value of the double that the pointer goes into that
statement pointing to.

Before the next line of code executes (I'm simplifying here),'
the value of liftPtr will have been incremented to point to
the /next/ double in sequence. That's what the ++ does, and its
position on the right of its operand ("postfix" notation)
is what "delays" the incrementing until after
the old value has been sampled for use as the operand to *.

Make sense?

I want to emphasize that there is no order as to
whether the evaluation or the increment takes place first.
By putting the word "delays" in quotes, you suggest that
you are aware of that, but it might be too subtle for OP.

 

[Leor Zolman]

I want to emphasize that there is no order as to
whether the evaluation or the increment takes place first.
By putting the word "delays" in quotes, you suggest that
you are aware of that, but it might be too subtle for OP.

Right, I just didn't think the OP was in particular need of that level of
detail at this point in her learning curve. But note that I was careful in
my wording to say "the old value has been sampled", rather than stating
there was an order between the increment and the indirection operation (he
/can/ be taught.) I don't see how the increment could possibly take place
/before/ the old value had ever been "sampled". My intent was to prevent
the meaning from being misconstrued ;-)
-leor

 

[Bliss]

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean? And what does the function sprintf do?

It is like printf() but outputs to a string.
It means find the float (or double) pointed to by liftPtr and
put its text representation in the string pointed to by buf and then
add one to the pointer liftPtr.Roger.

 

[Chris Torek]

(on the postfix "++" operator)

... I don't see how the increment could possibly take place
/before/ the old value had ever been "sampled".

Some of this depends on what one means by "sampled", but consider
the following concrete expansion of:

i = j++;

on a machine with i and j in registers:

inc reg_holding_j # j = j + 1
sub reg_holding_j, 1, reg_holding_i # i = j - 1

Here, even though the "inc" happens "last" in principle (because i
has to get set to the old value of j), the compiler has for some
reason incremented j first, then subtracted 1 from the result to
re-compute the old value.

(Of course, the original example was more like "*p++", which probably
would have added 8 to p on a byte-oriented machine -- but the above
still works if one changes all the "1"s to "8"s. It is legal, just
peculiar, to do the increment first. There are some odd instruction
sets that encourage this kind of odd machine code, though.)

 

[Michele]

I'm sorry, maybe I'm too lazy...
thanks
michele

It means it's time to read some documentation. ;-)

--
Neil Cerutti
"Captain, every day I grow more and more convinced that the
wisest and the best is to fix your eyes on the good and the beautiful."
"You're some guy McKonan." -_The Phantom Planet_

 

[Leor Zolman]

I'm sorry, maybe I'm too lazy...
thanks
michele

I think it takes less work to look something up, once you have the book
handy or the bookmark in place in your browser favorites, than it does to
post a question to a newsgroup. So you can indulge your laziness /and/ get
the answer quicker. What's not to like?
-leor

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leor Zolman wrote:

[snip]
| I don't see how the increment could possibly take place
| /before/ the old value had ever been "sampled".


Leor, consider a hypothetical compiler on a machine that permits
indexing. The generated code might look like

~ inc liftPtr
~ ld temp,(liftPtr - 1)

Or, in terms of a real processor (still hypothetical compiler though),
consider the following Z80 instructions

~ inc ix
~ ld a,(ix-1)

where ix contains the value of liftPtr, and a will contain the result of
~ *(liftPtr++)

- --

Lew Pitcher, IT Consultant, Enterprise Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFAbav0agVFX4UWr64RAqxrAKC28vs1rRlDXKLuyzrjy+VtYTppZACgrusS
dtPCl/HffSc7gLBGRaHOjQ0=
=cdcR
-----END PGP SIGNATURE-----

 

[Leor Zolman]

(on the postfix "++" operator)



Some of this depends on what one means by "sampled", but consider
the following concrete expansion of:

i = j++;

on a machine with i and j in registers:

inc reg_holding_j # j = j + 1
sub reg_holding_j, 1, reg_holding_i # i = j - 1

Here, even though the "inc" happens "last" in principle (because i
has to get set to the old value of j), the compiler has for some
reason incremented j first, then subtracted 1 from the result to
re-compute the old value.

(Of course, the original example was more like "*p++", which probably
would have added 8 to p on a byte-oriented machine -- but the above
still works if one changes all the "1"s to "8"s. It is legal, just
peculiar, to do the increment first. There are some odd instruction
sets that encourage this kind of odd machine code, though.)

I was just asking for it, wasn't I? ;-)

Seriously, though, is it really the general consensus of the group that
this ordering issue should be required as part of the answer to /any/ level
of question on the behavior of post-increment expressions? I really, really
didn't want to go into the full-blown explanation, because I made the
judgment that Michele would neither have needed nor wanted to know the
full, gory details. If the question had been phrased at a different level,
such as "I know what the basic purpose is, but what are the /real/ ordering
requirements here?" then fine. But when someone asks "What does it mean?"
and points to a line of code such the one shown, I think that level of
detail is just plain inappropriate. I recognize I may be in the minority
here. Perhaps Michele would be willing to provide me with a reality check?
Thanks,
-leor

 

[Alan Balmer]

Seriously, though, is it really the general consensus of the group that
this ordering issue should be required as part of the answer to /any/ level
of question on the behavior of post-increment expressions?

Not for me. I would argue that if this fact makes any difference to
your program, the program probably needs some attention.

 

[Richard Heathfield]

Seriously, though, is it really the general consensus of the group that
this ordering issue should be required as part of the answer to /any/
level of question on the behavior of post-increment expressions?

Not on my account. It's a tricky line to walk. Explain too much and you get
typist's cramp. Explain too little and people correct you. (Sigh.)

On the other hand, Chris Torek is always good for a read, so don't let it
get you down.

 

[Leor Zolman]

Not on my account. It's a tricky line to walk. Explain too much and you get
typist's cramp. Explain too little and people correct you. (Sigh.)

On the other hand, Chris Torek is always good for a read, so don't let it
get you down.

Oh, it didn't get me "down" at all! (in fact, I get a buzz from seeing
assembly code, mostly because it makes me so happy to not have to be coding
in it any more.)

I just tried so /hard/ to write my explanation of *ptr++ in such a way as
to give the OP the info I thought was most important, without triggering
the nit picking, and I didn't quite pull it off. Looking back at what I
wrote, I realize now I could have re-phrased the offending part in a
temporally-neutral manner, which would probably have been good enough. So
instead of:

That's what the ++ does, and its position on the right of its
operand ("postfix" notation) is what "delays" the incrementing until after
the old value has been sampled for use as the operand to *.

I might have said:

That's what the ++ does, and its position on the right of its operand
("postfix" notation) is what specifies that the "old" value of liftPtr is
used as the operand to '*'.

Better?
-leor

 

[Richard Heathfield]

I just tried so /hard/ to write my explanation of *ptr++ in such a way as
to give the OP the info I thought was most important, without triggering
the nit picking, and I didn't quite pull it off.

Here's your badge. Here's your locker key. Toilets are down the hall, on the
left. Fire escape is out the back. You can use that coffee machine over
there. (This one here is private, I'm afraid. I get through a lot of
coffee, ever since the Incident Involving An Assertion Failure.)

Welcome to comp.lang.c.

Looking back at what I
wrote, I realize now I could have re-phrased the offending part in a
temporally-neutral manner, which would probably have been good enough. So
instead of:

That's what the ++ does, and its position on the right of its
operand ("postfix" notation) is what "delays" the incrementing until after
the old value has been sampled for use as the operand to *.

I might have said:

That's what the ++ does, and its position on the right of its operand
("postfix" notation) is what specifies that the "old" value of liftPtr is
used as the operand to '*'.

Better?

Yes, I think it's much improved. Specifically, it doesn't unwittingly assume
a particular implementation.

 

[Neil Cerutti]

I might have said:

That's what the ++ does, and its position on the right of its operand
("postfix" notation) is what specifies that the "old" value of liftPtr is
used as the operand to '*'.

Better?

I find it's clearest to speak about the value of operators with
side effects in terms of what they evaluate to, i.e., ptr++
evaluates to ptr, while ++ptr evaluates to ptr+1, even though
they have the same side effect.

 

[Leor Zolman]

I find it's clearest to speak about the value of operators with
side effects in terms of what they evaluate to, i.e., ptr++
evaluates to ptr, while ++ptr evaluates to ptr+1, even though
they have the same side effect.

That sounds good. I have more trouble with terminology than anything else;
perhaps it is because English was my third language, I don't know...
Thanks,
-leor

 

[Leor Zolman]

Here's your badge. Here's your locker key. Toilets are down the hall, on the
left. Fire escape is out the back. You can use that coffee machine over
there. (This one here is private, I'm afraid. I get through a lot of
coffee, ever since the Incident Involving An Assertion Failure.)

Thanks, Richard! So I've got my locker, my "Troll" badge... what's next?
What if I shoot for getting through an entire week of posting at my average
frequency without choosing to click "Send Now" prematurely? (I know, I
should probably just try for one full day first, but I'm notorious for
over-reaching...)
-leor