Quote:
Originally Posted by JMJ_coder
So it is more important to include the .h than to nitpick about < > and " " - at least to ensure the program will compile in 5 years regardless of standard committee politics.
|
I cant tell if by include you mean
#include the preprocessing directive or include the english word. In any case, it is recommended use standard header files
without
.h (because in 5 years time, a program using antiquated headers may no longer be valid).
The reason why
<> vs.
"" is less important is because the search paths and methods of file identification are left to be defined by the implementation (§16.2, clauses 2 and 3). As such, you can find extensive information in the
g++ documentation regarding the differences between the command-line switches
-I,
-I-,
-idirafter,
-iprefix ,
-iwithprefix,
-iwithprefixbefore,
-isystem, and
-iquote. Additionally, if a search for a file happens to fail when using
"", the fallback is to search for the file as if it had been with
<> (which is specified in §16.2, clause 3). By convention all files in places like
/usr/include,
/usr/local/include, or
/usr/lib/gcc/${ARCH}/${GCC_VERSION}/include (i.e., system include dirs) are searched for by
<>. With
"", all files in the same directory as the translation unit are searched (of course the other directories are a fallback).
I hope thats not too much language-legalese.
Quote:
Originally Posted by JMJ_coder
When I tried the Hello World program with the stdio library, it didn't like it at all. I had to change the program to have C syntax. In that context, all this means is that the C++ compiler can compile C programs. I suppose that one can mix and match C and C++ syntax, which is usually, from what I can tell so far, fairly similar - but there are some differences (i.e. cout vs. printf). So at the very least, this seems like it could get very confusing and be in poor programming style.
Or am I missing something?
|
The difference is not really in the syntax, but in what each header provides:
When you
#include <stdio.h> (or even
#include <cstdio> and use
namespace std), what you get is a defined type for interacting with a unique stream (i.e.,
FILE), a bunch of prototypes for for certain functions that may use such objects (e.g.,
printf(),
fprintf(),
fopen(), etc.), and certain external variables which are instances of pointers to that type (e.g.,
stdin,
stdout, and
stderr), with the guarantee that those functions and variables will be available during linking (to the standard library).
When you
#include <iostream>, what you get is a bunch of defined classes (e.g.,
ios,
istream,
ostream, etc.), member function prototypes for said classes (e.g.,
istream:
perator>>(),
ostream:perator<<(), etc.), and certain external variables which are instances of said classes (e.g.,
cin,
cout, and
cerr), with the guarantee that those classes (including their member functions) and variable instances will be available during linking (to the standard library).
So the syntax is necessarily different because the overall API is different.
There is, however, something else meant by the possibility to to interchange the libraries between C and C++. It has to do with the differences between linking C object files to C++ object files. For example, assume I have two files:
foo.c (a file which could be C or C++) and
bar.cc (a C++ file).
foo.c is as follows:
Code:
int foo(int a, int b)
{
return a+b;
}
And
bar.cc is as follows:
Code:
#include <iostream>
extern int foo(int,int);
using std::cin;
using std::cout;
int main(int argc, char *argv[]) {
int num1, num2, result;
cout << "Enter num1: ";
cin >> num1;
cout << "Enter num2: ";
cin >> num2;
result = foo(num1, num2);
cout << "Result is: " << result << "\n";
return 0;
}
If I compile them like this:
Code:
$ g++ -c foo.c
$ g++ -c bar.cc
$ g++ -o foobar foo.o bar.o
It all works out. However, suppose foo.c has been compiled as a C program (after all, the source is compatible with C or C++). Then, you get this:
Code:
$ gcc -c foo.c
$ g++ -c bar.cc
$ g++ -o foobar foo.o bar.o
bar.o: In function `main':
bar.cc:(.text+0xbc): undefined reference to `foo(int, int)'
collect2: ld returned 1 exit status
We can remedy this situation, by changing the third line of bar.cc to this:
Code:
extern "C" int foo(int,int);
and recompile for it to work this way. So any function that from an external object file which uses the C calling convention must be specified as such. This is very common for libraries (because there is no portable way to use the C++ calling convention from C). Many libraries (which dont make use of any C++ features) are written and compiled in C. To use any of their functions, you have to explicitly state that the function uses the C calling convention. This way, the library itself will get the maximum exposure, since both C and C++ programmers will use its functions. Luckily most such libraries provide sane header files for prototyping their functions. In this case, the preprocessor checks to see if youre compiling C++. If so, the entire header (or at least the functions) are armored with
extern "C". On headers where the author did not think of this, you may do it yourself, by armoring your entire include with
extern "C". E.g.,
Code:
#include <iostream>
#include <SaneCLibrary.h>
extern "C" {
#include <InsaneCLibrary.h>
}
