> 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.
>> - 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. 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? 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. dw ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
