On 2 Jun 2015 at 1:57, Andrey Semashev wrote:
Since other than the above there are no special treatment of extern "C" function calls from the language perspective, I would assume that as long as the call in unambiguous by the C++ overload resolution rules, the language should allow it.
If clang folks say this should not compile then perhaps they could point to the relevant part of the standard.
Obviously declspec anything is non-standard. I believe the reason clang is insisting on this behaviour is because declspec is part of the type definition. You can see this in how pointers to functions retain their declspec attributes in the pointer type. Therefore not always specifying them consistently is an ODR violation, and therefore clang is being right here. GCC matches MSVC's incorrectness here for ease of life. As does clang when in MSVC mode. Regarding mingw's broken headers which don't specify dllimport correctly for kernel32 imports, yeah that's one of a long litany of problems in mingw's headers. I in fact gave up on mingw support in AFIO in the v1.3 release, it was becoming too painful to keep working around their severe quality problems. AFIO now only supports mingw-w64. Mingw-w64 have done an excellent job, and are light years ahead of mingw in quality control and stability. They also support the C++ 11 <thread> header, which mingw does not. Regarding why clang is not on mingw-w64 yet, apparently it may be political. See http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/873 8aihlgy.fsf@wanadoo.es/. I agree with the assessment that mingw support is not a priority for the clang devs compared to MSVC support, but I am not aware of any active campaign against mingw-w64 support. It's more no one could be bothered relative to other things to do I think. Anyway, from my own perspective whilst it would be nice if mingw-clang was working, it's no showstopper for me personally. MinGW users are a tiny proportion of the user base, sufficiently tiny that GCC is good enough for now. I see mingw-w64 is very shortly going to release a GCC 5.1 build, it's hardly like MinGW users are suffering from ancient GCC tooling or something. winclang is a whole different beast though. That's an enormous threat to MSVC in the medium term. Microsoft may, of course, just go ahead and bundle a winclang toolset in future Visual Studios as an equally supported alternative to MSVC. That would be *enormous* for anyone trying to do modern C++ on Windows, though MSVC is coming along hugely of late and it's still vastly faster to compile than clang, and I suspect always will be. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/