Thanks, but no. Using an std::map is between 100 and 10,000 times slower than using direct struct access. Not exactly what you want to put at the inner core of a massively multiplayer physics simulation, say :-) Also, a struct lets you lay out the order of members explicitly, which is important in many cases.

Really, I'm coming at this from the point of view of having used plain structs plus separately coded meta-data (functions or macros) to do marshalling for networking, but I want a simpler model that doesn't separate data (the struct members) and metadata (the marshalling and other visitors). I also don't want to use code generation (the traditional "solution" used in RPC).

Anyway, with a combination of my initial attempt and the inspiration of using type-specific access to get the member (thanks!) I'm all set.

For more reference, see this thread in the networking forum, where I initially suggested the approach in answer to a question, and then made sure that the sketch I suggested actually was implementable :-)


Edit: Ah, I didn't see that the "map" was a boost::fusion map, not a std::map. I think my solution is better for my needs, because boost::fusion::map uses a std::vector to store data (yeach!) and because it allows me to specify metadata (# of bits used in marshalling, etc) and explicit visitor policies. The traits actually get defined from macros, so the "real code" looks a lot simpler; my specific templates go in a header somewhere.

Not to mention I think get<>() and set<>() just reads more naturally than at<>().

Well; it uses a boost::fusion::vector for storage internally. After wading through the hundreds of headers, I agree: it does pretty much the same thing. Mine's a lot shorter, though (and I still like get<name> better :-)

For reference, here's how I packed it up (the same example you posted):



So, mine's a few lines shorter, and compiles significantly faster (even with precompiled headers).

I admire everything they do in boost -- I just wish more of it was actually practically usable in everyday life. Having to do with anything from the readability of the code, to compile times, to the general understanding of the library among practitioners in the industry.

But that's a different thread :-)

Quote:Original post by darkchrono4
Not trying to hijack anything, but *nobody* can say that makes a program any more readable or easier. I thought I had a fairly decent grasp of the language but I have no clue what is going on.

Template tricks like that generally end up forming the guts of a library. The code that uses that library is usually very readable. Making a library that is easy to use is not simple.