cin/cout vs. scanf/printf

[Podrzut_z_Laweczki]

Hello, I have question (or 2 :)). Is that true that for a large data
using scanf/printf instead of cin/cout makes that the program runs
faster? And if it is, is it legal to mix scanf/printf with C++ code?
Program should execute below 1 sec and the hint is to use scanf/printf.

[Victor Bazarov]

Re: cin/cout vs. scanf/printf

Podrzut_z_Lawec zki wrote:

Hello, I have question (or 2 :)). Is that true that for a large data
using scanf/printf instead of cin/cout makes that the program runs
faster?

All generalizations are false.

And if it is, is it legal to mix scanf/printf with C++ code?

Yes, it is legal. scanf/printf are parts of C++.

Program should execute below 1 sec and the hint is to use
scanf/printf.

The hint to whom?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[mlimber]

Re: cin/cout vs. scanf/printf

Podrzut_z_Lawec zki wrote:

Hello, I have question (or 2 :)). Is that true that for a large data
using scanf/printf instead of cin/cout makes that the program runs
faster?

Sometimes, but the C-style I/O functions are also not typesafe, so your
development time may also increase. Try:

char c = 'a';
cout << c;
printf( "%s", c );

The third line sports undefined behavior, while the second line always
gets it right.

And if it is, is it legal to mix scanf/printf with C++ code?

Look into ios_base::sync_ with_stdio() (e.g., at
http://www.cplusplus.com/ref/iostrea...th_stdio.html).

Program should execute below 1 sec and the hint is to use scanf/printf.

It depends on your compiler and optimizer, your computer, your data
source, your programming skill, etc. etc. etc., not just C vs. C++
style I/O.

Cheers! --M

[Jack Klein]

Re: cin/cout vs. scanf/printf

On 3 Aug 2006 12:54:00 -0700, "Podrzut_z_Lawe czki" <emil020@o2.p l>
wrote in comp.lang.c++:

Hello, I have question (or 2 :)). Is that true that for a large data
using scanf/printf instead of cin/cout makes that the program runs
faster?

Yes, it's true. No, it's not true. Neither the C nor C++ standard
specify the absolutely or relative speed of any operator or function.
The C++ standard does specify the order of some operations, but order
alone does not define speed.

And if it is, is it legal to mix scanf/printf with C++ code?

It is legal to use <cstdiofunction s in a C++ program is you use them
correctly. It is rarely a good idea to use scanf() in either C or
C++, as it is very difficult and complex to use correctly.

Program should execute below 1 sec and the hint is to use scanf/printf.

What program? Who's hint? How long does the program take when you
use the cin and cout streams?

First write a program that runs correctly and meets all its
requirements. Then test it thoroughly, especially for corner cases.
Then, and only then, if it runs correctly but too slowly, you can
start thinking about ways to make it faster.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

[Marcus Kwok]

Re: cin/cout vs. scanf/printf

mlimber <mlimber@gmail. comwrote:

Sometimes, but the C-style I/O functions are also not typesafe, so your
development time may also increase. Try:
>
char c = 'a';
cout << c;
printf( "%s", c );
>
The third line sports undefined behavior, while the second line always
gets it right.

Almost, except when you have a pointer to char, at which point it tries
to treat it as a C-style string. For example:


#include <iostream>

int main()
{
int i = 42;
std::cout << "&i = " << &i << '\n';

char c = 'a';
std::cout << "&c = " << &c << '\n';
}


Output I got:

&i = 0012FEE4
&c = a*


In order to work around this, one method is to perform a cast:

std::cout << "&c = " << static_cast<voi d*>(&c) << '\n';

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Noah Roberts]

Re: cin/cout vs. scanf/printf


Podrzut_z_Lawec zki wrote:

Hello, I have question (or 2 :)). Is that true that for a large data
using scanf/printf instead of cin/cout makes that the program runs
faster? And if it is, is it legal to mix scanf/printf with C++ code?
Program should execute below 1 sec and the hint is to use scanf/printf.

I tested this once, I think, and the result was negative...c++ streams
where faster. At any rate, it is usually rather insignificant in the
larger scheme...string and stream operations are not usually your
bottlenecks.

[Sjouke Burry]

Re: cin/cout vs. scanf/printf

mlimber wrote:

Podrzut_z_Lawec zki wrote:
>

>>Hello, I have question (or 2 :)). Is that true that for a large data
>>using scanf/printf instead of cin/cout makes that the program runs
>>faster?

>
>
Sometimes, but the C-style I/O functions are also not typesafe, so your
development time may also increase. Try:
>
char c = 'a';
cout << c;
printf( "%s", c );
>
The third line sports undefined behavior, while the second line always
gets it right.

Did you make the stupid error in the printf line
on purpose or dont you know any better?
Any body used to using printf and its cousins,
knows that it is stupid to specify a char instead
of a string,and I am sure you can make just as
many stupid errors in the cout line.The cout
line might do the correct thing with an input
error,but it is stil an error.
If you want to prove a point, dont use false
arguments.

[Markus Moll]

Re: cin/cout vs. scanf/printf

Hi

Podrzut_z_Lawec zki wrote:

Hello, I have question (or 2 :)). Is that true that for a large data
using scanf/printf instead of cin/cout makes that the program runs
faster?

Could be faster. Could as well be slower.

Program should execute below 1 sec and the hint is to use scanf/printf.

Wild guess: you're doing some contest problems with huge inputs. Use
scanf/printf.

Markus

[Thomas J. Gritzan]

Re: cin/cout vs. scanf/printf

Sjouke Burry schrieb:

mlimber wrote:

>Sometimes, but the C-style I/O functions are also not typesafe, so your
>development time may also increase. Try:
>>
> char c = 'a';
> cout << c;
> printf( "%s", c );
>>
>The third line sports undefined behavior, while the second line always
>gets it right.

>
Did you make the stupid error in the printf line
on purpose or dont you know any better?
Any body used to using printf and its cousins,
knows that it is stupid to specify a char instead
of a string,and I am sure you can make just as
many stupid errors in the cout line.The cout
line might do the correct thing with an input
error,but it is stil an error.
If you want to prove a point, dont use false
arguments.

Another arguments from another person:

1)
<beginner's mode>
size_t mysize = some_container. size();

printf("%u", mysize);

size_t is unsigned int, isn't it? Or what is the correct modifier for
size_t?
</>

2)
some_typedef myvar;
printf("???", myvar);

How to print unknown types, or types that may change/be redefined?

3)
myclass myobject;
printf("???", myobject);

How to print custom classes?


With stream, the compiler handles it for you, and you can implement
operator<< for custom types.

--
Thomas

[Victor Bazarov]

Re: cin/cout vs. scanf/printf

Sjouke Burry wrote:

mlimber wrote:

>Podrzut_z_Lawe czki wrote:
>>

>>Hello, I have question (or 2 :)). Is that true that for a large data
>>using scanf/printf instead of cin/cout makes that the program runs
>>faster?

>>
>>
>Sometimes, but the C-style I/O functions are also not typesafe, so
>your development time may also increase. Try:
>>
> char c = 'a';
> cout << c;
> printf( "%s", c );
>>
>The third line sports undefined behavior, while the second line
>always gets it right.

>
Did you make the stupid error in the printf line
on purpose or dont you know any better?
Any body used to using printf and its cousins,
knows that it is stupid to specify a char instead
of a string,and I am sure you can make just as
many stupid errors in the cout line.The cout
line might do the correct thing with an input
error,but it is stil an error.
If you want to prove a point, dont use false
arguments.

I suggest checking in your attitude at the door. The is no "false argument"
here. The simple demostration is supposed to show that 'printf' has no type
safety. And that's true. Besides, if you want to output an object, printf
is of no help.

Now, about the errors in the "cout line". *I* am sure that *you* can make
just as many stupid mistakes, but I would doubt very much that 'mlimber'
can (even if he tried). Now if you didn't intend to insult 'mlimber', then
you could probalby show us what kind of "stupid mistake" one can make on
a "cout line"... I am sure everybody would appreciate it.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Podrzut_z_Laweczki]

Re: cin/cout vs. scanf/printf


Jack Klein wrote:

What program? Who's hint? How long does the program take when you
use the cin and cout streams?

First of all thank you all for replying. It's nothing big, just a
starter for online problems solving (Fibonacci numbers). Sry for this
-people send source files to a server (files are compiled by an
automate) and get reply with some stats - whether it passed time limit,
memory limit, if there were runtime or compilation errors etc.
On the server it is compiled with GNU C++ 4.0.2, hint about
printf/scanf is in faq. The task is here:

http://opss.safo.biz/?menu=comp&sub=prob&comp=0&prob=1000

I made sth like this (more or less the same as the spoiler). Are there
any free progs for Windows and Linux to measure this speed and memory
limit?

#include <cstdio>
int main()
{
double t[46] = {1,1};
for (int i = 2; i < 46; ++i)
t[i] = t[i-1] + t[i-2];
int d;
scanf("%d",&d);
if ((d>=1)&&(d<=10 00)){
while (d--){
int j;
scanf("%d",&j);
printf("%.0lf\n ",t[j]);
}
}
}

[Default User]

Re: cin/cout vs. scanf/printf

Thomas J. Gritzan wrote:

<beginner's mode>
size_t mysize = some_container. size();
>
printf("%u", mysize);
>
size_t is unsigned int, isn't it?

No, it is an unsigned integral type. Usually unsigned long.

Or what is the correct modifier for
size_t?

There isn't one in C++. The new C standard added one. The usual
practice is to use ld and cast the value to unsigned long.




Brian

[Victor Bazarov]

Re: cin/cout vs. scanf/printf

Default User wrote:

Thomas J. Gritzan wrote:
>
>

><beginner's mode>
>size_t mysize = some_container. size();
>>
>printf("%u", mysize);
>>
>size_t is unsigned int, isn't it?

>
No, it is an unsigned integral type. Usually unsigned long.
>

>Or what is the correct modifier for
>size_t?

>
There isn't one in C++. The new C standard added one. The usual
practice is to use ld and cast the value to unsigned long.

Since the size of 'size_t' (which is its own type, not a typedef for
anything) is implementation-defined, you should consider looking for
an implemenation-specific solution. For example, in Win64 casting
to unsigned long is not going to work very well. Microsoft did add
the I64 specifier (IIRC) for printing out types that are longer than
unsinged long.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Amadeus W. M.]

Re: cin/cout vs. scanf/printf

On Thu, 03 Aug 2006 15:41:07 -0700, Podrzut_z_Lawec zki wrote:

>
Jack Klein wrote:

>What program? Who's hint? How long does the program take when you
>use the cin and cout streams?

>
First of all thank you all for replying. It's nothing big, just a
starter for online problems solving (Fibonacci numbers). Sry for this
-people send source files to a server (files are compiled by an
automate) and get reply with some stats - whether it passed time limit,
memory limit, if there were runtime or compilation errors etc.
On the server it is compiled with GNU C++ 4.0.2, hint about
printf/scanf is in faq. The task is here:

http://opss.safo.biz/?menu=comp&sub=prob&comp=0&prob=1000

I made sth like this (more or less the same as the spoiler). Are there
any free progs for Windows and Linux to measure this speed and memory
limit?
>
#include <cstdio>
int main()
{
double t[46] = {1,1};
for (int i = 2; i < 46; ++i)
t[i] = t[i-1] + t[i-2];
int d;
scanf("%d",&d);
if ((d>=1)&&(d<=10 00)){
while (d--){
int j;
scanf("%d",&j);
printf("%.0lf\n ",t[j]);
}
}
}

return 0;

at the end of main, to keep the compiler happy.

To see if it passes the 1 second time limit, try it yourself.
Build an input file with 1000 datasets, and time it.
On a unix system (probably windows too), you can use the
rand() or random() function for that.

Incidentally, except for cstdio, your code is all C.

[Victor Bazarov]

Re: cin/cout vs. scanf/printf

Amadeus W. M. wrote:

On Thu, 03 Aug 2006 15:41:07 -0700, Podrzut_z_Lawec zki wrote:
>

>>
>Jack Klein wrote:

>>What program? Who's hint? How long does the program take when you
>>use the cin and cout streams?

>>
>First of all thank you all for replying. It's nothing big, just a
>starter for online problems solving (Fibonacci numbers). Sry for this
>-people send source files to a server (files are compiled by an
>automate) and get reply with some stats - whether it passed time
>limit, memory limit, if there were runtime or compilation errors etc.
>On the server it is compiled with GNU C++ 4.0.2, hint about
>printf/scanf is in faq. The task is here:
>http://opss.safo.biz/?menu=comp&sub=...mp=0&prob=1000
>I made sth like this (more or less the same as the spoiler). Are
>there any free progs for Windows and Linux to measure this speed and
>memory limit?
>>
>#include <cstdio>
>int main()
>{
>double t[46] = {1,1};
>for (int i = 2; i < 46; ++i)
>t[i] = t[i-1] + t[i-2];
>int d;
>scanf("%d",&d) ;
>if ((d>=1)&&(d<=10 00)){
>while (d--){
>int j;
>scanf("%d",&j) ;
>printf("%.0lf\ n",t[j]);
>}
>}
>}

>
>
return 0;
>
at the end of main, to keep the compiler happy.

If your compiler is unhappy about the absence of 'return 0;',
throw away that compiler and get yourself a happier one.

To see if it passes the 1 second time limit, try it yourself.
Build an input file with 1000 datasets, and time it.
On a unix system (probably windows too), you can use the
rand() or random() function for that.
>
Incidentally, except for cstdio, your code is all C.

--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask