I work on a well-established, embedded C++ code base. We have been using a proprietary API to our filesystem. For better integration with third-party C libraries, we are currently in the process of implementing most of stdio.h and fcntl.h. I made what I thought was a non-controversial proposal that we should also implement the fstream class and encourage new C++ code to use it instead of the new (to our code base) C-style API. We already have the stdout parts of iostream available, although it is not widely used.

Given a choice between using stdio and fstream, what are good reasons to choose stdio for embedded software development in C++?

  • Do you have some use case scenarios that are typical or are you asking for use case scenarios for each side? – Martin York Sep 19 '12 at 17:56
  • We mostly use the filesystem to read and write config files. – Karl Bielefeldt Sep 19 '12 at 21:56
  • So speed is not your goal. But accuracy/correctness and ease of use are. – Martin York Sep 19 '12 at 22:59

My top reason would be familiarity with the library. Back in my embedded days (a little over a decade ago), most C++ developers in several companies where I worked came from a strong C background. C-style input and output did not require any learning, while dealing with advanced concepts of manipulating streams often required checking a book.

As far as purely technical reasons go, I don't think there are any: properly implemented stream I/O should be as fast as the C-style I/O, and use roughly the same amount of memory.


Since you're asking about the API, there's not much to say other than the classic <iostream> vs <stdio.h> arguments. While many of these sort of arguments are just subjective matters of taste, it seems clear to me that there are many objective reasons that make iostream vastly preferable. IOstream provides you with type-safety and extensibility, and avoids the possibility of leaving you open to a format string security exploit.

I see no particular reason why this should be much different in an embedded environment. I would go with <iostream>.

The only (somewhat contrived) reason I can see to favor stdio.h in a C++ project is if you are working with a C API that often uses varargs, forcing you to frequently use v*printf functions. In that case, you could argue that it might be better to stick with stdio.h just for the sake of consistency throughout the code.


IF the classes are already implemented for fstream(including the operator overloading and the likes), then I would certainly use fstream(seems like more C++ programmers in the team). BUT If i were to implement the libraries myself(which is usually the case with MOST embedded system programmers) I would choose a faster efficient library like stdio. stdio is less dependent on the 'std-runtime-of-c' and more dependent on buffers and pointers to structures, which is obviously faster(to use and to code as well)!

stdio takes less space(hence executes faster) compared to fstream(which relies on oo concepts and branches off into ifstream and ofstream, above fstream there is a stream class).

  • But stdio also has to parse format strings at runtime, whereas arguments to ostream are resolved at compile time. So ostream may be faster than stdio - you'd need to really do benchmarks on various implementations to find out either way. – Charles Salvia Sep 19 '12 at 17:04
  • In our case, both implementations would call into our existing underlying object-oriented library, so the performance difference is probably going to be negligible. I'm mostly looking for arguments about the API rather than the implementation. – Karl Bielefeldt Sep 19 '12 at 17:08
  • @KarlBielefeldt then, I think its a matter of taste. Like I said if its implemented already then I would stick to C++(Fstream) for an OO project, while use stdio on a structured(C) software. – Aniket Inge Sep 19 '12 at 17:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.