Apologies if this is too naive or obvious but after a fair bit of searching around, I'm not 100% sure that I understand the fortran/unix interface. My uncertainty is regarding the nature of .src, .f, then .o, and .out files that you run into when compiling fortran programs into a unix executable. It's tough to google file extensions like this. But if you could tell me if I've got this straight, I'd really appreciate it!
.src is the source file which contains the meaty fortran code
.f is the 'host-language specific include file' that tells your fortran compiler a little bit about the source code. It's sometimes interactive.
--- After you've obtained .o or .out files, can throw away the .src and .f files, yeah?
.o is the binary object file that results from compiling but not linking the fortran .f and .src files. It contains the same meat but now converted into machine-specific instructions?
.out is the linked object file(s) which is executable and remains dependent on the .o file(s) and is machine-specific. The .out file extension is not really needed and is often omitted?
I think that covers it. Thanks for any corrects or further descriptions.
Kyle
Nothing about these file extensions is set in stone; as you said, they can even be omitted, or you can make up your own. However, it makes life far easier if you use the conventional ones.
I've never seen the .src extension. The directory where the source files are located is often referred to as ./src; maybe you've seen this.
Usually, the source code (plain text) is in a file with extension .f or .f90. The first one indicates fixed source form ("old style"), and the second one free source form ("modern"). Some compilers interpret uppercase file extensions (.F and .F90) as an indication that the source has to be run through the preprocessor first. Instead of letting the compiler use the extensions for these interpretations, all this can also be explicitly stated/overruled by passing flags to the compiler.
Compilation of the source code produces object code (the machine-specific instructions you mention), contained in an object file, usually with .o as extension (sometimes .obj, or other).
After creating the object files, you could indeed throw away your source code files, but you don't want to do that. You want to fix any bugs you most likely made, and also keep them for future alterations to your program.
The object code has to be linked to produce the final executable. If you have more than one object file, they are tied together, with inclusion of any system/external library code you referred to. On Unix, if you don't specify a name for the executable, the default name it gets is usually a.out. Again, you can overrule this by passing an argument to the compiler.
No, the Fortran code is usually in .f or .f90 files. In more detail, Fortran source code usually has the extension .f if it uses the fixed source form (the standard source form of Fortran 77 and earlier versions) or .f90 it uses free source form (present from Fortran 90 on).
After you've obtained .o or .out files, can throw away the .src and .f files, yeah?
No. As an addendum to the answers describing the various suffix conventions, I advise that you don't delete the Fortran source files (the .src or .f files in your description). You'll need these files if you ever want to modify the program, or if you need to investigate and fix errors you notice from running the executable file (a.out).
Related
I have 2 questions about c++ precompiled-headers feature.
1.What actually is happening when you make a .gch file (using GCC), what it contains ?
2.Why those files are so huge in size , but the final executable is so small.
When you precompile a header, it all begins like an usual compilation:
The preprocessor is run, including any dependent headers and performing macro substitution
The resulting source code is hander over to the compiler, which parses it and validates the syntax
Then the compiler produces the AST, the data structure which encodes the semantics of the code
Usually, this is done on .cpp files, and goes on afterwards to actually compile the AST and generate executable code. However, a header precompilation stops there, and the compiler dumps the AST inside the .gch file.
On further uses of this precompiled header, the compiler can then directly load the AST back from file and pick it up from there, skipping the costly processing listed above.
The .gch file is huge, because it contains a lot of information that was implicit in the original header. But it has no relation to the size of the final executable -- compiling with and without precompiled headers should produce the exact same result.
How do compilers know when it is not necessary to recompile certain parts of code especially in larger projects?
For example, let's say in C++ we have two C++ files and two header files. The header files depend on one another. (They use the classes specified in each others files.)
Does a compiler always need to parse both header files, (and maybe C++ files for method implementation,) to obtain the class information in order to generate either of the two C++ files?
I always thought that when you run the compiler at the command prompt, it closes immediately after outputting the object files - so it would be impossible to cache the Abstract Syntax Trees or intermediate code. Do most C++ compilers know when a certain file doesn't need to output to an object file, and is therefore skipped?
All of the compilers I know compile every source file they're
told to. Always. And they generate a new version of the object
file for every source file they compile.
Only compiling what is necessary is a job generally left to the
build system (make or other). Knowing which objects need to be
regenerated depend on what each source file includes, directly
or indirectly; most compilers have options to output this
information in some format, either on the fly or as a separate
invocation, and the build systems (the usable ones, at least)
use this information to determine dependencies.
As said above, compilers will compiler every file that it is asked to compile. It is up to tools like make to decide what needs to be compiled.
In make one sets up rules. Each rule has a target, list of dependencies followed by the commands to run if those dependencies are not met. For example
target.o : target.c
gcc -c -o target.o target.c
On most file systems, each file has a timestamp. If target.o has a newer timestamp than target.c (the rule dependency) then make does not run the gcc command below. This is because one firsts edits a source file and then compiles the source file into an object file.
If however the dependent source file is newer than the target, then we know the source file was edited after the compile took place and another compile is in order. make will therefore execute the build command for the rule.
It gets a lot more complex when rules are dependent on other rules but the same principle applies.
I don't know how they (don't) implement it (because many don't... Don't ask me why) but I'm quite sure it would be VERY easy. You save in the intermediate (obj) file the name and the hash of the source file and of every dependent file you are compiling, together with the compilation options that are being used, the hash of the compiler (or its internal version) and the compilation result (ok/error). Next time the user tries to recompile the file, the compiler checks if there is already the intermediate file, checks if all the hashes are the same, if the compilation options are the same and if the compiler is the same... If everything is the same, it gives the pre-saved error message and exits without doing anything.
The intermediate files would be a little bigger (probably some kb each).
I was reading on Clang and Ch (c++ interpreters), but its not clear for me, is it possible to run a newly generated .cpp file without any installations? Because i need to run the final program on any pc...
ps. if yes, does anyone have a good example, where a .cpp file is being executed within c++ code?
This is probably impossible or at least very hard. You would have to include the whole compiler (including linker, assembler, optimizer, preprocessor, ...) inside your program and that would make it extremely big.
One way of doing this is with Clang (as you already noted), there is even a demo project called "Clang interpreter" in the source: http://llvm.org/viewvc/llvm-project/cfe/trunk/examples/clang-interpreter/
However I once tried to compile this "beast" into my program and gave up halfway, because the file size of the result binary (or binaries with external libraries) gets into tens of megabytes (maybe even a hundred).
My suggestion is to either produce a different script (e.g. bash/sh script, which you could execute on any unix machine) that can be interpreted easily.
As far as I know, it is impossible, because compilation process of a CPP file is like this-
Preprocessing: the preprocessor takes a C++ source code file and deals with the #includes, #defines and other preprocessor directives. The output of this step is a "pure" C++ file without pre-processor directives.
Compilation: the compiler takes the pre-processor's output and produces an object file from it.
Linking: the linker takes the object files produced by the compiler and produces either a library or an executable file.
So, there should be intermediate files and executable files.
More can be found here-
https://stackoverflow.com/a/6264256/7725220
Kind of depends on what you mean by "installations".
Yes you can distribute your program with a full compiler, compile the source code and then execute the final result (all from the original exe).
I just started a graphical C++ course and I have problem getting an overview how it is.
we got some starting code, two files; one of type "C++ Source" and another of "C/C++ Header".
its supposed to be a graphical program which fills the screen with color.
also, we are using some custom libraries such as SDL and GLM, in the same folder as those two files there is a folder named gml and loads of subfolders, which I wont get into.
I have downloaded mingw, cmake and Visual Studio 11 beta for c++.
I've tried making a normal Win32 program and also a forms-application for the graphical part, but its always something wrong when compiling.
My question: how are you supposed to handle C++ files? I just got used to java and there its so easy to just open the .java file and paste into your IDE, dealing with C++ makes me really confused.
Hmm... Where to begin...
Somethings that happen behind the scenes in other languages are much more visible in C++. The process of obtaining a binary (say, an executable) from C++ involves first compiling the source code (There are sub-steps of this but the compiler handles them) to obtain object files, then the object files are linked by the linker to generate a binary.
In theory, you could simply #include all the cpp files in a project, and compile them all together and "link" (although there's nothing to link) but that would take a very long time, and more importantly, in complex projects that could deplete the memory available to your compiler.
So, we split our projects into compilation units, and by convention a .cpp file represents a single compilation unit. A compilation unit is the part of your project that gets compiled to generate one object file. Even though compilation units are compiled separately, some code has to be common among them, so that the piece of code in each of them can use the functionalities implemented by the others. .h files conventionally serve this purpose. Things are basically declared (sort of announced) in them, so that each compilation unit knows what to expect when it's a part of a linking process to generate a binary.
There's also the issue with libraries. You can find mainly two kinds of things in libraries;
Already implemented functionality, shipped to you in the form of binary files including CPU instructions that can almost be run (but they've to be inserted in the right place). This form is accompanied by .h files to let your .cpp files know what to expect in the library.
The second type is functionality implemented directly in the .h
files. Yes, this is possible under special cases. There are cases,
where the implementation has to (a weak has to) accompany the
declaration (inlined functions, templated types etc.).
The first type comes in two flavors: A "static library" (.lib in windows, .a in linux), that enters your executable and becomes a part of it during linking, and a "dynamic library", that is exposed to your binary (so it knows about it) but that doesn't become a part of it. So, your executable will be looking for that dynamic library (.dll files in windows and .so files in linux f.x.) while it's run.
So, in order for your .cpp files to be able to receive services from libraries, they have to #include their .h files, to know about what there is in them. Later on, during linking, you have to show the linker where (what path in the file system) to find the binary components of those libraries. Finally, if the library is dynamic, the .dll's (or .so's etc.) must be accessible during run time (keep them in the same folder for instance).
While compiling your compilation units you have to tell the compiler where to find the .h files. Otherwise, all it will see will be #include <something.h> and it won't know where to find that file. with gcc, you tell the compiler with the -I option. Note that, you just tell the folder. Also of importance is that if the include directive looks like #include<somefolder/somefile.h> you shouldn't include somefolder in the path. So the invocation looks like:
g++ mycompilationunit.cpp -IPATH/TO/THE/INCLUDED/FILES -IPATH/TO/OTHER/INCLUDED/FILES -c
The -c option tells the compiler that it shouldn't attempt to make an executable just from this compilation unit, so it creates a .o file, to be linked with others later. Since we don't tell it the output file name, it spits out mycompilationunit.o.
Now we want to generate our binary (you probably want an executable, but you could also want to create a library of yours). So we have to tell the linker everything that goes into the binary. All the object files and all the static and dynamic libraries. So, we say: (Note g++ here also acts as the linker)
g++ objectfile1.o objectfile2.o objectfile3.o -LPATH/TO/LIBRARY/BINARIES -llibrary1 -llibrary2 -o myexecutable
Here, -L option is self explanatory in the example. -l option tells which binaries to look for. The linker will accept both static and dynamic libraries if it finds them on the path, and if it finds both, it'll choose one. Note that what goes after -l is not the full binary name. For instance in linux library names take the form liblibrary.so.0 but they're referred to as -llibrary in the linker command. finally -o tells the compiler what name to give to your executable. You need some other options to f.x. create a dynamic library, but you probably don't need to know about them now.
What is the difference between a .cpp file and a .h file?
Look at this answer. Also a quick google search explains a bit too.
Pretty much .h (header) files are declerations and .cpp (source) files are definitions. It is possible to combine both files into one .cpp file but as projects get bigger and bigger its becomes annoying and almost unreasonable.
Hope that helps.
In C++ there is a notion of a function declaration (the function signature) and a function definition (the actual code).
A header file (*.h) contains the declarations of functions and classes. A source file (*.cpp, *.c++, *.C) contains the definitions.
A header file can be included in a source file using #include directive.
When you define a class in C++, you typically only include the declarations of the member functions (methods in Java lingo), and you put the class definition into a header file. The member function definitions containing the body of each function are typically put outside the class definition and into the source file.
Generally the best thing to do here is to get a book on C++ or C, and to look at some sample code.
Header files (.h) are supposed to contain definitions of classes, methods, and variables. Source file (.cpp) will contain the code. So in your .cpp file you need to include the header file as #include "header-file-name.h".
Then use g++ to compile the .cpp file. Make sure that the path to .h file is correct.
If you are using CodeBlocks or Visual Studio, then just compiling the project and running will do everything for you. You can also add .h or .cpp file from there. You need not worry about anything.
Hope this helps.
If you have a c++ project with several source files and you hit compile, which file does the compiler start with?
I am asking cause I am having some #include-dependency issues on a library.
Compiler would be: VC2003.
It should not be order-dependent. The only relevant steps are:
Each compilation unit includes what it depends on, and should be compilable individually. This means, first, that each CPP file includes all the headers it depends on; and second, that each header should in turn include what it needs so that it can compile even if it is the first one to be compiled.
A link step puts all the compiled object code together and builds the final binary.
It should not matter which file it starts with, the linker resolves external references after all the files have been compiled
Irrelevant. Post the exact issue. The compilation order is non-deterministic and arbitrary, and must have no effect on the compilability of your project.
This depends on the environment. In general a "compiler" only works on a single source file at a time; you use higher-level tools to direct it and compute the proper build order.
Examples of such tools can be make, ant, CMake, SCons, Eclipse, and Visual Studio. A basic check is generally the modification date of the source code files, coupled with built-in and custom rules that define how various output files depend on the inputs.
The order the compiler compiles in shouldn't make a difference, as others have noted.
From the compiler's point of view, when you compile a file with a #include, the included file is inserted into the file being compiled at the point where the #include is, recursing as necessary.
Others have already said that the order shouldn't make a difference.
What you might not have realized is that the compiler compiles every .cpp or .cc file. It does not compile header files. And typically, you only #include header files, and never .cpp files, so the order does not matter. Every .cpp file is processed in isolation. It includes a number of headers, but these are never compiled separately, and it does not typically include other .cpp files either.
The only "include-dependency" problem I can think of is a recursive inclusion. For which the fix normally is guarding it with #ifdef
#ifndef INCLUDED_THEFILENAME_H
#define INCLUDED_THEFILENAME_H
/* content goes here *
#endif
But you better elaborate on the issue you're having.
As others have pointed out, conceptually it is not important which file it starts with. However, it can be useful to start with the most recently edited file (assuming more than one file has been edited) of with the file with the most dependencies. Some environments, such as Code::Blocks, actually allow you to give weightings to source files to give you some control over the compilation order.
A make tool builds a directed acyclic graph of the dependencies specified in the make file. This will normally say the executable depends on a number of object files. The object files depends on source files, each source file depends on headers, and so on.
This produces essentially a multi-way tree. The tree will have the executable as its root, and typically have mostly headers as the leaf nodes (though if you're using some sort of code generator, it could also have the input file for that code generator as a leaf).
It then walks that tree working its way from the leaf nodes to the root node and building as it goes. The answers that have said "it doesn't matter" are basically pointing out that it can pick any branch of that tree to build first. It does matter, however, that when it picks a branch, it builds in the order specified for that branch.