4 ms·

This looks cool but c++17 is required (as far as I can tell, since it requires std::optional), so it's difficult to use for many things until all my colleagues

by cozzyd 6y ago

This looks cool but c++17 is required (as far as I can tell, since it requires std::optional), so it's difficult to use for many things until all my colleagues (and their clusters) upgrade their compilers.

mehrdada 6y ago
Might be possible to substitute with `absl::optional` for the time being.
- jeffbee 6y ago
  It's sort of weird to drag in absl to get a flags library.
  - malkia 6y ago
    I switched from gflags to absl::flags and I like it, though there are recommendations against using them too much - https://abseil.io/tips/45 https://abseil.io/tips/45 and https://abseil.io/tips/103 https://abseil.io/tips/103 (one of my first surprises starting at google, was that binaries (e.g. "exe's") would have thousands of options, just adding a new library to your binary, and more flags are there). I actually like that one, as rather than configuring top-down everything, one can directly "inject" values - for example if you were told to switch from one library to the other, and change your borg template for launching jobs, that new borg template that you've used would have flags set (by another team). Then that team can take it further and modify them if needed, thus allowing them to control their part of the software in your own deployed binary. (This way experiments can be rolled out too, or who knows what else).
    - jeffbee 6y ago
      I don't think it's weird to use absl flags, I think it would be weird to import absl to support some other flags library, and not use absl flags.
      - malkia 6y ago
        I get it, I'm using it in one project myself, and happy. I do wish though if namespaces were kept - e.g. if there is ambiguity in the names, one can resolve with full namespace (but maybe that also creates an issue, as previously existing invocations may help, so it's like - you better don't rely on C++ namespaces as you may need to fully qualify a flag later and that could be problematic).. Hmm..
beached_whale 6y ago
I hope you can sooner than later. It really is a good upgrade and allows for some really nice ways of expressing code.
s9w 6y ago
While I can understand that problem, I think it's a reasonable time to target C++17. In fact I would be somewhat weary of new libraries that use something prior of c++17.
qppo 6y ago
Then upgrade their compilers, it's not as big a jump as c++11 was. It's not bleeding edge. The only legitimate case I've seen for C++ <17 is if you need to compile on MacOS <= 10.13 for shipping 32 bit binaries on Mac, where C++17 features are experimental in XCode (but I haven't had an issue with compatibility in C++17 supported compilers). CentOS and Debian shipping ancient GCC versions isn't an excuse, it's trivial to update.
- rumanator 6y ago
  > Then upgrade their compilers If only life was that simple.
- cozzyd 6y ago
  For me, yes (I often compile my own gcc). For $USER on $RANDOM_CLUSTER_AT_OTHER_UNIVERSITY_THAT_I_CANT_LOG_INTO, somewhat less easy :).
- ncmncm 6y ago
  For the record, CentOS 7 can have gcc-9 by installing devtoolset-9. To get access, you have to start a shell that can see them with "scl enable devtoolset-9 bash". But people delivering libraries to customers who have elected not to upgrade to current releases are pretty much stuck. It is extremely common for banks, in particular, to still be running gcc-4, and to have no plans ever to upgrade. It is common at least in banks to have an unbreakable policy never to upgrade software on a server to a version that was not on it when it was unboxed. They may bend just so far as to install back-patched security fixes from the vendor. But a libstdc++.so compatible with a current language Standard? Haha, they say, you must be joking. It is not unusual for them to still run RHEL 6, or even 5. Bloomberg infamously still has 32-bit SPARCs in the basement, running code compiled only ever with Sun's old compiler.
  - hoistbypetard 6y ago
    I had a celebration the day I could push RHEL5 builds off the compatibility raft. Then I spent a couple weeks learning about "new" C++ features I hadn't been able to use because it was too hard to ship code that a customer could build on RHEL5.
jcelerier 6y ago
Kinda frustrating that in 2020 people complain about a library targetting a 3 years old standard as being "too recent". I'm sure some guys in your company update their node_modules daily and don't get any flak so why not just do the same and use recent tools ? Recent compilers are available for every platform. If you can compile c++17 for commodore 64 and MS-DOS you can for everything else too.
- cozzyd 6y ago
  The problem is that not everyone is in control of their computing environment, especially on university clusters. Yes, it's possible to install your own compiler (and in some cases, this might require recompiling a bunch of things due to C++ ABI issues), but for many users, that's a difficult task!
  - jcelerier 6y ago
    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" brew install gcc@10 or https://github.com/fsquillace/junest https://github.com/fsquillace/junest are your friends

by cozzyd 6y ago

mehrdada 6y ago

Might be possible to substitute with `absl::optional` for the time being.

jeffbee 6y ago
It's sort of weird to drag in absl to get a flags library.
- malkia 6y ago
  I switched from gflags to absl::flags and I like it, though there are recommendations against using them too much - https://abseil.io/tips/45 https://abseil.io/tips/45 and https://abseil.io/tips/103 https://abseil.io/tips/103 (one of my first surprises starting at google, was that binaries (e.g. "exe's") would have thousands of options, just adding a new library to your binary, and more flags are there). I actually like that one, as rather than configuring top-down everything, one can directly "inject" values - for example if you were told to switch from one library to the other, and change your borg template for launching jobs, that new borg template that you've used would have flags set (by another team). Then that team can take it further and modify them if needed, thus allowing them to control their part of the software in your own deployed binary. (This way experiments can be rolled out too, or who knows what else).
  - jeffbee 6y ago
    I don't think it's weird to use absl flags, I think it would be weird to import absl to support some other flags library, and not use absl flags.
    - malkia 6y ago
      I get it, I'm using it in one project myself, and happy. I do wish though if namespaces were kept - e.g. if there is ambiguity in the names, one can resolve with full namespace (but maybe that also creates an issue, as previously existing invocations may help, so it's like - you better don't rely on C++ namespaces as you may need to fully qualify a flag later and that could be problematic).. Hmm..

beached_whale 6y ago

I hope you can sooner than later. It really is a good upgrade and allows for some really nice ways of expressing code.

s9w 6y ago

While I can understand that problem, I think it's a reasonable time to target C++17. In fact I would be somewhat weary of new libraries that use something prior of c++17.

qppo 6y ago

Then upgrade their compilers, it's not as big a jump as c++11 was. It's not bleeding edge. The only legitimate case I've seen for C++ <17 is if you need to compile on MacOS <= 10.13 for shipping 32 bit binaries on Mac, where C++17 features are experimental in XCode (but I haven't had an issue with compatibility in C++17 supported compilers). CentOS and Debian shipping ancient GCC versions isn't an excuse, it's trivial to update.

rumanator 6y ago
> Then upgrade their compilers If only life was that simple.
cozzyd 6y ago
For me, yes (I often compile my own gcc). For $USER on $RANDOM_CLUSTER_AT_OTHER_UNIVERSITY_THAT_I_CANT_LOG_INTO, somewhat less easy :).
ncmncm 6y ago
For the record, CentOS 7 can have gcc-9 by installing devtoolset-9. To get access, you have to start a shell that can see them with "scl enable devtoolset-9 bash". But people delivering libraries to customers who have elected not to upgrade to current releases are pretty much stuck. It is extremely common for banks, in particular, to still be running gcc-4, and to have no plans ever to upgrade. It is common at least in banks to have an unbreakable policy never to upgrade software on a server to a version that was not on it when it was unboxed. They may bend just so far as to install back-patched security fixes from the vendor. But a libstdc++.so compatible with a current language Standard? Haha, they say, you must be joking. It is not unusual for them to still run RHEL 6, or even 5. Bloomberg infamously still has 32-bit SPARCs in the basement, running code compiled only ever with Sun's old compiler.
- hoistbypetard 6y ago
  I had a celebration the day I could push RHEL5 builds off the compatibility raft. Then I spent a couple weeks learning about "new" C++ features I hadn't been able to use because it was too hard to ship code that a customer could build on RHEL5.

jcelerier 6y ago

Kinda frustrating that in 2020 people complain about a library targetting a 3 years old standard as being "too recent". I'm sure some guys in your company update their node_modules daily and don't get any flak so why not just do the same and use recent tools ? Recent compilers are available for every platform. If you can compile c++17 for commodore 64 and MS-DOS you can for everything else too.

cozzyd 6y ago
The problem is that not everyone is in control of their computing environment, especially on university clusters. Yes, it's possible to install your own compiler (and in some cases, this might require recompiling a bunch of things due to C++ ABI issues), but for many users, that's a difficult task!
- jcelerier 6y ago
  /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" brew install gcc@10 or https://github.com/fsquillace/junest https://github.com/fsquillace/junest are your friends