[glenfe]

I think VC14 also has a less conforming std::alignment_of than VC12.

Not to my knowledge, and I maintain the thing. We're now implementing alignment_of with the compiler's alignof (instead of library machinery) and as far as I know, alignof returns perfect answers. If you have examples otherwise, I'd like to see them. Note that aligned_storage is still powered by imperfect library tech (unchanged since 2013) because the compiler's alignas doesn't permit highly-aligned objects to be passed by value. STL

[Glen Fernandes]

Only what was reported for the RC:

Was this reported on Connect? I didn't see any bug reports filed against the STL.

1. For x86 and x64: std::alignment_of<std::nullptr_t>::value is 1, yet compiler aligns at 4 2. For x86: std::alignment_of<T Class::*>::value is 4, yet compiler aligns at 8 For x64: std::alignment_of<T Class::*>::value is 8, yet compiler aligns at 4 3. For x86: std::alignment_of<T (Class::*)()>::value is 4, yet compiler aligns at 8 For x64: std::alignment_of<T (Class::*)()>::value is 8, yet compiler aligns at 4

I am observing discrepancies with nullptr_t on x86/x64 and PMDs on x64 only, but not with PMFs. I've filed DevDiv#1202506 "alignof reports inaccurate values" with the repro at the end of this mail. If you can demonstrate x86 PMD failure, or x86/x64 PMF failure, I'll add that to the bug report.

I haven't checked the RTM yet, but apparently VC12's std::alignment_of for the relevant types reported the same value that the compiler chose to align objects of those types.

Yeah, that's because 2013 used library-only tech, and 2015 uses alignof as required/depicted by the Standard. Thanks, STL C:\Temp>type meow.cpp #ifdef _MSC_VER #pragma warning(disable: 4127) // conditional expression is constant #endif #include <stddef.h> template <typename T> struct RemoveReference { typedef T type; }; template <typename T> struct RemoveReference<T&> { typedef T type; }; template <typename T> struct RemoveReference<T&&> { typedef T type; }; template <typename T> struct GetAlign { T elem0; char elem1; T elem2; }; template <typename T> struct AlignmentOf { using U = typename RemoveReference<T>::type; static const size_t value = sizeof(GetAlign<U>) - 2 * sizeof(U); }; struct Meow { }; #include <cstddef> #include <iostream> using namespace std; template <typename T> void print(const char * const name) { cout << name << endl; cout << "AlignmentOf<T>::value = " << AlignmentOf<T>::value << endl; cout << " alignof(T) = " << alignof(T); if (AlignmentOf<T>::value != alignof(T)) { cout << " <== FAIL"; } cout << endl << endl; } #define PRINT(X) print<X>(#X) int main() { PRINT(char); PRINT(short); PRINT(int); PRINT(long); PRINT(long long); PRINT(float); PRINT(double); PRINT(int *); using PMD = int Meow::*; using PMF = int (Meow::*)(int); PRINT(nullptr_t); PRINT(PMD); PRINT(PMF); } [x86] C:\Temp>cl /EHsc /nologo /W4 /MTd meow.cpp meow.cpp C:\Temp>meow char AlignmentOf<T>::value = 1 alignof(T) = 1 short AlignmentOf<T>::value = 2 alignof(T) = 2 int AlignmentOf<T>::value = 4 alignof(T) = 4 long AlignmentOf<T>::value = 4 alignof(T) = 4 long long AlignmentOf<T>::value = 8 alignof(T) = 8 float AlignmentOf<T>::value = 4 alignof(T) = 4 double AlignmentOf<T>::value = 8 alignof(T) = 8 int * AlignmentOf<T>::value = 4 alignof(T) = 4 nullptr_t AlignmentOf<T>::value = 4 alignof(T) = 1 <== FAIL PMD AlignmentOf<T>::value = 4 alignof(T) = 4 PMF AlignmentOf<T>::value = 4 alignof(T) = 4 [x64] C:\Temp>cl /EHsc /nologo /W4 /MTd meow.cpp meow.cpp C:\Temp>meow char AlignmentOf<T>::value = 1 alignof(T) = 1 short AlignmentOf<T>::value = 2 alignof(T) = 2 int AlignmentOf<T>::value = 4 alignof(T) = 4 long AlignmentOf<T>::value = 4 alignof(T) = 4 long long AlignmentOf<T>::value = 8 alignof(T) = 8 float AlignmentOf<T>::value = 4 alignof(T) = 4 double AlignmentOf<T>::value = 8 alignof(T) = 8 int * AlignmentOf<T>::value = 8 alignof(T) = 8 nullptr_t AlignmentOf<T>::value = 8 alignof(T) = 1 <== FAIL PMD AlignmentOf<T>::value = 4 alignof(T) = 8 <== FAIL PMF AlignmentOf<T>::value = 8 alignof(T) = 8

[Glen Fernandes]

I don't know if it was reported on Connect; it was reported to me, along with a few other library bugs in VC14.

You really need to report this stuff to Microsoft. If you don't, you're making your life and our lives harder.

...

I've filed DevDiv#1202506 "alignof reports inaccurate values" with the repro at the end of this mail.

To be fixed in VC15? :-)

I don't understand what your smiley face is trying to imply. This bug is currently targeted for Dev14 Update 1, although we can't promise anything yet (it may have to be delayed to a future Update, or Dev15). Had it been reported a couple of months ago, we could have probably fixed it for Dev14 RTM, or I could have reworked alignment_of to go back to the library-only tech.

Replacing "struct Meow { };" with "struct Meow;" and on x86 I see:

Thanks, I've added this to the bug report. STL

...

Given we are so late in the 1.59 release cycle, we may want to leave BOOST_NO_CXX11_CONSTEXPR defined in master until after 1.59 ships to be conservative.

+1, I think this would be the correct decision.

+2. I've reinstated that macro in develop for now, let's revisit this when VC14 is released and we have more time to figure out the consequences of enabling constexpr support. John.

On Wed, Jul 22, 2015 at 1:02 PM, John Maddock <jz.maddock@googlemail.com> wrote:

Given we are so late in the 1.59 release cycle, we may want to leave

...

...

BOOST_NO_CXX11_CONSTEXPR defined in master until after 1.59 ships to be conservative.

+1, I think this would be the correct decision.

+2.

I've reinstated that macro in develop for now, let's revisit this when VC14 is released and we have more time to figure out the consequences of enabling constexpr support.

It shipped Monday. See http://blogs.msdn.com/b/vcblog/archive/2015/07/20/visual-studio-2015-rtm-now... Also https://msdn.microsoft.com/en-us/library/hh567368.aspx --Beman

On Thu, Jul 23, 2015 at 4:57 AM, John Maddock <jz.maddock@googlemail.com> wrote:

I've reinstated that macro in develop for now, let's revisit this when

...

...

VC14 is released and we have more time to figure out the consequences of enabling constexpr support.

It shipped Monday.

See

http://blogs.msdn.com/b/vcblog/archive/2015/07/20/visual-studio-2015-rtm-now...

Also https://msdn.microsoft.com/en-us/library/hh567368.aspx

Thanks, got it. Just made one last tweak to Boost.Config (VC14 still doesn't quite handle value initialization correctly), ...

Do file a Connect bug report. Filing bug reports is much more rewarding than it used to be - responses in days instead of years, and the roughly quarterly updates to the production compiler mean the fixes make a real difference. Mention that the bug is impacting Boost code, as this seems to bump the priority up a bit. http://blogs.msdn.com/b/vcblog/archive/2015/07/01/c-compiler-front-end-fixes... documents 750 bug reports from users that were fixed in VC++ 2015. You will see a lot of familiar names - Marcel Raad had an even dozen fixes, most or all Boost related. --Beman

John Maddock <jz.maddock <at> googlemail.com> writes:

I will, however, this bug has been reported at least 3 times already, closed variously as "won't fix" or "fixed" - and indeed it was fixed at one point in VC14 pre-release - and then seems to have regressed again for the final release :(

It seems there were several bugs with value initialization and the only one not fixed in RTM is this one about pointers to data members: https://connect.microsoft.com/VisualStudio /feedback/details/956553/

On 23 Jul 2015 at 4:21, Glen Fernandes wrote:

...

I'm finally beginning to run into things older GCCs and clangs won't compile that VS2015 will, and that's *amazing*.

I don't know if it's so amazing that version of VC released only days ago [and almost two years after its predecessor] can compile things that other compilers released more than a year ago [and who release much more frequently] could not.

(Unless that was humor or a jibe at VC for its track record of conformance).

No, it's entirely serious. But then I'm a fan of MSVC and especially the team they have behind it whom are all seriously impressive engineers at least out of the ones I've met. MSVC has lots of outstanding features no other compiler has: * It's vastly faster to compile, like 5x-10x faster as it's not an AST based compiler like clang and GCC. * It has the best debugger in the business, and still far outclasses anything in the GCC/clang ecosystem. I still develop for Visual Studio first because of that debugger and IDE which also debugs Python very well indeed. * It generates some very unique assembler which still beats the assembler coming out of clang/LLVM, though it has fallen behind GCC in recent years. * It has a totally unique interpretation of the C++ standard. * It's the last full stack compiler ecosystem left, and a major bulwark against a clang monoculture. My only criticism about the compiler really is it accepts too much C++ 11/14 which won't compile on GCC nor clang, so I am still forced to run several passes of mingw-w64 from the command line before each git commit of new code. If Visual Studio had a switch for the EDG red underlining tool to switch on "don't pretend to be MSVC" in the IDE I'd be very pleased, it would save me a lot of time. Even better of course if Visual Studio dual compiled your code with both MSVC and winclang and gave you a combined set of warnings. I'd also like if Visual Studio could make use of the clang-tidy lint tool. Since Chandler turned me onto that tool I've found it remarkably useful for catching accidental slip ups. But all these are minor things. VS2015 is by far the best Visual Studio ever, and that's what matters. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

In the benchmarks of my sort algorithms, the same code, the same input data, running on the same machine. With VC++ 2015 need the double of time than with GCC 4.9. El 23/07/2015 21:27, "Chris Glover" <c.d.glover@gmail.com> escribió:

...

No, it's entirely serious. But then I'm a fan of MSVC and especially the team they have behind it whom are all seriously impressive engineers at least out of the ones I've met. MSVC has lots of outstanding features no other compiler has:

* It's vastly faster to compile, like 5x-10x faster as it's not an AST based compiler like clang and GCC.

I find this claim interesting because in my (anecdotal) experience over the past few years, MSVC is significantly slower than Clang. It seems to be generally accepted that MSVC is the fastest, but that is just not my experience.

...

* It generates some very unique assembler which still beats the assembler coming out of clang/LLVM, though it has fallen behind GCC in recent years.

This is also contrary to my experience. I find that generally both clang and gcc generate better code on a more consistent basis.

-- chris

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Niall Douglas wrote:

No, it's entirely serious. But then I'm a fan of MSVC and especially the team [...]

I get that impression, yes. :-)

It has the best debugger in the business, and still far outclasses anything in the GCC/clang ecosystem

It's interesting you say this. At least one team I was in during my 5+ years at Microsoft elected to (or in some cases had to) use WinDbg over the VS debugger.

It has a totally unique interpretation of the C++ standard

This sounds almost dangerous - like commending a criminal for having a unique interpretation of the law. :-) I thought we prefer compilers to have a correct interpretation of the standard.

It's vastly faster to compile, like 5x-10x faster as it's not an AST based compiler like clang and GCC.

This is interesting. Which (preferably public-available open source) project(s) have you compiled with all three, and what were the build times? Glen -- View this message in context: http://boost.2283326.n4.nabble.com/BOOST-NO-CXX11-CONSTEXPR-and-msvc-14-0-tp... Sent from the Boost - Dev mailing list archive at Nabble.com.

On 24.07.2015 19:45, Niall Douglas wrote:

On 23 Jul 2015 at 14:15, Glen Fernandes wrote:

...

This sounds almost dangerous - like commending a criminal for having a unique interpretation of the law. :-) I thought we prefer compilers to have a correct interpretation of the standard.

Microsoft can read a standard just as well as anyone, and that's exactly where the value add comes from - the same text means different thing to different people. Correctness is relative.

Imagine a world with just clang and GCC. Firstly, clang would utterly destroy GCC in short order as it's so much easier to modify and evolve, so then it would be just clang. Then there would no longer be much need for a C++ standard at all, because whatever clang does IS the standard.

Competition is good, on that I agree with you. But I don't think MSVC is the compiler that drives the competition currently. If anything, this compiler, being the main compiler on Windows, has been an absolute embarrassment in terms of language support for many years. It still is in several areas, even though it's catching up and VS2015 claims to support C++11 and C++14 more fully. As for clang, I've surely been hearing that it is about to conquer the world for the last several years but I don't see that happening. I don't think it would even in the absence of MSVC. All that does not diminish the efforts of each dev team. I'm pleased to see that MS is trying to improve their compiler at a faster pace and with more frequent releases.

...

...

It's vastly faster to compile, like 5x-10x faster as it's not an AST based compiler like clang and GCC.

This is interesting. Which (preferably public-available open source) project(s) have you compiled with all three, and what were the build times?

It depends on if you use precompiled headers or not. I would assume anyone sane in Boost-land does.

I didn't research this but my impression has always been that precompiled headers mostly hide the slowness of the Windows filesystem. When I was building natively on Windows, I noticed that the same code compiled with MinGW on Windows much more slowly than with gcc on Linux, on the same machine.

https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a16.BUILD:C onsiderdefaultingtoheaderonlybutactivelymanagefacilitiesforreducingbui ldtimes for some empirical numbers. tl;dr about 2x faster in debug than clang, about 3x faster in release than clang. clang itself is 2x faster than GCC in debug.

AFIO is very easy on the compiler as it's a tiny simple library. The more templates you feed it, the relatively faster MSVC becomes because it doesn't do two phase lookup i.e. it completely ignores template code until instantiation and neither clang nor GCC do that.

I can't see how a non-conforming behavior is an advantage.

Andrey spaketh:

...

Competition is good, on that I agree with you. But I don't think MSVC is the compiler that drives the competition currently.

Niall respondeth:

I personally think you're very wrong on this.

<snip, discussion of C++ compiler ecosystem and MSVC2015> I really have to agree with Niall on this. We use gcc, clang, and MSVC to compile a common codebase. The current project is fortunate enough to be able to use the "latest-tools". The product will deploy using gcc/Linux. I do most of my development using MSVC. This is because: *- The IDE is fast-and-snappy (MSVS2015). (Yes, IMHO MSVS2010 and 2012 were unusable, MSVS2013 was ok). *- No better alternative exists for workspace refactoring, code-completion/intellisense, and the available "plugins" are good (colored error-output, etc.) *- The integrated debugger is fantastic (fast, powerful, and accurate), and they have invested lots in profiling and multi-threaded debugging support. *- MSVC generates useful and interesting warnings/errors, sometimes different or complimenting to gcc and clang (our codebase generates no warnings nor errors on any of the three compilers as a prerequisite for merge-to-master). *- The C++ Language compliance is good, albeit lagging for some C++14 TMP, and some hiccups with Boost-lib support (currently being discussed on other threads). *- Regarding "driving-the-competition", their experimentation with modules and resumable functions is very sound and interesting, and may significantly advance the C++ language standard and change how the community solves problems. *- I've spoken directly with a number of the MSVC compiler and library team members over the last several years, and concluded that they are really smart, have very substantive insight, and are very active in supporting and driving forward the C++ language standard and coding community. (Yes, this is likely "more-true" in the last several years as compared with previous eras, but I see it as a positive trend.) So, if the discussion relates to "drive the competition" or even "positive for the C++ ecosystem", IMHO the MSVC compiler is quite significant. I'm not a "fan-boy", but merely want the best tools. I can write the greatest amount of high-quality C++11/14 code per unit-of-time using MSVS, so I use it. One of the biggest pain-points is that the NTFS file system is so slow. Others on the team use SlickEdit, vim (no IDE), Eclipse, are experimenting with CLion, and I also spend a lot of time in QtCreator. I realize this "mixes-the-discussion" because the compiler is not the IDE, but our codebase targets MSVC because it's a good compiler, and because the IDE is so strong. Lastly with regards to, "driving the competition", I've come to develop a very deep appreciation for "compiler-attitudes" and for that which is intended (or ambiguous) in the C++ standard, so I really do think options among these tools-and-compilers is positive for the C++ ecosystem. For example, it's been mentioned that gcc is "eager" to parse templates, while MSVC is "lazy", and there are pros-and-cons for the implications and how to think about that which might be "preferred" (e.g., IMHO good-for-the-ecosystem). Further, clang and gcc seem to be competing-with and mimicking each other (in different ways), so it's nice to see MSVC as a "fresh-approach" or alternative. --charley

[Niall Douglas]

B() = default; constexpr B(int) : B() { } ... and VS2015 barfed about the B(int) not properly initialising all base classes, even though it is via a delegation to the defaulted constructor.

Probably a duplicate of DevDiv#1184689 "constexpr delegating constructors". STL

Hi Yuriy Today I am on vacations. In two weeks, when returned home. I will send you all the information, the files and the results obtained. It will be a pleasure collaborate with your work Francisco El 24/07/2015 03:53, "Adam Merz" <adammerz@hotmail.com> escribió:

Stephan T. Lavavej writes:

...

[Niall Douglas]

...

B() = default; constexpr B(int) : B() { } ... and VS2015 barfed about the B(int) not properly initialising all base classes, even though it is via a delegation to the defaulted constructor.

Probably a duplicate of DevDiv#1184689 "constexpr delegating

constructors".

...

STL

Also https://connect.microsoft.com/VisualStudio/feedback/details/1579279/ for something publically trackable.

Regards,

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost