----- Original Message ----- From: "Vicente Botet Escriba" <vicente.botet@wanadoo.fr> ... Hi, I'm aware of your proposal Vladimir :) ... BTW, does your library provides a RecklessPimpl implementation or something like that?
You are right, it does not. For quite some time I shared H. Sutter's point of view that the RecklessPimpl-based solution was, well, evil. :-) Then, I read Tony's explanations and that did not look that scary to me after all... if as Tony's suggested all the "nastiness" is encapsulated in RecklessPimpl. Now that I am thinking of the RecklessPimpl-based Pimpl, I see that it does provide the implementation-hiding property. However, what troubles me is that we seem to lose the other important Pimpl property -- the separation of the interface and implementation. Namely, if the internal implementation size changes, it has to be reflected in the public header. So, all the user-code has to be recompiled. Still, elimination of the memory-allocation-related overhead of the RecklessPimpl-based Pimpl looked very attractive. Then, I thought that a fixed-size allocator for the XImpl implementation class might be a good-enough main-stream alternative. Granted that a fixed-size allocator might not be as fast as allocation on the stack. More so, if my experience is of any guidance, I overwhelmingly use pimpls with pointer semantics. In my code they outweigh pimps with value semantics like 100:1. I am under impression that the RecklessPimpl-based Pimpl only provides value semantics. All in all, IMHO the RecklessPimpl-based Pimpl might be a nice fit for certain tasks. However, I am under impression that it is not generic enough... and, in fact, not Pimpl enough as it loses the separation of the interface and implementation and does not provide pointer semantics. All IMHO, of course. Best, V.