Hi Andreas, Instead of replying point by point, let me summarize your message and reply in general. 1. My one sentence summary of your rationale was unfair 2. If I object to part of your library I should offer a concrete proposal to fix it 3. If I want to understand where the performance bottlenecks are, I should examine the code. I'm still not sure what part of my summary was wrong, but I'm sorry I offended you. What I would like to see in the rationale is a comparison of a small handful (2-5) of alternate implementation technique, either approaches taken by other libraries or approaches you tried yourself early in development, together with an explanation of why they fail to satisfy the requirements. I realize you do mention some other frameworks, but you don't sketch their design/implementation or show how they fail to satisfy the requirements. Furthermore, readers wishing to understand the performance limitations of your library should not have to be told to examine the code. You should provide a section giving a fairly detailed presentation of the implementation, explaining where the performance problems arise. Andreas Huber wrote:
Jonathan Turkanis wrote:
Andreas Huber wrote:
Jonathan Turkanis wrote:
- The restriction on event deferral -- one must pass an event pointed to by an instance of intrusive_ptr -- is extremely inelegant:
You don't explain why a pointer to a dynamically allocated event can't be passed.
I could offer such an interface, but that would leave users guessing who will be deleting the event after consumption.
Jonathan