tags:

views:

1594

answers:

6

What are the advantages of having declarations in a .inl file? When would I need to use the same?

Thanks, Light

A: 

In my experience, .inl files are used to define inline functions. When they're in an .inl file, the file can be included in a header to get inline functions and in a .c file to get regular function definitions.

This way the same source can more easily work with compilers that do not have inline function supportas well as compilers that do.

They're usually used with straight C code, not often with C++ code as all C++ compilers support inline functions.

Michael Burr
I don't see the point in doing this just to get C support. For C, you'd just conditionally `#define inline static`, and define your inline functions in the header.
Pavel Minaev
I guess this avoids multiple copies of the same function from ending up in the binary. I'm just saying I've seen .inl files used this way, not that it's the only technique (or even best).
Michael Burr
A: 

I believe it's just a naming convention for a "header" file includes inline code. it's so that .h files can contain definitions and .inl files contain inline code which is necessary for templates.

I don't belive there is anything more to it than an naming convention to make the purpose of the file clear

John Burton
+7  A: 

.inl files are never mandatory and have no special significance to the compiler. It's just a way of structuring your code that provides a hint to the humans that might read it.

I use .inl files in two cases:

  • For definitions of inline functions.
  • For definitions of function templates.

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

I like it because it separates the interface from the implementation and makes the header file a little easier to read. If you care about the implementation details, you can open the .inl file and read it. If you don't, you don't have to.

Nick Meyer
Indeed, it's mostly about separating interface from implementation.
Pavel Minaev
I've also seen .ipp and .ixx used for inline definitions and .tpp and .txx for template one.
AProgrammer
+3  A: 

Since nobody else has mentioned it:

The use of .inl files to store your inline functions can be useful for speeding up compiles.

If you only include the declarations (.h) where you need declarations, and only include inline implementations (.inl) where you need them ( i.e. probably only in .cpp and other .inl files, not .h's ), it can have a beneficial effect on your header dependencies.

This can be a significant win on larger projects with many interacting classes.

Andy J Buchanan
+1: the world is definitely a different place when you are managing millions of lines of code and thousands of files.
gatorfax
+1  A: 

INL files are necessary when you have a dependency cycle between 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() ;
    }
} ;

There's no way you'll have it compile, including using forward declaration.

The solution is then to break down definition and implementation into two kind of header files:

  • HPP for header declaration/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() ;
}

This way, you can include whatever .INL file you need in your own source, and it will work. Now, the suffix names are not really important, only their uses.

paercebal
A: 

Thank you for your sincere responses.

Zuzu