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?
--
Bruno Medeiros - Software Engineer
