Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Boris Dušek

Boris Dušek Boris Dusek

Niner since 2009

  • Garrett Serack - Open Source on Windows and the CoApp Project

    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 a blessing.

     

    A scenario I also thought about is to allow for Visual Studio users to very easily use 3rd-party libraries provided through (not only) CoApp. See my feature request for Visual C++: https://connect.microsoft.com/VisualStudio/feedback/details/594909/c-easy-using-of-3rd-party-libraries

     

    Thanks for your work! I can't wait for CoApp to become available and used Smiley

  • VC 10: Stephan T. Lavavej and Damien Watkins - Inside STL

    Thank you very much for the thorough explanation, now I completely get it! I was familiar type erasure already (e.g. any_iterator, adobe::poly), so it's interesting to see it in action again.

    Thanks again, Boris

  • VC 10: Stephan T. Lavavej and Damien Watkins - Inside STL

    Hello Stephan,

    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?

    Thanks, Boris

    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 Smiley

  • VC 10: Stephan T. Lavavej and Damien Watkins - Inside STL

    Hi,

    I am not sure I am hearing right - the team that wanted you to implement lambdas (approx. 08:00 in video) - is it "PCP"? What does that stand for? (I guess not Power Conservation Program -Smiley

    Thanks, Boris

    Update: oops, should have waited 6 minutes - it's Parallel Computing