Any chance to call Tango as Extended Standard Library

Don nospam at nospam.com
Thu Jan 22 08:43:07 PST 2009


Daniel Keep wrote:
> 
> Andrei Alexandrescu wrote:
>> Don wrote:
>>> [snip]
>>>
>>> It means that any code which uses a library based on both Tango and a
>>> library based on Phobos will end up with two copies of all of the
>>> functions, and they'll have different name mangling etc. You end up
>>> with two incompatible Bigints, for example, even though they have
>>> identical code inside.
>> Oh, I see. You want your library to be usable whether the end user
>> prefers Phobos or Tango. But then why not stick it into a namespace of
>> your choosing? Let's say your libraries are general enough to warrant
>> putting them in a common core, but then anyone who defines some library
>> don't have to go to the "core ombudsman" to add it to the common
>> namespace. They'd just create unique namespaces of their own. No?
>>
>>
>> Andrei
> 
> I think he means this: let's say you're writing app A.  A depends on
> libraries B and C.  B depends on Phobos, and C depends on Tango.  Both B
> and C happen to use BigInts or IO or anything else that isn't shared.
> 
> All of a sudden, you've now got to link in TWO standard libraries
> instead of just one, each with potentially duplicated code.

And you can't obtain a BigInt from library B and pass it into library C, 
since they are different types; even though they have 100% identical 
source code except for the name.

> 
> From personal experience, the alternative isn't much better: writing
> code that switches between the two.
> 
> I have an XML library that can use either Phobos or Tango.  It does this
> by implementing all the calls it needs in a shim library, essentially
> using it's own standard library.
> 
> It gets really fun when you need to implement some call that's trivial
> in one library, but really hard in the other.  I remember having to
> build an IO layer so that both Phobos and Tango had the same semantics
> regarding EOF or something...
> 
> Urgh.
> 
>   -- Daniel



More information about the Digitalmars-d mailing list