"Christopher Kohlhoff" <chris@kohlhoff.com> wrote in message news:20060601012008.72917.qmail@web32609.mail.mud.yahoo.com...
Hi Beman,
Beman Dawes <bdawes@acm.org> wrote:
That said, I guess there could be an argument to expose the templates for those who prefer them.
Here's an argument for exposing templates:...
I am going to expose the templates - I'm made the code changes and am working on docs now.
it allows the template parameter to propagate up into my own types. I'm thinking something like:
template <typename Endianness> struct my_message { integer<4, Endianness> foo; integer<2, Endianness> bar; ... };
This permits me to write one function template to handle my_message structures in programs that need to deal with both little- and big-endian at runtime (i'm thinking "receiver makes right" protocols).
With this scheme there should probably also be a type for native endianness so we could write:
my_message<endian::big> msg1; my_message<endian::little> msg2; my_message<endian::native> msg3;
Interesting.
etc. In my opinion a similar argument applies to exposing the alignment as a template parameter.
Yeah. Those are separate classes now. Probably not too hard to wrap in a generative class template that takes endianness and alignment as template arguments and then just instantiates one of the current classes. Anyone like to contribute such an animal? --Beman