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.

[xdevel]

On 2 Lug, 18:43, Keith Thompson <[e-mail] ote:

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

On 2 Lug, 15:23, Pietro Cerutti <[e-mail] 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) [e-mail] <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]

In article <3x************ ****@newsb.teli a.net>,
Michael Brennan <br************ @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) [phone]
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]

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

In article <3x************ ****@newsb.teli a.net>,
Michael Brennan <br************ @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]

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]

CBFalconer <cb********@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

[Ben Bacarisse]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

CBFalconer <cb********@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.

<snip>

The only way I can think of to solve this, but one which I've never seen
used in actual practice,

<OT>At least one language (Haskell) does this and more with
imports</OT>

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

As you point out below, this breaks the idea of '#include' being a
textual operation. The same(ish) effect could be achieved by allowing
a wrapper that adds a prefix chosen by the library user:

with dlist {
#include <common/dll.h>
};

making all the file-scope names in dll.h acquire a prefix[1].
(Personally, I'd rather not see . reused -- maybe : is better.) The
pain comes when the linker has to match up the names. There would
have to be some tool chain support for this. Maybe -ldlist:dll to
show which 'delete' is being referenced. If dll.h is qualified with
dlist in one source module and with 'linked_list' in another one would
need to get creative (-ldlist+linked_l ist:dll anyone?).

[1] I'd include macro names and structure tags, too.

--
Ben.

[Keith Thompson]

Ben Bacarisse <be********@bsb .me.ukwrites:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

[...]

>The only way I can think of to solve this, but one which I've never seen
used in actual practice,

<OT>At least one language (Haskell) does this and more with
imports</OT>

>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

As you point out below, this breaks the idea of '#include' being a
textual operation. The same(ish) effect could be achieved by allowing
a wrapper that adds a prefix chosen by the library user:

with dlist {
#include <common/dll.h>
};

making all the file-scope names in dll.h acquire a prefix[1].
(Personally, I'd rather not see . reused -- maybe : is better.) The
pain comes when the linker has to match up the names. There would
have to be some tool chain support for this. Maybe -ldlist:dll to
show which 'delete' is being referenced. If dll.h is qualified with
dlist in one source module and with 'linked_list' in another one would
need to get creative (-ldlist+linked_l ist:dll anyone?).

[1] I'd include macro names and structure tags, too.

I think using ':' would cause problems with the '?:' operator, which I
suspect is why C++ chose '::'.

I think I'd prefer to let headers define an explicit namespace,
leaving '#include' as a purely textual inclusion. A program can then
import and rename the namespace. For example:

/* foo.h */
namespace foo {
void func(void);
...
}

/* main.c */

#include "foo.h"
import foo as foo1;
...
foo1.func();

The point here is to allow two different 'foo' namespaces to be
imported under different names. There are a lot of details to be
worked out, though.

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

[Ben Bacarisse]

Keith Thompson <ks***@mib.orgw rites:

Ben Bacarisse <be********@bsb .me.ukwrites:

>rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

[...]

>>The only way I can think of to solve this, but one which I've never seen
used in actual practice,

<OT>At least one language (Haskell) does this and more with
imports</OT>

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

As you point out below, this breaks the idea of '#include' being a
textual operation. The same(ish) effect could be achieved by allowing
a wrapper that adds a prefix chosen by the library user:

with dlist {
#include <common/dll.h>
};

<snip>

>
I think using ':' would cause problems with the '?:' operator, which I
suspect is why C++ chose '::'.

Agreed. ':' would certainly get messy and is probably un-workable.

I think I'd prefer to let headers define an explicit namespace,
leaving '#include' as a purely textual inclusion. A program can then
import and rename the namespace. For example:

/* foo.h */
namespace foo {
void func(void);
...
}

I intended exactly that (that include should remain textual). The
example I gave was simply to show that the syntax can be put round a
#include. I could have just shown a function prototype inside the
'with'.

Presumably in your notation:

namespace foo {
#include "mydefs.h"
}

would qualify everything in "mydefs.h" with 'foo'. You might be
saying something stronger here: that the syntax would only permit
declarations (and only as-yet-unqualified ones at that). I would
suggest that anything can be put in a namespace (although the only
other things of any practical value are typedefs, structure
definitions, inline functions, and #defines).

/* main.c */

#include "foo.h"
import foo as foo1;

one could save on keywords by making 'namespace fool foo' (to mirror
typedef syntax) mean this.

...
foo1.func();

The point here is to allow two different 'foo' namespaces to be
imported under different names. There are a lot of details to be
worked out, though.

Indeed. Is there any sign that something like this is being
considered? I think it would be a very significant step forward for C
without undermining the basic character of the language.

--
Ben.

[Richard Heathfield]

Keith Thompson said:

<snip>

I'm also tempted to suggest stealing C++'s namespace feature and
adding it to C more or less intact.

I don't think the C++ guys will be too happy about that. Perhaps we
could just sort of borrow it off them until the weekend?

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Richard Heathfield <rj*@see.sig.in validwrites:

Keith Thompson said:
<snip>

>I'm also tempted to suggest stealing C++'s namespace feature and
adding it to C more or less intact.

I don't think the C++ guys will be too happy about that. Perhaps we
could just sort of borrow it off them until the weekend?

I suggest joint custody.

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