# C++ standard library extensions

**URL:** https://discourse.cmake.org/t/c-standard-library-extensions/206
**Category:** Development
**Created:** [November 14, 2019, 4:51pm UTC](https://discourse.cmake.org/t/c-standard-library-extensions/206 "2019-11-14T16:51:00Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![marc.chevrier](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/m/ecb155/32.png) [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [November 14, 2019, 4:51pm UTC](https://discourse.cmake.org/t/c-standard-library-extensions/206/1 "2019-11-14T16:51:00Z")

</div>

Currently, C++ standard library headers usage for `CMake` is normalized through the directory prefix `cm`. For example: `#include <cm/memory>`.

But, there is no clear approach regarding extensions to the standard library. For now, the header `cmAlgorithms.h` holds mainly extensions to the C++ standard library. But because it is located at the same place as the `CMake` code, it is not clear to determine the goal and usage of this header…

I propose the following approach to facilitate development and usage of standard library extensions:

- Use directory prefix `cmext`.
- Use same names as from standard library to hold related topics.
- Store these new headers under `Utilities/std/cmext`.

And for the coding rules:

- Use namespace `cm`. I think it is better to keep same namespace as `CMake` standard headers to show the close relationship with them.
- use naming conventions from the standard library: all lowercase with underscores.

As an example, extensions to memory utilities (std::unique\_ptr and std::shared\_ptr) for conversion types (on the model of `std::static_pointer_cast`): `cm::static_reference_cast` and `cm::dynamic_reference_cast`

File `Utilities/std/cmext/memory`

```auto
#include <memory>

namespace cm
{
template <typename T, typename O>
T& static_reference_cast(O& item)
{
  return *(static_cast<T*>(item.get()));
}

template <typename T, typename O>
T& dynamic_reference_cast(O& item)
{
  return *(dynamic_cast<T*>(item.get()));
}
} // namespace cm

```

And for the usage (nota: including `cmext/memory` do not include automatically `cm/memory`):

```auto
#include <cm/memory>
#include <cmext/memory>

class Base
{}
class Derived : public Base
{
public:
   void func ();
}

std::unique_ptr<Base> up = cm::make_unique<Derived>();
cm::static_reference_cast<Derived>(up).func();

```

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [November 14, 2019, 7:13pm UTC](https://discourse.cmake.org/t/c-standard-library-extensions/206/2 "2019-11-14T19:13:36Z")

</div>

This sounds fine to me, though I’d be interested in others’ thoughts too.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 14, 2019, 9:19pm UTC](https://discourse.cmake.org/t/c-standard-library-extensions/206/3 "2019-11-14T21:19:58Z")

</div>

Sounds fine to me too. If possible I’d like to see comments on the functions if/when they have future-C++ variants on their way in. That can help find code we can remove given a C++ standard bump in CMake itself.

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [November 14, 2019, 9:20pm UTC](https://discourse.cmake.org/t/c-standard-library-extensions/206/4 "2019-11-14T21:20:32Z")

</div>

I’d actually advise _against_ using the same file names as the standard headers. It opens up too many possibilities for confusion. You have to be very careful not to add the directory that contains them to the header search path or else you can’t reach the same-named standard headers any more. Having experienced this exact problem in one or two projects, I’m keen to avoid even the chance of seeing that here.

I personally also find it a bit strange having to include both `<cm/memory>` and `<cmext/memory>`. If I’m wanting to include CMake’s helpers/replacements/stand-ins for the `<memory>` header, it seems odd that I would have to pull in two headers instead of just one to do that.

---

<div class="post-metadata">

### Author: ![marc.chevrier](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/m/ecb155/32.png) [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [November 15, 2019, 9:18am UTC](https://discourse.cmake.org/t/c-standard-library-extensions/206/5 "2019-11-15T09:18:32Z")

</div>

The headers under `cmext` are not dedicated to replace standard headers. This is the role of headers under `cm` which are a pure **replacement** of the standard ones.

Under `cmext`, are headers **extending** the capabilities of the standard library. There is currently already some extensions to `<algorithm>` in the file `cmAlgorithms.h` for example.

I agree that directory holding the headers **must not** be included but re-using same name enforce the strong relationship between the two headers.

---

<div class="post-metadata">

### Author: ![marc.chevrier](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/m/ecb155/32.png) [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [November 18, 2019, 4:29pm UTC](https://discourse.cmake.org/t/c-standard-library-extensions/206/6 "2019-11-18T16:29:30Z")

</div>

@brad.king I will create a `MR` to show up a concrete example of this proposition.  
What is the process for that? Is it required to create an issue or is it enough to add a link to this discussion in the `MR`?

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [November 18, 2019, 4:53pm UTC](https://discourse.cmake.org/t/c-standard-library-extensions/206/7 "2019-11-18T16:53:03Z")

</div>

@marc.chevrier references to this discussion are fine from the MR discussion posts, but if any commit messages need to reference discussion it’s best to have a numbered issue (whose number will survive future hosting platform changes).