2013/6/15 dw <[email protected]>:
>
>> we don't need to maintain implementation at two places, if we do
>> things right.
> Are you talking about something like what I did with intrin-mac.h? While
> that allows us to (mostly) write it once, you still need to have it in
> two places (and test both). Or did you mean something else? If you
> have some clever trick in mind, I'd love to hear about it.
Well, not sure what you mean by two places. I mean something near
intrin-mac.h ...
I mean that in the header we have inline-versions (best each of them
can be enabled separately by build-macro), which can be used in
implementation file too (of course with disabling inlining).
Eg. In file guard is for each function:
#if (!defined (IMPLEMENT_FUNCTION) && !defined
(SPECIAL_FUNCTION_<NAME>)) || (defined (IMPLEMENT_FUNCTION) && defined
(SPECIAL_FUNCTION_<NAME>))
#undef SPECIAL_FUNCTION_<NAME>
#define SPECIAL_FUNCTION_<NAME>
#ifndef IMPLEMENT_FUNCTION
__CRT_INLINE
#endif
<implementation ....>
#endif
By this we can controll in implementation-file to have just *one*
function in TU, but for intrin.h (or otherplaces) we can controll what
to declare.
>>> - Putting intrinsic prototypes in *system headers* (other than intrin.h)
>>> seems like a bad idea. Without including intrin.h, any code that uses
>>> it will end up using the library version instead of the inline version.
>> Hmm, in platform-headers we have some intrinsics (and specializations
>> for C++), which need to be there without having all other things
>> declared from intrin.h header. Anyway my concerns aren't strong here.
> This isn't any sort of deal-breaker. It just seems like a bad idea. We
> will "silently" be changing people's intrinsics (which presumably they
> are using for max performance) to static library functions. Plus, I
> think having multiple definitions of intrinsics all over is as bad an
> idea as having multiple printf definitions all over.
Well, true, but to have different place defining same intrinsics by
including same header, is to be preferred. At least if it is really
required to have some intrinsics declared at different places ... like
winnt.h and intrin.h ... or in winbase.h (where actual the
interlocked-functions live).
> As for the "specializations for c++" I have to wonder about that. So far
> the places I've seen intrinsics defined (a limited sample, it's true)
> they've all been wrapped with extern "C". I don't think those can get
> overloaded. Do you have an example?
See specialization for C++ regarding unsigned types.
Eg:
FORCEINLINE unsigned InterlockedIncrement (unsigned volatile *Addend) {
return (unsigned) InterlockedIncrement ((volatile long *) Addend);
}
> When you say "having all other things declared from intrin.h header",
> are you just talking about having a bunch more #defines/prototypes? Or
> do things actually end up getting linked in that wouldn't otherwise? If
> the former, it doesn't sound like much of a problem. If the latter, I'd
> like to take a look at it.
I am talking here about the other ...intrin.h headers and the
additional includes intrin.h does.
> dw
Kai
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
