C++20? #1204
Comments
|
std::format !!
designated initializers to help our vecs initializers (how many NULLs is
that, again?) It's rare that C99 had it first
std::endian and std::byteswap to let us finally kill our poorly designed
ones. (Outliving Big Endian computers in our market helped...)
In other codebases, I've had spans instead of (foo*, size_t) as a
non-owning view, like StringView, and it flows nicely
In a different project I work on, ranges will be a big deal, but I'm not
sure they're that useful to us. Subsetting an array is super fundamental to
it, less so to us.
std::source_location is something i've wanted in Fatal(), but we dont use
__FILE__, __LINE__ now, so maybe not.
using enum cuts down on the repetition of case XcsvStyle::X
std::numbers::pi Yawn. It is probably just different enough than ours to
regenerate refs. That #define doesn't exactly bother me.
modules. Maybe. I'm still watching them in real code. Hating headers isn't
the same as loving modules.
Others are excited about concepts. I prefer TMP that doesn't need them. I
must live in a simple world.
As a mix of 17 and 20, __has_include ad __has_attribute are handy in a
future way. Right now, you can use them unless you ahve a compiler than
includes them, though both compilers have included them for a long time. I
use it, for example, to include optional "drop in a file and recompile, no
source or build edits needed" feature. For us, they're just good to know so
we can start sneaking in C++23 or whatever.
…On Wed, Nov 1, 2023 at 7:22 AM tsteven4 ***@***.***> wrote:
Should we raise the floor to C++20?
Compilers in use:
Assuming we drop toolset v141,version=14.16.27023 which is the lastest
toolset for visual studio 2017, and require at least the latest toolsets
for visual studio 2019 which would be v142, version 14.29.30133 or any in
support toolset for visual studio 2022 which would be >= v143, version
14.32.31326. (14+5=19 on the support features page below).
Ubuntu jammy, has g++ 11.4.0 and clang 14.0.0.
The oldest Xcode we use in CI is currently 12.5.1 on macOS 11, which has
apple clang 12.0.5. We could use Xcode 13.2.1, with apple clang 13.0.0 on
macOS 11.
Compiler/Library feature support
Support is summarized here:
https://en.cppreference.com/w/cpp/compiler_support#cpp20 and here
https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B20_library_features
Benefits
One features I have wanted for consistency is "Default member initializers
for bit-fields", although the impact on our code set is minimal.
What other features would be useful?
—
Reply to this email directly, view it on GitHub
<#1204>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3ZZMVDU7LFZ4W2ELMTYCI5JBAVCNFSM6AAAAAA6ZGOO4SVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE3TEMRXGQ2DANY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Also, unlike 20 years ago, Visual Studio CODE is a thing. It's "just" an
IDE around GCC and Clang and it's free. We have so extremely view
developers on "real" Studio that I have no interest in holding things back
too far for them. When we were trying to preserve an interest in $1500
tools, it was different.
No, I haven't built us with VSC. I know they can read CMakefiles and I know
they use the great open source compilers, so I don't feel a need to provide
a platformio.ini to 'prove' it.
RJL
On Wed, Nov 1, 2023 at 11:56 AM Robert Lipe ***@***.***>
wrote:
… std::format !!
designated initializers to help our vecs initializers (how many NULLs is
that, again?) It's rare that C99 had it first
std::endian and std::byteswap to let us finally kill our poorly designed
ones. (Outliving Big Endian computers in our market helped...)
In other codebases, I've had spans instead of (foo*, size_t) as a
non-owning view, like StringView, and it flows nicely
In a different project I work on, ranges will be a big deal, but I'm not
sure they're that useful to us. Subsetting an array is super fundamental
to
it, less so to us.
std::source_location is something i've wanted in Fatal(), but we dont use
__FILE__, __LINE__ now, so maybe not.
using enum cuts down on the repetition of case XcsvStyle::X
std::numbers::pi Yawn. It is probably just different enough than ours to
regenerate refs. That #define doesn't exactly bother me.
modules. Maybe. I'm still watching them in real code. Hating headers isn't
the same as loving modules.
Others are excited about concepts. I prefer TMP that doesn't need them. I
must live in a simple world.
As a mix of 17 and 20, __has_include ad __has_attribute are handy in a
future way. Right now, you can use them unless you ahve a compiler than
includes them, though both compilers have included them for a long time. I
use it, for example, to include optional "drop in a file and recompile, no
source or build edits needed" feature. For us, they're just good to know
so
we can start sneaking in C++23 or whatever.
On Wed, Nov 1, 2023 at 7:22 AM tsteven4 ***@***.***> wrote:
> Should we raise the floor to C++20?
> Compilers in use:
>
> Assuming we drop toolset v141,version=14.16.27023 which is the lastest
> toolset for visual studio 2017, and require at least the latest toolsets
> for visual studio 2019 which would be v142, version 14.29.30133 or any
in
> support toolset for visual studio 2022 which would be >= v143, version
> 14.32.31326. (14+5=19 on the support features page below).
>
> Ubuntu jammy, has g++ 11.4.0 and clang 14.0.0.
>
> The oldest Xcode we use in CI is currently 12.5.1 on macOS 11, which has
> apple clang 12.0.5. We could use Xcode 13.2.1, with apple clang 13.0.0
on
> macOS 11.
> Compiler/Library feature support
>
> Support is summarized here:
> https://en.cppreference.com/w/cpp/compiler_support#cpp20 and here
>
https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B20_library_features
> Benefits
>
> One features I have wanted for consistency is "Default member
initializers
> for bit-fields", although the impact on our code set is minimal.
>
> What other features would be useful?
>
> —
> Reply to this email directly, view it on GitHub
> <#1204>, or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ACCSD3ZZMVDU7LFZ4W2ELMTYCI5JBAVCNFSM6AAAAAA6ZGOO4SVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE3TEMRXGQ2DANY>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#1204 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VADY53FLRHYRIEPJJLHLYCJ5NRAVCNFSM6AAAAAA6ZGOO4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBZGMYTGMZZGE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
It looks to me like the only toolset we use with complete support is MSVC! The community edition is free. I think the question is how much the version of gcc and clang are going to hold us back on Ubuntu jammy, and apple clang on whatever we want to set our minimum development floor to be for macOS. |
|
Without going down the chart one-by-one, I'm OK splitting "complete" and
"enough". There are compilers (hello, MSVC!) that still don't support
Complex in C99. I don't think that's a reason to not use // comments in C.
Most of the items on my wish list were probably rolled out in clang and gcc
in some form before they were standardized. The absence of floating point
atomics isn't exactly a deal-breaker for us.
I think that people building on old MacOS are really rare. (Duly
noting that there's one machine that I care about, but if I have to ssh
into one of the other Macs in my life, that's not exactly terrible. I know
that machine is on borrowed time.) Let's cross that off the blocking list.
I'm a bit torn on holding things back for LTS releases. Users of LTS are on
LTS because they don't WANT to use new versions of things. I suspect that
anyone wanting a bugfix for what's in an LTS release is accustomed to
cherry-picking a fix and not trying to upgrade their entire Qt/devchain
tree. Again, I think that's a small market for us. People grabbing and
installing from us (as opposed to using the version from their OSV) seem
more likely to run a more rapid release (formerly Fedora vs. RHEL, but now
with new names...) that comes closer to HEAD of most projects.
It looks like Jammy was GCC 11, so it wasn't exactly contemporary when it
was frozen in 2022. The good news for us is that it looks like the huge
majority of C++20, the parts we care about (designated initializers, for
example, are basically turning on code that was already there for C99) was
in 11 according to https://gcc.gnu.org/projects/cxx-status.html#cxx20
There's the question of libc++ vs. g++ but it's likely that if it was
enabled in that timeframe in the compiler that at least the low-hanging
fruit (the kind we're likely to care about) is likely in the ibraries.
Actually,
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2020
shows that if they're shipping 11, we're probably fine even in the library.
Offhand, I don't _know_ the status of MacOS, but it's pretty
straight-foward clang++ these days.
Parallel STL was something I wanted, too, and it was something I haven't
seen looking at these lists today, which means it's either in our future or
our past and already there. Some of our filters would fan out to threads
and AVX-512/Vector pretty nicely if we could express it ... without
managing thread pools ourselves.
I think we'll have to treat it like conformance itself. Turn it on, try it
with a simple CL and if it breaks, verify that our CI floor is what we
think it is, and if it fails, stay with plan a. This is what we do with Qt
or libc or anything else, right? We can argue that something we use is in
the spec, but if it doesn't work on a platform we care about, we just can't
use it. We've lived this battle with Qt for years.
We don't have to go hog wild. Let's throw the master switch and start
trickling things in. Before I rolled out a thousand changes to make Fatal
take a default source_line_indicator and take fmt{} style args, I'd try a
single change, throw it into CI and see if it sticks.
Let's throw top-level flag soon, if not now. We can then dip toes into
things like format or whatever when one of them wants to use it.
…On Wed, Nov 1, 2023 at 1:53 PM tsteven4 ***@***.***> wrote:
It looks to me like the only toolset we use with complete support is MSVC!
The community edition is free. I think the question is how much the version
of gcc and clang are going to hold us back on Ubuntu jammy, and apple clang
on whatever we want to set our minimum development floor to be for macOS.
—
Reply to this email directly, view it on GitHub
<#1204 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3Y46Q5QYMHNAKLPNQDYCKLDXAVCNFSM6AAAAAA6ZGOO4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBZGQ4DGNBQGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
The important user of the jammy LTS for us is the github runners. jammy is currently the latest Ubuntu release available on a github hosted runner. |
|
And the first failure is on macOS, with the newest version of Xcode we currently use: Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/concept:318:1: error: Parse error at "::" |
|
above error with concepts is reported at https://bugreports.qt.io/browse/QTBUG-117765 |
|
@robertlipe what version of macOS are you trying to keep alive for building? As an alternative you likely can use teamviewer or ssh to our macstadium machine. I believe more than one developer is allowed but usage is restricted to development of gpsbabel. |
|
Sheesh. We might not care about modules, but I'm sure that Qt cares deeply
about them. It's interesting that older versions of Qt don't trip this up.
It's also interesting how that bug and most that link to it are very
contemporary - active in recent weeks.
I'm surprised that moc has lived as long as it has, but the templated
alternatives I've seen that try to automate the signal/slot plumbing have
been even more terrifying.
…On Wed, Nov 1, 2023 at 3:03 PM tsteven4 ***@***.***> wrote:
above error with concepts is reported at
https://bugreports.qt.io/browse/QTBUG-117765
—
Reply to this email directly, view it on GitHub
<#1204 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VAD5S4RU6BPA4K5FA7ILYCKTITAVCNFSM6AAAAAA6ZGOO4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBZGU4TEOBRGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
see PR #1206 for latest CI results |
|
My 27" 2012 iMac with 10.15.7 (3.4Ghz, 32GB, external 'fusion' drive) is
still a pretty likeable desktop. If I could use it as a monitor, I would
probably feed it from a Mini or something. I carry a 13" 2020 M1 MBP around
the house for most of my tinkering. I can ssh/screen share to that or my
wife's M1 iMac. Let's not hold back development because I'm using a machine
I make fun of others for using. :-).
I understand there's a way to hack more modern OSes to run on it, but it
runs into the kinds of problems that I buy Macs to avoid.
Shame on Apple for talking green but making e-waste by discontinuing OS
support so aggressively. But that's a dog I can't wag.
Let's not let that machine factor into larger project issues.
CI results
It is interesting that it's one specific configuration that fails. Maybe
newest Qt and older (Sonoma was released, what, two weeks ago?) MacOS just
isn't a combination we test. It might be a bit nonsensical. I wonder what
percentage of Mac devs (and I've already acknowledged we don't have many at
all...) really run Qt installers vs. running it from homebrew which
probably patches around this kind of thing.
It looks like my M1 is running homebrew qt
qmake --version
QMake version 3.1
Using Qt version 6.5.2 in /opt/homebrew/lib
(Probably because I was an early M1 adopter at Qt was one of the last open
source blockers)
While my x86 iMac is running a manually installed Qt version 6.4.2
…On Wed, Nov 1, 2023 at 3:21 PM Robert Lipe ***@***.***> wrote:
Sheesh. We might not care about modules, but I'm sure that Qt cares deeply
about them. It's interesting that older versions of Qt don't trip this up.
It's also interesting how that bug and most that link to it are very
contemporary - active in recent weeks.
I'm surprised that moc has lived as long as it has, but the templated
alternatives I've seen that try to automate the signal/slot plumbing have
been even more terrifying.
On Wed, Nov 1, 2023 at 3:03 PM tsteven4 ***@***.***> wrote:
> above error with concepts is reported at
> https://bugreports.qt.io/browse/QTBUG-117765
>
> —
> Reply to this email directly, view it on GitHub
> <#1204 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AC3VAD5S4RU6BPA4K5FA7ILYCKTITAVCNFSM6AAAAAA6ZGOO4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBZGU4TEOBRGI>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
|
I'll admit some egg on face.
I almost started and ended the list at std::format. That was enough, I
thought. I then thought more about the other things in C++20 and sketched
in the response.
In the spirit of your PR, I started on a PR (on MacOS 14.1) that ran just a
little bit of each item from the bullet list so I could throw it into CI
and see how well it survived the gauntlet. For whatever reason, I started
at the bottom of the list and worked up.
I hit std::format. What a mess. It turns out that on the pretty graph you
showed me that there are separate columns for clang and clang as shipped by
apple. Guess what square is missing. Yep. The header is there and it looks
approximately believable (so much for testing __has_include()) but it's
just plain not in the library. I think I have all the goo in our our own
fmt.h to let us switch between the system one, one in. our tree, or one
that's found externally by CMakeLists.txt (OK, two files...) It's much
like we did with variant (optional?) in the past and for the same reasons.
The bright side of using libfmt is that we can use ::print and ::println
which, somehow, didn't make it until c++23, but they're not too hard to
shim in even if we need system versions.
I worked through the template voodoo so we can mix and match char* and
QStrings.
I'm going to throw this into the machine. I know it won't pass. I'm more
interested in seeing the coverage of everything else in the PR. If most
stuff passes in most places, we can figure out if we should:
1) Not use std::format yet. :-(
2) Decide whether we
2a) Install fmt via homebrew, include and link in CMakeList.
2b) Use git modules and check libfmt into us.
2c) Use cmake voodoo and demand pull libfmt in if missing.
2d) Build with homebrew's GCC that allegedly hs this. (Not a fan...)
2e) Seems like there was another, but it's late...
3) Use a mechanically different spelling, perhaps forcing into GPSBabel
namespace, and use format only in easy cases where we implement our own
std::format (NAF)
So #1207 is my equivalent of your
PR from earlier. Lets see how it goes. I KNOW the libfmt stuff is going up
in flames on MacOS. It works on mine - this is whiteboard scribbling.
Comments encouraged, of course.
RJL
…On Wed, Nov 1, 2023 at 3:43 PM GPSBabel ***@***.***> wrote:
My 27" 2012 iMac with 10.15.7 (3.4Ghz, 32GB, external 'fusion' drive) is
still a pretty likeable desktop. If I could use it as a monitor, I would
probably feed it from a Mini or something. I carry a 13" 2020 M1 MBP
around
the house for most of my tinkering. I can ssh/screen share to that or my
wife's M1 iMac. Let's not hold back development because I'm using a
machine
I make fun of others for using. :-).
I understand there's a way to hack more modern OSes to run on it, but it
runs into the kinds of problems that I buy Macs to avoid.
Shame on Apple for talking green but making e-waste by discontinuing OS
support so aggressively. But that's a dog I can't wag.
Let's not let that machine factor into larger project issues.
> see PR #1206 <#1206> for
latest
CI results
It is interesting that it's one specific configuration that fails. Maybe
newest Qt and older (Sonoma was released, what, two weeks ago?) MacOS just
isn't a combination we test. It might be a bit nonsensical. I wonder what
percentage of Mac devs (and I've already acknowledged we don't have many
at
all...) really run Qt installers vs. running it from homebrew which
probably patches around this kind of thing.
It looks like my M1 is running homebrew qt
qmake --version
QMake version 3.1
Using Qt version 6.5.2 in /opt/homebrew/lib
(Probably because I was an early M1 adopter at Qt was one of the last open
source blockers)
While my x86 iMac is running a manually installed Qt version 6.4.2
On Wed, Nov 1, 2023 at 3:21 PM Robert Lipe ***@***.***> wrote:
> Sheesh. We might not care about modules, but I'm sure that Qt cares
deeply
> about them. It's interesting that older versions of Qt don't trip this
up.
>
> It's also interesting how that bug and most that link to it are very
> contemporary - active in recent weeks.
>
> I'm surprised that moc has lived as long as it has, but the templated
> alternatives I've seen that try to automate the signal/slot plumbing
have
> been even more terrifying.
>
> On Wed, Nov 1, 2023 at 3:03 PM tsteven4 ***@***.***> wrote:
>
>> above error with concepts is reported at
>> https://bugreports.qt.io/browse/QTBUG-117765
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <
#1204 (comment)>,
>> or unsubscribe
>> <
https://github.com/notifications/unsubscribe-auth/AC3VAD5S4RU6BPA4K5FA7ILYCKTITAVCNFSM6AAAAAA6ZGOO4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBZGU4TEOBRGI>
>> .
>> You are receiving this because you commented.Message ID:
>> ***@***.***>
>>
>
—
Reply to this email directly, view it on GitHub
<#1204 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD373OJO5I7QKIQEZ27TYCKYA3AVCNFSM6AAAAAA6ZGOO4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBZGY2TCMZTGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Should we raise the floor to C++20?
Compilers in use:
Assuming we drop toolset v141,version=14.16.27023 which is the lastest toolset for visual studio 2017, and require at least the latest toolsets for visual studio 2019 which would be v142, version 14.29.30133 or any in support toolset for visual studio 2022 which would be >= v143, version 14.32.31326. (14+5=19 on the support features page below).
Ubuntu jammy, has g++ 11.4.0 and clang 14.0.0.
The oldest Xcode we use in CI is currently 12.5.1 on macOS 11, which has apple clang 12.0.5. We could use Xcode 13.2.1, with apple clang 13.0.0 on macOS 11.
Compiler/Library feature support
Support is summarized here: https://en.cppreference.com/w/cpp/compiler_support#cpp20 and here https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B20_library_features
Benefits
One features I have wanted for consistency is "Default member initializers for bit-fields", although the impact on our code set is minimal.
What other features would be useful?
The text was updated successfully, but these errors were encountered: