extern "C" block

[varun]

Don't we have to include headers in extern "C" block to prevent mangling of function names if i am using a c++ compiler
(http://wiki.osdev.org/Meaty_Skeleton)

#ifndef _KERNEL_TTY_H
#define _KERNEL_TTY_H

#include <stddef.h>

void terminal_initialize(void);
void terminal_putchar(char c);
void terminal_write(const char* data, size_t size);
void terminal_writestring(const char* data);

#endif

[Techel]

Compile C with a C-Compiler and C++ with a C++-Compiler.

[Schol-R-LEA]

Given that Meaty Skeleton is written with GCC in mind, I will (unless you say otherwise) assume you are using GCC.

The thing to remember is that GCC is not a single compiler, but a framework for writing and using compilers. The C and C++ compilers are included in the default installation, but there are front-ends for several different languages built on that framework; the gcc program which is invoked in the shell is not itself one of the compilers, but is rather a default front end for running the C compiler and gas assembler, and if used to build an executable, will use ld to link the object files to each other, and to the standard C library unless an explicit option disables that feature.

Note that this means whenever you use GCC, it will link to the C library - even when used for a different language. While the gcc front-end is smart enough to detect at least certain languages by the source file's extension, and will use that language's compiler, it won't change libraries, as it is assuming that the main program (that is, the object file with the loader preamble and the code entry point) is going to be in C regardless of the language of the source files. To link to a different language's libraries, you would need to explicitly include them in the linking instructions. It also will only recognize the compiling and linking options that are appropriate for C programs; the language-specific options for other languages aren't accessible from it.

For this reason, each installed language is given it's own invocable front end, which then calls the compiler proper, links the object files with that language's library, and provides language-specific options. For C++, the front-end is g++; for D, it is gdc; for Objective-C, gobjc; Ada, gnat; Fortran, gfortran; Pascal, gpc; Go, gnugo; Rust, gccrs; Common Lisp, gcl (though it is a bit different, in that it defaults to opening a REPL, which invokes the compiler in compile-and-go mode - it can be used to compile at the command line, but it assumes you want the Lisp Listener); Java, gcj; and so forth. The default installation includes C, C++, Objective-C, Fortran, Ada, and Go; all the others need to be installed separately.

It is strongly recommended that you use the appropriate front-end based on the language in question, and when using mixed code, you really would be better off using a Makefile and an explicit linkage script (as Meaty Skeleton does), rather than running the front-end from the shell manually, to ensure that it does what you want it to consistently.

To quote the GCC manual:

C++ source files conventionally use one of the suffixes ‘.C’, ‘.cc’, ‘.cpp’, ‘.CPP’, ‘.c++’, ‘.cp’, or ‘.cxx’; C++ header files often use ‘.hh’, ‘.hpp’, ‘.H’, or (for shared template code) ‘.tcc’; and preprocessed C++ files use the suffix ‘.ii’. GCC recognizes files with these names and compiles them as C++ programs even if you call the compiler the same way as for compiling C programs (usually with the name gcc).

However, the use of gcc does not add the C++ library. g++ is a program that calls GCC and automatically specifies linking against the C++ library. It treats ‘.c’, ‘.h’ and ‘.i’ files as C++ source files instead of C source files unless -x is used. This program is also useful when precompiling a C header file with a ‘.h’ extension for use in C++ compilations. On many systems, g++ is also installed with the name c++.

When you compile C++ programs, you may specify many of the same command-line options that you use for compiling programs in any language; or command-line options meaningful for C and related languages; or options that are meaningful only for C++ programs. See Options Controlling C Dialect, for explanations of options for languages related to C. See Options Controlling C++ Dialect, for explanations of options that are meaningful only for C++ programs.

Now, regarding Meaty Skeleton, if you look at the config.sh shell script, you will see that it exports the environment variable CC, which it defines as... gcc. Not the C++ compiler, but the C compiler.

So the practical upshot of all of this is, no, you don't need to use extern "C", because it is in fact using the C compiler, not the C++ compiler. If you do end up using any C++ code, then yes, you would need extern "C" in that code when calling something written in C, but the libc and libk headers are exactly what they ought to be otherwise. Since the headers used by C++ shouldn't be the same as the C headers anyway (given that C++ is not a strict superset of C, and the C++ library isn't one for the C library either, which means that trying to use C headers in C++ code can give unpredictable results in a handful of edge cases), you would simply create separate C++ headers for that, or else add a bunch of ugly conditional compilation switches if you really insist on have one set of headers for both.

[Geri]

in short: extern c will keep function and symbol names in compatible ways by the compiler, so if you make a library then it will stay usable widely,