On 30/05/2016 12:29, Vladimir Batov wrote:
Again, I feel you are rushing things. Adapting doccs and putting it into Boost namespace are minor issues to be addressed in due course.
It would be minor if your entire design wasn't based around template specialisation. Since it is, however, it becomes a major consideration since it directly impacts the primary API of the library.
On 05/30/2016 10:08 AM, Gavin Lambert wrote:
(Though even being in the global namespace doesn't avoid this clunkiness, if the user classes are themselves in a non-global namespace.)
That's something I do not understand. I have plenty of classes like:
template<> struct pimplchart::panel::leg::implementation.
This can't exist inside a "namespace chart { namespace panel {" block. If you have the convention that these blocks span the file, it means you either have to put such specialisations at the top or bottom of the file outside the namespace block (which may break locality) or you have to close the namespace blocks and reopen them later (which is ugly). (Imagine the case where you want to define some detail classes that only exist in the implementation *first*, then the pimpl definition, then the public interface. The first and last should be in the local namespace [or child thereof]; the second can't be. And they have to be defined in that order due to the dependencies.) Granted implementation files don't *have* to have namespace blocks -- they can use using directives or explicit naming instead; but the latter is ugly and the former risks accidentally defining global symbols, so it's generally safer to use namespace blocks instead.