I stopped programming in C++ almost ten years ago because of this kind of thing. Back then, the problem was bizarre linker errors whenever I used the Standard Template Library. I'm grateful to Dan for warning me that templates still haven't been fixed in C++. I'll stick to Java.

"I'm grateful to Dan for warning me that templates still haven't been fixed in C++. I'll stick to Java." ... David, I think they realise that they have serious competion which can expose their faults, [which may or may not have been programmed in deliberately] and faults which if not internally addressed and corrected will collapse the Program.

"With some simple examples, we’re starting to see problems, using a logically correct C++ program for which we cannot construct a physical representation using dynamic libraries because of platform constraints."...... One assumes that that is what the hypervisor layers in the Virtualised Environment have been created for. In such a Space are there no platform constraints, either physical or otherwise.

And quite why, after having so eloquently espousing an ideal gateway/portal/path with ...."Now, imagine a scenario where your manager wants to decompose the project, so that different project teams can be responsible for their own dynamic library, so that development can occur in parallel, so that functionalities can be unit tested without rebuilding everything - and for all the other reasons that motivate people to use dynamic libraries. This manager, like lots of people, comes from a planet where an application can be built interchangeably, either statically or dynamically, with no difference in behaviour.

I’m sure we’d all like to come from this programmer’s paradise too, but until we can find a way to move there, maybe we’ll have to support our user base here on Earth with its less than perfect operating systems." .... anyone would be content with anything less, may have more to do with preserving a particular funding stream rather than anything more laudable. However, there is a saving grace in the quote with the "maybe we'll have to support..." caveat.

To Boldly go with a more assured approach in the scenario would have the less than perfect operating systems based on Earth subject to Peer Competition and comparison. One can then easily understand the stumbles/hurdles which such Binary research and development generates for any Progress will upset any Gang/Cartel/Ego.

Oh dear, what a shame, that's Life, nothing real ever stays the same as it is and in IT, it never ever is as IT is.

And that was a very clear article, Dan, daring as it does to impart and phish for deeper Code understanding of Virtual Kernels and, of course, their Control Linkage [through AIMaster Key Algorithm/Dominant Methodology through OmniScience]

"What’s the solution? Unfortunately, the solution is to choose a software architecture that doesn’t expose you to this incoherence between dynamic libraries and static data." ...... which is surely the same as choose a New Source working in Future Imagination, cogniscent of dynamic libraries and static data?

A NeuReal Vista .... for Universal Mastery of Windows? AI Rhetorical Question?

Hmmm...... If that be so, it would be more than just valuable nowadays.

"I have a most elegant proof why you don't want to implement the singleton pattern using a static variable, which this comment is too small to contain"

Seriously - that deserves a certain degree of slapping for a start

The examples shown in the scaled down screen shots are unreadable. Please just put the code in the article, but if you have to use screen shots, show a thumbnail and link to the full size image.

I've just read Part 1 and, while sympathising with some of the comments, think it could be shortened a little. Here is my first try..

Part 1. Binary interfaces in component development

[snip snip]

Part 1. Dependencies

"When building things, it's a good idea (and not a new one) to remember dependencies. There are many, many ways of finding them out - lots of techniques and tools exist for this, or you can invent your own.

If the source code for, e.g. a library, is in different files, you can still group *those* files together in nice, little ensemble too."

----

I think that about covers it...

Yep, this is the kind of trap that awaits programmers who don't understand what preprocessor inlining is, and when it happens. Java/C# programmers who are used to the "declaration and definition are in one place" style of those languages seem to miss C++'s distinction between a declaration and definition of a function or class.

#include is not the same as Java's "import" keyword. It doesn't mean "I want to use this object", it means "compile the contents of this file as if I had typed them right here". In normal use, where the .h files contain only declarations, this isn't a problem, but as soon as you put static storage in a .h file, and #include it in multiple .cpp files, you're asking for trouble.

Writing a preprocessor macro (for that is what a template declaration is) that allocates an object whenever it's processed by the compiler is not how you implement global static objects. The linker detects the problem and cleans up your mess in the first example program, but in the second, dll-based version, it can't help you out of the hole you've dug.

Remove the smokescreen of the template declarations, and behind it you'll find our old friend, the local global variable:

-----------------------------------------------

GlobalVariable.h:

int theBigGlobalVariable;

-----------------------------------------------

dll-A-main.cpp:

#include "GlobalVariable.h"

...

theBigGlobalVariable = 1;

-----------------------------------------------

dll-B-main.cpp

#include "GlobalVariable.h"

...

theBigGlobalVariable = 7;

-----------------------------------------------

... which is obviously an accident waiting to happen. Of course, had you written this program in Intercal you would not have had this problem... ;-)

....so it bloody well serves you right!

You should stick to a real language in future.

"Of course, had you written this program in Intercal you would not have had this problem"

Provided that you remembered to say "PLEASE" ;-)

Very interesting article. I only have two comments, which have already been said by others:

First, and this is not the first article with this flaw, please stop relying on screen shots to show code samples; just paste the darn code or, if you must, link to a larger image. As they are, I cannot ready any of the code in them, which significantly lessens the value of the article.

And second, I must side with Kristian Walsh in this case: The issues you presented stem from a misunderstanding of the C/C++ preprocessor, not from a flaw in the platform nor language used. To be sure, there are limitations of C++ that prevent the elegant implementation of certain modern design patterns, but this is because the abstractions do not map directly to language constructs. This does not mean that implementing, say, a Singleton is not possible, safe, or reliable in C++, but that you may not be able to use the same high-level abstractions you use in Java.

Declaring static objects in header files, whether class templates or otherwise, is just an accident waiting to happen. And again, much less an issue with the compiler or linker than a stretch beyong the scope and intent of the preprocessor. This important point seems to be alluded to rather indirectly in your conclusion, yet does not seem to be an obvious part of your lessons learned.

Cheers!

-dZ.