Idea #1 on integrating RC with GC

Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com> Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Thu Feb 6 02:21:41 PST 2014


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.


More information about the Digitalmars-d mailing list