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

Checking In: Stephan T. Lavavej - Inside STL (the person, not the library)

Download

Right click “Save as…”

Stephan T. Lavavej is a Channel 9 hero. You've learned a great deal from him over the years, but you've not really learned much about him. How did STL—that's what we call him since, well, look at his name and what he does for a living—get to where he is today? What's his story?

Of course, given STL's expertise and passion, this conversation includes STL's perspectives and opinions on C++ programming, compilers, templates, modern C++, STL (the library), and more. But it also includes a more personal perspective, too. How does STL think about computing? And why C++? 

Did you know that STL can compile code in his head? Really.

Erik Meijer leads this friendly interrogation and considering the IQ, passion, and great conversation the hour goes by much too fast. It's a real pleasure to share a more personal piece on STL as an addition to the usual deeply technical and pragmatic lectures and conversations we're accustomed to. But there's certainly no talking to STL without talking about STL and C++. You are definitely going to learn things by listening in. This is for sure.

A huge thanks to Erik for taking the time to do this interview. He was super busy cranking code (C++ at that) on the day we shot this and this interview took him away from his keyboard. Thank you, man.

Thank you, STL, for taking the time to be checked in on.

 

Tags:

Follow the Discussion

  • STL is impressive as always. Looking forward to the production of more STL videos!

     

  • @schroedl:ditto

  • Charles,

    You, STL, Erik, Anders and Don B. are all the aspects of the 5 headed MS Yoda.

    Bravo, on another outstanding "Checking In" episode. 

     

  • Grant BoyleGrantB What the hell are we supposed to use man? Harsh language?

    That's a damn good video guys, I'm going to have to watch that one again.

    Some great discussion on gc, synchronous destruction, etc. Would love to see an extended discussion on that (memory leaks in gc environments,, scaling gc for large heaps or many cores, exception safety, gc for type safety, dealing with non-memory resources).

    Also liked that you keep touching on early warning as a benefit. Could get into static vs dynamic, contracts or static analysis annotations and even the billion dollar mistake.

    (I don't think anyone but Erik could have kept up with STL in this video, he's a machine!)

  • CharlesCharles Welcome Change

    @faperdue2112: Smiley
    C

  • , schroedl wrote

    STL is impressive as always. Looking forward to the production of more STL videos!

     

    and I hope so

  • IvanIvan

    STL rocks...
    regarding 1000x problem... it is really strange, I always thought that for primitive types of same sizeof it cant be different.
    To bad for the NDA :( I would really really like to hear what the bug was.

    Btw one cool question that Chareles could ask some cpp experts is why shared_ptr is not thread safe. Or at least why there is no template argument that specifies it.

  • CharlesCharles Welcome Change

    @Ivan: I don't need to ask. shared_ptr is thread safe...
    C

  • STLSTL

    GrantB> Also liked that you keep touching on early warning as a benefit.

    One of the things we're doing in VC11 is emitting linker errors early, preventing incomprehensible runtime crashes later. (I like to think of this as "breaking users' builds for fun and profit".) Currently, we detect:

    * _MSC_VER mismatch. Mixing STL objects compiled with different major versions of VC is absolutely forever forbidden, because we change their representations. Static libraries are a common way to accidentally do this (e.g. building code with VC11, and linking against Boost static libraries built with VC10). My detection logic works only when both versions involved are VC10+, but it's better than nothing.

    * _ITERATOR_DEBUG_LEVEL mismatch. I've talked about this one a lot, and it's already detected by VC10.

    * RuntimeLibrary mismatch - this is mixing /MT, /MTd, /MD, and /MDd options in a single binary. Dragging multiple CRTs/STLs into a single binary is not good, and now VC11 will detect it.

    Ivan> I would really really like to hear what the bug was.

    http://connect.microsoft.com/VisualStudio/feedback/details/689342/unordered-map-thousand-time-slower-than-the-vc-2010-version

    Ivan> why shared_ptr is not thread safe.

    shared_ptr unconditionally supports the usual thread safety guarantees:

    1. Multiple threads can simultaneously read a single shared_ptr object.

    2. Multiple threads can simultaneously read/write different shared_ptr objects.

    As usual, anything that can be done to a const object counts as a read (e.g. dereferencing, using as the source of a copy, etc.), and everything else counts as a write (e.g. resetting, using as the destination of an assignment, etc.), with construction and destruction counting as writes.

    Unlike the rest of the STL (e.g. vector), where the usual thread safety guarantees are inherently supported without writing any special code, shared_ptr has a couple of twists that require us to write special code. For #1, reads are secretly modifying - if two threads simultaneously copy a single shared_ptr object, each thread will want to increment its refcount. For #2, this must be supported even when the different shared_ptr objects share ownership of something. (In contrast, different vectors don't share anything). If shared_ptr A and shared_ptr B share ownership, and A is reset() while B is copied, A's thread will decrement the shared refcount while B's thread will increment the shared refcount.

    For bonus complexity, weak_ptr adds additional twists.

    This is one of the reasons why having a Standard Library is a good thing.

  • STL,

    As an aside...you're a bit of an inspiration to me Stephan. I also lack steroptic vision abilities, (because of glaucoma/retinal detatchment monkey-business). And you seem to be handling it with your usual subtle coolness. Give - em Hades !!!! Smiley

  • felix9felix9 the cat that walked by itself

    STL is really passionated and thats great. super awesome. Smiley

    A 'What's new in VC11' video will be super too.

    and, Erik Meijer + C++ == ???

  • C64C64

    Very interesting, as usual from Stephan.

    And he nailed the problem of GC vs. C++ deterministic reference counting destruction.

    Thanks for the interview!

     

  • Great video STL.

    Btw, you might find this useful:

    http://www.segwaysafety.com/

    Smiley

     

  • beware: shared_ptr uses Interlocked* to enforce thread safety on its refcounts. if you're false-sharing in the same cache line you can absolutely kill your app's performance.

    speaking of machine models, anyone care to explain pointers to members of classes with mutiple virtual bases? or what happens when an exception is thrown?

  • IvanIvan

    @STL I know what shared_ptr guarantees are , but I see 2 problems with that...
    that it uses atomic operations just to get normal safety. :)
    and that people will guess if it is shared it must be thread safe. :)
    But again I can see why it is not thread safe, AFAIK making pointer thread safe doesnt mean it is thread safe to play with what it points to... again I could be wrong.
    Also I dont know if you can comment on D but if you can I would like to know your opinion on D, esp on TMP. Again just opinion on a language we all know it will never replace cpp. :)

  • STLSTL

    faperdue2112> As an aside...you're a bit of an inspiration to me Stephan.

    Cool, although I've had it easier than most - I was simply born without a right eye, so I never lost anything.

    Have you seen the new Thor movie, with Odin *and* Nick Fury? So awesome. (I especially liked Odin's crown-helmet.)

    Raman_Sharma: Heh. The problem I have with Segway Inc. is that they always show people wearing bicycle helmets, which don't really help with most Segway accidents (and having been through 3, I speak from experience). They do it because bicycle helmets look more approachable, and are appropriate for police officers/security guards, but for serious commuters like me, motorcycle helmets are way better. Even aside from accidents, keeping rain and tree branches out of my face is wonderful.

    piersh> speaking of machine models, anyone care to explain pointers to members of classes with mutiple virtual bases? or what happens when an exception is thrown?

    This is magic beneath my level of abstraction (i.e. I know stuff about it, but not comprehensively).

    Ivan> and that people will guess if it is shared it must be thread safe. Smiley

    Being serious for a moment, "thread safe" is not a useful phrase. I recommend banning it from your vocabulary.

    People sometimes ask whether vector is "thread safe", and I have to explain that it supports the usual thread safety guarantees. They seem to be expecting something different - multiple threads simultaneously read/writing a single object. There are many problems with that, including two especially major ones:

    * Providing that is extremely expensive - every member function must take a lock.

    * Even if provided, that guarantee would be useless in practice. Consider this code:

    if (!v.empty()) {     v.pop_back(); }

    Even if every vector member function took a lock, this code could not be executed on multiple threads (affecting the same v). The problem is that thread A could verify that v is non-empty, then thread B sneaks in and pops v's one and only element, then thread A tries to pop_back() on a vector that's empty. Boom.

    Locks have to be taken at a higher level than individual member functions.

    PPL's concurrent_vector is a lock-free data structure (as usual, "lock-free" means "extremely scary code that should be maintained by experts") that supports very special guarantees. For example, it permits simultaneous push_back(), but clear() cannot be called simultaneously with other things, and (unlike vector) it is not contiguous.

    > Also I dont know if you can comment on D but if you can I would like to know your opinion on D, esp on TMP.

    I have no interest in D. I don't need and don't want garbage collection, and it has "const propagation" which is incredibly wrong (C and C++ get this right).

  • GlenGlen

    Great video. Thanks Charles, thanks STL.

    It's good to see Stephan talking passionately about C++ and STL and standing up for the design choices in both - he is a great advocate for the language and an asset to the team.

    STL, you mention static_assert. It sounds like it wouldn't take much to bend the code of that feature into implementing static_if. What is your thoughts on that?

  • IvanIvan

    @STL
    "Being serious for a moment, "thread safe" is not a useful phrase. I recommend banning it from your vocabulary." I agree(because I agree with philosophy that I think you endorse(again my mind could be playing tricks on me :) ):"you need to be able to quickly learn and unlearn :) things." ), is MRSW and MRMW ok terminology?

    "I have no interest in D. I don't need and don't want garbage collection, and it has "const propagation" which is incredibly wrong (C and C++ get this right)."
    Now I dream of Andrei(Charles can correct me but I think that Andrei said many times that he thinks that D is the only language that gets immutability right) vs STL E2E. :)

    Also can I ask you some style question: sometimes I'm tempted to use size_t instead of int for idx but then sometimes I get into troubles when I need to do reverse pass(while idx>=0/*always true for unsigned ints, size_t is unsigned int */ { ... idx-=block_size }). Do you have some advice, except avoiding idx arithmetics. In some cases I really need it (for eg. because my inputs are char arrays).
    P.S. you are really cool, but I feel that you resist new things to much => you should try VS, not because you work for MS but because it is really nice tool(disregarding "c++11 support" :) ).

  • NovoxNovox “Simplicity is the ultimate ​sophisticat​ion.” —Leonardo da Vinci

    Now I dream of Andrei(Charles can correct me but I think that Andrei said many times that he thinks that D is the only language that gets immutability right) vs STL E2E. Smiley

    Now this would be certainly an amazing E2E, indeed!

  • Using /vmg  in a static library, but not using it in the application also creates a nasty runtime crash.

    See http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/be4af7c2-db82-4976-9faf-df924b4d7339  for details.

    So if you are already in the area of preventing incomprehensible runtime crashes by detecting problems due to mismatched compiler options in the linker, perhaps that error might be detected too.

     

  • CharlesCharles Welcome Change

    @Ivan: Re Andrei on D (I'm not qulaified to speak on his behalf, obviously...) : Check out what he says: http://channel9.msdn.com/posts/Scott-Meyers-Andrei-Alexandrescu-and-Herb-Sutter-C-and-Beyond#time=04m17s (Why D?) Watch it for the entirety of the discussion on D. Maybe you'll find what you're looking for.

    C

  • STLSTL

    Glen> STL, you mention static_assert. It sounds like it wouldn't take much to bend the code of that feature into implementing static_if. What is your thoughts on that?

    There's already a perfectly good mechanism for that - overloading on true_type and false_type.

    Ivan> is MRSW and MRMW ok terminology?

    What does that mean?

    Ivan> sometimes I'm tempted to use size_t instead of int for idx

    size_t respects 64-bit, while int doesn't.

    Ivan> but then sometimes I get into troubles when I need to do reverse pass

    ptrdiff_t is size_t's signed partner. Both are provided by stddef.h.

    bdhc73a> So if you are already in the area of preventing incomprehensible runtime crashes by detecting problems due to mismatched compiler options in the linker, perhaps that error might be detected too.

    The compiler would have to do that - I don't believe that /vmg can be detected through macros.

  • IvanIvan

    @STL
    MRSW =multiple readers single writer... MRMW= multiple writers Ofc on the same mem location
    Tnx for the ptr_diff. Still makes me nervous on 32 bit(because it cant represent some gigantic diffs like 1.5*2^31-0.4*2^31=1.1*2^31>INT_MAX :( )
    But luckily Im now always on 64b, so I hope there it is guaranteed to be correct.

    BTW you probably dont remember but i was harrasing you before about difference between map.count and count(map.begin()) ... point is that specific implementation gives gigantic speed boost :) for large containers. What I was thinking since that discussion ...were you ever tempted to try to create some warning about using "global" find or count function on RBTree based ontainer. If not for VS then just for the internal MS use.

  • STLSTL

    > MRSW =multiple readers single writer... MRMW= multiple writers Ofc on the same mem location

    That's not focusing on the right thing.

    The right thing to focus on is the guarantee that's naturally provided by a class where reads are really reads (not secretly modifying) and where different objects don't share data. This guarantee is provided by vector and other STL objects, and is the strongest guarantee that can be conveniently provided. Classes that don't naturally provide this guarantee should think strongly about providing it with special code (as shared_ptr does, and as our debug mode STL does).

    Conversely, if you need something stronger than this usual thread safety guarantee, you should take locks, or use very special data structures like concurrent_vector.

    > Tnx for the ptr_diff. Still makes me nervous on 32 bit(because it cant represent some gigantic diffs like 1.5*2^31-0.4*2^31=1.1*2^31>INT_MAX Sad )

    ptrdiff_t can store the difference between two pointers. It doesn't have anything to do with floating-point.

    > were you ever tempted to try to create some warning about using "global" find or count function on RBTree based ontainer.

    That is within our power, but I don't believe it's worth the cost (almost everything has a cost in complexity).

  • IvanIvan

    @Charles
    I watch all c++ tags on C9. :)
    So I saw that, I was happy that Andrei said that Bjorne was one of the great language designers :)
    What is also cool (because STL doesnt like const in D) that Andrei said that he thought that const was unforced error in c++ but now he doesnt think so. :)
    Also this discussion with STL reminds me that it would be cool to have some lectures about TBB/PPL, in a way that STL had a great indroductory series on STL.

    @STL
    "ptrdiff_t can store the difference between two pointers. It doesn't have anything to do with floating-point."
    You misunderstood my concern. I was just talking about the point that signed 32 bit int cant store the diff between all pairs of UNSIGNED ints. That is why i used 1.5*2^31 and 0.4*2^31.(lets ignore if those ints really exist :), I was concerned with their diff)
    For example if it was 8 ibt instead of 32. [-128,127] range cant represent all the diffs a-b where a,b in [0,255], for eg a=10, b=222 diff=212,212>127

    "That is within our power, but I don't believe it's worth the cost (almost everything has a cost in complexity)."
    Now I'm confused... :) Cost as in implementation cost or runtime cost. ? I presume it can be detected at compile time so I presume you mean implementation cost.

    And one small question: do you agree that iterators must go? :)
    I presume that you know what I'm talking about but if not it is a talk from Andrei Alexandrescu where he proposes smothering iterators and replacing them with ranges.

  • STLSTL

    > I was just talking about the point that signed 32 bit int cant store the diff between all pairs of UNSIGNED ints.

    Ah. In C and C++, subtracting arbitrary pointers is forbidden - they have to point within the same array. So a 32-bit implementation just needs to forbid 2GB+ arrays, and a 64-bit implementation just needs to forbid Galaxy-class arrays, and then the result of pointer subtraction will always fit in ptrdiff_t.

    > Cost as in implementation cost or runtime cost. ?

    Implementation cost. Someone has to write and maintain every line of code.

    > do you agree that iterators must go? Smiley

    I saw his BoostCon 2009 keynote in person, and I disagree in the strongest possible terms. Ranges are awesome as packages of iterators. Ranges are terrible as fundamental entities.

  • jackjjackj

    @Charles: thanks for posting this video. As usual it was great!

    @STL: thanks for sharing your insights, but I got the impression you were cutting Erik off all the time. It's usually better to let the other person articulate their viewpoint, whether one agrees with what they have to say or not.

    @Erik: I'm really impressed by your ability to be so respectful even when being interrupted. (I noticed something similar in the Sutter interview, esp. when he insulted Haskell users.)

  • CharlesCharles Welcome Change

    @jackj: STL wasn't being rude. He's got a lot to say, is all! Erik wasn't offended in the least. Next time, Erik will need to get his questions out faster Smiley

    C

  • STLSTL

    Apparently that's a thing I do without realizing it.  I recall someone complaining after one of my shared_ptr presentations in 2007-2008 that I kept stepping over people during the Q&A instead of waiting for them to finish.

    I'll try to keep this in mind.  I think what happens is that when I can see where someone's going, I jump right to the end and begin replying.  It's not that I think 10x faster than humans, it's just that in areas I'm familiar with I can usually see where things are going.  I might have picked up this habit from high school Knowledge Bowl, where buzzing in before the end of a question was critical.  (My best answer: "This planet's magnetosphere" --BUZZ-- "Jupiter.")

  • CharlesCharles Welcome Change

    @STL: Smiley
    C

  • IvanIvan

    @STL
    so can I get your opinion on boost::range? Useless, usefull in some cases but not all...
    BTW one thing I dont like about cpp that you cant tell the language what to expect. For example I alreday harrased :P you about the fact that RBTree containers cant preallocate space even if user wants it. What I would like to ask you do you believe that std should adopt something like
    http://llvm.org/docs/ProgrammersManual.html#dss_smallvector
    link is llvm but Charles is AFAIK OK with people mentioning gcc so I presume LLVM is not illegal, also it has nice words for your favourite container ("std::vector is well loved and respected. ") and MSVC ("e.g. libc++ and MSVC provide a highly optimized string class, *** contains a really slow implementation"). :)

  • STLSTL

    I figured out that unordered_map<double, X> perf bug. It was awesome. (Hint: debug into its hashing.) I'm currently fixing that and significantly speeding up our other hashes like for unsigned long long.

    > so can I get your opinion on boost::range?

    Haven't used it.

    > What I would like to ask you do you believe that std should adopt something like [SmallVector]

    That's currently being discussed on the Boost mailing list. My feeling is "maybe" - it is sometimes desired. Note that such a data structure differs from std::vector in important ways - std::vector is efficiently movable and swappable with just a bit of pointer twiddling, and its swaps are O(1), nofail, non-iterator-invalidating.

    DIRE WARNING: Never attempt to give an STL container a custom allocator that returns memory from "inside itself". This is forbidden by C++98/03/11 and VC11's optimizations will break such code.

  • BekennBekenn

    @Ivan: > sometimes I'm tempted to use size_t instead of int for idx but then sometimes I get into troubles when I need to do reverse pass

    This is what I do:

    for (size_t n = count; n-- > 0; )
    {
    // do stuff
    }

  • IvanIvan

    @STL @ hash bug
    cool,
    do a show on it :)
    Im serious... at least it wont take long, people like me love cool bugs and you can show some mad debugging skillz. :)
    @Bekenn problem is that sometimes i dont do n-- i do n-=block_size...

  • IvanIvan

    @
    STL
    "
    DIRE WARNING: Never attempt to give an STL container a custom allocator that returns memory from "inside itself". This is forbidden by C++98/03/11 and VC11's optimizations will break such code.
    "
    Can you expand on inside itself... I mean does that prevent someone more skilled than me map allocator that does the allocate in 32*sizeof(element) chunks? BTW I know that this means that map could end up using 32x more space than needed, but it is a rare rare case and could be avoided with some maintenance from the allocator...

  • STLSTL

    I'm referring to allocators that store an array as a data member, and hand out pointers to within that array when they're asked for memory. Such "stack allocators" are forbidden by the STL.

  • I found a way that should help me with the /VMG problem.

    #pragma detect_mismatch( "name", "value"))

    http://msdn.microsoft.com/en-us/library/ee956429.aspx

  • Hi STL! Your videos are really awesome and is helping me to love the C++ language even better. You said in one of your initial videos that you will do a tutorial on "Iterator Invalidation". Waiting for the video Smiley

Remove this comment

Remove this thread

close

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.