Can you use MVAPICH2 to compile a fortran 2003 programme?
MVAPICH2 states that a) it provides its own compilers and b) it provides the mpif77 and mpif90 wrappers (which both point to e.g. /opt/mvapich2-2.3.1/bin/mpifort). I can't find any docs which help with this.
MPI implementations (MVAPICH is one of many MPI implementations) only provide wrappers around other compilers. They do not provide any "own" compilers. You can compile whichever Fortran does your compiler support.
The build of MVAPICH you download somewhere may be already compiled to be used with some specific compiler, but that does not mean MVAPICH provides that compiler. Similarly, if you buy a compiler suite, it can come with an MPI library (like MVAPICH) pre-compiled.
It is customary to call the mpif90 wrapper to compile any modern Fortran but often the difference from mpif77 is very small, if any at all. Some compilers also provide mpifort or some other wrapper name, which does not explicitly contain any Fortran standard version.
Most modern compilers you will find support most, if not all, features of Fortran 2003. It depends on the exact version you have.
Related
I have two related questions, one more theoretical for curiosity and another one asking for a possible use case.
(1) Would it be possible to compile a C++ program (using e.g., g++) but link the program with the C standard library (e.g., libc) instead of the C++ standard library (e.g., libstdc++) ? I know the C++ standard library contains the C standard library, but I am asking for a way to keep only the C library. I know it is possible to remove the standard library with the -nostdlib flag, but I would like to remove only the "C++ part" of the standard library and keep the "C part".
(2) From what I have heard, one reason why some people still use C instead of C++ is when the target system has low memory (e.g., an embedded system) where the C++ stdlib would be too big for the available memory. In this case, would replacing the C++ stdlib with the C stdlib solves the issue and allows these people to use C++ language features (namespace, more type safety, etc.) at no cost ? If it is possible, would there be downsides ? Why aren't today's C programmers doing this?
Is it possible to replace C++ standard library with C standard library when linking C++ programs?
No, it is not possible. Typically, C++ standard library is implemented on top of C interface. You have to link with both.
Would it be possible to compile the program as a C++ program (using e.g., g++) but link the program with the C standard library (e.g., libc) instead of the C++ standard library (e.g., libstdc++) ?
Not "instead", but just "without" C++ standard library. Just use gcc.
gcc file.cpp
Basically, the difference between g++ and gcc, is that g++ links with C++ standard library. Inspect gcc -v vs g++ -v verbose output.
target system has low memory (e.g., an embedded system) where the C++ stdlib would be too big for the available memory.
Specifically, std::cout (i.e. std::ostream) is heavy, because of buffering and whole support for std::iomanip stuff. And in most cases std::cout is not optimized for embedded (smaller size), like for example printf is. Exceptions are rather avoided or not used at all, because of how are they implemented - speed first, with no regard to size. In embedded, you use C++ normally. Very big MBed and Arduino are both prominent examples of C++ in bare-metal world.
would replacing the C++ stdlib with the C stdlib solves the issue and
No, C++ stdlib and C stdlib are different things.
allows these people to use C++ language features (namespace, more type safety, etc.) at no cost ?
It is not forbidden in any way.
Why aren't today's C programmers doing this?
Why aren't C++ programmers writing in Rust or Java? Most probably because they like the programming language that they like.
I want to know if it is important to know which compiler was used to compile a specific library in C++? Because I heard about ABI compatibility and I am curious to know if it does matter or not!
For example can I download binaries of OpenCV (including dlls and libs) for Windows which were compiled with MSVC and use them in another code which is compiled with MinGW?
It depends:
If a library's interface is C++-based, it will need to match the C++ ABI of the compiler the user of the library is using. This usually means that the user needs to be using the same compiler with a close version number.
If the library exposes only a "flat" C-based interface, even if it's internally written in C++, it only needs to match the C ABI of the compiler that the user of the library is using. The C ABI is usually defined by the platform and common across compilers.
Note that a "flat" interface could be "reconstituted" into a C++ class-based interface using "wrapper" classes defined in headers. In this case, as long as the library binary only exposes C-compatible functionality, it will still only be dependent on the C ABI.
Additionally as an aside, on Windows only, there is functionality called "COM" which provides a standard ABI to allow programs to use objects written using different compilers and even different languages entirely. However, COM classes are not ordinary C++ classes and their creation and use is quite different.
In the specific case of OpenCV, I've never used it but, looking at the filename of the download of the latest version "opencv-4.1.1-vc14_vc15.exe"; this indicates that it contains libraries for use with Microsoft's Visual C++ compiler versions 14 and 15 (aka Visual Studio 2015 and 2017). If you want to use it with MinGW (which uses the GCC compiler) then you'll need to get an unofficial build or compile it from source yourself.
I want to create a program with a mix of C++ and D, and I would like to be able to work on it as a single project.
My understanding is that I can use some D compiler to output *.obj files, then I can do the same with some C++ compiler, and then link all of the *.obj files into a single binary, is this correct?
If this is correct, can I use any C++ compiler with any D compiler? Or am I restricted to certain combinations like, DMD-DMC, LDC-Clang, and GDC-GCC?
Which linker do I use?
And which standard library do I use?
In theory, you could mix the compilers, but in practice you'd have object file format and standard library mixing issues from time to time, especially on 32 bit Windows. It'd be hard there, but not too bad elsewhere since most things are based on de-facto standards like MSVC and gcc.
Win32: use dmc++ (the digital mars compiler and C runtime) with dmd OR g++ and gdc. Other combinations can be done but are messy. Best way to mix code in Win32 across compiler families is to build a DLL with a C or COM api and use that from D.
Win64: Since dmd uses the 64 bit Microsoft format and C library, you should have little trouble mixing dmd with Visual C++ code. I'm not sure about g++ on Windows64 with dmd.
Most other platforms, including Linux: dmd works along well with g++, as does gdc + gcc. I'm not sure if ldc and g++ are compatible, but ldc should work fine with other LLVM based commpilers on any platform too.
What is the extent of interoperability between C++11 and a recent version of Boost (say 1.55) built with a C++11 compiler.
Does the behavior of any library feature change depending on whether I built the libraries with c++11 flags enabled or not?
How do language features like lambda functions cooperate with Boost's lambdas?
You cannot use objects built with gcc with and without -std=c++11 together. You will get link errors or even runtime crashes. I cannot vouch for other C++ implementations. So at least with gcc, you do need to build a separate version of Boost with c++11 mode enabled.
They are pretty much independent. They don't cooperate and don't interfere with each other.
EDIT I see people are still reading (and upvoting!) this answer. Point 1 is no longer true (or perhaps never was true). Versions of gcc from I think 5.1 upwards use an ABI compatible with -std=<anything> by default.
No behaviours change: at the code level Boost is compatible with both C++03 and C++11.
However, at the object level you won't be able to mix and match: if your program is compiled as C++11, and you're using some non-header Boost libraries, you will have to build those Boost libraries as C++11 as well. This is because the respective C++ runtimes of your toolchain for each version of the language cannot be guaranteed to have ABI compatibility.
What are the difference between the 3 compilers CC, gcc, g++ when compiling
C and C++ code in terms of assembly
code generation, available libraries, language features, etc.?
The answer to this is platform-specific; what happens on Linux is different from what happens on Solaris, for example.
The easy part (because it is not platform-specific) is the separation of 'gcc' and 'g++':
gcc is the GNU C Compiler from the GCC (GNU Compiler Collection).
g++ is the GNU C++ Compiler from the GCC.
The hard part, because it is platform-specific, is the meaning of 'CC' (and 'cc').
On Solaris, CC is normally the name of the Sun C++ compiler.
On Solaris, cc is normally the name of the Sun C compiler.
On Linux, if it exists, CC is probably a link to g++.
On Linux, cc is a link to gcc.
However, even on Solaris, it could be that cc is the old BSD-based C compiler from /usr/ucb. In practice, that usually isn't installed and there's just a stub that fails, wreaking havoc on those who try to compile and install self-configuring software.
On HP-UX, the default 'cc' is still a K&R-only C compiler installed to permit relinking of the kernel when necessary, and unusable for modern software work because it doesn't support standard C. You have to use alternative compiler names ('acc' IIRC). Similarly, on AIX, the system C compiler goes by names such as 'xlc' or 'xlc32'.
Classically, the default system compiler was called 'cc' and self-configuring software falls back on that name when it doesn't know what else to use.
POSIX attempted to legislate its way around this by requiring the programs c89 (originally) and later c99 to exist; these are the compilers compatible with the ISO/IEC 9899:1989 and 9899:1999 C standards. It is doubtful that POSIX succeeded.
The question asks about the differences in terms of features and libraries. As before, the answer is platform specific in part, and generic in part.
The big divide is between the C compilers and the C++ compilers. The C++ compilers will accept C++ programs and will not compile arbitrary C programs. (Although it is possible to write C in a subset that is also understood by C++, many C programs are not valid C++ programs). Similarly, the C compilers will accept C programs and will reject most C++ programs (because most C++ programs use constructs not available in C).
The set of libraries available for use depends on the language. C++ programs can usually use C libraries on a given platform; C programs cannot usually use C++ libraries. So, C++ has a larger set of libraries available.
Note that if you are on Solaris, the object code produced by CC is not compatible with the object code produced by g++ -- they are two separate compilers with separate conventions for things such as exception handling and name mangling (and the name mangling is deliberately different to ensure that incompatible object files are not linked together!). This means that if you want to use a library compiled with CC, you must compile your whole program with CC. It also means that if you want to use one library compiled with CC and another compiled with g++, you are out of luck. You have to recompile one of the libraries at least.
In terms of quality of assembler generated, the GCC (GNU Compiler Collection) does a very good job. But sometimes the native compilers work a bit better. The Intel compilers have more extensive optimizations that have not yet been replicated in GCC, I believe. But any such pontifications are hazardous while we do not know what platform you are concerned with.
In terms of language features, the compilers all generally hew fairly close to the current standards (C++98, C++2003, C99), but there are usually small differences between the standard language and the language supported by the compiler. The older C89 standard support is essentially the same (and complete) for all C compilers. There are differences in the darker corners of the language. You need to understand 'undefined behaviour', 'system defined behaviour' and 'unspecified behaviour'; if you invoke undefined behaviour, you will get different results at different times. There are also many options (especially with the GCC) to tweak the behaviour of the compiler. The GCC has a variety of extensions that make life simpler if you know you are only targetting that compiler family.
CC is an environment variable referring to the system's C compiler. What it points to (libraries accessible, etc) depend on platform. Often it will point to /usr/bin/cc, the actual c complier (driver). On linux platforms, CC almost always points to /usr/bin/gcc.
gcc is the driver binary for the GNU compiler collection. It can compile C, C++, and possibly other languages; it determines the language by the file extension.
g++ is a driver binary like gcc, but with a few special options set for compiling C++. Notably (in my experience), g++ will link libstdc++ by default, while gcc won't.
I wanna add just one information what cc in Linux. It is linked with gcc. To check it.
Similarly, the same thing with c++.
uddhavpgautam#UbuntuServer1604:~/Desktop/c++$ whereis c++
c++: /usr/bin/c++ /usr/include/c++ /usr/share/man/man1/c++.1.gz
uddhavpgautam#UbuntuServer1604:~/Desktop/c++$ ls -l /usr/bin/c++
lrwxrwxrwx 1 root root 21 Jul 31 14:00 /usr/bin/c++ -> /etc/alternatives/c++
uddhavpgautam#UbuntuServer1604:~/Desktop/c++$ ls -l /etc/alternatives/c++
lrwxrwxrwx 1 root root 12 Jul 31 14:00 /etc/alternatives/c++ -> /usr/bin/g++