I've just finished reading C++ Template Metaprogramming again. I just don't get it.
Why would someone use a type container?
I have used enable_if, along with some of the logic functions for managing an overload set. Otherwise, I'm clueless.
I'd really like a reference to an MPL primer or some case studies.
The book contains a case study in which type sequences are used to describe the rows of a state machine's transition table. Was that not a sufficient motivating case?
FSMs are not something I'm familiar with. I didn't really notice the vector of rows until recently. How is the FSM approach in your book better than arrays of structs? I didn't see any advantage, and the supporting code is too complex. There must be an advantage, otherwise, why would you work so hard to write these things? I'll try to implement a reusable FSM framework, without MPL. Then, perhaps, advantages/disadvantages of MPL would be more apparent to me. Is there a good way to post hundreds of SLOCs for discussion? I don't have a website. BTW, on the boost website, there are three versions of the FSM player example. A ReadMe.txt to explain the differences would be helpful.
Too much pain with very little gain.
What, specifically, do you find painful?
Well, you asked...
I write stuff that I think should work, but the compiler issues tons of
error messages.
Pitfalls like when to use typename.
Brain cramps trying to comprehend the compile-time/run-time boundary.
Recently, I tried to avoid using a large 150-case switch statement using
metaprogramming.
Each MessageNN has a unique static const int TAG member. They all derive
from a common Message base class that has the common message header,
including the tag.
The only thing each case did was something like.
switch (msg.tag()) {
case Message26::TAG:
cout << static_cast
Time to ask for help. Rereading this, it sounds negative. Really, I think the MPL is really cool!
Cool, how can we help?
Do know how to do a mind-meld? (Spock recoiled, his face white with shock.
He had never experienced such chaos before.)
I need to be patient and ask one question at a time. There is a lot of
really difficult material packed into a deceptively slim book.
So, back to that switch statement... is there a better way?
I thought of using something like:
template <Tag> struct DerefTag { typedef Message type; }
And then specializing it like this.
template <> struct DerefTagMessage26::TAG { typedef Message26 type; }
But that can only be used with compile-time constants, limiting its
usefulness.
Now I can write each case statement like this:
case Message26::TAG:
cout << static_cast