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

Hi,

I might be wrong but when you are talking about Standard C++ you are talking about the C++ not running on the CLR right? I always used "Thinking in C++" from bruce eckel te learn C++.

Great video !

So C++ CLI is less recomended? I mean if you want to make it easy you should use C# or VB and if you disside you really want performance and don't mind the extra knowledge you need to make a decent C++ program you should use native C++ and not C++ CLI, right?

Thanks for the claryfication ! Thanks Charles !

Hello

> “As always, use the right tool for the job at hand.”

Or as my mother would tell me: “to a man with a hammer everything looks like a nail”.

I just want to reinforce the comment Charles made above – knowing all the tools of your trade is vital if you want to do any engineering discipline. If you want to build a managed-only application  today, the right tools for that job would be C#/VB/F# (my personal favorite of those would actually be F#– but that is purely my personal preferences coming through ) If you want to write a high performance native application, then you are probably going to use C/C++. If you want to mix native/managed then write the native parts in C/C++, the managed parts in C#/VB/F# and do the interop shim in C++/CLI (and keep it is small as possible, keep it self contained,  avoid chatting interfaces, … – alternatively you can use PInvoke or COM Interop but I am sure you understand the idea.)

BTW: Stephan really is as enthusiastic, passionate and knowledgeable as he appears in the video – this is what makers coming to work here every day so enjoyable.

And as Charles said, we have a few more Channel 9 on the way (the pause was caused by waiting until VS2010 Beta 1 came out – it is so much more fun to describe these features when you can actually play with them too.)

Thanks

Damien

Hello

> Or as my mother used to say "When your hammer is C++, everything starts looking like a thumb"

That is why man evolved to have two thumbs (even way back then someone knew C++ was on the way.)

Thanks

Damien

Hello

So on one level we do not actually have “managed C++” guys, when I say I am the PM for the compiler FE and libraries on the Visual C++ team that means both native and managed. To be direct, in VS2010 our focus was on the native developer. With VS2008 and immediately prior releases (in both compiler work - such as “C++/CLI” - and libraries work - such as “STL/CLR” and the “Marshalling Library”) we felt we had devoted sufficient time recently to “managed C++” developers, potentially at the expanse of the native code developer in some ways. So, as you can see in the current beta, there is not that much new for “managed C++” code developers in VS2010. However some of the new features work both ways, try using auto in managed code for example. But I also want to be very clear and respond to your “abandoned” comment, this emphasis on native code development in VS2010 is really a re-balancing of efforts (native had been underdone for a while) and is in no way any indication of relinquishing anything.

Thanks

Damien

Hello

I took no offence from your statements and did not think you said anything negative. It is just that other readers can accidently read unintended intentions into my posts/replies, so sometimes I find it is just best for me to be super explicit

I would agree that recently C++/CLI has found a place as the interop language - while C#/VB/F# add new functionality at a pace that we cannot keep up with if we are also to innovate in the native space as well. And since we are the only native game in the VS box I personally feel we need to devote more time to the native arena then we have in recent releases,

Personally I am very happy about the new features in C++0x – I agree they took a long time to get here and unfortunately we could not do more of them for VS2010. As we said in the interview, not having variadic templates in VS2010 is Stephan’s and my biggest regret (although we also would also have wanted nullptr too.)

 Thanks

Damien

Hello

Have a look at this video for more details on the PCP/lambdas work for VS2010: http://channel9.msdn.com/shows/Going+Deep/Parallel-Computing-in-Native-Code-New-Trends-and-Old-Friends/

 Thanks

Damien

Hello

We do mention somewhere in the video that now we have the re-implementation work completed we will look at performance/cost for the iterator switches and may change the default for VS2010  - no concrete decision yet but stay tuned (as always you will be able to simply switch between the default and whatever you want by defining a macro too.) But we do hear you on the default issue.

Thanks

Damien

Hello

BTW: both Ale (Contenti) and Louis (Lafreniere) have Channel 9 videos in the pipeline - and we also have a new face on the way too.

Thanks

Damien

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

I was referring to the layout of shared_ptr itself. shared_ptr always stores two raw pointers: a pointer to its object and a pointer to its reference count control block. This is true regardless of how the shared_ptr is constructed, whether through the ordinary way or through make_shared().

What I was talking about in the video was that when you use make_shared(), the pointer to the reference count control block is technically redundant, since the object and the reference count control block live at the same location. However, this redundancy is unavoidable, since make_shared() has to return a shared_ptr, which always stores two raw pointers.

make_shared() does squeeze out redundancy in what those raw pointers point to - by allocating the object and its reference count control block in a single chunk of memory, it saves one memory allocation's worth of overhead. Also, ordinary construction makes the reference count control block store a raw pointer to the object (this is in addition to the raw pointer to the object stored by the shared_ptr itself), but make_shared() doesn't need to store this; the reference count control block already knows where the object lives.

> But I am not getting how the library can "know" what layout is used.

Virtual functions power this particular magic trick.

Your scenario assumes that shared_ptr's destructor (and reset(), etc.) knows how to delete its owned object, and you're rightly wondering how it can tell the difference between ordinary construction (two dynamic memory allocations) and make_shared() construction (one dynamic memory allocation). But before we get to that, consider shared_ptr's support for custom deleters.

You can construct a shared_ptr by giving it a raw pointer (obtained from "somewhere") and a custom deleter, which is a functor of arbitrary type. When the last shared_ptr dies, the custom deleter is called with the raw pointer, returning it "somewhere". This is useful, because otherwise shared_ptr expects new/delete. Note the following important fact:

The custom deleter's type doesn't affect the shared_ptr's type.

shared_ptr<T> is templated on the object type T, but not on the custom deleter type D. You can, in fact, construct one shared_ptr<T> owning a new T, and another shared_ptr<T> owning a custom-allocated T with a custom deleter D, and each shared_ptr destructor will call the right deleter (plain old delete in the first case, D in the second case). But how is this possible, given that D has arbitrary type? (If it were an arbitrary function pointer of fixed type, void (*)(T *), say, then no magic would be involved.)

The answer is that when shared_ptr's constructor (or reset(), etc.) constructs a reference count control block, it knows whether it's using a custom deleter or not. (shared_ptr's one-arg ctor takes T *, while its two-arg ctor is templated on D and takes T * and D). shared_ptr stores T * and RefCountBase<T> * (not its real name, of course). RefCountBase<T> has a virtual void DeleteObject() member function. shared_ptr's one-arg ctor constructs a RefCount<T>, derived from RefCountBase<T>, that overrides DeleteObject() and simply calls delete p;. shared_ptr's two-arg ctor constructs a RefCountCustomDeleter<T, D> (this is templated on the deleter's type, since the two-arg ctor is templated on the deleter's type), derived from RefCountBase<T>, that overrides DeleteObject and calls d(p);. The deleter is stored in RefCountCustomDeleter<T, D>. Then, when shared_ptr's destructor (or reset(), etc.) runs, it calls m_refcount->DeleteObject(), where m_refcount is RefCountBase<T> *. This selects the right virtual function.

This trick is known as "type erasure" (I usually call it "type forgetting"). shared_ptr "forgets" whether it has a custom deleter at all, including what type the custom deleter is, so that the shared_ptr's type isn't affected. But this knowledge is recovered when the object is destroyed, through that virtual function call, so that the custom deleter is properly called if present.

The same trick is used for make_shared(). When you call make_shared(), it constructs a RefCountUnified<T> object, which stores the T. Its DeleteObject() implementation simply destroys the T in-place. shared_ptr itself doesn't know anything about this, and it doesn't have to. (However, make_shared() must be implemented by the Standard Library, since users can't provide their own reference count control blocks. It's possible to "fake" the single dynamic memory allocation with custom deleter and custom allocator support, but this doesn't result in the same space efficiency.)

Type erasure is important because it significantly increases shared_ptr's usability. You can pass shared_ptr<T> around without caring where it came from, whether from something with a custom deleter, a custom deleter and a custom allocator, make_shared(), or allocate_shared() (which is make_shared() plus a custom allocator, naturally).

Hello

FYI: we just posted on our VC Blog about some STL performance results we have been seeing recently using the new C++0x functionality: http://blogs.msdn.com/vcblog/archive/2009/06/23/stl-performance.aspx

Thanks

Damien