A nice surprise (re: name-mangling)

I might be wrong about this - but in earlier versions of Visual C++ I've a recollection that it wasn't possible to "mix + match" between different compiler versions. So if you compiled something with VC++12, you could link it to a 'C' library from (say) VC++8 or VC++9 - but you couldn't do the same for C++ libraries (because each compiler used different name-mangling schemes).

However... I just built a test project using VS2019 (VC++14) and I was surprised to find that I can link it to libraries that were written back in VC++8. Is that a happy accident - or something that Microsoft fixed at some point?

See https://docs.microsoft.com/en-us/cpp...7?view=vs-2019

:thumb:

It's great to hear that MS have fixed this but I must admit, I'm confused... If I'm reading the article correctly it implies that VS2015, 2017 and 2019 will now be compatible with each other - but in my case, I built a DLL with VS2019 and managed to link it to some link libs from DLLs built with VS2005. I'm not complaining - it's great news!!! I have an enormous project here written with VS2005 and I've always been put off updating it because of the huge amount of work involved. But if I could update it in small steps, that'd really be useful :thumb:

The words mouth, horse and gift comes to mind! :d

I'm guessing - but I'd say that depending upon the interface, some VS2019 will link with versions earlier than VS2015 and some might not. Certainly there have been changes to the 'mangling' since VS2005. You might be lucky - or not.

That reminds me... whatever happened to manifest files? In some earlier versions of VC++ it was necessary to include something called a manifest file at the link stage. IIRC this later told the OS which version of the CRT to use. But manifest files seem to have disappeared now - unless I'm missing something (or is this all implemented some other way now :confused: )

Quote:

---

Originally Posted by John E

But manifest files seem to have disappeared now - unless I'm missing something (or is this all implemented some other way now :confused: )

---

When a Windows application is started not everything it needs to run is present inside the executable. The executable must bind to outside stuff that is described in the Manifest.

https://docs.microsoft.com/en-us/cpp...s?view=vs-2019

A Manifest must always be present but you don't have to bother with it much these days due to the increasing user-friendliness of VS. If you stick with ordinary MS technology the linker doesn't need any help to generate a Manifest for you.

I really appreciate VS and the C++ language but sometimes if find the increasing complexity and loss of control quite scary. That's when I regress back to simpler times and feel a strong urge to rewrite everything in C using Emacs. :)

Quote:

---

Originally Posted by John E

Is that a happy accident - or something that Microsoft fixed at some point?

---

Linking C++ code depends on presence of symbolic names. In its turn, the presence of the names that to be resolved depends on two factors. First, the scheme of name mangling, which is typically standardized for quite a long time within the same family of compilers. Second, the version of STL a compiler forces you to link with. And exactly the latter factor is the most unpredictable and poorly comprehensible thing nowadays and this is where your happy accident might really be.