Olivier Langlois

> AFAIK, #42 does not change this behavior. correct... but I think it is less good because: 1. It bypasses the iterator debugging code found in replace() 2. It adds...

there is one thing that I wonder about... How do compilers choose the correct overload replace() when only 1 parameter is passed to the emplace functions? That might be what...

no worry. I have been able to reproduce the issue... I think that the initial PR prior to rework to address the code review was working fine. This is the...

thx! This is exactly what I was looking for... Yesterday, I have written the feature myself and after reviewing the PR commits, I find it recomforting that I have came...

what was the problem with the initial replace() code? I left a comment about what I feel was observed here https://github.com/boostorg/circular_buffer/pull/15#issuecomment-1572194345 this is an excellent PR but I would sort...

Here is my take. This is a patch over branch after having reverted "replace replace() with destroy_item() + construct()" This reverts commit c4c85d730dc8e31c4d50aa45ada146ce8c2f5340. ``` diff --git a/include/boost/circular_buffer/base.hpp b/include/boost/circular_buffer/base.hpp index 5ed1321..846cb32...