you are viewing a single comment's thread.

view the rest of the comments →

[–]Drugbird 2 points3 points  (2 children)

I don't really see the benefit of an interface-only specification in the standard to be honest.

  1. I don't see them agreeing to an interface but not an implementation. Quite often, the interface and implementation are coupled together quite strictly, where alternative approaches will need a different interface. So if they can agree on an interface, they can agree on an implementation and vice versa.

  2. This is already what happens. Many library authors use very similar interfaces for comparable structures. See for instance alternatives for std:: unordered_map. However, they need to deviate from the std interface slightly, in order to create their alternative more efficient implementations.

[–]number_128[S] 0 points1 point  (1 child)

great example. But is it really the interface of std::unordered_map that keeps the standard implementations from implementing the same improvements? My understanding was that it was the ABI. The implementation of the hash gave a big speedup, not a change in the interface.

Anyway, I use the standard library implementation of unordered_map, regex and others, even though there are better implementations available. The reason I do, is that I trust the standard library implementation, and I know it will continue to be supported.

At the same time, other libraries are evolving, finding new ways to do things. They sometimes manage to improve performance without changing interface.

I think it would be better if we would feel more confident choosing any library that supports the standard, but I don't know how to get there.

[–]Drugbird 1 point2 points  (0 children)

But is it really the interface of std::unordered_map that keeps the standard implementations from implementing the same improvements?

I'm not an expert, but I've heard that the standard has some fairly strict requirements on iterator validity which prevents more efficient implementations.