Wait, you never said that I had to initialize the object before I used it!

re: Wait, you never said that I had to initialize the object before I used it!

JamesJohnston — Mon, 27 Aug 2012 14:18:50 GMT

Why did they make every object in .NET / Java an object, anyway? It seems like that needlessly complicates the runtime, when a class in the base library called "Monitor" could have done the job just as well. As an added bonus, it forces the user to specify that functionality in a scope. As it is, who knows what objects are being used as locks and what are not?

re: Wait, you never said that I had to initialize the object before I used it!

Joshua — Sun, 26 Aug 2012 21:33:00 GMT

@Carl D. Last I checked, the slab locks that I prefer to use require only zero initialization and no cleanup, and when not being waited on way two pointers in size (actually an atomic_t followed by a pointer but padding will push it to two pointers in the rare architecture where that's different).

re: Wait, you never said that I had to initialize the object before I used it!

arm ram — Sun, 26 Aug 2012 21:24:47 GMT

@alegr1: Good luck cooding on WindowsRT.

re: Wait, you never said that I had to initialize the object before I used it!

John Doe — Fri, 24 Aug 2012 16:22:45 GMT

«MSDN doesn't say "You must initialize an SRW lock before using it" because the statement was believed to be so obvious that it never occurred to anybody that somebody would think the opposite was true. I mean, what's the point of having an InitializeSRWLock function if initialization is not required? Think of it as one of the ground rules for programming: If an object has an initialization method, you must initialize the object before using it.»

@Raymond, not everyone knows the Windows API as you do. I dare to say most people don't, actually. It may seem very logic to you that the mere presence of an Init* function in the reference is enough to imply that it must be used. I could say the same about the API's I or my colleagues develop to people outside the department or even the company.

I say it should be explicitly there. What's not there is not to take for granted. Of course, there are limits to this, such as passing strings that are not zero-terminated to C API's that deal with char * (and the likes of it). But imagine that there was no string convention for C; then at least the latter would have to be specified somewhere, either in each function reference or in an introductory chapter stating that "every char * parameter and return value is a zero terminated string".

I regard the MSDN library as a very good quality documentation library, actually one of the best you can read and navigate online. It often states how to initialize many structures, mainly the first field of structures that are expected to evolve between versions of Windows. These don't have an initialization function, so they kind of have to say how to initialize. Others don't need initialization, such as an array of structs that is filled by some API function. Yet others have initialization functions, such as VariantInit:

«Before use, all VARIANTARGs must be initialized by VariantInit.»

Why should the synchronization section be any different from others in this regard? Why not say how and when to initialize the objects it handles? The user doesn't know what's required unless it's stated. Try to put yourself on the other side.

Disclaimer: I belong to that group of people that doesn't know the Windows API that intimately, so there may be other sections that also lack documentation about required initializations. I myself may have taken some initializations for granted just because I've seen an Init* function in the reference section.

Disclaimer: My intention is not to point a finger to the MSDN library or the synchronization section, I'm just keeping the subject of conversation.

re: Wait, you never said that I had to initialize the object before I used it!

jas88 — Fri, 24 Aug 2012 11:55:20 GMT

"If newed variables didn't need to be initialized, and local variables didn't need to be initialized, then what's the point of InitializeSRWLock? In the author's mental model, you would never need to call it!"

If they're using a higher level wrapper, it seems reasonable to assume the wrapper calls InitializeSRWLock for you - after all, you aren't explicitly calling any memory management functions either, but they are still documented and involved behind the scenes.

In this particular case, the 'memory leak' could pass for an optimization if it had a good PR team: it gets disposed of implicitly when the process exists anyway, and that automatic disposal could well be more efficient. Not an issue here, but I've seen a few programs spent long enough to be quite irritating cleaning up all their internal state before exiting. (In particular, swapping pages back in just to dispose of their contents, when the OS could just have marked those pages free on exit without the excess I/O.)

re: Wait, you never said that I had to initialize the object before I used it!

Matt — Fri, 24 Aug 2012 08:59:30 GMT

@Eugene When in doubt, Microsoft uses the WINAPI calling convention. There are some exceptions (like printf) but by-and-large, expect all Microsoft functions to be WINAPI.

re: Wait, you never said that I had to initialize the object before I used it!

Matt — Fri, 24 Aug 2012 08:51:31 GMT

On the subject of Pinvoking, the default calling convention is WINAPI (which is __stdcall on x86), and it transparently handles the W/A case (under the hood it tries GetProcAddress(module, name) - if that fails, then it tries GetProcAddress(module, name+W) and sets the conversion of strings to unicode, and if that fails it tries GetProcAddress(module, name+A) and sets the conversion mode to ascii).

BONUS: This logic is the same as the logic used by rundll32.exe :)

re: Wait, you never said that I had to initialize the object before I used it!

Crescens2k — Fri, 24 Aug 2012 02:29:18 GMT

@Eugene

Even still, it is well known that the MSDN is for documenting, and if you have found some functions that do it then it is best not to assume that everyone will put in the calling convention. Oh, and it isn't related to the shell team either, look at the WDK documentation, none of them include the calling convention either. So even though it is their policy, not all of the teams stick to it.

I agree with Raymond, if you want to re-prototype a function, get the prototype from the header, that is the only way you are guaranteed accuracy. This is how I normally do it when I need to access a small amount of backwards incompatable functions. If I need to use a larger amount, I tend to write DLLs that wrap the behaviour I want and dynamically load it after a version check.

re: Wait, you never said that I had to initialize the object before I used it!

Carl D — Thu, 23 Aug 2012 22:50:25 GMT

@Gabe

While the CLR and JVM logically have a lock per object, neither of them is actually implemented that way. Both use a pool of locks that are associated with objects on an as-needed basis. Since the vast majority of objects are never waited on, this saves resources on an enormous scale.

A quality design for an in-memory database would likely involve a similar level of indirection and not actually allocate a lock per row.

re: Wait, you never said that I had to initialize the object before I used it!

Eugene — Thu, 23 Aug 2012 22:38:33 GMT

@Raymond

I need my application to work on WinXP, so I cannot link directly to Win7-only functions. I have to GetProcAddress it, so prototype doesn't help much.

And MSDN used to include calling convention in prototypes. Take any old function: LoadLibrary, CreateFile, EnterCriticalSection etc. Or SRW functions mentioned in this post -- all have WINAPI, which is a calling convention macro. In fact, the only functions without calling convention that I can find in a couple of minutes are from Shell32.dll. So this looks more like Shell Team policy rather than general MSDN policy.

[if you're going to re-prototype a function, get it from the header file. That's where the compiler gets it. (Or use decltype.) The MSDN documentation is presented for exposition, not for handing directly to a compiler. (SAL annotations are often stripped down or removed entirely, and separate prototypes are not given for A/W variants.) -Raymond]