On 6 February 2014 20:21, <"Ola Fosheim Grøstad\" <ola.fosheim.grostad+dlang@gmail.com>"@puremagic.com> wrote:
On Thursday, 6 February 2014 at 09:27:19 UTC, Paulo Pinto wrote:
So what do you do when different libraries require different runtimes?

I guess a given compiler could have a "cross compiler option" that generates libraries for all the available runtimes the compiler supports?


To be more specific to my previous comment. Objective-C GC required special compilation flags and care needed to be taken in GC enabled code, like in C GCs.

I understand. I am not sure if having multiple flags that creates a combinatorial explosion would be a good idea. I think you should have a set of invidual runtimes targeting typical scenarios, supporting different sets of functionality. (embedded, kernel, multimedia, server, batch, hpc…)

However, I think it would only work for the same compiler, because you really don't want to prevent innovation…


So no distinct runtimes were required as the generated code is no different than an Objective-C developer would have written by hand.

You might be able to design the runtime/object code in such a way that you get link errors.


In any case there isn't a standard C++ ABI defined. Well, there are a few, but vendors don't use them.

Yeah, well I am not personally bothered by it. The only time I consider using binary-only libraries is for graphics and OS level stuff that is heavily used by others so that it is both well tested and workaround is available on the net. (OpenGL, Direct-X, Cocoa etc)

Not having the source code to a library is rather risky in terms of having to work around bugs by trail and error, without even knowing what the bug actually is.

Thankfully, most useful libraries are open source.

Some that I regularly encounter: system libs, opengl, directx, fmod, physics (havok, phyzx, etc), animation (euphoria, natural motion), bink, lip-sync libraries, proprietary engine libraries, art-package integration libraries (3ds max, maya, photoshop), fbx, and many, many more.
Yes these are C libs, but the idea that people don't regularly use proprietary libs is fantasy.