* Chidambaram Annamalai <[email protected]> [2010-08-11 13:12:46 +0530]: > Have you even bothered to look through the sources? You really have yes although it was a couple of years ago last time i used bgl
> to decouple the storage schemes from the algorithms so that you can write > O(M + N) code to support O(M*N) template instances. And there is no point if > this abstraction had a severe penalty on the runtime performance. BGL > exactly knows which algorithm to use for a particular storage mode because > intelligence is built into it using traits. The hierarchial design (which is this is a misconception about bgl and c++ generic programming in general you can treat certain aspects of the algorithms but not everything genericity is only available where the designers thought about it (eg you cannot reuse a stack in dfs graph traversals of various graphs because it is hardcoded in boost) this usually ends up in a lot of configurability where users don't need it, but the result is still not flexible enough for practical problems that's why everyone ends up implementing their own containers instead of using stl in a bigger c++ project (eg by adding concurrency support or using different tradeoffs in the algorithm design, so eventhough stl is very generic it is still not flexible enough) intuition tells that generic code allows easy replacement of components but this is a fallacy: - the designer must know how the code will be used in advance and decompose the algorithms that way - the users need to know a lot more about the internal implementation, how an abstract component interacts with others (the more fine grained the generic code the more difficult to use it) (it's not true that you can easily write your own graph represantation to use it with boost you need to know a lot of details) (from the docs a lot of semantic detail is not clear, eg can you modify a graph from a visitor? boost uses iterators and in many datastructure modifications invalidates them) - when an algorithm is used in the most simple and usual way, genericity causes a lot of unnecessary boilerplate, confusion about the api, and cryptic compiler error messages (to find the shortest path in a simple directed graph with int edge weights, i still have to fill the template arguments http://www.boost.org/doc/libs/1_43_0/libs/graph/example/dijkstra-example.cpp this is not elegant code) i experimented with various types of genericity for algorithms here is one approach: implement the algorithm in the simplest way for the most useful types etc. then when you need it for a specific task then copy the code and apply appropriate modifications in the source (often s/type1/type2/g) it turns out that with this approach it's often easier to change a component without screwing things up than by understanding all the gory details of a generic api like boost adapting an algorithm for your usecase usually takes less than an hour and the result is readable customized code, easy to debug, easy to edit > Template metaprogramming uses static polymorphism which is an entirely > different beast from OO inheritance that uses dynamic polymorphism. yes, each of them has quirks and the user of the library should deal them (using various concepts together the complexity of the result is the product of the complexity of each part, not the sum) my argument is that this amount of abstraction just not worth the effort (at least in c++)
