Extension .inl

Is it fairly well accepted for the implementation file of a library class or
function template to have a .inl (for inline) extension? Example:

my_library.h:
template <class T>
class problem_solver
{
public:
int solve(const T &problem);
};

#include "my_library.inl"

my_library.inl:
template <class T>
int problem_solver<T>::solve(const T &problem)
{
....
}


Obviously, I could put the implementation directly in the header file. But
in the case where one wants to separate the implementation from the
interface (usually a good idea!), is .inl commonly accepted? I've seen it a
few places and somewhere along the line I picked it up myself (I don't
remember where), but I would like to find out to what extent it is common
practice.

re: Extension .inl

"Dave" <better_cs_now@yahoo.com> wrote in message
news:10b0d0t24d27v4d@news.supernews.com[color=blue]
> Is it fairly well accepted for the implementation file of a library
> class or function template to have a .inl (for inline) extension?
> Example:
>
> my_library.h:
> template <class T>
> class problem_solver
> {
> public:
> int solve(const T &problem);
> };
>
> #include "my_library.inl"
>
> my_library.inl:
> template <class T>
> int problem_solver<T>::solve(const T &problem)
> {
> ...
> }
>
>
> Obviously, I could put the implementation directly in the header
> file. But in the case where one wants to separate the implementation
> from the interface (usually a good idea!), is .inl commonly accepted?
> I've seen it a few places and somewhere along the line I picked it up
> myself (I don't remember where), but I would like to find out to what
> extent it is common practice.[/color]


Microsoft uses it for its MFC and ATL libraries. This alone is about enough
to make it qualify as "common practice".


--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)