Re: Meaning of iniline in declspec(dllexport)
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:gjvo03tcuk6j0305691vv7s8i7li9jcd4e@4ax.com...
Uh, no. If it helps, pretend g and X came from a DLL header file that was
#included by a.cpp, and the macro that controls dllexport vs dllimport was
set to import. The file a.cpp would belong to a client of the DLL.The
result of preprocessing would look exactly like my example.
Now if you move h() to a different module and then show the generated code
to be the same thing, then I will truly be amazed that it is inlined.
You are hereby amazed. :)
Way cool! Thanks for the explanation! :-)
Really? You've never seen a class declared __declspec(dllexport) that had
even one member function defined inside the class body? You must hang with
a very disciplined bunch.
Well, this is a matter of taste. I personally like to treat the header as
an interface contract, to the extent possible, which means no implementation
in the header file. But a lot of it is due to my heritage of cutting my
teeth on C++ when you were penalized for putting code in the header by
pre-compiled headers simply breaking for that header.
Something else to consider are the
compiler-generated functions, the default ctor, copy ctor, assignment
operator, and dtor, which the compiler will generate as needed in client
code for exported classes. There's more to fully exporting classes than I
think most people probably realize...
I guess I was thinking of using the "inline" keyword in the header file and
defining the function in the .cpp file. I don't think using
__declspec(import) on such a function would result in that function being
inlined. But I could be amazed again! :-)
-- David