I see a lot of people talking about the differences between:
#include <iostream>
and
#include <iostream.h>
What are the differents and whats the correct choice and why?
Thanks! :)
Printable View
I see a lot of people talking about the differences between:
#include <iostream>
and
#include <iostream.h>
What are the differents and whats the correct choice and why?
Thanks! :)
>> whats the correct choice
iostream.
along with one of the following:
using namespace std;
OR
using std::cout;
using std::cin;
using std::endl;
//etc. etc. ; with whatever else you are using
OR
std::cout << std::endl; //for example
>>why?
it's standard.
check the faq, i think it may be there, not sure.
>>what are the differences
in that library many, in others just an include of the old style header in namespace std.
>>what is the correct choice
providing your compiler is not too old then <iostream> is the correct choice. <iostream.h> is for backwards compatability with legacy code only.
>>why?
because the c++ standard says so. The old iostreams are deprecated.
<iostream>
Is the new iso standard for c++ since 97 i think..
so usually u better without the .h
but there are few exceptions..
like string and string.h
if u want to use c string : include .h
if u need c++ string : just <string>
hope that helped..
Also i think that question was in the faq..
If not should be added..
sorry the question wasn't in the FAQ.
"but there are few exceptions..
like string and string.h
if u want to use c string : include .h"
Not true. You can do that, but it won't be according to the standard.
#include<string> //for string objects
#include<cstring> //for c-style string functions
serruya,
"sorry the question wasn't in the FAQ."
See here:
http://www.cplusplus.com/doc/ansi/hfiles.html
"Bull$$$$! Actually check the standard before you attempt to use it to ``prove'' someone wrong!
No thanks. My life doesn't hinge on the semantics of the standard.
it can, won't necessarily, but can.Quote:
Originally posted by 7stud
"Bull$$$$! Actually check the standard before you attempt to use it to ``prove'' someone wrong!
No thanks. My life doesn't hinge on the semantics of the standard.
Really? So, if you follow the new standard for header files instead of the old deprecated method included for backwards compatability, you could actually die?
lol
ooh, let's go for the sarcasm. I thought your statement was more based on, for example, work. Depending what you are coding, the standard can be relied upon.Quote:
Originally posted by 7stud
Really? So, if you follow the new standard instead of the old deprecated method included for backwards compatability, you could actually die?
lol
lol
Greetings,
The thing is, if you are using <iostream> you should use <cstring> if you are using the old C string routines. <string.h> is only in the standard for the same reason <iostream.h> is: backward compatibility! The old C/C++ style headers (*.h) are deprecated, which means that they may not be included in future versions of the standard.
If you, vVv, had bothered to read the page you quoted, you'd notice at the very begginning this part:
(Quote from the standard at: http://std.dkuug.dk/jtc1/sc22/wg21/d...depr.c.headers)
So, in conclusion, <string.h> and all <*.h> headers are there for bacward compatibility and should no longer be used if you want to garantee that your code will be compilable in the future!Quote:
1 This clause describes features of the C++ Standard that are specified
for compatibility with existing implementations.
2 These are deprecated features, where deprecated is defined as: Norma-
tive for the current edition of the Standard, but not guaranteed to be
part of the Standard in future revisions.
(there's some points referencing some other deprecated features not relevant to this discussion right before the part you quoted, that i'll include below)
1.5 Standard C library headers [depr.c.headers]
1 For compatibility with the Standard C library, the C++ Standard
library provides the 18 C headers, as shown in Table 1:
Table 1--C Headers
-----------------------------------------------------------------
<assert.h> <iso646.h> <setjmp.h> <stdio.h> <wchar.h>
<ctype.h> <limits.h> <signal.h> <stdlib.h> <wctype.h>
<errno.h> <locale.h> <stdarg.h> <string.h>
<float.h> <math.h> <stddef.h> <time.h>
-----------------------------------------------------------------
| |
| |
| |
| |
2 Each C header, whose name has the form name.h, behaves as if each name
placed in the Standard library namespace by the corresponding cname
header is also placed within the namespace scope of the namespace std
and is followed by an explicit using-declaration (_namespace.udecl_)
3 [Example: The header <cstdlib> provides its declarations and defini-
tions within the namespace std. The header <stdlib.h> makes these
available in the global name space, much as in the C Standard. --end
example]
And, always read before you quote!
Greetings,
In that case I'm sorry, but what I got from 7stud's post was not that <string.h> isn't there, but if you are coding C++ you should be using the Cname header instead, i.e: <cstring> and he is right.
By the way, I made one mistake on my last post, <iostream.h> isn't even in the standard, some compilers support it, but the standard does not.
"I didn't advocate their use, either - What I did was show that 7stud's (rather implicit) claim that the string.h header is, according to the standard, not available anymore, is wrong."
lol. Too bad your reading comprehension hasn't kept pace with your over inflated ego. Let's see if we can lead you through it step by step. Luigi cited the **new** standard for header files:
"<iostream>
Is the new iso standard for c++..."
But Luigi said there were exceptions like <string.h>:
"but there are few exceptions..
like string and string.h"
I pointed out that <string.h> wasn't an exception to the standard--the standard in discussion being the **new** standard:
"You can do that, but it won't be according to the standard."
at which point you threw a hissy fit. Whether you believe a statement like that is correct or not is irrelevant in light of your juvenile responses. The only thing you proved is how a spoiled child acts when he doesn't get his way. The previous posts made it adequately clear what the standard includes and doesn't include. Your contribution to this thread was nothing.
I made no attempt to "prove" anything. I just pointed out to Luigi and possibly the original poster that instead of <string.h>, one should include <cstring> instead.
Good day.
"Bull$$$$! Actually check the standard before you attempt to use it to ``prove'' someone wrong!"
"If you can't take constructive criticism, and have to resort to personal ``insults'', then don't post here!"
lol. Your understanding of constructive criticism matches your level of reading comprehension.
But back to the matter at hand: so you agree with Luigi that string and string.h are exceptions to the new standard? Also, in your world what other header files are exceptions to the new standard?
While on the subject for header files, why are these 'new' standard headers extention-less? I checked my include folder, and both "iostream.h" and "iostream" (no extention) are there. Why didn't they name them "*.hh" or "StandardIostream.h" or something instead?
I have seldom seen a more pointless discussion in a tech forum...
Magos: probably because <iostream> looks cooler than <iostream.hh> :)
I'd prefer an extension too, that way I could associate them with an app.