Skip to content

Commit fa52094

Browse files
author
SSS-XPS-9530
committed
Minor improvements
1 parent bfc1204 commit fa52094

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

README.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -47,7 +47,7 @@ shared_ptr<const Derived> const_derived = any_shared_ptr_cast< const Derived >(
4747
// OK - up-cast is supported
4848
shared_ptr<Base> base = any_shared_ptr_cast< Base >( any );
4949
```
50-
A causal user of ```std::any``` may be surprised to find that ```std::any``` doesn't preserve pointer cv-qualifier promotion (e.g. ```shared_ptr<Derived> -> shared_ptr<const Derived>```) or pointer up-cast behaviour (```shared_ptr<Dervied> -> shared_ptr<Base>```). This is not a ```std::any``` defect. Its primary purpose is to store *objects* and not *references* to an object. In contrast ```any_shared_ptr``` is designed to store *references* to an object and thus preserves normal pointer behaviour. However there's a [catch](#what's-the-catch) if performance is critical.
50+
An occasional user of ```std::any``` may be surprised to find that ```std::any``` doesn't preserve pointer cv-qualifier promotion (e.g. ```shared_ptr<Derived> -> shared_ptr<const Derived>```) or pointer up-cast behaviour (```shared_ptr<Dervied> -> shared_ptr<Base>```). This is simplify a limitation of ```std::any```. Its primary purpose is to store *objects* and not *references*. In contrast ```any_shared_ptr``` is designed to store *references* to an object and thus preserves normal pointer behaviour. However there's a [catch](#what's-the-catch) if performance is critical.
5151
## ```any_shared_ptr``` interface
5252
```any_shared_ptr```'s interface tries to be as consistent as possible with ```std::any_ptr```. The notable exceptions are;
5353
1. The noexcept version of ```any_shared_ptr_cast``` returns ```std::optional<std::shared_ptr<T>>``` and not ```std::shared_ptr<T>*``` as is the case for ```std::any_ptr_cast```. The reason is due to temporary ```shared_ptr<T>``` returned by ```any_shared_ptr_cast``` that's necessary to handle an up-cast which may return a different pointer address where there's multiple inheritance.
@@ -104,7 +104,7 @@ template<class T, class... Args>
104104
bad_any_shared_ptr_cast
105105

106106
## What's the catch
107-
To implement ```any_shared_ptr``` we need a new function, let's call it dynamic_up_cast, that's similar to C++'s dynamic_cast except that it only performs an up-cast. We could try implementing dynamic_up_cast by accessing the compilers internal RTTI data structures in a similar manner as dynamic_cast. However many compiler/platform combinations would require its own implementation which is not very appealing. Instead a better solution is a portable implementation that needs nothing more than standard C++ that's supported by all compilers. The inspiration we need is Cassio Neri's observation [[1]](#references) that throwing and catching an exception can be use to implement an up-cast as shown in the following code snippet.
107+
To implement ```any_shared_ptr``` we need a new function, let's call it dynamic_up_cast, that's similar to C++'s dynamic_cast except that it only performs an up-cast. We could try implementing dynamic_up_cast by accessing the compilers internal RTTI data structures in a similar manner as dynamic_cast. However many compiler/platform combinations would require its own implementation which is not very appealing. Instead a better solution is a portable implementation that needs nothing more than standard C++ that's supported by all compilers. The inspiration we need is Cassio Neri's observation [[1]](#references) that throwing and catching an exception can be used to implement an up-cast as shown in the following code snippet.
108108

109109
```
110110
struct any_ptr

0 commit comments

Comments
 (0)