Who can help with VC 2015?

[rbock]

Hi all,

Playing around a bit here http://webcompiler.cloudapp.net/ I found a simple workaround to the constexpr problem reported here: #34 (comment)

It is pushed to the develop branch. Who can give it a try with VC 2015 and report the remaining errors?

Best,

Roland

[jhunold]

I've tried develop. In order to do this, I've had to apply #44 and #45 to the current develop branch.
This leads to a 1MB log file with

• 27 Warning(s)
• 2023 Errors

The interesting one being:

• sqlpp11\tests\Result.cpp(50): error C2338: Yikes [..\sqlcpp11\tests\sqlpp11_tests.vcxpro]

This seems like a lost cause to me, at least as long as the constexpr support is broken. @rbock if you still want the log, drop a note where to put it.
One other note: Please put compiler workarounds in an #idef/#endif-Block. So users of a conforming compiler are not affected by this and one can easily spot them even without git (read: from a release tarball)

[rbock]

Thanks for the report. "Yikes" is an interesting error message indeed.

Yes, I'd be interested in the log, can you zip and and send it to me rbock eudoxos de?

Regarding your note on workarounds: Do you consider these changes a workaround that justifies an #ifdef block: 30a3a6b ?

[niXman]

One other note: Please put compiler workarounds in an #idef/#endif-Block.

may be better do it like this?:

// declare the macro
#ifdef _MSVC
#  define SQLPP_CONSTEXPR_CSTRING(var, str) \
   static constexpr const char var[sizeof(str)] = str
#else
#  define SQLPP_CONSTEXPR_CSTRING(var, str) \
   static constexpr const char var[] = str
#endif // _MSVC

// usage
SQLPP_CONSTEXPR_CSTRING(varname, "some string");

[rbock]

@niXman Sure, that's an option.

Anyway, if it turns out (and it looks this way from @jhunold 's report) that this is currently a lost cause, I'll just revert this commit and wait for the next release or the release after that...

[jhunold]

@niXman Yes, that is better, although checking for _MSVC is not enough in most cases. Think of Intel compiler disguising as msvc etc. pp.
@rbock I'm not a big fan of obfuscating a clean (and cool 👍 ) c++ code base for a non.conforming compiler. We have too many of those workaround in Boost, some dating back to vc-6.0 and really hard to eliminated. Sigh, some vc-6.0 shortcoming even lead to obfuscated library design, see Boost.Graph for the gory details. I'd rather put more pressure on the compiler vendors. Especially as clang-cl is coming forward and mingw-w64 is already quite promising.

[rbock]

@jhunold Thanks for the log!

Seems like my sizeof did not work anyway since the compiler is not happy with its usage. And since without the size of the array, MSCV won't understand the constepxr, it's settled: I'll revert the named commit in a minute and continue to concentrate on conforming compilers :-)

Best,

Roland

[rbock]

FYI: MS is getting closer. I just received message from the compiler team today:

This notification was generated for feedback item: static constexpr const char _literal[] = "delta"; // not working inside struct (http://connect.microsoft.com/VisualStudio/feedback/details/1290476/static-constexpr-const-char-literal-delta-not-working-inside-struct) which you submitted at the Microsoft Connect (http://connect.microsoft.com) site.

Thank you for reporting this issue. We've checked in a fix but the fix demands some explanation. Till date the VC++ compiler never had to emit initializers for in-class statics because they were always of scalar types. Now with initializers allowed for arbitrary types for static constexpr members this becomes a problem. We've implemented as many kinds as we can do while minimizing risk to the compiler's quality as we near RTM. We allow the use of such members in constant expressions but some kinds will remain uninitialized at runtime. We emit a warning-as-error (C4759) about this. We do plan to fix this fully in Update 1 but for now this seems to be the best that we can do.