On 2010-05-28 14:12, Steven Schveighoffer wrote:
On Fri, 28 May 2010 06:10:49 -0400, Jacob Carlborg <d...@me.com> wrote:
On 2010-05-27 12:32, Steven Schveighoffer wrote:
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
<brunodomedeiros+s...@com.gmail> wrote:
On 24/05/2010 16:45, Andrei Alexandrescu wrote:
In the past I have built a C++ library that abstracted features of
the OS. My goal was to make it possible to dynamically load a module
that abstracted things like setting the IP address of a network
interface. My modules used std::string instead of char * to lookup
services to get objects that implement the interface. Big mistake. On
a later version of the standard C++ runtime, the private
implementation of std::string changed, so the dynamically loaded
libraries crashed horribly. No change in string's interface, just the
private stuff changed, but because it's a template, the code that
uses it necessarily has to be aware of it. We ended up ditching the
standard C++ library's version of string, and used STLPort so we
could control the library.
I envision this same sort of problem would be likely with D
collection objects that were not used via interfaces.
I see no problem retrofitting a no-interface container into a formal
interface if so needed.
I don't understand this discussion: isn't the reason above pretty much
a dead-on hard requirement for the collections to have interfaces?
Something like, for example, an interface version of the range traits?
Only if you wish to have binary compatibility with dynamic libs. Such a
thing isn't likely today since dynamic libs aren't very well supported
in D, and even phobos or dcollections isn't a dynamic lib.
I've got my patch, for build Tango as a dynamic library on Mac, quite
recently included in trunk. And I've also have a patch for druntime
and Phobos in bugzilla just waiting to be included + one patch making
it easier creating dynamic libraries directly with DMD. I would say
it's a bad idea to still think that dynamic libraries aren't support,
we have to think forward and assume they will be supported.
I remember that, and I'm very encouraged by it. That being said, the
ultimate goal is to have dmd be able to build dynamic libraries easily.
D has had dynamic library "support" for years, but you have to do all
kinds of manual stuff, and the standard library isn't dynamic. Until the
standard library is dynamic, and I can build a dynamic library with a
-shared equivalent switch, dynamic libs are a laboratory feature, and
not many projects will use it.
Yes, exactly, I noticed there isn't an easy way to build dynamic
libraries, among other things you have to know the path to the standard
library when manually building.
Just so you know, I think it's important to support binary compatibility
in dcollections, and since std.container has not adopted dcollections,
I'm going to keep interfaces. I was just pointing out the position
others may have WRT binary support.
-Steve
--
/Jacob Carlborg
