On 13/07/2016 19:45, Jonathan Wakely wrote:
On 22/06/16 22:05 +0200, François Dumont wrote:
Hi
Here is eventually the so long promized patch to introduce Debug
algos similarly to Debug containers.
I'm trying to decide how much benefit this really gives us, and
whether the obfuscation to the code (even more namespaces involved,
and having to use __std_a:: instead of std::) is worth it. It also
means more code to maintain of course, with extra overloads.
Why such an evolution:
- More flexibility, debug algos can be used explicitely without
activating Debug mode.
Although nice in theory, I doubt this will get much usage in practice.
- Performance: Debug algos can get rid of Debug layer on top of
container iterators to invoke normal algos. Operations on normal
iterators are faster and we also benefit from the same algos
specialization that sometimes exist on some container iterators (like
std::deque ones). Also normal algos are now using other normal algos,
Debug check won't be done several times.
- It will be easier to implement new Debug checks without the
limitation to do so through some Debug macro
To do so I introduced a new namespace __cxx1998_a used for normal
algos when Debug mode is active. I couldn't reuse __cxx1998 cause
with current implementation of Debug containers __cxx1998 is exposed
and because of ADL we could then have ambiguity between Debug and
normal versions of the same algos. I also introduced a __std_a
namespace which control the kind of algos used within the library
mostly for containers implementation details.
I think I need to apply the patch locally and spend some time looking
at the new structure, to see what ends up calling what. I'm finding it
difficult to follow that just from reading the patch.
This is definitely more code to maintain but I hope this code won't
require much maintenance as it only host the Debug logic and not the
algo logic itself. It relies on normal algo for algo logic.
You can see this patch as a way to cleanup the normal mode too !
If __cxx1998 namespace was perfectly encapsulated we could avoid the
__cxx1998_a but for the moment the boundary between normal and debug
mode is too tight.
François
