Why does printf_s exist?

[PIEBALDconsult]

C is cool. :cool:

[Lost User]

Depending on the target system, I would use C anytime. Especially for older systems or microcontrollers C is still a very good choice. For example, I have a C compiler that compiles for the old 6502 CPU. With a relatively simple hardware abstraction layer, you can easily write programs that run on 8 bit Atari computers, 8 bit Commodore computers or an Apple II. I still have several Ataris and also two C64 and can write and compile programs on the PC, test them in emulators and then transfer them to the real thing when finished.

The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.

[Espen Harlinn]

tomatopipps wrote:

EDIT: I don't even know why I'm not just using cout

The compiletime overhead?

Espen Harlinn Chief Architect - Powel AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

[Brisingr Aerowing]

Because Microsoft. That's why.

What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???

[Gary R Wheeler]

Hardly. print_s and related functions are part of the C and C++ standard libraries: http://en.cppreference.com/w/c/io/fprintf[^].

Software Zen: delete this;

[Joe Woodbury]

It's a security feature because by ensuring a parameter is valid, it can prevent unchecked input, crashes and so forth. https://en.wikipedia.org/wiki/Uncontrolled_format_string[^] printf has a flexibility and control that cout doesn't provide. I've also found that ostream can be very slow. Not a big deal or console output, but can stack in other places.

[Gary R Wheeler]

printf (or its secure variants these days) has an economical expressiveness that cout can't provide. It's interesting that the string.Format(...) model in .NET is more printf-like than anyone would like to admit. Granted, it 'cheats' and uses the CLR type mechanism to guarantee reasonable behavior, but I still like it better than the cout model.

Software Zen: delete this;

[James Curran]

> printf has a flexibility and control that cout doesn't provide. Say what? What kind of flexibility does printf offer that cout lacks? (The entire purpose for cout's existence is to be more flexible than printf)

Truth, James

[Dexterus]

C is fine ... I use it and will probably keep using it for a few years more. But usually printf in my system ends up in stack overflow, on 8 core 1GHz 2/4/8GB memory.

[patbob]

tomatopipps wrote:

The whole "uncontrolled format string" problem it's supposed to solve could be avoided by basic knowledge of what printf actually does.

Nope. Its needed because, despite knowing what printf actually does, people still get it wrong. In my experience, a large percentage of C program crashes were precisely because of a mismatch in printf format strings and arguments, often in non-happy-case code paths that clearly were never tested.

We can program with only 1's, but if all you've got are zeros, you've got nothing.

[pschaeffer]

"I don't even know why I'm not just using cout" Because the printf family of functions are drastically easier to use than cout?

[Joe Woodbury]

James Curran wrote:

What kind of flexibility does printf offer that cout lacks?

for one example, I find:

printf("%0.3f %.2f", x, p);

More clear and concise than:

cout << std::fixed << std::setprecision(3) << x << " " << std::defaultfloat << std::setprecision(3) << p;

Also, something like a logging function where the formatting happens after a series of checks, is easier to write using the printf family. Finally, using snprintf family can be extremely useful, especially in combination with the logging issue. PS. In several cases, I do prefer the ostream family. It all depends on what I'm trying to accomplish with the code. (There is a huge chunk of diagnostic code in the project I'm current working on which uses lots of CString::Format (snprintf_s internally), which would be a whole lot more readable using ostringstream, but I'd likely be shot if I changed it.) EDIT: Visual Studio 2010 and especially 2013 have really optimized ostream functionality. I wrote a quick test using some code from the aforementioned project. Using ostringstream was 17% faster than CString::AppendFormat with VS 2010 and 30% faster with VS 2013. I wouldn't be surprised if VS 2015 offers more improvement.

[James Curran]

aha... But you didn't say "concise" you said "flexible". I totally agree, printf is way more concise that cout, but for flexibility :

  Point p(2,3);
  cout << p << endl;

beats

  printf("(%d, %d)\\n", p.x, p.y);

Truth, James

[swampwiz]

I was modifying a console app (in C) that did amplification of WAV files, and it seemed that I had to change every one of those

printf

function calls to get it to compile in Visual Studio. I really need to completely redo that app in C# WinForms.