On Wed, Jun 06, 2007 at 10:52:28AM -0400, David Abrahams wrote:
By "down-to-earth" I suppose you mean "like the problem I'm trying to solve?"
No. I mean examples other than implementing DSLs. I can compare it to the first time I learned about pointers from Wirth's Pascal book: he introduces pointers, shows how to allocate a variable on the heap and how to access it, but.. I kept wondering about what pointers are *useful* for all the way until the example with a linked list. [I was _very_ young then, so I have also wondered about what the linked list was good for, but.. :)]
I'm in the process of writing a recursive data structure with very similar operations at every level, but still with small behavioral variations. It seems like a perfect problem for metaprogramming,
Why?
Hm, good question. I might be prejudicing the solution. Because I have a recursive algorithm and data structure that I'd like to "unroll" at compile-time.
Maybe because that's not the most appropriate approach for your problem. Did you go through the book's criteria for when metaprogramming might apply, in section 1.1.6?
Yes. So, to summarize the questions 1-5: 1. Abstractions of the problem domain: there is no 'domain'. It's a single specialized data structure and associated code (hierarchical scheduler). The scheduling algorithm is the same at each level in the hierarchy (+ a special case at the root). 2. No large amounts of boilerplate code. Just (almost) duplicated code for three (almost) identical classes. 3. I don't need to choose component implementations. 4. Yes, I do want strong type-checking and behavioral customization (different data structures in scheduler nodes). 5. Yes, I want to do it all in C++.
I have been working on something that sounds similar to what you're doing, but I'm using basic generic programming to do it. Have you seen http://lafstern.org/matt/segmented.pdf ?
No, I'll take a look. Thanks. It may also be the case that I'm missing the boundary between generic programming and metaprogramming.
would be of much help to you. If you're not specifically trying to raise the abstraction level of your client's code to the point where they can be seen to be using a DSEL, you probably don't want
No, I'm not trying to do that. I'm trying to refactor the code so that it becomes "manifestly correct" when read together with a high-level description of the algorithm. Best regards, Zeljko.