The value of the .inl file in C ++

What are the benefits of having ads in a .inl file? When will I need to use the same?

+89
c ++
Jul 30 '09 at 17:17
source share
5 answers

.inl files are never mandatory and have no special meaning to the compiler. This is just a way to structure your code, which gives a hint to people who might read it.

I use .inl files in two cases:

  • To define built-in functions.
  • To define function templates.

In both cases, I put the function declarations in the header file, which is included in other files, then I #include .inl file at the bottom of the header file.

I like it because it separates the interface from the implementation and makes it easier to read the header file. If you care about implementation details, you can open the .inl file and read it. If you do not, you do not need.

+113
Jul 30 '09 at 17:21
source share

Nick Meyer is right: the compiler doesn't care about the file extension you include, so things like ".h", ".hpp" .hxx ",". Hh ",". Inl ",". Inc ", etc. e. is a simple convention to make it clear which files should contain.

The best examples are STL header files that do not have an extension.

Typically, β€œ.inl” files contain inline code (hence the extension β€œ.inl”).

These ".inl" files are needed if you have a dependency loop between the header code.

For example:

 // A.hpp struct A { void doSomethingElse() { // Etc. } void doSomething(B & b) { b.doSomethingElse() ; } } ; 

and

 // B.hpp struct B { void doSomethingElse() { // Etc. } void doSomething(A & a) { a.doSomethingElse() ; } } ; 

It is not possible to compile it, including using a forward declaration.

The solution is to break up the definition and implementation into two kinds of header files:

  • hpp for declaration / header definition
  • inl for header implementation

which breaks down into the following example:

 // A.hpp struct B ; struct A { void doSomethingElse() ; void doSomething(B & b) ; } ; 

and

 // A.inl #include <A.hpp> #include <B.hpp> inline void A::doSomethingElse() { // Etc. } inline void A::doSomething(B & b) { b.doSomethingElse() ; } 

and

 // B.hpp struct A ; struct B { void doSomethingElse() ; void doSomething(A & a) ; } ; 

and

 // B.INL #include <B.hpp> #include <A.hpp> inline void B::doSomethingElse() { // Etc. } inline void B::doSomething(A & a) { a.doSomethingElse() ; } 

That way you can include any ".inl" file that you need in your own source, and it will work.

Again, the suffix names of the included files are not very important, only their use.

+72
Aug 15 '09 at 9:29
source share

Since no one has mentioned this yet:

Using .INL files to store your built-in functions can be useful to speed up compilation.

If you include declarations (.h) where you need declarations, and include only built-in implementations (.inl) where you need them (i.e. probably only in .cpp and other .INL files, not .h) , this can have a positive effect on the dependencies of your title.

This can be a significant victory in large projects with many interacting classes.

+28
Jul 30 '09 at 19:51
source share

In my experience, INI files are used to define built-in functions. When they are in the .inl file, the file can be included in the header to get built-in functions and in the .c file to get regular function definitions.

Thus, the same source can work more easily with compilers that do not have built-in support functions, as well as with compilers.

They are usually used with direct C code, and not often with C ++ code, since all C ++ compilers support built-in functions.

+3
Jul 30 '09 at 17:19
source share

I believe that just the naming convention for the header file includes inline code. this is so that .h files can contain definitions, and .inl files contain the built-in code needed for templates.

I do not believe there is anything more to this than a naming convention to clear the file

+1
Jul 30 '09 at 17:21
source share



All Articles