"But what about the Windows-specific issues - DLLs versus shared objects?"

I imagine there that immediate difficulties arise if DLLs are considered proprietary codes with an owner expecting payment as against shared objects with an owner expecting just reward.

"It is possible to call a constructor in a DLL transitive dependency. It involves allocating memory with malloc, writing assembler to prepare the stack frame manually and calling the constructor as if it was a C function. This is unlikely to win awards for portable code though."

It would win top Prize though for Secure Code on Base Operating SystemS, Dan..... for it would be Leading with its own Initiatives in Legacy Coded Systems...... for Continuity of Service in a Changed and Alien, Virtualised Environment.

Sorry, this article is completly biased. There is no standard way how UNIX handles shared libraries. The problems on Windows persist on UNIX, too.

It may be a correct comparing Windows with Linux.

The Author does not mention the namespace pollution through use of the pam modules on UNIX. For instance you have to be very carefully not to link with a private LDAP library because you get injected a ldap shared lib if pam_ldap is configured! This is a major blocker if you develop cross plattform software for us.

AIX shared libraries for instance behave very much like the Windows ones. For instance symbols have to be exported explicitly.

ELF shared libaries (Linux, HPUX ia64, Solaris) have a feature not to export every symbols, which prevents clashing of symbol names, this have to be

The author states that windows dll use a full link step. There is a not-to-be-used feature marking dll entries with numbers rather than symbol names, but this should now be used anymore.

IMHO UNIX shared libraries are evenly complex compared to windows ones. Have a look at HP-SUX PARisc 32 bit. Try to dlclose() a shared library: Your application surely will crash, because the do not implemented reference counting.

Why make a single huge executable instead of using a zillion separate processes?

It's not like anybody's going to have a single CPU in their PC in even two year's time (not to mention the servers), so your choices are to build either insanely complex multithreaded beasts that will never have a fraction of their bugs dealt with or a huge number of different processes that can each be tested to spec, if not expectation.

Also avoid C++ entirely in favor of Java or some other CPU wasting scripist abomination, because the user can always just add a few dozen more CPU cores to their system.

-HJC

While this is an oldie-but-goodie, it might be good to update the book. C++ has morphed a bit, and I'm sure that the author has some more experience and things have changed just a bit.

While the book addresses general practicality of large-scale projects with C++, the author's article is about Windows .DLLs and apparently porting from Unix. Most of the issues would seem to be addressed by some forward, thought, also known as "design."

It would have been nice if the author would have allowed more than one paragraph for the book, instead of focusing on Windows .DLL files.