Idea #1 on integrating RC with GC

Manu turkeyman at gmail.com
Thu Feb 6 03:29:13 PST 2014


On 6 February 2014 20:21, <"Ola Fosheim Grøstad\"
<ola.fosheim.grostad+dlang at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140206/13adca7d/attachment.html>


More information about the Digitalmars-d mailing list