David Abrahams wrote:
Again, this does not mean that we avoid templates, and it doesn't mean we have no templated interfaces :).
Oh, I got a different impression from earlier messages in this thread.
What Chris says is true. My message was more to the point of seeing if Boost could provide solutions for common problems in llvm. When I brought this up on the llvm list, the feedback was rather strongly negative. My goal here is not to force anything on llvm. Rather, it's to improve the Boost community's ability to clearly articulate the tradeoffs involved in using Boost. Now, in my own experience these tradeoffs have almost always been a win and I believe there are places in llvm where they could be a win as well. Mathias brings up reasonable questions as to the pointer-based interface. It's true that llvm has had more problems with iterators (in fact, I discovered many of them). I believe this is due to a combination of relative inexperience with the standard library but also some inconsistency in how the standard library's proponents present their case. BUT, those problems were easily found BECAUSE the iterator interface is well-encapsulated in a way that allows injection of bug-checking code. BTW, the specific issue that keeps coming up involves taking the address of the first element of an empty std::vector: &a[0]; The C++ community promotes std::vector as a C array replacement, but it's really not because it's not legal to do the above operation when the vector is empty. I believe this is because the vector interface is characterized in terms of iterators rather than addresses. Thus operator[] implies operator* even though the address of the result is all that's desired. -Dave