Part 1 of my video lecture series exploring the Standard Template Library's implementation is now available. In this part, I explain how some of shared_ptr's magic works, including type erasure and make_shared<T>()'s optimizations that save both space and time.
This advanced series assumes that you're familiar with C++ and the STL's interface, but not the STL's implementation. If you haven't used the STL extensively yet, I recommend watching my introductory series. For reference, here are all of the links:
Part 1 (sequence containers)
Part 2 (associative containers)
Part 3 (smart pointers)
Part 4 (Nurikabe solver) - see Wikipedia's article and my updated source code
Part 5 (Nurikabe solver, continued)
Part 6 (algorithms and functors)
Part 7 (algorithms and functors, continued)
Part 8 (regular expressions)
Part 9 (rvalue references)
Part 10 (type traits)
Part 1 (shared_ptr)
Stephan T. Lavavej
Visual C++ Libraries Developer
I love the series. But I've always been concerned that so much focus is given to STL when the C++ Standard Library is bigger than that.
Where is the series on iostream? Or on locales? These things are rarely if ever discussed; there are whole books on STL and using it properly, and most of them completely ignore locals or iostream. I'd love to see some real discussion of how best to use these two features.
That's a reflection of my knowledge - I'm not an expert at iostreams/locales.
@Nicoi, STL is based on modern generic programming designs, so thats' what is most useful to learn. Iostreams represent dated designs, in that they where added to the language before the STL. They rely on highly coupled inheritance hierarchies (with virtual inheritance uglyness) instead.
Stephan, good video as always.
Great one! Extractly what I needed!
Something I would like to understand better is unordered_map etc.
Some days ago I tried to write a custom hash function for a compound data type, but it was a very hard nut to crack (there are only very few examples available). It always failed with an C2440 error in xfunctional (which I didn't understand). The same problem occured with 'google sparsehash'.
Section 20.2.4 [hash.requirements] of the C++0x Working Paper N3225 specifies what you must implement - and it's actually pretty easy, you just need "size_t operator()(const Key&) const" that behaves sanely (e.g. equivalent keys MUST have identical hashes).
Without a self-contained test case, I can't diagnose the specific problem you encountered.
Bigger tools window font
Explanation for the visualizers failing to show the expected names
Why delete this, again?
> Bigger tools window font
I don't know how to modify the Watch (etc.) window's font, or whether that's even possible. If someone could enlighten me, I'd appreciate it.
> Explanation for the visualizers failing to show the expected names
I suspect that I had messed with my visualizer file, and forgot to restore it to its original condition. I've reformatted my laptop to purge such weirdness.
> Why delete this, again?
Assuming you're asking about "delete this;" in shared_ptr's machinery, when all shared_ptrs and weak_ptrs to an object are destroyed/reset/reassigned/etc. the refcount control block needs to be deleted. Our implementation gets the refcount control block to delete itself with "delete this;" which is perfectly conformant as long as it's the last action performed by that object - which it is.
To change the size of the text in the watch window do the following.
Menu -> Tools -> Options..
Options Dialog -> Environment -> Fonts and Colors
Select the drop combo for Show settings for:
Select Watch Windows
Change the font size to what you want. This will make the lines of the watch window bigger.
Delete this again was in regard to this (that) being the second time it was typed. The day or two before it was there, and seen, but the following (or two) day was gone. Same content. Rearding the watch/etc font, if you have not said (why are these names not what I expect) I don't believe anyone would/could have noticed since it's just a blur in the video. The text editor size seems okay. I dread reformat. I put off using my win7 machine for 6 months because I would have to re-install so much. Took two weeks. I suppose you have things all set up. Maybe enen a ground crew to handle that stuff.
PS. "Implemenation" details are so much simpler to understand than the abstract. If you were to share more "implementation" details (these can be very short; in my opinion you went 300% too long in shared_ptr - we liked the very simple-to-follow drawings) .. on the abstract STL you cover. This would be very useful for understanding what's going on. It doesn't matter that the implementation might/will change. I mean, seriously, shared_ptr were trivial when presented in the diagram. You could have turned off the audio and still gotten what was going on.
Stephan, can you explain how does enable_shared_from_this fits into this picture? How does the data structure look like?
" Rearding the watch/etc font, if you have not said (why are these names not what I expect) I don't believe anyone would/could have noticed since it's just a blur in the video. "
Then you were watching a low quality video or at too low a resolution, I was able to read it just fine. I watched the high quality video maximized on my 1920x1200 screen.
"these can be very short; in my opinion you went 300% too long in shared_ptr - we liked the very simple-to-follow drawings"
I was fine with the level of description in this video.
Mike00001: Thanks, that worked! All shall love Consolas 20 and despair.
BIG FONT> I dread reformat.
Me too. I never reformat my home computer, I just build a new one from scratch every 3-4 years. There's less to configure on my work computers, so I can stand to reformat them occasionally. And I have the lightest footprint of all on my work laptop - it's really just for Channel 9 and the occasional Powerpoint presentation.
BIG FONT> Maybe enen a ground crew to handle that stuff.
I wish. No, it's just me.
BIG FONT> I mean, seriously, shared_ptr were trivial when presented in the diagram.
That would be because it took me hours to create those diagrams. (I can scribble them out quickly, but making graphics that look nice takes forever.)
Lrdx> Stephan, can you explain how does enable_shared_from_this fits into this picture? How does the data structure look like?
enable_shared_from_this<X> contains a weak_ptr<X>. When a shared_ptr<X> acquires ownership of an X *, it determines whether X derives from enable_shared_from_this<X>. If so, the internal weak_ptr<X> is set to point to the object and its refcount control block. That way, calling shared_from_this() can return a shared_ptr<X> that knows about the refcount control block, but the internal weak_ptr<X> doesn't keep the object alive forever (if it owned itself that would be bad).
I meant the whiteboard diagram. Very good enough. I am generally distracted by colorful/gradient-filled rounded-corner flowchart-like diagrams. I look away as Dracula does at the sign of a cross.