Integer to Ustring

[Jason C. McDonald]

I am trying to write a function that can convert an integer to its
equivalent Ustring (or, arguably, most any string class), without having
to rely on the STL or third-party libraries. I'm also wanting to use
math as much as possible, so I don't have to use massive conditionals or
data structures.

This code IS working quite well, but I feel like it can be improved. Any
feedback, improvements, or whatnot?

---

Glib::ustring int_to_ustring(int num)
{
bool neg = false;
int sub = 0;
char digit;
//This is what we'll return.
Glib::ustring str = "";

//If number is 0, the math won't work. Just return the string "0".
if(num == 0)
{
str = "0";
return str;
}
//Else, if the number is negative...
else if(num < 0)
{
//Store that information and make the number positive.
neg = true;
num = abs(num);
}

//Determine place value.
int pv = 0;
do
{
//Divide by a power of ten and trunicate decimal.
sub = num / pow(10, pv);
//Increase pv.
pv++;
}
//If we got zero, then we've overshot place value.
while(sub != 0);

//NOTE: The above seems to sometimes make the place value two-too-large?

//Loop backwards through the place values.
for(pv; pv >= 0; pv--)
{
//std::cout << "10^" << pv << "::" << num;
sub = num / pow(10, pv);
num -= sub*(pow(10, pv));
//std::cout << " --> " << "[" << sub << "]" << num << std::endl;

if(sub < 0 || sub > 10)
{
//Throw an error. I'm just using this as a placeholder.
std::cout << "Something went really weird." << std::endl;
}
//The char code for the digit is always 48 more than the digit.
digit = sub + 48;
//If this isn't a leading zero...
if(!(str == "" && digit == '0'))
{
//This is the best way to push a char to a ustring.
str.insert(str.end(), digit);
}
}

//If that number was negative, insert the negative sign.
if(neg)
str.insert(str.begin(), '-');

return str;
}


--
The number of ways in which code can be potentially screwed up is
theoretically infinite.
www.indeliblebluepen.com

[Christopher Pisz]

On 6/16/2015 5:18 PM, Jason C. McDonald wrote:
> I am trying to write a function that can convert an integer to its
> equivalent Ustring (or, arguably, most any string class), without having
> to rely on the STL or third-party libraries. I'm also wanting to use
> math as much as possible, so I don't have to use massive conditionals or
> data structures.
>
> This code IS working quite well, but I feel like it can be improved. Any
> feedback, improvements, or whatnot?

1) what is a UString?
2) what's wrong with the STL?
2a) What's wrong with std::string?
3) Why would you want to use math for something that can be done a few
lines with the STL?
4) Massive conditionals and data structures? huh?


All of the improvements I would suggest would be to throw away the
aforementioned constraints. You really shouldn't make constraints
without very good reason. I can't say that I've heard a good reason for
using C++ without the STL to date.

Your statement is like, "I want to do things better, but I can't use the
better way of doing things to do it."

Here is my version:

//------------------------------------------------------------------------------
std::string IntToString(const long long & value)
{
std::ostringstream converter;
converter << value;
return converter.str();
}

//------------------------------------------------------------------------------
std::string UIntToString(const unsigned long long & value)
{
std::ostringstream converter;
converter << value;
return converter.str();
}

//--------------------------------------------------------------------------------------------------
int StringToInt(const std::string & value)
{
int result;
std::istringstream converter(value);

if( (converter >> result).fail() )
{
std::ostringstream msg;
msg << "Could not convert string: \"" << value << "\" to int";
throw Shared::Exception(__FILE__, __LINE__, msg.str()); // Use
your favorite exception here
}

return result;
}

//--------------------------------------------------------------------------------------------------
boost::optional<int> StringToNullableInt(const std::string & value)
{
if( value.empty() )
{
return boost::none;
}

return Shared::StringToInt(value);
}

etc. etc.
Which looks more readable and maintainable?

Feel free to use the C library functions instead of you are more
interested in saving the bit of performance over using streams, but are
sure to do the proper error checking.

Another alternative is boost::lexical_cast.

EDIT:
After Googling ustring, I'd opt to use std::string internally and call
the glib conversions when I needed UTF-8 only when a call was expecting
UTF-8. I am not a fan of "X uses unicode, so let's use different string
representations in our entire program." It makes messes.

Furthermore, it looks like yer glib::ustring has stream operators
anyway, so you can use those in the same manner.



--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---

[Jason C. McDonald]

On 06/16/2015 03:48 PM, Christopher Pisz wrote:
> On 6/16/2015 5:18 PM, Jason C. McDonald wrote:
>> I am trying to write a function that can convert an integer to its
>> equivalent Ustring (or, arguably, most any string class), without having
>> to rely on the STL or third-party libraries. I'm also wanting to use
>> math as much as possible, so I don't have to use massive conditionals or
>> data structures.
>>
>> This code IS working quite well, but I feel like it can be improved. Any
>> feedback, improvements, or whatnot?
>
> 1) what is a UString?

Glib::ustring is a string which has full unicode support and is a
required component of the the gtkmm library, which runs a HUGE number of
GUIs.

> 2) what's wrong with the STL?

Nothing inherently. It's a project-specific decision, and I'm not the
first to make it. It's a matter of efficiency w/ some hardware, i.e.
older machines. It is rather common for game engine designers to be VERY
selective about what parts of STL to use.

Besides, if you're using ustring, using stringstream is YET ANOTHER
import, so your program just got bigger arbitrarily.

> 2a) What's wrong with std::string?

Nothing inherently, except I need to use Ustring (see my reply to #1).
Also, string is inefficient in some situations. Argue w/ Jason Gregory
on that point. (author of "Game Engine Architecture".)

> 3) Why would you want to use math for something that can be done a few
> lines with the STL?

See above. Also, the question "why would you want to do it differently"
should set off alarm bells here. As soon as we stop trying to find more
efficient ways to do things, we start stagnating. I never rely blindly
on existing solutions. I often recreate functionality, to see if I can
improve on it. (Also, gives me a good code recipe with which to do this
in another language.) Besides that, just using someone else's solution
without understanding it is feeding into that infamous layers of
abstraction problem that Joel Spolsky pointed out.

> 4) Massive conditionals and data structures? huh?

The quickest hack solution to this would be using a large if statement
or an array. Unnecessary conditionals waste CPU cycles, and unnecessary
data structures waste RAM.

> All of the improvements I would suggest would be to throw away the
> aforementioned constraints. You really shouldn't make constraints
> without very good reason. I can't say that I've heard a good reason for
> using C++ without the STL to date.
>
> Your statement is like, "I want to do things better, but I can't use the
> better way of doing things to do it."

Careful of jumping to that conclusion. STL is not the for-all-end-all.
I'm not against using it, but if a simple task such as this requires me
to import an entire STL header, I'd prefer to wrap my own if I can come
close to efficiency. It yields a smaller program. I should mention that
I am targeting older systems as well as new. (Older, as in 256MB RAM or
less and 20-yr-old processors, which accounts for a surprisingly large
number of school computer labs, my target user group.)

[Christopher Pisz]

Fair enough. Just be careful. It's been my experience thus far that
every time I run into a code block that tries to "do what the STL does,
but better" it not only performed worse, but filled up the bug tracker
as well. Not that you are one of those people, but there exists a crowd
that takes that stance, whom never performance tested in a satisfactory
manner, and/or whom cannot compete, testing wise, with the millions of
users calling the STL vs the 5-20 calling their code.

I cannot comment on what to do with 20 year old computers, because I was
still learning what poke 53280,0 meant on my c64 and sneaking out of my
bedroom at night to play Elite in my batman PJs.

[Jason C. McDonald]

On 06/16/2015 04:24 PM, Christopher Pisz wrote:
> Fair enough. Just be careful. It's been my experience thus far that
> every time I run into a code block that tries to "do what the STL does,
> but better" it not only performed worse, but filled up the bug tracker
> as well. Not that you are one of those people, but there exists a crowd
> that takes that stance, whom never performance tested in a satisfactory
> manner, and/or whom cannot compete, testing wise, with the millions of
> users calling the STL vs the 5-20 calling their code.

Absolutely. There's dangers on both sides of the line, really. Glib and
ICU are two libraries that reportedly succeed at out-performing STL,
though I haven't tested that claim personally yet. I'm using Glib
more-or-less out of necessity, since I'm relying to gtkmm for GUI
building. I tend to be wary of code libraries by default.

I'm actually designing a language at the moment, so that's the other
reason I'm in "recreate functionality" mode.

> I cannot comment on what to do with 20 year old computers, because I was
> still learning what poke 53280,0 meant on my c64 and sneaking out of my
> bedroom at night to play Elite in my batman PJs.

Heck, at the moment, I can't either. All I know is to be
near-pathologically stingy with memory and CPU cycles.

[Ahhhh, Elite. Side note, have you seen the open-source Elite-clone,
Oolite? Quite impressive.]

[Jason C. McDonald]

On 06/16/2015 03:18 PM, Jason C. McDonald wrote:
> I am trying to write a function that can convert an integer to its
> equivalent Ustring (or, arguably, most any string class), without having
> to rely on the STL or third-party libraries. I'm also wanting to use
> math as much as possible, so I don't have to use massive conditionals or
> data structures.
>
> This code IS working quite well, but I feel like it can be improved. Any
> feedback, improvements, or whatnot?

Following up on my own, thanks to a Stack Overflow discussion
(http://stackoverflow.com/a/30880365/472647). Apparently, no one online
bothered to mention the bright-blazingly-obvious solution using Glib...

Glib::ustring text = Glib::ustring::format(123456);

However, I still would like feedback on mine, as there is still those
who desire to do something like this for custom string classes without
using third-party libraries. Just ignore Glib::ustring, and insert <your
custom class> if you want to give feedback.

[Christian Gollwitzer]

Am 17.06.15 um 02:24 schrieb Jason C. McDonald:

> Following up on my own, thanks to a Stack Overflow discussion
> (http://stackoverflow.com/a/30880365/472647). Apparently, no one online
> bothered to mention the bright-blazingly-obvious solution using Glib...
>
> Glib::ustring text = Glib::ustring::format(123456);

for sure you are not the first person wanting to print data to ustring,
so I'm not very surprised you found a ready-made number formatter already.

> However, I still would like feedback on mine, as there is still those
> who desire to do something like this for custom string classes without
> using third-party libraries.

Your algorithm is a bit strange. Formatting integers is usually done by
the divide and mod algorithm, which works like this

if (i<0) { print "-"; i=-i }

i=12345678
while i {
print i % 10
i = i/10
}

Afterwards you reverse the digits. Calling a power library function for
each digit and doing subtracts etc. will likely be much slower than the
repeated div/mod apporach shown here. "pow" is a floating point
function. Your algorithm does repeated conversion between integer and
double, which is not going to help either accuracy or speed.

> Just ignore Glib::ustring, and insert <your
> custom class> if you want to give feedback.

I'd get a decent implementation from somewhere else instead of writing
my own. It becomes an order of magnitude more complex if you are dealing
with floating point numbers. Then you'll have to handle NaN, Inf etc. in
addition to printing the normalized value. I wouldn't recommend to roll
your own unless you implement the string library (and let me ask, why)

Christian

[Jason C. McDonald]

On 06/17/2015 12:20 AM, Christian Gollwitzer wrote:
> Am 17.06.15 um 02:24 schrieb Jason C. McDonald:
>> Following up on my own, thanks to a Stack Overflow discussion
>> (http://stackoverflow.com/a/30880365/472647). Apparently, no one online
>> bothered to mention the bright-blazingly-obvious solution using Glib...
>>
>> Glib::ustring text = Glib::ustring::format(123456);
>
> for sure you are not the first person wanting to print data to ustring,
> so I'm not very surprised you found a ready-made number formatter already.
>
>> However, I still would like feedback on mine, as there is still those
>> who desire to do something like this for custom string classes without
>> using third-party libraries.
>
> Your algorithm is a bit strange. Formatting integers is usually done by
> the divide and mod algorithm, which works like this
>
> if (i<0) { print "-"; i=-i }
>
> i=12345678
> while i {
> print i % 10
> i = i/10
> }
>
> Afterwards you reverse the digits. Calling a power library function for
> each digit and doing subtracts etc. will likely be much slower than the
> repeated div/mod apporach shown here. "pow" is a floating point
> function. Your algorithm does repeated conversion between integer and
> double, which is not going to help either accuracy or speed.

Thanks for that, I appreciate the input. That's a much cleaner method
than my determine place value, and frankly it WOULD run faster.

>> Just ignore Glib::ustring, and insert <your
>> custom class> if you want to give feedback.
>
> I'd get a decent implementation from somewhere else instead of writing
> my own. It becomes an order of magnitude more complex if you are dealing
> with floating point numbers. Then you'll have to handle NaN, Inf etc. in
> addition to printing the normalized value. I wouldn't recommend to roll
> your own unless you implement the string library (and let me ask, why)
>
> Christian
>

I wound up using the built-in in my project, but I still wanted to wrap
my own for most of the reasons outlined in my follow-up to Christopher
Pilz. The only of those reasons that no longer stands is avoidance of
STL in the specific context of Glib (but not the intentional avoidance
in the case of a custom class.)

Thanks for the feedback!

[Jason C. McDonald]

On 06/17/2015 12:20 AM, Christian Gollwitzer wrote:

> Am 17.06.15 um 02:24 schrieb Jason C. McDonald:
>> Following up on my own, thanks to a Stack Overflow discussion
>> (http://stackoverflow.com/a/30880365/472647). Apparently, no one online
>> bothered to mention the bright-blazingly-obvious solution using Glib...
>>
>> Glib::ustring text = Glib::ustring::format(123456);
>
> for sure you are not the first person wanting to print data to ustring,
> so I'm not very surprised you found a ready-made number formatter already.

Actually, I was surprised NOT to initially. The Stack Overflow poster
was the first person I found online to mention it, even on the Glib
mailing list! Everyone suggested to use stringstream, which just didn't
feel right.

> Your algorithm is a bit strange. Formatting integers is usually done by
> the divide and mod algorithm, which works like this
>
> if (i<0) { print "-"; i=-i }
>
> i=12345678
> while i {
> print i % 10
> i = i/10
> }
>
> Afterwards you reverse the digits. Calling a power library function for
> each digit and doing subtracts etc. will likely be much slower than the
> repeated div/mod apporach shown here. "pow" is a floating point
> function. Your algorithm does repeated conversion between integer and
> double, which is not going to help either accuracy or speed.

Well, I knew something could be cleaned up. Thanks for that. The funny
thing about algorithms like this is that they are often considered so
obvious that no one writes them down anywhere anymore. That's one of the
problems with "just use X library": we wind up training an entire
generation of programmers that, if tasked with rebuilding any basic
functionality such as this, would be at a total loss. That's one of the
reasons I try to wrap my own so often, even if I DO use the library in
the end.

>> Just ignore Glib::ustring, and insert <your
>> custom class> if you want to give feedback.
>
> I'd get a decent implementation from somewhere else instead of writing
> my own. It becomes an order of magnitude more complex if you are dealing
> with floating point numbers. Then you'll have to handle NaN, Inf etc. in
> addition to printing the normalized value. I wouldn't recommend to roll
> your own unless you implement the string library (and let me ask, why)

I tend to go with the implementation built into a library I'm using, if
it is available. I am wary of using YET ANOTHER class, however, for
several reasons. I am extremely selective, even with STL. Full
explanation in my initial followup to Christopher Pilz's response.

Thanks for the feedback.

[Jason C. McDonald]

Ignore this reply...it said it failed, so I resubmitted a revised one. Meh.

[Christopher Pisz]

On 6/16/2015 6:44 PM, Jason C. McDonald wrote:
> On 06/16/2015 04:24 PM, Christopher Pisz wrote:

SNIP

>> I cannot comment on what to do with 20 year old computers, because I was
>> still learning what poke 53280,0 meant on my c64 and sneaking out of my
>> bedroom at night to play Elite in my batman PJs.
>
> Heck, at the moment, I can't either. All I know is to be
> near-pathologically stingy with memory and CPU cycles.
>
> [Ahhhh, Elite. Side note, have you seen the open-source Elite-clone,
> Oolite? Quite impressive.]
>

I haven't. I shall check it out!

[Christian Gollwitzer]

Am 18.06.15 um 02:28 schrieb Jason C. McDonald:

> On 06/17/2015 12:20 AM, Christian Gollwitzer wrote:
>> Your algorithm is a bit strange. Formatting integers is usually done by
>> the divide and mod algorithm, which works like this
>>
>> if (i<0) { print "-"; i=-i }
>>
>> i=12345678
>> while i {
>> print i % 10
>> i = i/10
>> }
>>
>> Afterwards you reverse the digits. Calling a power library function for
>> each digit and doing subtracts etc. will likely be much slower than the
>> repeated div/mod apporach shown here. "pow" is a floating point
>> function. Your algorithm does repeated conversion between integer and
>> double, which is not going to help either accuracy or speed.
>
> Well, I knew something could be cleaned up. Thanks for that. The funny
> thing about algorithms like this is that they are often considered so
> obvious that no one writes them down anywhere anymore.

Well for this one I know where I learnt it: in high school we were
taught about number representation in different bases (binary, ternary,
hexadecimal) and this algorithm was shown to us by the teacher. Note
this was the math course that every one had to take, not a special
computer science class. But in general I agree with you.

> That's one of the
> problems with "just use X library": we wind up training an entire
> generation of programmers that, if tasked with rebuilding any basic
> functionality such as this, would be at a total loss.

Well sometimes it's better to know the library, sometimes better to
build on simple blocks, ths varies and a great deal of software
engineering is the decision, which way to go.

Have fun,

Christian

[Jason C. McDonald]

On 06/19/2015 06:09 AM, Christian Gollwitzer wrote:
> Well for this one I know where I learnt it: in high school we were
> taught about number representation in different bases (binary, ternary,
> hexadecimal) and this algorithm was shown to us by the teacher. Note
> this was the math course that every one had to take, not a special
> computer science class. But in general I agree with you.

I have yet to meet an American high schooler who learned about other
number bases. I've been a math tutor at my college, and half of the HS
grads can't even multiply. I learned about other bases on my own - none
of my classes in HS or college even taught me about them.

American education has some seeeeerious problems. (And thus why I work
in educational software, ha ha.)

>> That's one of the
>> problems with "just use X library": we wind up training an entire
>> generation of programmers that, if tasked with rebuilding any basic
>> functionality such as this, would be at a total loss.
>
> Well sometimes it's better to know the library, sometimes better to
> build on simple blocks, ths varies and a great deal of software
> engineering is the decision, which way to go.

I agree, with the caveat that one should try and know HOW the library
works as much as possible. If you look at programmers who exclusively
use high-level languages such as Python and Java, they don't know HOW it
works, WHY it works, how how to make it work BETTER. Nothing gets
innovated that way. >.>

On the flip side, it is definitely true that one should not duplicate
work unnecessarily. Had I known the library had a built-in, I would have
only undertaken this algorithm as an experiment, ha ha. (I actually am
building a language and its library nearly from scratch, thus the
fascination.)

[Christopher Pisz]

On 6/19/2015 2:03 PM, Jason C. McDonald wrote:
> On 06/19/2015 06:09 AM, Christian Gollwitzer wrote:

>>SNIP

> I have yet to meet an American high schooler who learned about other
> number bases. I've been a math tutor at my college, and half of the HS
> grads can't even multiply. I learned about other bases on my own - none
> of my classes in HS or college even taught me about them.
>
> American education has some seeeeerious problems. (And thus why I work
> in educational software, ha ha.)

When I go out on online dates, my first question is "Can you tell me
what 1/8 * 3/4 is?"

I'm still single....

On okcupid, 90% of women answered they match question "Which is bigger,
the Sun or the Earth?" with "The Earth"..

> SNIP

[Jason C. McDonald]

On 06/19/2015 12:17 PM, Christopher Pisz wrote:
> On 6/19/2015 2:03 PM, Jason C. McDonald wrote:
>> On 06/19/2015 06:09 AM, Christian Gollwitzer wrote:
>>> SNIP
>> I have yet to meet an American high schooler who learned about other
>> number bases. I've been a math tutor at my college, and half of the HS
>> grads can't even multiply. I learned about other bases on my own - none
>> of my classes in HS or college even taught me about them.
>>
>> American education has some seeeeerious problems. (And thus why I work
>> in educational software, ha ha.)
>
> When I go out on online dates, my first question is "Can you tell me
> what 1/8 * 3/4 is?"
>
> I'm still single....
>
> On okcupid, 90% of women answered they match question "Which is bigger,
> the Sun or the Earth?" with "The Earth"..
>
> > SNIP

3/32. I was taking a state standardized test in middle school, and after
the test, one of the MIDDLE SCHOOLERS asked the teacher "what is pH?
Plant height?"

*Facepalm*

[David Brown]

On 19/06/15 21:41, Stefan Ram wrote:

> "Jason C. McDonald" <indelibl...@nospam.invalid> writes:
>> 3/32. I was taking a state standardized test in middle school, and after
>> the test, one of the MIDDLE SCHOOLERS asked the teacher "what is pH?
>> Plant height?"
>> *Facepalm*
>

> That's easy, because the upper-case and lower-case makes it unique:
>
> The unit »Henry« is the SI derived unit of inductance we all know
> and love. Its symbol is the /upper-case/ »H«.
>
> The /lower-case/ SI unit-prefix »p« stands for »pico« (1E-12 in C++).
>
> So, »pH« must be the /pico-Henry/!
>

pH is indeed the abbreviation for pico Henries, though inductors are
seldom smaller than a few nH. You might use pH for the inductance of
wires, chip pins/balls, pcb vias, etc.

Usually it's clear in the context what you mean by pH.

[Rosario19]

PH whould be a misure for acid-base

[gwowen]

On Saturday, June 20, 2015 at 6:51:08 AM UTC+1, Rosario19 wrote:
> >Usually it's clear in the context what you mean by pH.
>
> PH whould be a misure for acid-base

Quite right. I'd hate to walk all the way to a "PH" on my Ordnance Survey map and discover some sort of chemical works.

(For the non-Brits: http://www.ordnancesurvey.co.uk/resources/maps-and-geographic-resources/map-abbreviations.html#p)

[Rosario19]

On Sat, 20 Jun 2015 07:50:53 +0200, Rosario19 wrote:


>PH whould be a misure for acid-base

en.wikipedia.org/?title=PH

[Rosario19]

there is no chemical meaning...
etc
Ph Parish DM-Obs
PH Public House DM
etc

[Jason C. McDonald]

So typical of USENET for a thread to turn acidic. (Pun VERY MUCH
INTENDED, ha ha.)

I blame myself. :P