C++11 final and override specifiers fail to compiler Windows 2013.01

Matt_Clarkson · ‎12-10-2012

I added feature detection tests for C++11 final and override and they didn't compile:

class Final final {
public:
virtual int Foo(int a) {return a;}
};
int main() {
Final f;
return f.Foo(0);
}

['C:\\Program Files (x86)\\Intel\\Composer XE 2013\\bin\\intel64\\ICL.exe', '/nologo', '/Qstd=c++11', '/Qwd13000', '/W5', '/Wport', '/Wcheck', '/FC', '/Werror-all', '/Ox', '/Qipo', '/MD', '/IC:\\Program Files (x86)\\Intel\\Composer XE 2013\\compiler\\include', '/IC:\\Program Files (x86)\\Intel\\Composer XE 2013\\compiler\\include\\intel64', '/IC:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\VC\\INCLUDE', '/IC:\\Program Files (x86)\\Windows Kits\\8.0\\include\\shared', '/IC:\\Program Files (x86)\\Windows Kits\\8.0\\include\\um', '/IC:\\Program Files (x86)\\Windows Kits\\8.0\\include\\winrt', '/IC:\\Program Files (x86)\\Intel\\Composer XE 2013\\ipp\\include', '/IC:\\Program Files (x86)\\Intel\\Composer XE 2013\\mkl\\include', '/IC:\\Program Files (x86)\\Intel\\Composer XE 2013\\tbb\\include', '/DWAF_VARIANT_RELEASE=1', '/DNDEBUG', '/DWAF_CXX_FEATURE_LONG_LONG=1', '/DWAF_CXX_FEATURE_AUTO=1', '..\\..\\test.cpp', '/FC', '/c', '/Fotest.cpp.1.o']

out: test.cpp
F:\tool-chain\tests\build\conf_check_45a3a2be358d5c3e452de65820babaf1\test.cpp(2): error: incomplete type is not allowed
class Final final {
^

F:\tool-chain\tests\build\conf_check_45a3a2be358d5c3e452de65820babaf1\test.cpp(3): error: expected an expression
public:
^

F:\tool-chain\tests\build\conf_check_45a3a2be358d5c3e452de65820babaf1\test.cpp(7): error: incomplete type is not allowed
Final f;
^

err: compilation aborted for ..\..\test.cpp (code 2)

class Base {
public:
virtual ~Base() {}
virtual int Foo(int a) {return a;}
};
class Override : public Base {
public:
virtual ~Override() {}
virtual int Foo(int a) override {return a*2;}
};
int main() {
Override o;
return (o.Foo(1) == 2);
}

['C:\\Program Files (x86)\\Intel\\Composer XE 2013\\bin\\intel64\\ICL.exe', '/nologo', '/Qstd=c++11', '/Qwd13000', '/W5', '/Wport', '/Wcheck', '/FC', '/Werror-all', '/Ox', '/Qipo', '/MD', '/IC:\\Program Files (x86)\\Intel\\Composer XE 2013\\compiler\\include', '/IC:\\Program Files (x86)\\Intel\\Composer XE 2013\\compiler\\include\\intel64', '/IC:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\VC\\INCLUDE', '/IC:\\Program Files (x86)\\Windows Kits\\8.0\\include\\shared', '/IC:\\Program Files (x86)\\Windows Kits\\8.0\\include\\um', '/IC:\\Program Files (x86)\\Windows Kits\\8.0\\include\\winrt', '/IC:\\Program Files (x86)\\Intel\\Composer XE 2013\\ipp\\include', '/IC:\\Program Files (x86)\\Intel\\Composer XE 2013\\mkl\\include', '/IC:\\Program Files (x86)\\Intel\\Composer XE 2013\\tbb\\include', '/DWAF_VARIANT_RELEASE=1', '/DNDEBUG', '/DWAF_CXX_FEATURE_LONG_LONG=1', '/DWAF_CXX_FEATURE_AUTO=1', '..\\..\\test.cpp', '/FC', '/c', '/Fotest.cpp.1.o']
out: test.cpp

['C:\\Program Files (x86)\\Intel\\Composer XE 2013\\bin\\intel64\\XILINK.exe', '/NOLOGO', '/MANIFEST', 'test.cpp.1.o', '/OUT:F:\\tool-chain\\tests\\build\\conf_check_d1cbaf3b7a09d6a5c09da027a84d86e1\\testbuild\\release\\testprog.exe', '/LIBPATH:C:\\Program Files (x86)\\Intel\\Composer XE 2013\\compiler\\lib', '/LIBPATH:C:\\Program Files (x86)\\Intel\\Composer XE 2013\\compiler\\lib\\intel64', '/LIBPATH:C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\VC\\LIB\\amd64', '/LIBPATH:C:\\Program Files (x86)\\Windows Kits\\8.0\\lib\\win8\\um\\x64', '/LIBPATH:C:\\Program Files (x86)\\Intel\\Composer XE 2013\\ipp\\lib\\intel64', '/LIBPATH:C:\\Program Files (x86)\\Intel\\Composer XE 2013\\ipp\\..\\compiler\\lib\\intel64', '/LIBPATH:C:\\Program Files (x86)\\Intel\\Composer XE 2013\\mkl\\lib\\intel64', '/LIBPATH:C:\\Program Files (x86)\\Intel\\Composer XE 2013\\compiler\\lib\\intel64', '/LIBPATH:C:\\Program Files (x86)\\Intel\\Composer XE 2013\\tbb\\bin\\..\\lib\\intel64\\vc_mt']
err: XILINK: executing 'link'

Are these specifiers supported? I have seen that they are but compilation is failing on Windows?

Matt

Georg_Z_Intel · ‎12-11-2012

Hello Matt, according to our internal tracking both keywords should be supported with Intel(R) Composer XE 2013 and higher. Nevertheless I can confirm your sighting and will investigate what the current status is. I'll come back if I learn more. Best regards, Georg Zitzlsberger

Georg_Z_Intel · ‎12-11-2012

Hello Matt, according to Judy (http://software.intel.com/en-us/forums/topic/343118), support for both keywords will earliest be available with the next major update release (aka. SP1 as we called it for Intel(R) Composer XE 2011). It's to be expected in about one year. Best regards, Georg Zitzlsberger

Matt_Clarkson · ‎12-11-2012

In one YEAR?! Wow. I guess I can just put final and override preprocessor defines on the command line to remove those keywords from the compilation for now - will lead to side effects if anyone uses them as variables though... Thanks for the link, it's nice to see that Judy is on top of this. It's a pity this can't be released as a update for the current 13.0 as it seems it is now working. It looks like Intel follow the lengthy release model of Microsoft rather than feature releases when ready. Would it be possible to update the C++11 support page to explain what the Intel compiler doesn't support as it is a little confusing about what you're paying money for: http://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-compiler Other pages lead to confusing feature support: http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport Also "Partial" could do with an explanation of what bits it does and doesn't support.

Georg_Z_Intel · ‎12-12-2012

Hello Matt, adding full support for C++11 is a subject of many years -- just think about Fortran 2008, which isn't yet fully complete either. Some features are easy to implement, others require major design changes. Those changes put a risk on both stability and performance. That's also the reason why the final/override keywords won't make it for a minor update. I can understand that some people like to use the new C++11 features right away (including me!), but the majority prefers stability to "bleeding edge" technology. Would you trust a compiler that changes quality after every minor update? I agree that the term "partial" is confusing, as used here: http://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-compiler Please read it as follows: If it says "partial" those features should not be used for production, yet. However, we're working on them with highest priority. As such, those "partial" features are subject of frequent changes in engineering and additional documentation about the detailed status is both, hard to conduct and to describe. The WIKI on apache.org about our compilers does not seem to be correct... but this is something we don't have influence on. Please bear with us -- our engineers are working hard on C++11 support. Thank you & best regards, Georg Zitzlsberger

Matt_Clarkson · ‎12-12-2012

Georg, Thanks for the reply. I wasn't trying to get on anybodies back, I hoped that the release model would be minor feature updates containing new C++11 feature per minor update but after reading your reply I can understand that the target is a stable longer term compiler for customers that need stability. >> adding full support for c++11 is a subject of many years I understand, I'm know that new features don't get magically made, they require hard work by quality engineers. gcc 4.8 and clang 3.3 have them pretty much fully covered right now, benefiting from an enormous open source community. Our ARM compiler is based on gcc so we can target C++11. I can get them all running on Windows but the benefit that the Intel compiler has over them is the native integration with VS and all the Microsoft extensions that are needed to parse the crazy world of the dinkumware standard library. clang is working towards this but will take time to build all the microsoft extensions needed, sort coming at it from the other end as Intel. I read the EDG C++ manual and saw the C++11 features that they support so can understand they take time to filter down to the Intel compiler team to implement the back end. >> Would you trust a compiler that changes quality after every minor update? I would and do. gcc and clang, which we currently compile our C++11 library with, release minor versions often and continually improve in performance, stability and quality. We also work with the TI compiler as well to compiler DSP code so have lots of integrations to handle. At the end of the day, it's not a problem, we will work with whatever compiler features we have available to us. Portability of code is the highest priority for us as our library as it will be multi-platform and the easiest way to ease this is to conform to the standard as close as possible. Finding C++ standards support with native Microsoft toolchain has always been notoriously difficult. I was hoping that the Intel compiler would be the magic wand :) Matt

SergeyKostrov · ‎12-12-2012

>>...At the end of the day, it's not a problem, we will work with whatever compiler features we have available to us. Portability of code is >>the highest priority for us as our library as it will be multi-platform... For a highly portable C/C++ project support for several C/C++ compilers should be a mandatory requirement. Sometimes I think that support for five C/C++ compilers on a project is too much but on the other hand it really improved overall quality of our C/C++ codes. It is a good thing that you are following the same path as we are. Best regards, Sergey

SergeyKostrov · ‎12-12-2012

>>...Finding C++ standards support with native Microsoft toolchain has always been notoriously difficult... What exactly do you mean? Could you provide an example?

Matt_Clarkson · ‎12-12-2012

>>>>...Finding C++ standards support with native Microsoft toolchain has always been notoriously difficult... >> What exactly do you mean? Could you provide an example? msvc C++11 support is sketchy intel C++11 support is almost there gcc C++11 support is there but need to use MinGW which doesn't integrate well with VS clang C++11 support is there but doesn't have the microsoft extensions needed to use the dinkumware library comeau C++11 support is on it's way not sure how well that integrates with Visual Studio It's not that we just need to compile our library/executable for Windows we need a full development environment with Visual Studio as our engineers need the features in that IDE. If it was up to me I'd do everything cross-platform and make people use Eclipse like we use on Linux and MacOSX C++98 and C++03 still had issues. We always compile with full warnings as errors and disable language extensions in every compiler to stick to the standard and compiling standards compliant code on Windows is always the most work. For one, the Dinkumware library doesn't even compile at warning level 2 with it's own toolchain so you have to put it specific warning disables around the external headers (which is useful anyway because it extends to headers from other third party libraries) Another example is that stdint.h was only added to Visual Studio 2010 and I can't even remember when stdbool.h was added. Therefore you have to create a msstdint.h polyfill for older versions of Visual Studio...it gets tiring. I'd just love to be able to fire up Windows and jump into the native command line and do a fully standards compliant slightly complex "Hello, world!" executable with full warnings as errors. I can do that in 2 minutes on Mac and Linux once the dev packages are installed but I've never found the perfect solution on Windows. Matt

SergeyKostrov · ‎12-12-2012

>>>> What exactly do you mean? Could you provide an example? >> >>msvc C++11 support is sketchy Agree. >>intel C++11 support is almost there Agree. >>gcc C++11 support is there... Agree. >>...but need to use MinGW which doesn't integrate well with VS Integrated MinGW with several editions of VS using bat-files approach. The solution works well and it was a significant effort about 2 years ago. >>clang C++11 support is there but doesn't have the microsoft extensions needed to use the dinkumware library Can't say anything because don't use. >>comeau C++11 support is on it's way not sure how well that integrates with Visual Studio Can't say anything because don't use. >>... >>...I've never found the perfect solution on Windows... Unfortunately, Microsoft always creates ( I think deliberately ) some set of issues to keep users and developers on a "hook". I can live with it because codes already completely isolated from Microsoft's APIs, like Win32 API, by three abstraction layers.

SergeyKostrov · ‎12-12-2012

>>...We also work with the TI compiler as well to compiler DSP code... Could you provide some general details about it, please? I mean, versions, links to download, CPUs support, etc. Thanks in advance.

Matt_Clarkson · ‎12-12-2012

>> Integrated MinGW with several editions of VS using bat-files approach Sweet, well done! Our build process uses the waf build tool so I try to submit anything that I find back to the project so that the integration's can be shared. These kinds of integrations are a necessary evil but I hope to only do them once. I feel I've done them repeatedly on enough projects that contributing to a solid cross platform build tool can ease my work in the future. >> Unfortunately, Microsoft always creates ( I think deliberately ) some set of issues to keep users and developers on a "hook" +1. It is really frustrating that they do this but understand their business model for doing it. Our new C++11 library abstracts away all the system calls across all our platforms (Windows, Linux (posix), Mac, TI). It's in its infancy but will get bigger faster, we have unit testing/code coverage/static code analysis/style checking/code reviewing all integrated through the waf tool so I'm confident it will be great quality. Just need to get it targeting windows now!! >> Could you provide some general details about it, please? I mean, versions, links to download, CPUs support, etc. Thanks in advance. Sure. http://processors.wiki.ti.com/index.php/Category:Compiler is probably the best place to start. You can get the C6000 compiler here: https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm but will probably need to register for the TI community The cl6x compiler is a pretty low level compiler but does an excellent job of optimizing and providing feedback on the code - I actually really like working with it. It provides information on how the code has been allocated to the DSP work units and how to improve or modify the code to pipeline it better. It's not like we would expect to compile our C++11 library to run on it as the DSPBIOS isn't that kind of thing. We generally write highly optimised C, TI ASM or ASM kernels that supplement the application code running on the ARM. It's more that our build environment has to support projects that are DSP kernels.

Matt_Clarkson · ‎12-12-2012

However just found http://processors.wiki.ti.com/index.php/C6000_Linux_Support and http://linux-c6x.org/wiki/index.php/Main_Page

Matt_Clarkson · ‎12-12-2012

http://www.ti.com/lit/ug/spru187u/spru187u.pdf is the manual for the compiler

SergeyKostrov · ‎12-12-2012

Thanks, Matt! [ Sorry for a little deviation from the main topic ] I asked about TI compiler because in 2009 I tried to use TI Flash Studio v1.1 Build 37 ( still have it installed on my main development computer ) but that R&D was stopped almost instantly because the compiler was a pure C compiler without any support for C++ and C++ templates.