Why low-level libraries uses C ?
 

why not C++? For example XLib, XCB.
C++ libraries will difficult to link with next level libraries?

Because C++ is a higher level library than C, and has a lot more overhead when compiling/running.

... and of course, C came first.

In fact the Unix OS (& derivatives) & most DBs and higher level langs are written in C.
Therefore the libs can be used by the max number of programs.

Either language can be used, and both have been. There are some libraries that are written in FORTRAN.

C++ is handy, but how C++ libraries can be used by other programs? Especially inline, templates, name mangling, virtual methods.

If a component (library) is written in C++, its caller has to be written in C++, too. On the other hand, C components can be called from C++ without problems.

C was here first, it was invented to write Unix, so Unix is C.
C it has a standard ABI in opposite for example to C++.
it is relatively easy to include into other languages, in opposite to say C++, which is complex.
in the Unix world C is the lingua franca, you cann connect different programming languages via C interfaces.

Microsoft on the other hand does not even have a real C compiler, there you write your drivers with C++ base on a unbelievable ugly old style Cish interface.

If Microsoft didn't have a C-compiler, how could they compile Windows?

with the compiler they have, since C is a valid subset of C++ (99.9%), they can compile their C like code with their compilers. Thought, I think they have 2 different runtime libraries to link again. And maybe there is a old compiler, but I do not thing anyone uses this, if you compile python ruby whatever on MS they want MSVC


http://herbsutter.com/2012/05/03/rea...ut-vc-and-c99/
there is no problem with this, Haiku OS is an other example where the kernel is written in C++.
why should this be a problem?

(I have to admit that in Windows I use either BCC4.52 (16-bit) or BCC55 (32-bit) or mingw-gcc (64-bit).)

Different parts of Microsoft's total software system are obviously written in many different languages.

"C" is ordinarily used in operating-system code because languages like "C++" rely upon services provided by runtime libraries which only exist "in user-land." In this context, "C" is being used as "one small step up from assembler," and in fact is often intermingled with assembler-code sections. (The "trampoline" code in the /arch directory of the Linux source library is an excellent example of this. Some of the files there are pure-assembler files.)

Higher-level languages are used whenever possible, and when a legacy source-code base that was originally started in "C" does not exist. That's because, well, "because the language system is doing more of the niggling detail-work for you," and, "that's what digital computers are for!" :)

There's little difference in the actual object-code that is generated. In the gcc compiler suite, most of the back-end code generation code does not care what source-code language was originally used. It's working with an intermediate representation that is more or less source-language agnostic.

"C" is the hardware interface language. It's not about catering to the upward needs of the software stack. It's about talking to hardware in a predictable way. It's at this level almost all algorithms need to be checked for efficiency, be the efficiency in power, performance, or heat generation. For every run of your program's main loop, no-ops can happen low in the system millions of times. Hence why they calculus is still required for "Computer Systems Engineering", even though it's typically unnecessary for what most of us would consider programming.

Here is a video of Linus Torvalds discussing just this subject at a Q&A.

Knowing the language can help you a lot. However, writing everyday programs in C is typically unnecessary, or even dangerous if you were to publish code you are unwilling or unable to check for unsafe practices. For that reason, lots of people like to complain about the language's lack of exception handling. The reality is that it is simply not supposed to be there. Handling exceptions creates lots of overhead at the assembly level. It's the high-level application developers job to check input before passing it to some part of the system. I mean, if you're the one asking for input, it's not the libc developer's job to make sure it's well formed before trying to operate on the data, it's yours.