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

Q&A Panel

50 minutes, 8 seconds


Right click “Save as…”

Attendee-driven Q&A with Day 3 speakers: Herb Sutter, Niklas Gustafsson, Elliot H. Omiya, Sean Parent, Michael Wong, and Eric Brumer.

Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • samsamsamsam

    With slightly better C++ support and C++14 stuff getting added.

    Could ScopeWarden [0] be improved to remove the unsafe macro and have even more performance and usability?

    The examples I've seen generate too much overhead to be useful.

    scoped<HMODULE> dll(LoadLibraryA("kernel32.dll"), [](HMODULE h) { FreeLibrary(h); });

    scoped<int> ptr4(1729, [](int p) { cout << p << endl; });
    scoped<unique_ptr<SomeClass>> ptr4(make_unique(SomeClass(1729)), [](const unique_ptr<SomeClass>& p) { cout << p << endl; });

    scoped<int*> ptr2(new int, [](int *p) {/*last minute stuff*/ delete p; });
    scoped<int*> ptr3(new int[100], [](int *p) {/*last minute stuff*/ delete[] p; });

    [0] http://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavavej-Advanced-STL/C9-Lectures-Stephan-T-Lavavej-Advanced-STL-6-of-n#c634477472460000000


    ScopeWarden indeed used a macro, but I wouldn't say that it was unsafe.  You could say that it detracts from usability.  As for performance, the major cost is storing the "this" pointer for the lambda, which compilers may or may not be able to optimize away (however, you should otherwise get full inlining).  There is a scope guard proposal at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3677.html but I haven't thought about it carefully yet.

    Note that unique_ptr and shared_ptr already support custom deleters.

  • samsamsamsam

    > ScopeWarden indeed used a macro,

    Does that mean you have improved it? Like to share it?

    > Note that unique_ptr and shared_ptr already support custom deleters.

    But they do lots of other things too which is undesirable when you only want to run something when leaving scope, when performance is key.

    I rechecked the binary code from ScopeWarden and it still generates
    inefficient code. Jonas_No mentioned this too.

    To my eyes the compiler should be able to do a better job than what it do now. I really do despise visual studios compiler, it do so many bad things and the bad stuff never gets fixed.

    Compiler rant:
    "Don’t Help the Compiler"
    When I saw the title I expressed a depressed chuckle because the compiler will not do the right thing and you must help it. But as you pointed out in the talk, it will only make it worse.

    We need a feature to control the compiler and tell it to do the right thing. Since the compiler developers refuse to do the right thing.
    "If you want something done right, you have to do it yourself"

    Would it surprise you if I told you I have heard an instance of people patching the binary after compilation to fix the inefficient code?
    It had a big performance increase too.

    That is how desperate people are for a better compiler. Fire the compiler team and get some competent people to replace them. I've heard some competent people work on llvm.

    Even better, open source the compiler or replace the compiler with llvm. That way we can fix the problems ourselves.

  • samsamsamsam

    I forgot, thank you for the scope guard proposal link.
    Very interesting read.

Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.