Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)
From: Felix I. Wyss (felixw_at_inin.com)
Date: 03/16/05
- Next message: Larry Brasfield: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- Previous message: William DePalo [MVP VC++]: "Re: System.Xml.Schema in VC++ 6.0"
- In reply to: Larry Brasfield: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- Next in thread: Larry Brasfield: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- Reply: Larry Brasfield: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- Reply: Carl Daniel [VC++ MVP]: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 15 Mar 2005 19:44:38 -0500
> First, the 'inline' keyword is strictly an advisory to the
> compiler. There is no requirement in the C++ standard
> that the compiler inline whatever is so marked, nor is
> the compiler precluded from inlining code not so marked.
Yes, I know. However, you're missing the point! Semantically, the
following
two are equivalent (see C++ standard: 7.1.2-3, 9.3-2, and 9.3-3):
template<typename T>
class Foo
{
public:
T foo(void) const
{
return m_value;
}
T m_value;
};
template<typename T>
class Foo
{
public:
T foo(void) const;
T m_value;
};
template<typename T>
inline T Foo<T>::foo(void) const
{
return m_value;
}
The fact that the VC compiler treats them differently in some cases must be
considered a bug.
> One might make an argument (albeit a complex one)
> that this is a quality of implementation issue. I will
> take the side of the compiler implementers on this one.
Why? If you are taking the side of the implementer, you have to believe
that there is a rationale for treating these two cases differently. This
not
only violates the C++ standard but also the principle of least surprise.
> Why would you use a DLL if it was not supposed to
> be interchangable with newer versions or (in the case
> of plugin architectures) a different implementation?
> Inlined code from class methods is first and foremost
> an implementation detail that is exposed only for the
> sake of execution efficiency. DLL's are primarily
> motivated by a desire to separate interface from
> implementation, and bind the two at nearly the latest
> possible moment.
You are jumping to conclusions from the fact that I had to make a very
simple
example (which you then even find not basic enough) to showcase the problem.
Yes, in this simplistic example, using a DLL is of course overkill.
The problem is that from what I've seen, even if the template is declared in
a separate header file or a static lib, as soon as some class declared with
__declspec(dllimport) derives from that template, the template itself is
instantiated with __declspec(dllimport) and all its member functions are
exported by the DLL. If the writer of that template didn't put the
implementations of the member functions in the class body, they will never
be
inlined due to this bug.
> If you cannot get happy with it, I would suggest that
> a few friends with whatever privileged access those
> would-be inlined methods enjoyed could be made
> to accomplish the same effect. That approach will
> degrade encapsulation somewhat, but that clearly
> is something you are willing to tolerate.
That doesn't make any sense at all. It is akin to saying: "that bug is not
really a bug because there is a workaround for it". As it were, there is
actually a much simpler workaround: put the implementation of the member
functions into the class body. However, that of course only works for code
one has control over (as opposed to third party libraries). Even then,
having to go back and identify cases where it makes sense to move the
implemenation into the body it existing code is rather tedious and error
prone.
--Felix
- Next message: Larry Brasfield: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- Previous message: William DePalo [MVP VC++]: "Re: System.Xml.Schema in VC++ 6.0"
- In reply to: Larry Brasfield: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- Next in thread: Larry Brasfield: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- Reply: Larry Brasfield: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- Reply: Carl Daniel [VC++ MVP]: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
