Feeds

Binary interfaces in component development

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

Top 5 reasons to deploy VMware with Tegile

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.

Secure remote control for conventional and virtual desktops

More from The Register

next story
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
NSA SOURCE CODE LEAK: Information slurp tools to appear online
Now you can run your own intelligence agency
Microsoft: Your Linux Docker containers are now OURS to command
New tool lets admins wrangle Linux apps from Windows
Microsoft adds video offering to Office 365. Oh NOES, you'll need Adobe Flash
Lovely presentations... but not on your Flash-hating mobe
You stupid BRICK! PCs running Avast AV can't handle Windows fixes
Fix issued, fingers pointed, forums in flames
HTML5 vs native: Harry Coder and the mudblood mobile app princes
Developers just want their ideas to generate money
prev story

Whitepapers

Driving business with continuous operational intelligence
Introducing an innovative approach offered by ExtraHop for producing continuous operational intelligence.
Why CIOs should rethink endpoint data protection in the age of mobility
Assessing trends in data protection, specifically with respect to mobile devices, BYOD, and remote employees.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Mitigating web security risk with SSL certificates
Web-based systems are essential tools for running business processes and delivering services to customers.