C9 Lectures: Stephan T Lavavej - Advanced STL, 3 of n

Nice coincidence, I was reading a short text from Giovanni Dicanio about SCL to gain performance but lost protection.

Thanks again Stephan come with a razor sharp explanation, and plus insight of new IDL. The 'undocumented' feature that text out structure are very nice, my students (and I included) will like have fun visual info when I ask then to deal with command prompt only

Pardon my ignorance, but the source code still compare pointers to 0 (zero), its not the case to use nullptr?

/d1reportSingleClassLayout is super

Can the linker detect ODR violations when you use whole program optimisation?

STL: To zoom into those dialogs you can press the Windows Key + "+" to zoom in on the screen using software zooming, it's a Win7 feature not many people use but could be useful if u remember it and even a few of the Windows key + # shortcuts in the future like opening that console after breakpoints as long as its <10 icons in the taskbar.

OMG... /d1reportSingleClassLayout* is just awesome I feel like a newb again looking at some of my whacky class datastructure diagrams from older code That is officially awesome++.
I also think that undname is pretty usefull too, sometimes mangled names arent so easy to decipher on 1st glance to me, especially looking at video convertters and filesystem structs where their... enormous. You should probly update it though for not needing the "> >" template space like at the end like what it used to require.

Liked this video more than the others because "undocumented feature examples" are valuable when their this usefull, since I tend to always optimize beyond Debug level help and have always needed to just picture it in my brain which isnt so hard but using this just makes it easy enough a 4th grader could grok

Nice lecture [ though perhaps I've enjoyed the prior (more Standard C++) ones a bit more ].

BTW, /d1reportAllClassLayout is also pretty cool

That linker pragma missmatch feature is very important. 
Frankly I have find it a bit embarrasing that the C++ language standard says nothing about the linker. Version managing binary compatibility between libraries is unforgivably hard to do in C++. All this standarisation effort and type safety improvements that is done on the compiler, an none on the linker.
I wish this linker missmatch feature was somehow automated even for user defined classes. Maybe if the linker could somehow automatically calculate a short checksum for every type (maybe based on  structures, size, or compiler switches) and then include that in its mangled name. That way missmatches of binary compability could be found at link time. Anyone see a reason why this is not possible or desired? 
 
 

Great video again STL! Finally I know why the names are Containerbase12 and Containerbase0! I like to lurk through the STL headers and was always confused with this proxy stuff, thanks for going into all those details. But is it just me or do you get less time every video? :P

this video size is too much large so listen to it thats very critical.

petke> STL> In theory, in the next platform / major binary breakage that Microsoft gets, they could change the name mangling scheme so that non-built in types include a CRC.  This could detect a lot of binary breakers pretty easily.  This would cause some amount of binary bloat (import and export tables would be larger), it wouldn't help for extern "C" interfaces, and it wouldn't help with COM like situations where clients just call non-exported virtual functions, but it would be something. 

It would have to wait until a platform break, or be strictly opt-in though, because it does break binary.  Maybe it could be tackled with some __declspec tags?

 

STL> I would have thought that _ITERATOR_DEBUG_LEVEL would have given itself a bit more room to grow.  For example, SCL probably should be at 5, and HID at 10.  This way values could have been set in between.  One thing that I could see going in at less than 5 would be some /GS like modifications.  Basically, vector and string could put some security cookies before and after their "real" allocation, and check those values during each deallocation of their memory range.  That particular mitigation may not actually solve anything though, as an exploit may have already been run before a check ever happens.

Thanks!

Good Video and Lecture.

 

Thanks, Strephan!

Great, as always!

That looks like heavy use of the pre-processor, which gives ammo to the C stalwarts who berate the perf of C++. Isn't there a way of getting the effect and value checking with some clever use of templates at compile time to shut them up? :P

> Ben. Thanks for the reply. Makes sense.

STL> I did some reading on "inline namespaces". Very interesting. Thanks for the tip.

For instance I found this description of the feature: "At any time, in a given translation unit, one wants to pretend that a set of names that are defined in a namespace N, are also members of a namespace M, for all purpose but linkage (i.e. name mangling)."

(I'm mostly worried about my libraries being binary compatible even though they are of different (product wide) versions. Say if the implementation of a function has changed but the interface has not. I would like object files, or static and dynamic libraries from different versions to be impossible to link together without being told there is a version conflict.)

With I could imagine the name of namespace N being set to a version string by the preprocessor. Callers of the code would not have to know about the name of the N namespace, they could just use the fixed name of the enclosing namespace M. The implementors of the functions would only have to know about the not yet preprocessed name of the N namespace. That seems very clean. Does VC10 support inline namespaces?

Cheers, and good job by the way. I always look forward with anticipations to your videos.

@petke:
the open source compiler GCC have this support if i remember correctly
(yet another reason open source rules, always up to date and no hidden agendas that halt development and releases, take that microsoft!)

ok i will repeat since charles obviously didn't get it the last time: Make make these videos longer, please ! come on don't be so cheap ! For instance, craplight (silverlight) and windows phone 7 have hours upon hours of video content *cough* marketing, breaking c9 rules! *cough* but c++ have like one video barely 40 minutes long every 3 weeks ? Only expressing that comes to mind is: What the hell ! Where are all the c++ videos we where promised, charles ?

18 hours ago, Mr Crash wrote

ok i will repeat since charles obviously didn't get it the last time: Make make these videos longer, please ! come on don't be so cheap ! For instance, craplight (silverlight) and windows phone 7 have hours upon hours of video content *cough* marketing, breaking c9 rules! *cough* but c++ have like one video barely 40 minutes long every 3 weeks ? Only expressing that comes to mind is: What the hell ! Where are all the c++ videos we where promised, charles ?

 

Mr Crash: I think you are too harsh in judgment.

I think both Charles and Stephan are doing a great job. I prefer few quality videos (that just take the time they need, no more, no less) instead of a lot of marketing/useless videos. I prefer quality instead of quantity. And STL's videos do have quality.

Charles: in addition, some videos I'd be interested in watching would be related to the use that several teams in Microsoft (Windows, Office, XBox...) do of C++. I hope that you (and the other team members) can find a proper schedule for these.

Thanks, and keep up your good job on C9.

 

I also prefer quality over quantity. One thing I would like to ask though is to please post these videos to the VC++ Team blog. I check that much more often than I check C9 so I was two videos behind even though I read the VC blog weekly.

Actually I totally missed the 2nd part of the advanced series. I thought it had been ignored by the VC blog... my fault!

1 day ago, Charles wrote

*snip*

Actually, you're wrong. I have released a C++ interview almost every week (sometimes, 2 weeks goes by, but come on...).

 

Those interviews doesn't count becasue it's just chitchat.
Except this one "Parallel Programming for C++ Developers: Tasks and Continuations"
its was well acceptable yet watching it i felt they brushed over a lot that could have been interesting to talk about.

 

For one thing, the C++ team is very busy and they have a schedule for releasing information to you which I have to follow.

Well busy is a strong word relative to what they actually produce / release.
But yes they are there to work not make videos i understand that.

I have a number of interviews scheduled to dig into what the C++ team will share - according to their schedule. Perhaps you could share what type of C++ content you want to see? Not everything will be in lecture format.

 

Many have given suggestions of topics you could talk about already, i think i may have given some suggestions too.

In terms of these lectures lasting longer, well, STL only needed ~39 minutes to get across what he intended to get across to you in this episode.

Actually STL have mentioned in the videos many times that the limited time have forced him to not talk about related things, in this video too.

Secondly, i like STL and how he describes, etc, so given a few more minutes with him i think is a good thing.

If I could do a C++ interview every day, then I would. The problem is you need C++ people to talk to and good topics, too. You need to get on other people's calenders, etc.  As I said, the VC++ team is cranking hard right now and it's not right for me to randomize cranking developers to produce videos for Channel 9 when they should be writing code, fixing bugs, writing code, fixing bugs, writing code, ++

I understand but there is no reason for you to not plan ahead, ex. book time with devs.
So the random part can be removed completely if needed with planing ahead.

I don't think I've made any empty promises. From Jan '11 - March '11, 17 C++ videos have been produced for C9. When the time is right, you will see an increase in the amount of C++ content streaming through 9.

It's been an empty promis so far.
So i say "put the content where your mouth is"

13 hours ago, C64 wrote



Mr Crash: I think you are too harsh in judgment.

As i have said before, i don't beat around the bush. It's a waste of time and may dilute / corrupt the info i want you to know, etc..

Just think how much time you could save if politicians would skip the *-kissing, etc and get to the point.

I think both Charles and Stephan are doing a great job.

Hey !

i said nothing about Stephan, he's doing a fine job,  he's actually very good at this.
Don't assume stuff.
Read the text i have typed and take it for what it is, no need to read between the lines, it will only confuse you and you will get it wrong

  I prefer few quality videos (that just take the time they need, no more, no less) instead of a lot of marketing/useless videos. I prefer quality instead of quantity. And STL's videos do have quality.

I like quality too.
Yes there have been too much of marketing / PR / useless videos.
That is why i'm pushing for some good proper stuff.

You could say they somewhat owe us for force feeding marketing / pr videos too use..

Stephan, thanks a lot for this info.  You mentioned that you could manually inject the detect_mismatch pragma into your import library.  I haven't been able to find any information on this.  Can you give a pointer?

Thanks Stephan!

 

How come you have the allocator as a class member, instead of deriving from it? The empty base class optimization would allow you to get the vector size down to the "expected" 12 bytes then (for stateless allocators), and I'm not aware of any downside to it.

First of all thanks Stephan - very well presented lectures.

As for the optimizing for the empty allocator case (or empty deleter for unique_ptr) you can make one of the fields inherit from allocator/deleter instead of the main class thus solving unintentionally exposed interface problem. To make it generic you can use something like boost's compressed_pair.

Another question: your approach on keeping a list of iterators to invalidate - I was thinking of an alternative way to accomplish the same end result. What about keeping revision ID in proxy object that gets incremented on each change to the container invalidating existing iterators? Each iterator keeps revision ID value the container had when the iterator was created. So you can get rid of “next” pointer you had for the list and if you make revision ID 32-bit you don’t even increase iterator size.

Any updates on where in your encoding / uploading chain the 4th video currently is? I'm craving for it. ;)

Stephan, I have a question about previous lecture -- you've mentioned getting rid of pointer arithmetic -- why compiler did not do it for you? Usually MSVC is pretty good with micro-optimizations -- what about asking someone from compiler development team?

(Or maybe compiler decided that that extra multiplication overlaps with surrounding operations and causes no performance loss?)

I see your point, but still -- these microscopic things should be in compiler's domain.
It might be a good idea to check that compiler-generated code actually performs worse than hand-written case that treats all pointers as 'unsigned char const*'
;-)

Grat video as always. One question. I read your old article about vector swaptimization. What is the current state of that? BTW if you run out of ideas for AdvSTL you can always do a video on swaptimization. :D

The documentation for MSVC10's "Checked Iterators" and "Debug Iterator Support" make no mention of _ITERATOR_DEBUG_LEVEL.

- wrong page -

Just a quick question.

I am curious as to how the pragma detect_mismatch actually works with the IDL. I guess what I am really after is the rules by which IDL is placed into an object by the pragma detect_mismatch. Let me explain with some code.

I have two projects. One builds an executable and the other builds a static library. In the static library, I deliberately set IDL to be 1 from the project settings. The executable is left to the default value of 2 under debug builds.

Static Lib:
Header: ///////////////////////
#ifndef _IDL_LIB_H_
#define _IDL_LIB_H_

#define USE_STL 0

#if USE_STL == 1
#include <string>
std::string IDLDblToStr( double val );
#elif USE_STL == 2
#include <string>
const char * IDLDblToStr( double val, char * const buf );
#else
const char * IDLDblToStr( double val, char * const buf );
#endif

#endif // _IDL_LIB_H_

Source: ///////////////////////
#include "stdafx.h"
#include "IDLLib.h"

#include <map>
#include <vector>
#include <sstream>
#include <iostream>

#if USE_STL == 1
std::string IDLDblToStr( double val )
{
std::stringstream ss;
ss << val;
return ss.str();
}
#elif USE_STL == 2
const char * IDLDblToStr( double val, char * const buf )
{
std::stringstream ss;
ss << val;
strcpy(buf, ss.str().c_str());
return buf;
}
#else
const char * IDLDblToStr( double val, char * const buf )
{
std::vector< int > v;
v.push_back(1);
v.push_back(2);
v.push_back(3);

for (int i = 0; i < 3; ++i)
{
std::cout << v[i];
}

std::stringstream ss;
ss << val;
strcpy(buf, ss.str().c_str());
return buf;
}
#endif

Executable: ///////////////////////
#include "stdafx.h"
#include "IDLLib.h"

int _tmain(int argc, _TCHAR* argv[])
{
#if USE_STL == 1
std::string s = IDLDblToStr(123.456);
#elif USE_STL == 2
char buf[128];
std::string s = IDLDblToStr(123.456, buf);
#else
char buf[128];
IDLDblToStr(123.456, buf);
#endif

return 0;
}

If I define USE_STL as 1 or 2, then I get the expected linker error message of IDL 1 does not equal IDL 2, but if I define USE_STL as 0, I do not get any linker errors at all. I would have expected, since the static library source file still references STL, that the pragma would have inserted itself in the resulting object file.

Thanks for any clarification you can provide.

- Ryan