Walter, I note in std/syserror.d that it's importing std.c.stdio in order to convert an integer to string. This seems a bit of a shame.

Would you (or anyone else) be interested in a D-ified version of STLSoft's integer_to_string<>, for this, and other simple cases of int=>s conversion?

Note: for anyone that's not familiar, you can see the code in any recent distr of STLSoft (http://stlsoft.org/), and read about it in chapter 31 of my book Imperfect C++ (http://imperfectcplusplus.com) or in the series of instalments of my CUJ/DDJ column at http://www.ddj.com/columns/wilson/.

I'd be happy to adapt these functions to D. Not only would they cut down on coupling, they'd be quicker (unless rendering them to D would, in some way I'm yet to fathom, introduce latencies).

Cheers

The Dr .....

On Fri, 28 Jan 2005 10:11:49 +1100, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> Walter, I note in std/syserror.d that it's importing std.c.stdio in
> order to convert an integer to string. This seems a bit of a shame.
>
> Would you (or anyone else) be interested in a D-ified version of
> STLSoft's integer_to_string<>, for this, and other simple cases of
> int=>s conversion?
>
> Note: for anyone that's not familiar, you can see the code in any recent
> distr of STLSoft (http://stlsoft.org/), and read about it in chapter 31
> of my book Imperfect C++ (http://imperfectcplusplus.com) or in the
> series of instalments of my CUJ/DDJ column at
> http://www.ddj.com/columns/wilson/.
>
> I'd be happy to adapt these functions to D. Not only would they cut down
> on coupling, they'd be quicker (unless rendering them to D would, in
> some way I'm yet to fathom, introduce latencies).

Can't we simply change:
# result = new char[uint.sizeof * 3 + 1];
# sprintf(result, "%u", errcode);
# result = result[0 .. strlen(result)];

into:
# result = toString(errcode).dup;

Regan

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opslacb5zv23k2f5@ally...
> On Fri, 28 Jan 2005 10:11:49 +1100, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>> Walter, I note in std/syserror.d that it's importing std.c.stdio in order to convert an integer to string. This seems a bit of a shame.
>>
>> Would you (or anyone else) be interested in a D-ified version of STLSoft's integer_to_string<>, for this, and other simple cases of int=>s conversion?
>>
>> Note: for anyone that's not familiar, you can see the code in any
>> recent
>> distr of STLSoft (http://stlsoft.org/), and read about it in chapter
>> 31
>> of my book Imperfect C++ (http://imperfectcplusplus.com) or in the
>> series of instalments of my CUJ/DDJ column at
>> http://www.ddj.com/columns/wilson/.
>>
>> I'd be happy to adapt these functions to D. Not only would they cut
>> down
>> on coupling, they'd be quicker (unless rendering them to D would, in
>> some way I'm yet to fathom, introduce latencies).
>
> Can't we simply change:
> # result = new char[uint.sizeof * 3 + 1];
> # sprintf(result, "%u", errcode);
> # result = result[0 .. strlen(result)];
>
> into:
> # result = toString(errcode).dup;

Sure, but toString(uint) uses sprintf(). That's the coupling I think is unwelcome.

IIRC, I've seen mention of a floating point free Phobos, which would need something like integer_to_string to provide the toString()-ing of integers.

On Fri, 28 Jan 2005 11:24:08 +1100, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opslacb5zv23k2f5@ally...
>> On Fri, 28 Jan 2005 10:11:49 +1100, Matthew
>> <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>>> Walter, I note in std/syserror.d that it's importing std.c.stdio in
>>> order to convert an integer to string. This seems a bit of a shame.
>>>
>>> Would you (or anyone else) be interested in a D-ified version of
>>> STLSoft's integer_to_string<>, for this, and other simple cases of
>>> int=>s conversion?
>>>
>>> Note: for anyone that's not familiar, you can see the code in any
>>> recent
>>> distr of STLSoft (http://stlsoft.org/), and read about it in chapter
>>> 31
>>> of my book Imperfect C++ (http://imperfectcplusplus.com) or in the
>>> series of instalments of my CUJ/DDJ column at
>>> http://www.ddj.com/columns/wilson/.
>>>
>>> I'd be happy to adapt these functions to D. Not only would they cut
>>> down
>>> on coupling, they'd be quicker (unless rendering them to D would, in
>>> some way I'm yet to fathom, introduce latencies).
>>
>> Can't we simply change:
>> # result = new char[uint.sizeof * 3 + 1];
>> # sprintf(result, "%u", errcode);
>> # result = result[0 .. strlen(result)];
>>
>> into:
>> # result = toString(errcode).dup;
>
> Sure, but toString(uint) uses sprintf(). That's the coupling I think is
> unwelcome.

It does?

# char[] toString(uint u)
# {   char[uint.sizeof * 3] buffer;
#     int ndigits;
#     char c;
#     char[] result;
#
#     ndigits = 0;
#     if (u < 10)
# 	// Avoid storage allocation for simple stuff
# 	result = digits[u .. u + 1];
#     else
#     {
# 	while (u)
# 	{
# 	    c = (u % 10) + '0';
# 	    u /= 10;
# 	    ndigits++;
# 	    buffer[buffer.length - ndigits] = c;
# 	}
# 	result = new char[ndigits];
# 	result[] = buffer[buffer.length - ndigits .. buffer.length];
#     }
#     return result;
# }

It does use sprintf for the doubles, etc.

> IIRC, I've seen mention of a floating point free Phobos, which would
> need something like integer_to_string to provide the toString()-ing of
> integers.

AFAIKS sprintf is only used in std.string for floating point.

Regan

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opslaeyb1m23k2f5@ally...
> On Fri, 28 Jan 2005 11:24:08 +1100, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opslacb5zv23k2f5@ally...
>>> On Fri, 28 Jan 2005 10:11:49 +1100, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>>>> Walter, I note in std/syserror.d that it's importing std.c.stdio in order to convert an integer to string. This seems a bit of a shame.
>>>>
>>>> Would you (or anyone else) be interested in a D-ified version of STLSoft's integer_to_string<>, for this, and other simple cases of int=>s conversion?
>>>>
>>>> Note: for anyone that's not familiar, you can see the code in any
>>>> recent
>>>> distr of STLSoft (http://stlsoft.org/), and read about it in
>>>> chapter
>>>> 31
>>>> of my book Imperfect C++ (http://imperfectcplusplus.com) or in the
>>>> series of instalments of my CUJ/DDJ column at
>>>> http://www.ddj.com/columns/wilson/.
>>>>
>>>> I'd be happy to adapt these functions to D. Not only would they cut
>>>> down
>>>> on coupling, they'd be quicker (unless rendering them to D would,
>>>> in
>>>> some way I'm yet to fathom, introduce latencies).
>>>
>>> Can't we simply change:
>>> # result = new char[uint.sizeof * 3 + 1];
>>> # sprintf(result, "%u", errcode);
>>> # result = result[0 .. strlen(result)];
>>>
>>> into:
>>> # result = toString(errcode).dup;
>>
>> Sure, but toString(uint) uses sprintf(). That's the coupling I think
>> is
>> unwelcome.
>
> It does?
>
> # char[] toString(uint u)
> # {   char[uint.sizeof * 3] buffer;
> #     int ndigits;
> #     char c;
> #     char[] result;
> #
> #     ndigits = 0;
> #     if (u < 10)
> # // Avoid storage allocation for simple stuff
> # result = digits[u .. u + 1];
> #     else
> #     {
> # while (u)
> # {
> #     c = (u % 10) + '0';
> #     u /= 10;
> #     ndigits++;
> #     buffer[buffer.length - ndigits] = c;
> # }
> # result = new char[ndigits];
> # result[] = buffer[buffer.length - ndigits .. buffer.length];
> #     }
> #     return result;
> # }
>
> It does use sprintf for the doubles, etc.
>
>> IIRC, I've seen mention of a floating point free Phobos, which would
>> need something like integer_to_string to provide the toString()-ing
>> of
>> integers.
>
> AFAIKS sprintf is only used in std.string for floating point.

Ah, my bad. I must have had my bed head on this morning when I was looking through the toString()s.

:-)