通过

Language & Library Evolution

  • 项目

Let’s say you have a programming language, K-- version 1.0, with it’s accompanying runtime library, stdK--. And it turns out that the language needed some new features, like concepts, thread safety, concurrency, a strong memory model, improved security, and the library needed to repair, oh, perhaps a really awful std::kstring implementation, and perhaps std::vektor<bool>. But also, this K-- language is incredibly popular, to the tune of roughly 75% of worldwide software revenue. So you can’t just change the language and runtime – too much software depends on it. You have to provide a reasonable migration path.

You need to provide a way for the new language version to invoke code authored with the old language version at a function level. That’s pretty straightforward, generally. Now you get into the messier stuff: You also want to provide a mechanism by which old code can invoke new code when it’s interface doesn’t require any of the new features. Think extern "c",here. That takes care of the language side of the migration, but there’s still the library to worry about. Language users need to be able to rely on the old library, while bringing in portions of the new runtime, so your legacy code base can migrate as a business model allows.

I’ve heard comments that, hey, TR1 is this, but there’s nothing that breaks the old runtime, when it really should have been broken! Std::string needs to be replaced by a better implementation, which, unfortunately, will break current code. std::vector<bool> should be probably be deprecated. The containers need to be cleaned up. Stack/queue/pqueue implementations should have unified interfaces. <algorithms> needs to provide a "whole container" approach [I think to do this and still support ranges would require concepts, or massive renaming]. We should get an auto type-deduction for variables. We need a strong memory model, we need a better story for concurrent programming, and we need this stuff soon! All of these things could be done, but only parts of them are being considered, because there seems to be too much concern over legacy support.

Rather than worrying about legacy support, there should be concern over providing a well defined and straightforward migration path.

But then what do I know, I'm just a back-end guy...

Comments