Ofek's Visual C++ stuff

The fopen documentation states:

When the "r+", "w+", or "a+" access type is specified, both reading and writing are allowed (the file is said to be open for "update"). However, when you switch between reading and writing, there must be an intervening fflush, fsetpos, fseek, or rewind operation.

Indeed? A brief experiment, if you please.

This indeed succeeds:

char buff[10]; 
FILE* fp = fopen("c:\\test.txt" ,"r+" ); 
// file contains, say, "1 \n 2 \n 3 \n 4 \n 5 \n" 
fgets(buff, 10, fp); // buff contains "1" 
fgets(buff, 10, fp); // buff contains "2" 
fseek(fp, 0, SEEK_CUR); 
fputs("a" , fp); // succeeds
fclose(fp); 

While this fails miserably:

char buff[10]; 
FILE* fp = fopen("c:\\test.txt","r+" ); 
fgets(buff, 10, fp); 
fgets(buff, 10, fp); 
fflush(fp); 
fputs("a" , fp); // fails 
fclose(fp); 

Stepping into the CRT source gives some conjectured reasons:

(1) fopen with ‘r+’ sets fp->_flag to (_IORW & ~(_IOREAD | _IOWRT)).

(2) fgets adds _IOREAD.

(3) fputs contains code (in _flswbuf), logically equivalent to –

    if (stream->_flag & _IOREAD && !(stream->_flag & _IOEOF))) 
    { 
     stream->_flag |= _IOERR; 
     return (_TEOF); 
    }

with an explicit comment (snip):

/* Note that _IOREAD and IOEOF both being set implies switching 
from read to write at end-of-file, which is allowed by ANSI. */

So indeed an explicit transition is mandated.

(4) fseek contains just such a transition. Code in _fseek_nolock reads:

 /* If file opened for read/write, clear flags since we 
     don't know what the user is going to do next [..snip] */
     if (stream->_flag & _IORW) 
     stream->_flag &= ~(_IOWRT|_IOREAD); 

(5) However, fflush does NOT. It does contain code (in _flush) equivalent to –

if ((stream->_flag & (_IOREAD | _IOWRT)) == _IOWRT [..snip]) 
{ 
     _write([..snip]); 
     if ( stream->_flag & _IORW ) 
     stream->_flag &= ~_IOWRT; 
}

So fflush allows transitioning ONLY from write to read.

This is either a CRT bug (my guess), or a documentation issue. Might it be a subtle ANSI-C conformance thingy (as hinted by the _flswbuf comment) that I’m missing? (it’s still a documentation issue in that case). Opinions are very welcome.

This is almost verbatim a feedback I submitted at MS connect a while ago following a forum advice. The issue was triaged (I imagine) and escalated to the product team, and after a few weeks its status changed to ‘fixed’ without any word of explanation.    Oh well.   Hopefully this post will help someone out there some day.

A while ago I posted about vector::resize – how it takes a parameter by value and thus cannot store aligned elements. I confessed I didn’t understand Stephen Lavavej’s words:

…There’s a reason that our resize() is currently taking T by value – it guards against being given one of the vector’s own elements …

Some interpretations were suggested by commenters, but the mystery pretty much remained. In the last few days, a StackOverflow post –which I can’t find now – led me to Standard Library Defect #679:

The C++98 standard specifies that one member function alone of the containers passes its parameter (T) by value instead of by const reference:

void resize(size_type sz, T c = T());

This fact has been discussed / debated repeatedly over the years, the first time being even before C++98 was ratified. The rationale for passing this parameter by value has been:

So that self referencing statements are guaranteed to work, for example:

v.resize(v.size() + 1, v[0]);

However this rationale is not convincing as the signature for push_back is:

void push_back(const T& x);

And push_back has similar semantics to resize (append). And push_back must also work in the self referencing case:

v.push_back(v[0]);  // must work
…

In the former post I noted that since gcc does implement vector::resize with a by-reference argument, and so wrongfully concluded that the by-value argument is an MS issue. Turns out it is (well, was) a C++ standard acknowledged issue – and unlike gcc, MS were being strictly conformant. You could say, though, that MS did implement large parts of C++0x in VS2010 and they might have squeezed in this standard correction – but fact is they didn’t and since it isn’t yet a standard it isn’t yet a bug.

Either way, Stephen’s words make sense now. I still think, however, that the current implementation can take a const reference as is, and I can’t see any further internal changes required.  (Than again, that is probably part of the reason that I’m not the one maintaining MS’s STL…).

Alan Ning just posted about a cool hack of VS’s PGO switch, which was a sad reminder of all the wonderful goodies I’d never taste in my present job.

PGO builds can incorporate many optimizations that regular builds cannot, thereby leading to ~7.5% speedup (as measured by the VC++ team) with *zero* coding effort.  Still, eagerly trying it – I got struck with "Fatal Error C1310: profile guided optimizations are not available with OpenMP".

You see occasional rants about this incompatibility, but these are met with consistent MS reluctance to address it. Quoting from the Connect bug:

Since PGO and OpenMP are both designed to increase performance, it is a shame that they can’t be used together, but there were some major design issues preventing this. There is an ordering dependency in the designs of PGO and OpenMP. OpenMP changes some things about the program state that are important to PGO, and it does this after PGO has already processed the program state and made many decisions based on it.

And further yet –

We will be considering a modification of the designs of PGO and/or OpenMP to get this to work in a future product version.

That was written in April 2005. 3 VC++ versions later, the incompatibility persists.

We are using OpenMP, extensively, as do probably all dev shops today who care about performance. Seems anyone who does any new native code today probably cares deeply about performance – and those are exactly the devs that both OpenMP and PGO are aimed at!  The stated obstacles in addressing this issue (essentially, getting the order of operations right) don’t sound that insurmountable to me. I’d be surprised if other compilers suffer similar limitations (but frankly I have no idea. Anyone has better info?).

As crescens2k answered me some time ago,

The way Microsoft generally do things is by demand. So if you think this is something which should get fixed soon, the best thing you can do is submit a suggestion and get everyone you know to support it.

Well said.  Please, take 20 seconds and upvote it.

A while ago a friend asked me whether pure virtual functions have higher overhead than regular virtual functions. At the time I answered that this cannot be – the pure/non-pure distinction is meaningful only at compile time, and non-existent at runtime. Only a (long) while later did I connect the dots, and understand what he meant than (sorry Mordy..)

Regular Overhead

Virtual calls are known to be more costly than calls that are resolved at compile time.  Elan Ruskin measured ~50% difference – I measured a bit less, but the difference is certainly there. For functions that do real work the actual call overhead can be mostly neglected, but for functions that get called a lot in a scenario you’re struggling to optimize – you can get tangible results by eliminating virtual calls. It’s widely considered a good practice to use the added flexibility of virtual functions when you have a concrete reason and not just for the fun of it.

There are two reasons for the added call cost – main one being the CPU instruction-prefetch mechanism.  A regular call is resolved at compile time into something like –

call 0xabcd1234

– which the instruction caching apparatus (a.k.a trace cache) easily resolves ahead of time, and can tell where to continue the fetching from. However, a virtual call is compiled into something like –

call eax

Faced with the impossible task of predicting the contents of eax dozens of instructions in advance, the trace cache just stalls.

The second potential extra cost is an extra dereferencing. The first DWORD_PTR of a c++ object (neglecting virtual inheritance) is a pointer to it’s virtual table –  a table that is common to all instances of the same class. A call to a virtual function is resolved by first dereferencing that vtable pointer, and only then calling the function at a fixed offset from the vtable start. Maciej Sinilo tried to isolate this cost by comparing calls via explicit function pointers to calls via virtual functions, and turns out the difference is practically non-measurable. (BTW, I didn’t check but I suspect part of the reason is the compiler’s ability to resolve that dereference in compile time, in many situations).

Pure-Virtual Extra Overhead??

Well, not really. At least not directly. But the function ‘containers’ – classes that are used as interfaces – do come with some extra weight.

To put it short, an interface class by default has its own constructor and destructor – just like any other class. These are called just before/after a child class constructor/destructor – as you would expect in any hierarchy.

But wait… what? Why? If you didn’t provide an implementation for such a constructor,  what can it possibly do?

What every compiler-generated constructor does: set up the class vtable pointer. In this case, it is a very short lived pointer – one that is immediately overwritten by the child ctor.

Take the following code:

class A
{
public:
	__declspec(noinline) A()
		{ _tprintf_s(_T(" A::A "));}
	virtual ~A()
		{ _tprintf_s(_T(" A::~A "));}

	virtual	void	f() = 0;
	virtual	void	g() = 0;
};

class B : public A
{
public:
	__declspec(noinline) B()
		{ _tprintf_s(_T(" B::B "));}
	virtual ~B()
		{ _tprintf_s(_T(" B::~B "));}

	virtual	void	f()
		{ _tprintf_s(_T(" B::f "));}
	virtual	void	g()
		{ _tprintf_s(_T(" B::g "));}
};

int _tmain(int argc, _TCHAR* argv[])
{
	B b;
	return 0;
}

The order of events in B’s construction is as follows:

(1) The child ctor, B::B() is called and immediatly calls the parent ctor A::A().

(2) The parent ctor A::A(), setd the object vfptr to point to the common A vtable –

(keep those xxx placeholders in mind – more on them soon). Watching the object state in VS at this point you see:

– emphasized are the instruction that populates the object vfptr, and the referenced vtable itself.

(3) B::B() continues, and modifies the object vfptr to point to the common B vtable:

and again a VS view:

If you’d call f() from B::B() A::A() [thanks Roman!], which is the sort of self-foot-shots c++ allows,  you’d be using A’s vtable (which is the only one the object knows at that time), end up calling the nonexistent xxx and gloriously crash in runtime. Of course it’s never that direct, and it’s pretty much a consensus you should never call a class virtuals from its own ctor/dtor.

Why all that hassle??

Frankly, I don’t know. It seems C++ goes out of its way to build and tear apart abstract-parent vtables, than exposes them briefly only during child construction/destruction, and then the community expert unanimously recommend never to use them. Herb Sutter does give 3 scenarios where you might consider using them – I find none of them convincing, and generally consider this to be one of the C++ semantic warts.

So, can this extra weight be mitigated?

Yes – at least in MS-specific ways. The direct way is by adding a __declspec(novtable) modifier to the abstract interface declaration. If you can guarantee that the interface class would never need any constructors/destructors (which can be tricky at times), it would be more readable to use __interface instead.

Beyond the direct saving of the extra ctor/dtor work, a happy side effect of novtable is that it eliminates all references to the modified interface vtable. The linker is then able to remove it from the binary altogether – thereby reducing the binary size and providing some extra boost. (When applied to a lot of interfaces, this can get tangible results!)

Bonus – so what is xxx, really?

Google xxx and see for yourself. I’ll wait until you return. It’d probably be a while.

Ok – this probably deserved it’s own post, as there still appears to be some online confusion regarding it. Apparently the ‘= 0’ pure virtual syntax is leading some to believe that the xxx entries are truly zeros. In fact MSDN columnist Paul DiLascia wrote sometime in 2000 that –

…the compiler still generates a vtable all of whose entries are NULL and still generates code to initialize the vtable in the constructor or destructor for A.

That may actually have been true than (I’m not even sure of that), but certainly isn’t now.

xxx is the address of the CRT function _purecall, which is essentially a debugging hook. You can  control xxx’s value directly by overloading purecall yourself, or alternatively use _set_purecall_handler to route into your own handler from within _purecall. You might consider doing so, e.g., to collect stack traces or minidumps in production code.