Thread: .h files help

I found a lot of source codes which #include fstream.h file but i didn't have this file, so i checked and had to use #include fstream then use 'using namespace std;' What i want to know is the reason why this is used and whats the difference between the .h file and the extensionless one, regards

fstream is a file used to handle file input and output. The difference between the .h one and the extensionless one is that the .h is older and isn't in the std namespace. Since it's newer and has some features that the older one does, some compilers may even warn that use of the older version is deprecated.

thanks a lot for the quick replys

The .h version has never been deprecated. "Deprecated" has a specific meaning --- at one time, a deprecated feature was part of an official standard, and a later version of that official standard earmarked that feature for eventual removal from a future edition of that standard. There is only one official C++ standard, so it can't have any deprecated features. The next C++ standard might deprecate some features that are defined in the current standard.

When the C++ standard was in draft, various headers were defined. However, as the standard evolved (still in draft, before it was endorsed as an official standard), eventually a decision was made to (1) define a namespace called std, and place the standard library in that namespace and (2) define the C++ standard headers without a .h extension.

No; the description of fstream.h (according to the gnu documentation) is "antiquated" i.e. old. Being deprecated is a different thing.

Originally Posted by major_small

I know it's different, but I'm pretty sure it's deprecated... you may want to ask somebody who has a copy of the standard...

edit: I just quickly looked through the standard, and all it says is that the 18 C headers are deprecated... ie. <stdlib.h> becomes <cstdlib> (Annex D.5), mentioned in section C.2.1

I have a copy of the standard. I also have some familiarity with standardisation processes --- the term "deprecated" has specific meaning in any standardisation process, it is not unique to the C++ standard.

The reason the C headers are deprecated in C++ is that the C++ standard provides versions that (arguably) supersede them. The C++ standard currently requires backward compatibility to the 1989 C standard (with one or two minor exceptions). The C headers are deprecated in the C++ standard primarily to encourage usage of the newer headers, but were not removed from the C++ standard because of a desire for backward compatibility to C89. A secondary goal of deprecating, from discussions between committee members in about 1995, was to flag a possibility that C compatibility might eventually be deemed non-essential for C++.

Originally Posted by mitakeet

So, are the C++ versions of the C standard libs going to be deprecated?

The intent of the C++ versions of the C standard headers (<cstdio>, etc) was essentially to allow C++ programmers to access functionality of the C library, but place everything in the std namespace: this reduces likelihood of unintended clashes of function names with C++ code. I also seem to recall some mention of some other minor tweaks, but haven't chased to confirm/deny that.

Originally Posted by mitakeet

What I mean is I can understand of <stdlib.h> be dropped as long as <cstdio> remains, but if they drop support for C IO (printf, scanf, etc.), I think that would be a problem as even though I have been a professional C++ coder for several years, I still drop back to C IO from time to time (as well as C style memory management (primarily for realloc, which does not seem to be supported in C++)), though I try to use the C++ versions of the headers.

What you're doing is more or less the intent underlying the deprecation of the actual C headers (the .h versions).

Without a working crystal ball, it's impossible to say that headers like <cstdio> will never be deprecated. However, I would be surprised if they were .....

You can introduce features in the standard and deprecate them immediately. There is only one C++ standard, and it has some things marked as deprecated, and not just the C headers. For example, the <strstream> header is standard but deprecated, yet it was not part of any C or C++ standard previously, AFAIK.

I also doubt that the C libraries will ever be deprecated or removed from C++. Compatibility with C is one of the major goals of the language.

Originally Posted by Daved

You can introduce features in the standard and deprecate them immediately. There is only one C++ standard, and it has some things marked as deprecated, and not just the C headers. For example, the <strstream> header is standard but deprecated, yet it was not part of any C or C++ standard previously, AFAIK.

Yep. This is because the standards committees took a pragmatic view. Some features were implemented by some major compiler vendors, despite the fact that they were considered bad practice or otherwise undesirable by the standards committee. Those features were noted in Annex D, for "compatability with existing implementations", and immediately deprecated.

From a generic perspective of standardisation, this is a bit of misuse of deprecation. But it was one of the political compromises necessary to get the standard endorsed by the committee.

Originally Posted by Daved

I also doubt that the C libraries will ever be deprecated or removed from C++. Compatibility with C is one of the major goals of the language.

Compatibility with C (at least C89) is simultaneously one of the greatest strengths and also one of the greatest weaknesses of C++. That backward compatibility forces several compromises on the language (eg that ugly syntax) and, to a lesser extent on the library.

Given the weaknesses imposed by C compatibility, the question of "how much compatibility do we retain?" is one of several being quietly examined in the process leading to the next C++ standard. While I don't expect C compatibility to disappear, the extent of compatibility well might. I would be surprised if the libraries disappeared, but they may well be gradually cleaned up.

The question of C compatibility is a vexing one: the 1999 C standard introduced several features that are directly incompatible with C++ (have a look at the complex type for an example). In part that was because they weren't required to maintain C++ compatibility (one of the constraints on the C++ committee was maintaining, as much as possible, compatibility with C and a requirement to document incompatibilities). And there is always the political aspect: I've seen some suggestions that some members of the C committee resented the notion of C++ as a better C.