Time for C++20.

Time for C++20.

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

Hello.

Per [1], as a project we've generally committed to using the latest C++
standard.  C++20 was released in early Sept. 2020 and already had pretty
decent compiler support at the time it was released.  We're currently
using GCC10 and according to [2] it has support for nearly every C++20
feature I could see us regularly wanting to use(*).  It seems like it
is a reasonable time for us to move on to it.

* - Except I recall seeing some mention of std::source_location being
    useful to fix some of the issues with phosphor-logging, but that
    won't be available until GCC11.

In general the C++ standard is backwards compatible.  This shouldn't
have any impact if you are writing C++17-only code.  What it allows us
to do is to start using features out of C++20 like the spaceship
operator and ranges.

I've put up some commits to start this process.  So far the only hiccup
I've ran into is that you need Meson 0.57.0 or higher in order for it to
recognize the 'cpp_std=c++20' option.  I am adding code to our unit-test
framework to ensure you have this specified in your `meson.build` if you
are requesting C++20.

    - https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-build-scripts/+/42252
        * Adds some checking to ensure you've specified a meson_version
          in your meson.build that can handle C++20.

    - https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/42255
        * Update C++ style doc from C++17 to C++20.

    - https://gerrit.openbmc-project.xyz/c/openbmc/sdbusplus/+/42256
        * Update sdbusplus to use C++20.

Please let me know if you have any concerns with this upgrade; I'll be
surprised if this not a fairly low-contention move.

1. https://github.com/openbmc/docs/blob/master/cpp-style-and-conventions.md#code-should-be-written-with-modern-practices
2. https://en.cppreference.com/w/cpp/20
-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Time for C++20.

[Bills, Jason M]

On 4/14/2021 1:11 PM, Patrick Williams wrote:
> Hello.
> 
> Per [1], as a project we've generally committed to using the latest C++
> standard.  C++20 was released in early Sept. 2020 and already had pretty
> decent compiler support at the time it was released.  We're currently
> using GCC10 and according to [2] it has support for nearly every C++20
> feature I could see us regularly wanting to use(*).  It seems like it
> is a reasonable time for us to move on to it.
> 
> * - Except I recall seeing some mention of std::source_location being
>      useful to fix some of the issues with phosphor-logging, but that
>      won't be available until GCC11.
> 
> In general the C++ standard is backwards compatible.  This shouldn't
> have any impact if you are writing C++17-only code.  What it allows us
> to do is to start using features out of C++20 like the spaceship
> operator and ranges.
> 
> I've put up some commits to start this process.  So far the only hiccup
> I've ran into is that you need Meson 0.57.0 or higher in order for it to
> recognize the 'cpp_std=c++20' option.  I am adding code to our unit-test
> framework to ensure you have this specified in your `meson.build` if you
> are requesting C++20.
> 
>      - https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-build-scripts/+/42252
>          * Adds some checking to ensure you've specified a meson_version
>            in your meson.build that can handle C++20.
> 
>      - https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/42255
>          * Update C++ style doc from C++17 to C++20.
> 
>      - https://gerrit.openbmc-project.xyz/c/openbmc/sdbusplus/+/42256
>          * Update sdbusplus to use C++20.
> 
> Please let me know if you have any concerns with this upgrade; I'll be
> surprised if this not a fairly low-contention move.
+1

I just discovered starts_with() will be available for std::string which 
I want to use.  I turned it on locally and didn't have any issues.

coroutines are also an interesting possibility for some of our async calls.

> 
> 1. https://github.com/openbmc/docs/blob/master/cpp-style-and-conventions.md#code-should-be-written-with-modern-practices
> 2. https://en.cppreference.com/w/cpp/20
> 

Re: Time for C++20.

[Vernon Mauery]

On 14-Apr-2021 02:12 PM, Bills, Jason M wrote:
>
>
>On 4/14/2021 1:11 PM, Patrick Williams wrote:
>>Hello.
>>
>>Per [1], as a project we've generally committed to using the latest C++
>>standard.  C++20 was released in early Sept. 2020 and already had pretty
>>decent compiler support at the time it was released.  We're currently
>>using GCC10 and according to [2] it has support for nearly every C++20
>>feature I could see us regularly wanting to use(*).  It seems like it
>>is a reasonable time for us to move on to it.
>>
>>* - Except I recall seeing some mention of std::source_location being
>>     useful to fix some of the issues with phosphor-logging, but that
>>     won't be available until GCC11.

I am excited for this... always having the logging header file's 
location reported is less than useful.

>>In general the C++ standard is backwards compatible.  This shouldn't
>>have any impact if you are writing C++17-only code.  What it allows us
>>to do is to start using features out of C++20 like the spaceship
>>operator and ranges.
>>
>>I've put up some commits to start this process.  So far the only hiccup
>>I've ran into is that you need Meson 0.57.0 or higher in order for it to
>>recognize the 'cpp_std=c++20' option.  I am adding code to our unit-test
>>framework to ensure you have this specified in your `meson.build` if you
>>are requesting C++20.
>>
>>     - https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-build-scripts/+/42252
>>         * Adds some checking to ensure you've specified a meson_version
>>           in your meson.build that can handle C++20.
>>
>>     - https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/42255
>>         * Update C++ style doc from C++17 to C++20.
>>
>>     - https://gerrit.openbmc-project.xyz/c/openbmc/sdbusplus/+/42256
>>         * Update sdbusplus to use C++20.
>>
>>Please let me know if you have any concerns with this upgrade; I'll be
>>surprised if this not a fairly low-contention move.
>+1
>
>I just discovered starts_with() will be available for std::string 
>which I want to use.  I turned it on locally and didn't have any 
>issues.
>
>coroutines are also an interesting possibility for some of our async calls.

The c++ coroutines are implemented differently than the boost::asio 
stuff that ipmid is currently using. It will require some rewriting. But 
I would prefer to move on to the standard than using an older 
implementation from boost.

--Vernon

Re: Time for C++20.

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

On Wed, Apr 14, 2021 at 04:13:13PM -0700, Vernon Mauery wrote:
> On 14-Apr-2021 02:12 PM, Bills, Jason M wrote:
> >coroutines are also an interesting possibility for some of our async calls.
> 
> The c++ coroutines are implemented differently than the boost::asio 
> stuff that ipmid is currently using. It will require some rewriting. But 
> I would prefer to move on to the standard than using an older 
> implementation from boost.

Agreed.  I'm wanting to free up some time to work on enhancing sdbusplus
with co-routines support.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Time for C++20.

[Bills, Jason M]

On 4/14/2021 1:11 PM, Patrick Williams wrote:
> Hello.
> 
> Per [1], as a project we've generally committed to using the latest C++
> standard.  C++20 was released in early Sept. 2020 and already had pretty
> decent compiler support at the time it was released.  We're currently
> using GCC10 and according to [2] it has support for nearly every C++20
> feature I could see us regularly wanting to use(*).  It seems like it
> is a reasonable time for us to move on to it.
> 
> * - Except I recall seeing some mention of std::source_location being
>      useful to fix some of the issues with phosphor-logging, but that
>      won't be available until GCC11.
I just remembered and was excited to finally use std::format only to 
find that it isn't available in GCC.  Even the example code on the 
reference page fails to run: 
https://en.cppreference.com/w/cpp/utility/format/format. :)

I couldn't find anywhere that GCC has plans to include std::format. 
Does anyone know if or when std::format might be added to GCC?

> 

Re: Time for C++20.

[William Kennington]

Just use https://github.com/fmtlib/fmt format like many repos are already doing.

On Mon, May 17, 2021 at 8:18 AM Bills, Jason M
<jason.m.bills@linux.intel.com> wrote:
>
>
>
> On 4/14/2021 1:11 PM, Patrick Williams wrote:
> > Hello.
> >
> > Per [1], as a project we've generally committed to using the latest C++
> > standard.  C++20 was released in early Sept. 2020 and already had pretty
> > decent compiler support at the time it was released.  We're currently
> > using GCC10 and according to [2] it has support for nearly every C++20
> > feature I could see us regularly wanting to use(*).  It seems like it
> > is a reasonable time for us to move on to it.
> >
> > * - Except I recall seeing some mention of std::source_location being
> >      useful to fix some of the issues with phosphor-logging, but that
> >      won't be available until GCC11.
> I just remembered and was excited to finally use std::format only to
> find that it isn't available in GCC.  Even the example code on the
> reference page fails to run:
> https://en.cppreference.com/w/cpp/utility/format/format. :)
>
> I couldn't find anywhere that GCC has plans to include std::format.
> Does anyone know if or when std::format might be added to GCC?
>
> >