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.
And I have specifically decided not to use interfaces with ranges because
that makes them reference types. Ranges work well as value types, but not
well as reference types. Therefore, to use dcollections as interfaces,
you must not require the range traits.
-Steve
