Feeds

Binary interfaces in component development

A template class with static data - how can that possibly go wrong?

The essential guide to IT transformation

Clearly, the linker has no chance to resolve multiple definitions of a single symbol if the symbol name is not present to connect all the different instances together. As a first step to resolving this problem, we’ll use linkage specifiers to bring our data into the export, to see if that helps solve the problem.

However, in Microsoft Visual Studio there exists a mechanism to tag a definition that will be exported from a dll. This tag causes the linker to put the symbol name of the definition into the dll export table so that other binaries using the dll can find the definition. A second tag allows you to import definitions from a dll, signalling to the linker not to search for the definition at link time but instead to use an indirection which will be replaced at runtime by the real definition, in a process known as 'fixup' (see also here). In code, you typically see a system of macros to manage this tagging. Declarations that form the interface of the dynamic library are marked with this macro and when building on windows the preprocessor substitute the macro for ‘__declspec(dllexport)’ indicating to the linker that the symbol should be placed in the export table for use by other binaries linking to the library. When building a binary that uses a dll, the same macros expand to ‘__declspec(dllimport)’ indicating to the linker that the needed definition will be available at runtime if it’s not found. There’s one problem with this system, however. It works reasonably well when the binary definition is located in the library corresponding to the C++ class definition; but in a world of templates, the template definition could be located in some library far, far away, although its instantiation is in the library that you’re building.

If you have control over the template definition, you may be able to get past this with an increasingly messy system of macros as illustrated in the code below, but if the template definition is from a third party library then the only option is to hide any template instantiations far away from the interfaces of the dynamic library.

So, by adding a rather elaborate system of macros (check the code for this figure if you’re interested), we’re able to get our static data into the exports table. Just to clarify, I’m not recommending the usage of such a system of macros; it’s simply a way to get the static variable resulting from the instantiation of a template from another library exported. Have these efforts solved the problem though? Unfortunately not, as the following screenshot (Figure 5) reveals; depending on which dll the calling code is in. The static variable GenericSingleton<MySingletonObject>::m_instance is located at a different memory address.

Figure 5: Shows one static variable with 2 locations.

In our case, an important difference means this system will not work. Our class template is not defined in our dll so its definition is not tagged with the macro that expands to dllexport. Using a modified mechanism, we were able to export the symbol, but as both dlls needed to instantiate the variable and type, this still didn’t resolve the issue.

Boost IT visibility and business value

More from The Register

next story
Munich considers dumping Linux for ... GULP ... Windows!
Give a penguinista a hug, the Outlook's not good for open source's poster child
The Return of BSOD: Does ANYONE trust Microsoft patches?
Sysadmins, you're either fighting fires or seen as incompetents now
Intel's Raspberry Pi rival Galileo can now run Windows
Behold the Internet of Things. Wintel Things
Microsoft cries UNINSTALL in the wake of Blue Screens of Death™
Cache crash causes contained choloric calamity
Eat up Martha! Microsoft slings handwriting recog into OneNote on Android
Freehand input on non-Windows kit for the first time
Time to move away from Windows 7 ... whoa, whoa, who said anything about Windows 8?
Start migrating now to avoid another XPocalypse – Gartner
You'll find Yoda at the back of every IT conference
The piss always taking is he. Bastard the.
prev story

Whitepapers

5 things you didn’t know about cloud backup
IT departments are embracing cloud backup, but there’s a lot you need to know before choosing a service provider. Learn all the critical things you need to know.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.
Rethinking backup and recovery in the modern data center
Combining intelligence, operational analytics, and automation to enable efficient, data-driven IT organizations using the HP ABR approach.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.