I can't remember when I was last as excited about a project as about CoApp. As someone who had to compile gzip, libiconv, SQLite3, boost myself for a project in the past, and now in the process of compiling other libraries (libao and glib), CoApp seems like
you briefly mentioned the issue of mixing the 2 layouts of shared_ptr and that they have to match to avoid crashes and worse things. But I am not getting how the library can "know" what layout is used. Consider this:
auto sp = make_shared<string>("meow");
shared_ptr<string> sp2 = sp;
sp expects the string object and refcounts and the deleter object to be in one allocated memory block, sp2 has to expect the string object is in one allocated memory block and refcounts with the deleter object in second allocated memory block.
Now if in the end, sp is the last one destructed of any shared_ptr sharing content of sp, everything is fine, since sp expects the same layout as the actual one and will do one free.
But if in the end, sp2 is the last deleted, then it must do 2 frees, when only 1 block has been allocated, which makes the incorrect behavior.
Only 2 solutions I imagined are:
1. that shared_ptr constructor from pointer - shared_ptr<T>(p) - would allocate the one block like make_shared does, initialize refcounts and custom deleter and use new(block)(*p) to copy the object into the block, and then call delete p; since the contents
are already copied. But this involves 2 allocations, 1 copy, 1 free, instead of original 2 allocations you demoed on the whiteboard.
2. Or shared_ptr destruction logic could look if the 2 pointers it contains (to the real object and to the refcounts) differ only by sizeof(T) and dynamically decide which version of destruction to use.
So could you please explain how do these 2 forms of creating shared_ptr objects coexist together?
BTW. thanks for both your videos and all your C++0x blog posts, I am learning a great deal about C++0x from them, just like "release does not exist until you blog about it", I feel like C++0x does not really have a feature until you blog about it