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: J Trauntvein: "Re: Mixing setlocale() and c++ locales"
- Previous message: Carl Daniel [VC++ MVP]: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- In reply to: 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 21:53:42 -0500
> Actually, I don't believe that they are. If the function wasn't
> originally introduced with the inline keyword the compiler is free to
> ignore any subsequent request to inline it.
I'm sorry, but you're wrong. From the standard:
9.3-2
"A member function may be defined (8.4) in its class definition,
in which case it is an inline member function (7.1.2), [...]"
I think you're confusing it with this one:
9.3-3
"An inline member function [...] may also be defined outside of its
class definition provided either its declaration in the class
definition or its definition outside of the class definition declares
the function as inline."
> Change this to
>
> inline T foo() const;
Doesn't matter, see above. At any rate, this has no bearing on the issue
at hand anyway. After all, VC *does* inline the member functions if they
are implemented in the template class body (without the "inline" qualifier).
It doesn't inline them if they are defined outside the template class body
with the "inline" qualifier.
>> The fact that the VC compiler treats them differently in some cases
>> must be considered a bug.
>
> I don't think so. Whether a function is inlined or not is not observable
> behavior according to the C++ standard, so the compiler's free to inline
> or not at its sole discretion - including never inliing or always inlining
> or inlining only functions that contain an odd number of source tokens (or
> functions
>
> I'll admit it's quirky, and perhaps unexpected, but I don't think it can
> be classified as a compiler bug.
Well, that may be technically true, but I consider arbitrarily generating
poor
code for, according to the standard, semantically equivalent language
constructs a bug -- or at least a very dubious "feature" that should be
fixed.
--Felix
- Next message: J Trauntvein: "Re: Mixing setlocale() and c++ locales"
- Previous message: Carl Daniel [VC++ MVP]: "Re: VC++2003: Methods implemented outside class body are never inlined for templates that are instantiated with __declspec(dllimport)"
- In reply to: 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
|