C++20? about gpsbabel

[robertlipe]

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: ***@***.***>

[GPSBabelDeveloper]

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: ***@***.***>

[tsteven4]

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.

[robertlipe]

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: ***@***.***>

[tsteven4]

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.

[tsteven4]

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 "::"

[tsteven4]

above error with concepts is reported at https://bugreports.qt.io/browse/QTBUG-117765

[tsteven4]

@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.

[GPSBabelDeveloper]

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: ***@***.***>

[tsteven4]

see PR #1206 for latest CI results

[GPSBabelDeveloper]

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: > ***@***.***> >

[robertlipe]

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: ***@***.***>

[tsteven4]

closed via #1206