1

Possible Duplicate:
Which I/O library do you use in your C++ code?

in C++ why we go for COUT and CIN

Community
  • 1
  • 1

5 Answers5

8

Because classes can overload the insertion operator <<

They cannot edit printf and add %Foo to know how to print a Foo class.

EnabrenTane
  • 7,428
  • 2
  • 26
  • 44
  • I like the second part of your answer. Clever! :) – Prasoon Saurav Dec 23 '10 at 04:38
  • 2
    Which also means you can't mess it up! The compiler either figures out what operator << to call... or it gives an error. No crashing because the arguments don't match the format string! – MerickOWA Dec 23 '10 at 04:40
4

You can use them.

But the major problem is that they are not safe.
A lot of C code had problems because the format specifiers did not match the arguments and resulted in crashes etc.

// Example
char c;
scanf("%s",&c);  // quite an easy mistake. Usually leads to a crash or something worse.

The C++ variants are type safe (in that the compiler guarantees that the type you are inputting into is the correct type at compile time) and the runtime does the work of actually moving the data.

A secondary reason is that it is a lot easier to define output functions in C++ (operator >> and <<) than in C (There was never a standardized way of naming streaming functions).

The third advantage is that a stream is not limited to console or file. There are several other types of stream that automatically work with the operator >> and << thus allowing you to generalize the streaming (or serialization) of objects in different circumstances.

Martin York
  • 257,169
  • 86
  • 333
  • 562
1

The old stdio functionality is in C++ for compatibility (and partially because the original C++ (cfront) was just a pre-processor for C so they were available anyway).

The newer I/O model found in C++ is a lot more flexible, allowing you to add types at will, which can be printed in a way defined by that type.

In other words, in an object oriented way.

Just like complex or rational numbers numbers (or address book entries or dictionary entries or any other non-basic type for that matter) should be self contained in a class that knows how to add, subtract or otherwise manipulate them separately from the base language, the printing of those objects should also be left to the class as well.

If you're worried about the verbosity of the C++ way, there's nothing stopping you from adding a fmt() method, returning a string, to your own data types to get around that problem, something like:

std::cout << name.fmt('left',15)   // [Pax Diablo     ]
          << " " << age.fmt(4)     // [  45]
          << " " << score.fmt(3,2) // [100.00]
          << std::endl;

for sizes and/or justifications.

It's more coding on your part within the class but it is an option if you're really adverse to the setfill and setw stuff.

However, since you'll almost certainly have your formatting code in a function for each type of output (if you're smart), it'll be isolated in one area. I'd just suck it up and learn the C++ way of doing things.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
1

Along with the ability to overload insertion and extraction operators for classes of your choice, cin and cout are type-safe, which scanf and printf are not -- e.g., a mismatch between the conversion format and actual type with printf is fairly common:

printf("%d\n", 1.0);
printf("%f\n", 1);

Neither of these is at all likely to produce useful output.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
0

The C++ syntax is supposed to be easier but, frankly, I never adopted it. Besides, I do Windows programming, not console, so neither cout or printf are of much use. But sprintf and it's variations are.

Jonathan Wood
  • 65,341
  • 71
  • 269
  • 466
  • 1
    Perhaps you might want to look into the _other_ stream output functions (http://www.cppreference.com/wiki/io/sstream/start). That way, you get a more powerful, extensible sprintf, and nobody could call you a luddite. Come, join us :-) – paxdiablo Dec 23 '10 at 04:39
  • I've been a developer long enough to know what I like to use and what I don't. – Jonathan Wood Dec 23 '10 at 04:44