Dev will compile with either:
#include <iostream>
using namespace std;
or
#include <iostream.h>
BH <--- C++ nOOb
Dev will compile with either:
#include <iostream>
using namespace std;
or
#include <iostream.h>
BH <--- C++ nOOb
Alright... Sorry I said "discarded". I wasn't speaking about the input buffer, but rather the assignment to the character. Clearly, you cannot assign a long string to a single character, and so, for the purposes of that assignment, the extra characters were discarded.
* edit *
Dev doesn't compile anything, its just the IDE. The underlying compiler is some flavor of GCC (Cygwin or MinGW), which is standard compliant.
Last edited by Zach L.; 06-13-2003 at 03:24 PM.
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
Only the first one is legal C++, so if your compiler allows it, you should certainly use it.Originally posted by Black-Hearted
Dev will compile with either:
#include <iostream>
using namespace std;
or
#include <iostream.h>
BH <--- C++ nOOb
gcc 3.2 warns by default on iostream.h, or any of the depreciated headers. The Dev-C++ distribution may have modified this as the warning really couldn't be more explicit. With all the Dev-C++ users coding from seven year old books we should see lot's of complaints. The warning is relitively new, though I am not sure how new, I haven't used iostream.h for years. iostream.h has been implemented in terms of iostream for about as long as there has been an iostream. I don't expect gcc to drop the header any time soon. Half the poiint of gcc is being able to re-compile 20 year old code on a 10 year old machine with a brand new compiler and have that old program work better. If this really upsets you, changing the warning to an error would requre changing a single word in one header.
What is the advantage when 'using namespace std;' ??
I see that lots of people use it in their code, but when I delete it, the code still works. So why use it?
If you use <iostream> et al instead of the old <iostream.h> counterparts, then namespace std will make a difference. Namespaces prevent name collisions. For example, if you made a vector class in your own namespace (say, 'name1'), then the compiler would be able to distinguish between std::vector and name1::vector.
Additionally, all of the standard C++ libraries define their symbols within the std namespace.
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
If it has no effect, you're not writing legal C++. What kind of #includes are you doing? For example:Originally posted by FromHolland
What is the advantage when 'using namespace std;' ??
I see that lots of people use it in their code, but when I delete it, the code still works. So why use it?
if "using namespace std" has no effect, you're writing "old" C++, which is no longer standard, and won't even compile on many compilers.Code:#include <iostream.h> //ILLEGAL, should be <iostream> #include <string.h> //ILLEGAL, should be <string> #include <stdlib.h> //ILLEGAL, should be <cstdlib>
<string> clearly urinates all over null terminated strings from a great height, but a replacement for string.h it ain't. <cstring> is what you want here, keeping the global namespace nice and clean. I am somewhat surprised, and would really like more information on, the ILLEGAL nature of perfectly good C headers. It is my understanding that the cleaner c* headers for the C standard library should be preferred in C++, but making their C equivalents ILLEGAL just seems to break compatibility for no clear reason.Originally posted by Cat
Code:#include <string.h> //ILLEGAL, should be <string> #include <stdlib.h> //ILLEGAL, should be <cstdlib>
It doesn't matter as long as the compiler does not see the difference between LEGAL and NON-LEGAL code.
You are correct, I should, of course, have said <cstring> not <string>.Originally posted by grib
<string> clearly urinates all over null terminated strings from a great height, but a replacement for string.h it ain't. <cstring> is what you want here, keeping the global namespace nice and clean. I am somewhat surprised, and would really like more information on, the ILLEGAL nature of perfectly good C headers. It is my understanding that the cleaner c* headers for the C standard library should be preferred in C++, but making their C equivalents ILLEGAL just seems to break compatibility for no clear reason.
And, for example, <stdio.h> is illegal, wheras <cstdio> is legal, simply by definition of the C++ standard headers. C++ compilers are not obligated to compile C code; many cannot. The C++ standard does not require a C++ compiler to even provide <stdio.h>. It *does* require that a C++ compiler provide <cstdio>.
The only headers that a compliant C++ compiler is guaranteed to provide are the following 51 headers:
<algorithm>, <bitset>, <cassert>, <cctype>, <cerrno>, <cfloat>, <ciso646>, <climits>, <clocale>, <cmath>, <complex>, <csetjmp>, <csignal>, <cstdarg>, <cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, <cwchar>, <cwctype>, <deque>, <exception>, <fstream>, <functional>, <iomanip>, <ios>, <iosfwd>, <iostream>, <istream>, <iterator>, <limits>, <list>, <locale>, <map>, <memory>, <new>, <numeric>, <ostream>, <queue>, <set>, <sstream>, <stack>, <stdexcept>, <streambuf>, <string>, <strstream>, <typeinfo>, <utility>, <valarray>, and <vector>.
Of course, many will provide the C headers as well, but they don't have to, and a portable solution shouldn't require them.
Further, the C++ version of the C headers aren't functionally identical to the C versions. C++ makes additional guarantees about the standard headers that C didn't. For example, in C, it was acceptable for implementations to use masking macros; in C++, implementations are not allowed to do this.
Last edited by Cat; 06-15-2003 at 02:37 PM.
But if someone then wants to use a different compiler which DOES see a difference?Originally posted by FromHolland
It doesn't matter as long as the compiler does not see the difference between LEGAL and NON-LEGAL code.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Addendum:
I perused the ANSI-C++ standards, and found that <stdio.h> and the other C-headers are still legal ANSI-C++, although they are listed as deprecated and are recommended against using. They will probably be phased out in the next standard; the only reason to keep them was for compatibility with ANSI-C, but ANSI-C, since C99, isn't a subset of C++. They're like <strstream>, they still exist, still are technically legal, but they've given advance warning that they will be phased out soon. So it is, until the next standard, legal, but not advisable to use.
Actually, it matters very much. Legal code is guaranteed by the standard to behave in a certain way. The functions, classes, namespaces, etc. are guaranteed to exist and behave as the standard demands. On the other hand, compiler-specific, nonstandard headers can be implemented however the implementor chooses. They are under no obligation to provide the functionality that you expect. For example, if you #include <iostream.h>, cin is not necessarily of type basic_istream<char>. Code that would work with <iostream> might fail with <iostream.h> because whomever implemented <iostream.h> didn't necessarily make it an equivalent to <iostream>.Originally posted by FromHolland
It doesn't matter as long as the compiler does not see the difference between LEGAL and NON-LEGAL code.
Last edited by Cat; 06-15-2003 at 02:56 PM.
