How to concatenate two integer values

[Rapscallion]

Well, it's entirely possible that I don't know what I'm doing. Perhaps
you could provide a test that you've proven correct and says otherwise?

Use the original problem:

long binary(long number)
{
long remainder;
long re;
while(number >1)
{
remainder = number%2;
number = number / 2;
// re = re & remainder; //concatenate these two integer values
}

Compare sprintf + scanf and stringstream implementations.

 

[Rapscallion]

If you want concatenate two integers and assign to long type. You can
use the below code. ....
sprintf(s1,"%d",a);
sprintf(s2,"%d",b);
strcat(s1,s2);

One sprintf here is enough, isn't it?

 

[James Daughtry]

I was talking about a direct comparison between sprintf and strtol (or
sscanf), and stringstream, not a comparison of those two with a low
level solution.

 

[Rapscallion]

I was talking about a direct comparison between sprintf and strtol (or
sscanf), and stringstream, not a comparison of those two with a low
level solution.

That's what I propose. But it's not me who insists that stringstream is
faster.

 

[James Daughtry]

I honestly don't see what your problem is. I ran a test with
stringstream and the equivalent solution using sprintf and strtol. My
results on that implementation showed stringstream to be slightly
faster. Here's the test. I don't claim it to be anything but a simple
and naive test, but it is consistent:

#include <cstdio>
#include <cstdlib>
#include <iostream>
#include <sstream>
#include <boost/timer.hpp>

int main()
{
int a = 10, b = 90;
char buffer[5];
std::stringstream ss;
boost::timer t;

for (int i = 0; i < 1000000; i++) {
int c;
sprintf(buffer, "%d%d", a, b);
c = (int)strtol(buffer, 0, 0);
}

std::cout << "sprintf/strtol: " << t.elapsed() << '\n';
t.restart();

for (int i = 0; i < 1000000; i++) {
int c;
ss << a << b;
ss >> c;
}

std::cout << "stringstream: " << t.elapsed() << '\n';
}

The results for one run of this test are (with all optimizations turned
off):

sprintf/strtol: 1.203
stringstream: 0.953

I never insisted that stringstream was always faster. In fact, I made
it very clear that the results would be implementation-dependent.
Knowing that my code could have been better, I asked for a test that
you wrote to so that I could run it and admit ignorance if the results
favored sprintf/strtol. Though you still haven't provided anything but
empty claims that I'm wrong (implying all cases) while I have
consistent proof that I'm not.

 

[Rapscallion]

I honestly don't see what your problem is.

I don't have any problem. You have made unfounded performance
assertions so far.

I ran a test with
stringstream and the equivalent solution using sprintf and strtol. My
results on that implementation showed stringstream to be slightly
faster. Here's the test. I don't claim it to be anything but a simple
and naive test, but it is consistent:

....

The trick is, of course, that you define std::stringstream outside the
loop. BTW, I never trust performance measurements that I haven't forged
myself.

 

[James Daughtry]

You have made unfounded performance assertions so far.
I have code with results and I've posted said code. How is that
unfounded?

As it is, I've admitted multiple times that my test is only legitimate
on the implementation that I ran it. You've admitted that performance
is strictly implementation-dependent. So the only issue should be that
my code is wrong somehow. Please, give me details so that I can learn
from my mistakes.

The trick is, of course, that you define std::stringstream outside the loop.

Seeing as how I'm comparing the conversion with the conversion and not
the conversion with construction and destruction of an object as well
as the conversion, defining the object in my loop would be stacking the
deck by forcing more operations per iteration into the stringstream
loop. That's not an objective test, and if you think it is then that
explains why you're busting my balls about making "unfounded
performance assertions".

 

[msalters]

Rapscallion schreef:

Really? I guess you have a bug in your tests

Of course not. stringstream is an istream and an ostream. They know at
compile time which parser/formatter they need. scanf/printf have to
parse
the format specfier, then select the appropriate parser/formatter, and
then do what istream:perator>> or ostream:perator<< was doing.
Clearly
these extra steps take some time.

HTH,
Michiel Salters

 

[Rapscallion]

Of course not. stringstream is an istream and an ostream. They know at
compile time which parser/formatter they need. scanf/printf have to
parse
the format specfier, then select the appropriate parser/formatter, and
then do what istream:perator>> or ostream:perator<< was doing.
Clearly these extra steps take some time.

I see you are an expert. You have only overlooked dynamic memory
allocation. Otherwise you are, of course, right. People less skilled
than you may be interested in the article series: "Efficient Integer To
String Conversions" by Matthew Wilson:
http://synesis.com.au/articles.html

 

[msalters]

Rapscallion schreef:

I see you are an expert. You have only overlooked dynamic memory
allocation. Otherwise you are, of course, right.

Dynamic memory allocation? In istringstream? That's an implementation
detail, just like in scanf. Either one *could* use dynamic memory
during the sting to integer conversion, but doesn't have to.

In ostringstream? Clearly, the output has to go somewhere. Even sprintf
needs a destination buffer. Now, if you didn't reserve memory up front
ostringstream will indeed allocate dynamic memory. sprintf will simply
overwrite whatever your char* points to. If you did allocate sufficient
memory, neither sprintf nor ostringstream will reserve memory.

HTH,
Michiel Salters

 

[Jacques Labuschagne]

I see you are an expert. You have only overlooked dynamic memory

If you're incapable of using dynamic memory you could always use a
std::strstream.

Jacques.