function conversion

[xdevel]

Hi,

I know there are in stdlib.h many functions to perform conversion from
string to int, double ecc.
but I don't understand if there are some standards function to perform
conversion from
int, double ecc to string

Thanks.

[Pietro Cerutti]

Re: function conversion

xdevel wrote:

Hi,
>
I know there are in stdlib.h many functions to perform conversion from
string to int, double ecc.
but I don't understand if there are some standards function to perform
conversion from
int, double ecc to string

I would use sprintf (or snprintf) from stdio.h

>
Thanks.
>

--
Pietro Cerutti

PGP Public Key:

http://gahr.ch/pgp

[xdevel]

Re: function conversion

On 2 Lug, 15:23, Pietro Cerutti <g...@gahr.chwr ote:

xdevel wrote:

Hi,

>

I know there are in stdlib.h many functions to perform conversion from
string to int, double ecc.
but I don't understand if there are some standards function to perform
conversion from
int, double ecc to string

>
I would use sprintf (or snprintf) from stdio.h
>
>
>

Thanks.

>
--
Pietro Cerutti
>
PGP Public Key:http://gahr.ch/pgp

Yes, but I wish to know if there are standard "one-to-one" functions.
I read that i.e. itoa is not!

[Mike Wahler]

Re: function conversion


"xdevel" <xdevel1999@gma il.comwrote in message
news:1183382256 .008827.49600@g 4g2000hsf.googl egroups.com...

Hi,
>
I know there are in stdlib.h many functions to perform conversion from
string to int, double ecc.
but I don't understand if there are some standards function to perform
conversion from
int, double ecc to string

'sprintf()' works like 'printf()', except the output
is to a string instead of stdout.

(Be careful to ensure that your strings are large
enough to hold the output).

-Mike

[Pietro Cerutti]

Re: function conversion

Mike Wahler wrote:

"xdevel" <xdevel1999@gma il.comwrote in message
news:1183382256 .008827.49600@g 4g2000hsf.googl egroups.com...

>Hi,
>>
>I know there are in stdlib.h many functions to perform conversion from
>string to int, double ecc.
>but I don't understand if there are some standards function to perform
>conversion from
>int, double ecc to string

>
'sprintf()' works like 'printf()', except the output
is to a string instead of stdout.
>
(Be careful to ensure that your strings are large
enough to hold the output).

Or use snprintf() and set the limit yourself.

>
-Mike
>
>

--
Pietro Cerutti

PGP Public Key:

http://gahr.ch/pgp

[Keith Thompson]

Re: function conversion

xdevel <xdevel1999@gma il.comwrites:

On 2 Lug, 15:23, Pietro Cerutti <g...@gahr.chwr ote:

>xdevel wrote:

I know there are in stdlib.h many functions to perform conversion from
string to int, double ecc.
but I don't understand if there are some standards function to perform
conversion from
int, double ecc to string

>>
>I would use sprintf (or snprintf) from stdio.h

>
Yes, but I wish to know if there are standard "one-to-one" functions.
I read that i.e. itoa is not!

No.

You can see all the functions in the standard C library by reading the
standard; search for "n1124.pdf" to see the latest draft.

(Please don't quote signatures; trim quoted material to what's
necessary for your response to make sense.)

--
Keith Thompson (The_Other_Keit h) kst-u@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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Re: function conversion

Pietro Cerutti <gahr@gahr.chwr ites:

Mike Wahler wrote:

>"xdevel" <xdevel1999@gma il.comwrote in message
>news:118338225 6.008827.49600@ g4g2000hsf.goog legroups.com...

>>I know there are in stdlib.h many functions to perform conversion from
>>string to int, double ecc.
>>but I don't understand if there are some standards function to perform
>>conversion from
>>int, double ecc to string

>>
>'sprintf()' works like 'printf()', except the output
>is to a string instead of stdout.
>>
>(Be careful to ensure that your strings are large
> enough to hold the output).

>
Or use snprintf() and set the limit yourself.

If your implementation provides snprintf(). That function was added
in C99; many non-C99 implementations provide it as an extension, but
not all do.

--
Keith Thompson (The_Other_Keit h) kst-u@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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Pietro Cerutti]

Re: function conversion

Keith Thompson wrote:

Pietro Cerutti <gahr@gahr.chwr ites:

>Mike Wahler wrote:

>>"xdevel" <xdevel1999@gma il.comwrote in message
>>news:11833822 56.008827.49600 @g4g2000hsf.goo glegroups.com.. .
>>>I know there are in stdlib.h many functions to perform conversion from
>>>string to int, double ecc.
>>>but I don't understand if there are some standards function to perform
>>>conversion from
>>>int, double ecc to string
>>'sprintf()' works like 'printf()', except the output
>>is to a string instead of stdout.
>>>
>>(Be careful to ensure that your strings are large
>> enough to hold the output).

>Or use snprintf() and set the limit yourself.

>
If your implementation provides snprintf(). That function was added
in C99; many non-C99 implementations provide it as an extension, but
not all do.

Uh, I wasn't aware of the fact that snprintf (and also vsnprintf) were
added only in C99.

Tnx for pointing it out!


--
Pietro Cerutti

PGP Public Key:

http://gahr.ch/pgp

[Flash Gordon]

Re: function conversion

Pietro Cerutti wrote, On 02/07/07 18:05:

Keith Thompson wrote:

>Pietro Cerutti <gahr@gahr.chwr ites:

<snip>

>>Or use snprintf() and set the limit yourself.

>If your implementation provides snprintf(). That function was added
>in C99; many non-C99 implementations provide it as an extension, but
>not all do.

>
Uh, I wasn't aware of the fact that snprintf (and also vsnprintf) were
added only in C99.

You also need to be aware that not all C89 implementations that provide
it as an extension provide the same semantics as C99 requires. IIRC the
_snprintf function MS provide has different sementaics (this is legal as
it starts with an _ and MS do not claim C99), for example.
--
Flash Gordon

[Michael Brennan]

Re: function conversion

On 2007-07-02, Flash Gordon <spam@flash-gordon.me.ukwro te:

Pietro Cerutti wrote, On 02/07/07 18:05:

>Keith Thompson wrote:

>>Pietro Cerutti <gahr@gahr.chwr ites:

>
><snip>
>

>>>Or use snprintf() and set the limit yourself.
>>If your implementation provides snprintf(). That function was added
>>in C99; many non-C99 implementations provide it as an extension, but
>>not all do.

>>
>Uh, I wasn't aware of the fact that snprintf (and also vsnprintf) were
>added only in C99.

>
You also need to be aware that not all C89 implementations that provide
it as an extension provide the same semantics as C99 requires. IIRC the
_snprintf function MS provide has different sementaics (this is legal as
it starts with an _ and MS do not claim C99), for example.

At first when I read this I was surprised that this was legal
since I thought that identifiers starting with an underscore
are reserved. Then when I checked the standard I understood that
it is reserved for implementations , which it is in this case.

I just want to check if I've understood this correct:
is it true, that all the reserved identifiers in the standard
are reserved for use only by the implementations ?
That is, if I'm writing and implementation of the standard libary
I am permitted to define new functions starting with an underscore,
but _not_ if I'm making some library that is not the standard lib?

--
Michael Brennan

[xdevel]

Re: function conversion

On 2 Lug, 18:43, Keith Thompson <k...@mib.orgwr ote:

xdevel <xdevel1...@gma il.comwrites:

On 2 Lug, 15:23, Pietro Cerutti <g...@gahr.chwr ote:

xdevel wrote:
I know there are in stdlib.h many functions to perform conversion from
string to int, double ecc.
but I don't understand if there are some standards function to perform
conversion from
int, double ecc to string

>

I would use sprintf (or snprintf) from stdio.h

>

Yes, but I wish to know if there are standard "one-to-one" functions.
I read that i.e. itoa is not!

>
No.
>
You can see all the functions in the standard C library by reading the
standard; search for "n1124.pdf" to see the latest draft.
>
(Please don't quote signatures; trim quoted material to what's
necessary for your response to make sense.)
>
--
Keith Thompson (The_Other_Keit h) k...@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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

ok I have seen in the n1124 so my question is simply for which reasons
there aren't!
philosophical? technical? not important thanks to sprintf and other
solutions?
is not better to make all the possible functions to manage almost
every programming aspect?
may be, but obviously this is only a my "poor" opinion if a c (or c++)
programmer had more
standard library functions should be more productive (think to Java,
C# and so on).
But this problem is also a C++ problem (for making some very useful
thinks we have to use a great external library named BOOST).

Regards

[Chris Torek]

Re: function conversion

In article <3xfii.3339$ZA. 1462@newsb.teli a.net>,
Michael Brennan <brennan.brisad @gmail.comwrote :

>... I just want to check if I've understood this correct:
>is it true, that all the reserved identifiers in the standard
>are reserved for use only by the implementations ?
>That is, if I'm writing and implementation of the standard libary
>I am permitted to define new functions starting with an underscore,
>but _not_ if I'm making some library that is not the standard lib?

Essentially, yes. (A future standard could, however, use names in
the "implementa tion name space" as new, standard names, creating
problems for implementors who used those names themselves. In
practice, though, standards groups doing updates actually tend to
take whatever names they like, rather than sticking with just the
implementor space. In other words, the C0x or C1x group is likely
to pester both implementors *and* users, the same way the C99 group
did.)

It may help to think of it this way: as far as the C-Standards-
Writers are concerned, there are only two kinds of people in the
world: "implemento rs" and "users". So, they gave "implemento rs"
one set of names to use, that they told the "users" to stay away
from; and they gave "users" the rest of the names, so implementors
must stay away from those.

This world-view quickly breaks down in the presence of "third party
vendors". If you are a third-party vendor, so that you are not
writing a compiler, but are also not the end-user writing the code
to use with the compiler, what names shall *you* use? (Probably
the best approach is to pick some sort of "library prefix" for
yourself, using one that lives in the "user" name space, and tell
your customers: "We will use names starting with <fill in your
prefix>, so if you avoid those, but otherwise stick with user name
space names, you will be OK." This, of course, does not help the
user who wants to use both your library *and* a second third-party
library, if you and the other third-party vendor choose the same
prefix.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Michael Brennan]

Re: function conversion

On 2007-07-03, Chris Torek <nospam@torek.n etwrote:

In article <3xfii.3339$ZA. 1462@newsb.teli a.net>,
Michael Brennan <brennan.brisad @gmail.comwrote :

>>... I just want to check if I've understood this correct:
>>is it true, that all the reserved identifiers in the standard
>>are reserved for use only by the implementations ?
>>That is, if I'm writing and implementation of the standard libary
>>I am permitted to define new functions starting with an underscore,
>>but _not_ if I'm making some library that is not the standard lib?

>
Essentially, yes. (A future standard could, however, use names in
the "implementa tion name space" as new, standard names, creating
problems for implementors who used those names themselves. In
practice, though, standards groups doing updates actually tend to
take whatever names they like, rather than sticking with just the
implementor space. In other words, the C0x or C1x group is likely
to pester both implementors *and* users, the same way the C99 group
did.)
>
It may help to think of it this way: as far as the C-Standards-
Writers are concerned, there are only two kinds of people in the
world: "implemento rs" and "users". So, they gave "implemento rs"
one set of names to use, that they told the "users" to stay away
from; and they gave "users" the rest of the names, so implementors
must stay away from those.
>
This world-view quickly breaks down in the presence of "third party
vendors". If you are a third-party vendor, so that you are not
writing a compiler, but are also not the end-user writing the code
to use with the compiler, what names shall *you* use? (Probably
the best approach is to pick some sort of "library prefix" for
yourself, using one that lives in the "user" name space, and tell
your customers: "We will use names starting with <fill in your
prefix>, so if you avoid those, but otherwise stick with user name
space names, you will be OK." This, of course, does not help the
user who wants to use both your library *and* a second third-party
library, if you and the other third-party vendor choose the same
prefix.)

Thank you for your excellent answer!

--
Michael Brennan

[CBFalconer]

Re: function conversion

Chris Torek wrote:

>

.... snip ...

>
This world-view quickly breaks down in the presence of "third party
vendors". If you are a third-party vendor, so that you are not
writing a compiler, but are also not the end-user writing the code
to use with the compiler, what names shall *you* use? (Probably
the best approach is to pick some sort of "library prefix" for
yourself, using one that lives in the "user" name space, and tell
your customers: "We will use names starting with <fill in your
prefix>, so if you avoid those, but otherwise stick with user name
space names, you will be OK." This, of course, does not help the
user who wants to use both your library *and* a second third-party
library, if you and the other third-party vendor choose the same
prefix.)

This idea breaks down completely for the forseeable future, because
there are no arbitrary namespaces available in C. The prefix
portion is perfectly usable, but not guaranteed.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net



--
Posted via a free Usenet account from http://www.teranews.com

[Richard Bos]

Re: function conversion

CBFalconer <cbfalconer@yah oo.comwrote:

Chris Torek wrote:

This world-view quickly breaks down in the presence of "third party
vendors". If you are a third-party vendor, so that you are not
writing a compiler, but are also not the end-user writing the code
to use with the compiler, what names shall *you* use? (Probably
the best approach is to pick some sort of "library prefix" for
yourself, using one that lives in the "user" name space, and tell
your customers: "We will use names starting with <fill in your
prefix>, so if you avoid those, but otherwise stick with user name
space names, you will be OK." This, of course, does not help the
user who wants to use both your library *and* a second third-party
library, if you and the other third-party vendor choose the same
prefix.)

>
This idea breaks down completely for the forseeable future, because
there are no arbitrary namespaces available in C. The prefix
portion is perfectly usable, but not guaranteed.

It breaks down even when you add namespaces the way they're normally
done, exactly because of Chris' last sentence. I guarantee you that when
you write a program to handle Dynamically Linked Libraries that uses
Doubly Linked Lists, and you want to delete a member from a list, you
will not want to worry whether dll.delete() doesn't remove a function
from your library.
The only way I can think of to solve this, but one which I've never seen
used in actual practice, is to leave the choice of prefix to the user-
programmer, instead of, as is now usually done, to the library
implementor. For example, you could have a new feature in a hypothetical
next Standard for C:

#include <sys/dll.has lib
#include <common/dll.has dlist

int main(void)
{
...
lib.delete(func name);
...
dlist.delete("t empdata");
...
callfunc(funcna me, paramlistptr);
sort(entrylist) ;
...
return 0;
}

The "as" keyword itself does not invade the user namespace, since it
occurs only in #include statements; thus, an object called "as" remains
as possible as one called "include". One could even "#include <as.has
as", if one wanted to.
The use of the period for namespace selection is equally unambiguous, as
long as we require that the names used for namespaces are ordinary,
file-scope identifiers - which would make them different from any other
object, and specifically, from any struct or union. To avoid confusion,
one would probably want to forbid shadowing of a namespace identifier
by a later block-scope declaration.
Alternatively, we could use a new operator - perhaps stealing C++'s :: -
but this seems undesirable to me, both because this is really not the
same thing at all as normal namespace operation, and we don't want to
pretend that it is, and because re-using an existing operator in a way
which coincides with its current use really quite well seems to me to
fit well with C's spirit of less-is-more.
Note that, in the above example, I've allowed for calls to functions
(and references to identifiers would work similarly) with, and where
possible also without the namespace identifier. delete() is common to
both headers, so it definitely needs the prefix - and I would suggest
that trying to use it without prefix should invoke undefined behaviour -
but callfunc() and sort() are unique, and can therefore be called
without.

This method _would_ mean that the pre-processor now has a real influence
on the semantics of the normal program code, and is no longer a mere
text replacement tool. But that's the only downside to this solution
that I can see. Even this can be ameliorated if we demand that all
references to namespace members be done with the namespace prefix. That
would, again, allow the pre-processor to function as a text replacer,
although in this case a slightly more complex one; but it would disallow
the calls to sort() and callfunc() in my example, and thus require more
typing.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net
>
>
>
--
Posted via a free Usenet account from http://www.teranews.com
>

Fix yer sig.

Richard