- A question about if constexpr - 2 Updates
- __cplusplus - 8 Updates
| Daniel <danielaparker@gmail.com>: Nov 27 05:45AM -0800 Consider #include <string> #include <iostream> int main() { constexpr int n = 1; constexpr int m = 10; std::string s = "abcd"; if (n < m || s.empty()) { std::cout << "ok\n"; } } Is it reasonable that vs2019 produces a warning warning C4127: conditional expression is constant consider using 'if constexpr' statement instead g++ and clang do not, even with -Wall or -pedantic The context is generated code where n = 1, ... 10, 11 ... Daniel |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 27 03:03PM +0100 On 27.11.2019 14:45, Daniel wrote: > consider using 'if constexpr' statement instead > g++ and clang do not, even with -Wall or -pedantic > The context is generated code where n = 1, ... 10, 11 ... It's reasonable here because `n < m` is always true, which is known at compile time, and `||` has short-circuit evaluation, which means that the non-`constexpr` empty checking of the string is not considered. If you switch the values of `n` and `m` then `if constexpr` can no longer be used, because then, though the result is also then knowable at compile time, it isn't /necessarily/ known at compile time. The compiler needs some smarts to understand that `s.empty()` must be `false` here. That said, I find the Visual C++ warning about constant conditions to be generally unreasonable. For example, it pops up if you write `while(2+2 == 4)` instead of the slightly more idiomatic `for(;;)`. Apparently it no longer does that for `while(true)`, but I just don't trust it, it's evidently tuned to ignore one special literal case, and that's it. - Alf |
| "Öö Tiib" <ootiib@hot.ee>: Nov 26 04:04PM -0800 On Wednesday, 27 November 2019 01:23:48 UTC+2, Barry Schwarz wrote: > >the /Zc:__cplusplus option of the compiler. If I don't the compiler > >statically reports 199711L. > Wouldn't that depend on which compiler you are using? OP seemed to claim using VC++. Everybody who accepts VC++ as one of target compilers for their code will anyway check presence and value of _MSC_VER in it since there is always some microsoft-specific weirdness to work around regardless if that /Zc:__cplusplus was set as compiler option or forgotten to. |
| woodbrian77@gmail.com: Nov 26 06:15PM -0800 On Tuesday, November 26, 2019 at 6:05:01 PM UTC-6, Öö Tiib wrote: > of _MSC_VER in it since there is always some microsoft-specific > weirdness to work around regardless if that /Zc:__cplusplus was set > as compiler option or forgotten to. I have Microsoft and Linux warts to work around. Please, Microsoft, get rid of WSAStartup and please, Linux, put sctp.h in a better place: https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc The bulk of my code is closed source and doesn't run on Windows or Linux. It runs on FreeBSD. Thankfully I don't have warts due to FreeBSD. Brian Ebenezer Enterprises - In G-d we trust. https://github.com/Ebenezer-group/onwards |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 27 05:45AM +0100 > of _MSC_VER in it since there is always some microsoft-specific > weirdness to work around regardless if that /Zc:__cplusplus was set > as compiler option or forgotten to. _MSC_VER wouldn't be a replacement for __cplusplus when you want to be portable. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 27 05:49AM +0100 > get rid of WSAStartup and please, Linux, put sctp.h in a better > place: > https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc Where's the problem? Use a C++ socket-lib because there are a lot of differences between BSD-sockets and Windows sockets: https://www.apriorit.com/dev-blog/221-crossplatform-linux-windows-sockets |
| "Öö Tiib" <ootiib@hot.ee>: Nov 26 09:53PM -0800 On Wednesday, 27 November 2019 06:45:40 UTC+2, Bonita Montero wrote: > > as compiler option or forgotten to. > _MSC_VER wouldn't be a replacement for __cplusplus when you want to > be portable. Did I say anything will replace anything? All useful portable C++ code keeps having growing pile of preprocessor checks of various macros in one or other place forever. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 27 07:18AM +0100 >> _MSC_VER wouldn't be a replacement for __cplusplus when you want to >> be portable. > Did I say anything will replace anything? ... 1. The discussion-context was __cplusplus 2. If you don't care for portability, checking _MSC_VER could be a replacement for __cplusplus-checking. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 26 11:00PM -0800 On Wednesday, 27 November 2019 08:18:42 UTC+2, Bonita Montero wrote: > >> be portable. > > Did I say anything will replace anything? ... > 1. The discussion-context was __cplusplus So what? It is standardized but non-portable in practice. > 2. If you don't care for portability, checking _MSC_VER > could be a replacement for __cplusplus-checking. Nonsense, it would be utterly useless check in majority of non-portable C++ code that I've seen. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 27 08:11AM +0100 >> 1. The discussion-context was __cplusplus > So what? It is standardized but non-portable in practice. If you set the MSVC compiler-settings appropriately MSVC conforms. And the other compilers are conformant anyway. So there's a way to use __cplusplus across all compilers. >> could be a replacement for __cplusplus-checking. > Nonsense, it would be utterly useless check in majority of > non-portable C++ code that I've seen. I said that it wouldn't be portbale. But if you're fixed to MSVC you could replace __cplusplus-checks with _MSC_VER-checks to different values. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment