I'm reading the JSF AV C++ Coding Standards and the rule 22 says:
AV Rule 22 (MISRA Rule 124, Revised)
The input/output library <stdio.h> shall not be used.
Is there any reason to not use <stdio.h>?
I know that these rules are for C++ and we can use <iostream>... but what's wrong with <stdio.h>?
Every now and then, there are questions like this, about why some coding standard mandates this or that.
The correct answer should always be: Whatever the authors of that coding standard intended. Sometimes, a coding standard gives reasons for its rules; this one apparently does not. Therefore, we can only guess what the answer to your question might be.
I'll thus add my own guess:
Air vehicles sounds like really serious business, with extremely high correctness and robustness requirements. printf, scanf et al make it easy to write code which happily passes the compiler but creates undefined behaviour at run time.
Those C functions do have one advantage to normal C++ streams: format strings make it easier to write internationalised code. Consider this quickly made-up example using an std::ostream for some UI component such as a button label in a customer management application:
os << "Update customer\n";
You might want to dynamically add the customer's name:
os << "Update " << customer_name << "\n";
And you might want to dynamically insert the foreign-language word for "Update":
os << InternationalString(id_update) << " " << customer_name << "\n";
However, this is inherently English-centric. It will product correct English strings like "Update John" or "Update Joe", but will e.g. fail for German, which has different grammar and requires strings like "John aktualisieren" or "Joe aktualisieren", with the name in front of the verb in this case.
This is where format strings shine:
sprintf(s, FormatString(id_update_customer), customer_name);
Depending on the application's language setting, such a FormatString function may return "Update %s" or "%s aktualisieren".
Still, it's very dangerous. As a matter of fact, if customer_name in my example above was a std::string, you'd have undefined behaviour already.
Libraries like Boost.Format try to combine the flexibility of format strings with the type safety of streams.
Going back to your actual question, my guess is that flexibility with regards to international strings is not a great concern in the air-vehicles business.
As you can see, every aspect of a coding standard can be discussed at great length. The reasons for individual rules may not always be so apparent, and they will often have something to do with the application domain for which the standard was written.
If you cannot ask the author of the coding standard, then your question cannot really be answered.
The most obvious problem would be the lack of type safety in printf, scanf, and their various cousins (e.g., sprintf).
Along with the type safety problems, the scanf and sprintf families make it fairly difficult to ensure against buffer overruns. It can be done, but it's not trivial, and it would appear that only a tiny minority of C programmers have any clue of how to handle these kinds of tasks at all.
This JSF C++ standard is referencing MISRA-C:1998 and both are related to use of the C language in safety critical systems. The latest standard, MISRA-C:2012 has been updated (providing more rationale and better examples), and MISRA Rule 124 is now Rule 21.6 "The Standard Library input/output functions shall not be used".
The rationale is pretty simple: streams and file I/O have unspecified, undefined and implementation-defined behaviours associated with them. Also included in the guideline are the references to the C standards (C90 and C99) sections where these unpredictable behaviors are described.
The rule can be broken (through a deviation process) if the actual implementation is well defined or the code is shown not to be critical.
Related
I have read the document about naming rule of C++, they seems to be usable names.
However, in practice, when I tried to create a variable/enum with a name like iter, yes, no, out, i, Error, etc. , Visual Studio will strangely use italic font for them.
I can only guess that they are reserved for special thing, and IDE (e.g. refactoring/rename process) might act strangely if I use such names.
Is it safe to use those names in practice? Am I just too panic?
Sorry if it is too newbie or an inappropriate question.
I doubt about it for a few weeks but too afraid to ask.
These names are valid and will not cause any "harm", the standard only says:
Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the
implementation for any use.
Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
Which means that all your names are fine to use in user-code. Visual Studio might just have a thing for these names as i and iter are usually used in looping.
These names are not reserved in standard C++, as explained by Rick Astley. An implementation may choose to accept additional reserved words to provide language extensions, such as ref class in C++/CLI. In some cases, such as with ref class, where ref is a contextual keyword, these extensions only make otherwise ill-formed programs well-formed in the scope of the extended language. In other cases, an otherwise well-formed program may change its meaning or become ill-formed. In the former case, the implementation is still conforming to the C++ standard, as long as it issues all mandatory diagnostics; in the latter case, it is certainly not conforming.
It is considered good practice to make the latter kind of extensions optional e.g. using a command line option, so that the implementation still has a mode in which it is fully standards compliant. My immediate guess is that VC++ in fact does allow you to write well-formed programs containing yes, no, i, iter which will behave as required by the standard (implementation bugs notwithstanding).
The IDE is a different beast, though. It is considered to be outside of the scope of the C++ standard, and might discourage or even stop you from writing perfectly well-formed code. That would still be a quality of implementation issue, or an issue of customer satisfaction, if you will.
I have been working in C and C++ and when it comes to file handling I get confused. Let me state the things I know.
In C, we use functions:
fopen, fclose, fwrite, fread, ftell, fseek, fprintf, fscanf, feof, fileno, fgets, fputs, fgetc, fputc.
FILE *fp for file pointer.
Modes like r, w, a
I know when to use these functions (Hope I didn't miss anything important).
In C++, we use functions / operators:
fstream f
f.open, f.close, f>>, f<<, f.seekg, f.seekp, f.tellg, f.tellp, f.read, f.write, f.eof.
Modes like ios::in, ios::out, ios::bin , etc...
So is it possible (recommended) to use C compatible file operations in C++?
Which is more widely used and why?
Is there anything other than these that I should be aware of?
Sometimes there's existing code expecting one or the other that you need to interact with, which can affect your choice, but in general the C++ versions wouldn't have been introduced if there weren't issues with the C versions that they could fix. Improvements include:
RAII semantics, which means e.g. fstreams close the files they manage when they leave scope
modal ability to throw exceptions when errors occur, which can make for cleaner code focused on the typical/successful processing (see http://en.cppreference.com/w/cpp/io/basic_ios/exceptions for API function and example)
type safety, such that how input and output is performed is implicitly selected using the variable type involved
C-style I/O has potential for crashes: e.g. int my_int = 32; printf("%s", my_int);, where %s tells printf to expect a pointer to an ASCIIZ character buffer but my_int appears instead; firstly, the argument passing convention may mean ints are passed differently to const char*s, secondly sizeof int may not equal sizeof const char*, and finally, even if printf extracts 32 as a const char* at best it will just print random garbage from memory address 32 onwards until it coincidentally hits a NUL character - far more likely the process will lack permissions to read some of that memory and the program will crash. Modern C compilers can sometimes validate the format string against the provided arguments, reducing this risk.
extensibility for user-defined types (i.e. you can teach streams how to handle your own classes)
support for dynamically sizing receiving strings based on the actual input, whereas the C functions tend to need hard-coded maximum buffer sizes and loops in user code to assemble arbitrary sized input
Streams are also sometimes criticised for:
verbosity of formatting, particularly "io manipulators" setting width, precision, base, padding, compared to the printf-style format strings
a sometimes confusing mix of manipulators that persist their settings across multiple I/O operations and others that are reset after each operation
lack of convenience class for RAII pushing/saving and later popping/restoring the manipulator state
being slow, as Ben Voigt comments and documents here
The performance differences between printf()/fwrite style I/O and C++ IO streams formatting are very much implementation dependent.
Some implementations (visual C++ for instance), build their IO streams on top of FILE * objects and this tends to increase the run-time complexity of their implementation. Note, however, that there was no particular constraint to implement the library in this fashion.
In my own opinion, the benefits of C++ I/O are as follows:
Type safety.
Flexibility of implementation. Code can be written to do specific formatting or input to or from a generic ostream or istream object. The application can then invoke this code with any kind of derived stream object. If the code that I have written and tested against a file now needs to be applied to a socket, a serial port, or some other kind of internal stream, you can create a stream implementation specific to that kind of I/O. Extending the C style I/O in this fashion is not even close to possible.
Flexibility in locale settings: the C approach of using a single global locale is, in my opinion, seriously flawed. I have experienced cases where I invoked library code (a DLL) that changed the global locale settings underneath my code and completely messed up my output. A C++ stream allows you to imbue() any locale to a stream object.
An interesting critical comparison can be found here.
C++ FQA io
Not exactly polite, but makes to think...
Disclaimer
The C++ FQA (that is a critical response to the C++ FAQ) is often considered by the C++ community a "stupid joke issued by a silly guy the even don't understand what C++ is or wants to be"(cit. from the FQA itself).
These kind of argumentation are often used to flame (or escape from) religion battles between C++ believers, Others languages believers or language atheists each in his own humble opinion convinced to be in something superior to the other.
I'm not interested in such battles, I just like to stimulate critical reasoning about the pros and cons argumentation. The C++ FQA -in this sens- has the advantage to place both the FQA and the FAQ one over the other, allowing an immediate comparison. And that the only reason why I referenced it.
Following TonyD comments, below (tanks for them, I makes me clear my intention need a clarification...), it must be noted that the OP is not just discussing the << and >> (I just talk about them in my comments just for brevity) but the entire function-set that makes up the I/O model of C and C++.
With this idea in mind, think also to other "imperative" languages (Java, Python, D ...) and you'll see they are all more conformant to the C model than C++. Sometimes making it even type safe (what the C model is not, and that's its major drawback).
What my point is all about
At the time C++ came along as mainstream (1996 or so) the <iostream.h> library (note the ".h": pre-ISO) was in a language where templates where not yet fully available, and, essentially, no type-safe support for varadic functions (we have to wait until C++11 to get them), but with type-safe overloaded functions.
The idea of oveloading << retuning it's first parameter over and over is -in fact- a way to chain a variable set of arguments using only a binary function, that can be overload in a type-safe manner. That idea extends to whatever "state management function" (like width() or precision()) through manipulators (like setw) appear as a natural consequence. This points -despite of what you may thing to the FQA author- are real facts. And is also a matter of fact that FQA is the only site I found that talks about it.
That said, years later, when the D language was designed starting offering varadic templates, the writef function was added in the D standard library providing a printf-like syntax, but also being perfectly type-safe. (see here)
Nowadays C++11 also have varadic templates ... so the same approach can be putted in place just in the same way.
Moral of the story
Both C++ and C io models appear "outdated" respect to a modern programming style.
C retain speed, C++ type safety and a "more flexible abstraction for localization" (but I wonder how many C++ programmers are in the world that are aware of locales and facets...) at a runtime-cost (jut track with a debugger the << of a number, going through stream, buffer locale and facet ... and all the related virtual functions!).
The C model, is also easily extensible to parametric messages (the one the order of the parameters depends on the localization of the text they are in) with format strings like
#1%d #2%i allowing scrpting like "text #2%i text #1%d ..."
The C++ model has no concept of "format string": the parameter order is fixed and itermixed with the text.
But C++11 varadic templates can be used to provide a support that:
can offer both compile-time and run-time locale selection
can offer both compile-time and run-time parametric order
can offer compile-time parameter type safety
... all using a simple format string methodology.
Is it time to standardize a new C++ i/o model ?
I am using gcc 4.2.4.
According to Schildt, "C++ The Complete Reference", 1995, user defined parameterized manipulators should be defined as:
istream &mymanip(istream &stream, type param)
{
// here my code
return stream;
}
// overload
imanip<type> mymanip(type param){
return imanip<type>(mymanip, param)
}
// usage
cin >> mymanip(param);
I believe that imanip(mymanip, param) is supposed to return an object that contains mymanip and mymanip's arguments. This should be used by an overloaded operator>> to call mymanip. However, this does not work, imanip is not declared.
I also found this version:
IMANIP(int) fld(int n){
return IMANIP(int)(fld,n);
}
which also does not work.
My questions are:
does gcc 4.2.4 follow the ANSI C++ standard on this detail or not? If it does, did the standard change since 1995 in this respect?
in order to define my own parameterized manipulators do I need to understand the iostream code and write my own overloaded imanip and operator>> functions?
regardless the answer to question 2, what is the best strategy for me to understand the iostream code? Should I read the code? How do I find out the names of compiled libraries which are part of iostream? Should I read a book?
The code you posted seems out of context. imanip looks like some template, but that template is never defined anywhere in your code.
But to be honest, I would not even consider using a 1995 book on C++ any more. In 1995 C++ was not even standardized, although there existed an "annotated reference manual". Your book is over 17 years old, which means "more than extremely outdated" when it comes to programming languages. C++ has evolved a lot since then, you should consider to buy a more recent book, perhaps take a look at http://isocpp.org/get-started to give you some examples.
To give you more specific answers to your questions:
Yes, gcc follows the standard in this regard, but your book might not, because it is pre-standard.
Manipulators are made so you do not have to reimplement the op<< and op>> again. However, depending on what your manipulators are designed to do, you might need to call some of the lower level methods provided by the stream or streambuf.
"The code" does not exist, there are several implementors of standard libraries, and they all have their own, sometimes very complicated code for etc. I would recommend to search the web for information about how those libraries work. Of course, a book is even better. Consider buying "The C++ Standard Library" by N. Josuttis. There is a recent Edition that covers the standard library "as of now and tomorrow", i.e. including the additions of the C++11 standard.
Does the C++ correct programming style demand writing all your code with classes or are C-like procedures allowed ? If I were to give some code to someone else, would it be accepted as C++ just because it has std::vector and std::string (instead of char *) inside, or everything has to be a class?
eg:
int number = 204;
std::string result = my_procedure(number);
OR
MyClass machine;
std::string result = machine.get(number);
Are there cases where the programmer, will have to, or is allowed to have C-like procedures in some of his source code ? Did you ever had to do something like that?
In the context of this question where does the margin between C and C++ exist (if any)?
I hope my question is clear and inline with the rules.
It's certainly OK to have free functions in your code -- this is a matter of architecture, not of "++ness". For small programs it doesn't even make sense to go all-in with classes, as OO is really a tool to manage complexity. If the complexity isn't there to begin with, why bother?
Your second question, where is the line drawn, doesn't have a short answer. The obvious one is that the line is drawn in all places where the C standard differs from the one for C++. But if you are looking for a list of high-level language features that C++ has and C does not, here are some of them:
Class types and OO (of course)
The STL
Function/operator overloading
References
Templates
new/delete to manage memory
C++ is a multi-paradigm language, where OO, procedural, generic/generative and - to a lesser (but increasing with C++0x) extent functional - are among the paradigms. You should use whichever is the best fit for the problem: you want the code to be easy to get and keep right, and hard to stuff up.
The utility of classes is in packaging data (state) along with the related functions. If your wordify function doesn't need to retain any state between calls, then there's no need to use a class/object. That said, if you can predict that you will soon want to have state, then it may be useful to start with a class so that the client code doesn't need to change as much.
For example, imagine adding a parameter to the function to specify whether the output should be "first", "second" instead of "one", "two". You want the behaviour to be set once and remembered, but somewhere else in the application some other code may also use the functionality but prefer the other setting. It's a good idea to use an object to hold the state and arrange it so each object's lifetime and accessibility aligns with the code that will use it.
EDIT:
In the context of this question where does the margin between C and C++ exist (if any)?
C++ just gives you a richer set of ways to tackle your programming tasks, each with their necessary pros and cons. There are plenty of times when the best way is still the same way it would have been done in C. It would be perverse for a C++ programmer to choose a worse way simply because it was only possible in C++. Still, such choices exist at myriad levels, so it's common to have say a non-[class-]member function that takes a const std::string& parameter, combining the procedural function call with object-oriented data that's been generated by a template: it all works well together.
C++ allows a variety of programming styles, procedural code being one of them.
Which style to use depends on the problem you are trying to solve. The margin between C and C++ is are you compiling your code with a C++ compiler.
I do at times use procedural functions in my code. Sometimes it best solves the problem.
C++ code can still be valid C++ code even without classes. Classes are more of a feature, and are not required in every piece of code.
C++ is basically C with more features, so there isn't really a "margin" between the two languages.
If you read Stroustrup's Design and Evolution, you'll see that C++ was intended to support multiple programming styles. Use whichever one is most appropriate the problem (not the same as always just usnig the one you know.)
In legacy real world applications, there is often very little distinction. Some C++ code was originally C code nad then recompilied. Slowly it migrates to use C++ features to improve its quality.
In short, Yes, C++ code can be procedural. But you'll find it does differ from C code if you use C++ features where appropriate.
What is good practice needs to consider things like encapsulation, testability, and the comprehensibility of the client API.
#include <sstream>
#include <string>
#include <iostream>
using namespace std;
string wordify(int n)
{
stringstream ss;
ss << n; // put the integer into the stream
return ss.str(); // return the string
}
int main()
{
string s1 = wordify(42);
string s2 = wordify(45678);
string s3 = wordify(-99);
cout << s1 << ' ' << s2 << ' ' << s3 << '\n';
}
I was coding some C++ for a small hobby project when I noticed that I'm using C-style operations to access IO (printf, fopen, etc.).
Is it considered "bad practice" to involve C functions in C++ projects? What are the advantages of using streams over C-style IO access?
This is an heated topic.
Some people prefer to use the C++ IO since they are type-safe (you can't have divergence between the type of the object and the type specified in the format string), and flow more naturally with the rest of the C++ way of coding.
However, there is also arguments for C IO functions (my personal favorites). Some of them are:
They integrate more easily with localisation, as the whole string to localise is not broken up in smaller strings, and with some implementation the localizer can reorder the order of the inserted value, move them in the string, ...
You can directly see the format of the text that will be written (this can be really hard with stream operators).
As there is no inlining, and only one instance of the printf function, the generated code is smaller (this can be important in embedded environment).
Faster than C++ function in some implementation.
Personally, I wouldn't consider it bad practice to use C stream in C++ code. Some organisations even recommend to use them over C++ stream. What I would consider bad style is to use both in the same project. Consistency is the key here I think.
As other have noted, in a relatively large project, you would probably not use them directly, but you would use a set of wrapper function (or classes), that would best fit your coding standard, and your needs (localisation, type safety, ...). You can use one or the other IO interface to implement this higher level interface, but you'll probably only use one.
Edit: adding some information about the advantage of printf formatting function family relating to the localisation. Please note that those information are only valid for some implementation.
You can use %m$ instead of % to reference parameter by index instead of referencing them sequentially. This can be used to reorder values in the formatted string. The following program will write Hello World! on the standard output.
#include <stdio.h>
int main() {
printf("%2$s %1$s\n", "World!", "Hello");
return 0;
}
Consider translating this C++ code:
if (nb_files_deleted == 1)
stream << "One file ";
else
stream << nb_file_deleted << " files ";
stream << removed from directory \"" << directory << "\"\n";
This can be really hard. With printf (and a library like gettext to handle the localization), the code is not mixed with the string. We can thus pass the string to the localization team, and won't have to update the code if there are special case in some language (in some language, if count of object is 0, you use a plural form, in other language, there are three forms one for singular, one when there is two object and a plural form, ...).
printf (ngettext ("One file removed from directory \"%2$s\"",
"%1$d files removed from directory \"%2$s\"",
n),
n, dir);
printf and friends are hideously unsafe compared to <iostream>, and cannot be extended, plus of course fopen and friends have no RAII, which means that unless you've proved with a profiler that you definitely need the performance difference (that you've proved exists on your platform and in your code), you'd have to be an idiot to printf.
Edit: Localization is an interesting thing that I hadn't considered. I've never localized any code and cannot comment on the relative localizational ability of printf and <iostream>
Nothing can be considered bad practice if it has a definite purpose. I mean, if IO is the bottleneck of the program, then yes, C-style IO works faster than C++ IO. But if it is not, I would go with C++ stream approach. Cuz it's cuter :)
For a small hobby project I would probably go with the more type-safe C++ io streams.
Funny enough, I've never seen a non-trivial real-life project that uses either of them. In all cases we used some abstractions built on top of the native OS API for IO.
Advantages
Type safety: the argument types of C++ streaming operations are checked at compile time, while printf arguments are passed through ... causing undefined behaviour if they do not match the formatting.
Resource management: C++ stream objects have destructors to close file handles, free buffers, and what have you. C streams require you to remember to call fclose.
Disadvantages
Performance: this depends on the implementation, of course, but I've found formatting with C++ streams to be considerably slower than the equivalent printf formatting.
IMHO, a real C++ programmer tries to do things in idiomatic C++ way; the C converted programmer tries to cling on old ways of doing things. It has to do with readability and consistency.
For one, you don't have to convert C++ objects (notably strings) to C-compatible forms first.
Is it considered "bad practice" to involve C functions in C++ projects?
Usually, the file IO code should be encapsulated in a class or function implementation. I wouldn't consider any choices you make in the encapsulated implementations to be "bad practice", I reserve that term for what affects the user of your library or code (i.e. the interface). If you are exposing your file IO mechanism in the interface, then, IMO, it's bad practice whether you use IO stream or C-style IO functions.
I would rather say that C-style IO functions are (probably always) the worse choice.
What are the advantages of using streams over C-style IO access?
First, they integrate better with standard C++ constructs such as std::string. They integrate fairly well with STL <algorithms>. And they allow you to create encapsulated custom read/write operators (<< and >>) such that your custom classes almost look like primitive types when it comes to doing IO operations.
Finally, IO streams in C++ can use exception mechanism to report errors in the stream or read/write operations. These make the file IO code much nicer by avoid the terrible look of error-code mechanisms (sequence of if-statements and ugly while-loops, that check the error code after each operation).
As a general rule, you should prefer C++ operators, they're:
-- Type safe. You don't risk passing a double where the format
calls for an int.
-- Extensible. You can write your own inserters and
extracters, and use them.
-- Extensible. You can define your own manipulators (with
application specific logical meaning), and use them. If you
want to change the format of all of the WidgitNumber
(internally, an int) in your output, you change the
manipulator; you don't have to find all of the format
statements where %d is a WidgitNumber.
-- Extensible. You can write your own sinks and sources, and
these can forward to other sinks and sources, filtering or
expanding the input or output as desired.
(FWIW: I don't think I've ever written an application which
didn't use custom >> and << operators, custom manipulators, and
custom streambuf's.)
Is it considered "bad practice" to involve C functions in C++ projects?
No. C functions are often used in C++ projects. Regarding the streams, Google C++ Style Guide, for example, recommends using them only in limited cases such as "ad-hoc, local, human-readable, and targeted at other developers rather than end-users".
What are the advantages of using streams over C-style IO access?
The main advantages are type safety and extensibility. However C++ streams have serious flaws, see the answers to this question such as problems with localization, poor error reporting, code bloat and performance issues in some implementations.