Is there any interest in tagged tuple?
Hi all, Is there any interest in tagged tuple as extension of tuples library or fusion library? The example: struct name_t {}; //tagged types struct year_t {}; void foo() { tagged_tuple<std::string, name_t, int, year_t> s; s.get<name_t>() = "Hello World"!; s.get<year_t>() = 2005; assert(s.get<0>() == s.get<name_t>()); assert(s.get<1>() == s.get<year_t>()); } It already works in VC7.1 and VC8.0 :) What do you think? -- Pavel Chikulaev
Pavel Chikulaev wrote:
Hi all,
Is there any interest in tagged tuple as extension of tuples library or fusion library? The example:
struct name_t {}; //tagged types struct year_t {};
void foo() { tagged_tuple<std::string, name_t, int, year_t> s;
s.get<name_t>() = "Hello World"!; s.get<year_t>() = 2005; assert(s.get<0>() == s.get<name_t>()); assert(s.get<1>() == s.get<year_t>()); }
It already works in VC7.1 and VC8.0 :)
What do you think?
Hi, The plan for fusion is to have a set and map associative tuples. Your tagged_tuple is very similar to a fusion::map. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Pavel Chikulaev wrote:
Hi all,
Is there any interest in tagged tuple as extension of tuples library or fusion library? The example:
struct name_t {}; //tagged types struct year_t {};
void foo() { tagged_tuple<std::string, name_t, int, year_t> s;
s.get<name_t>() = "Hello World"!; s.get<year_t>() = 2005; assert(s.get<0>() == s.get<name_t>()); assert(s.get<1>() == s.get<year_t>()); }
It already works in VC7.1 and VC8.0 :)
Reminds me of the mpl::inherit_linearly example: http://www.boost.org/libs/mpl/doc/refmanual/inherit-linearly.html (it shows a few-lines tuples implementation, using the value type as an "index").
What do you think?
As far as I can see, the semantics you propose can be decorated easily via MPL (set,begin,find,distance) and their use is uncommon enough to leave it an excercise to the user. Am I missing something ? Regards, Tobias
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:d9optu$i5v$1@sea.gmane.org...
As far as I can see, the semantics you propose can be decorated easily via MPL (set,begin,find,distance) and their use is uncommon enough to leave it an excercise to the user. Am I missing something ? I used MPL and tuples to achieve such semantics, but I've used two mpl::vectors(although map would be better here I think). Yeah implemention is a bit uncommon for most users :) (See attachment). But client code is quite clean and has good readability imho.
-- Pavel Chikulaev
Pavel Chikulaev wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:d9optu$i5v$1@sea.gmane.org...
As far as I can see, the semantics you propose can be decorated easily via MPL (set,begin,find,distance) and their use is uncommon enough to leave it an excercise to the user. Am I missing something ?
I used MPL and tuples to achieve such semantics, but I've used two mpl::vectors(although map would be better here I think). Yeah implemention is a bit uncommon for most users :) (See attachment). But client code is quite clean and has good readability imho.
Oh - here's a slight misunderstanding. I meant usefulness and not efficiency: I'm afraid the use case is too uncommon for "ordinary users" -- and those who are "type system hackers" anyway can get it done quite easily (or use Fusion -- reading Joel's post)... I'm sorry, it's not my intention to discourage you and I find it great you are motivated to make a useful submission! You'ld have my vote for some shiny new memory management components for example, such as sub heaps, strided pools, optimized block copy, etc. - if I'ld have the time ITM, I'ld volunteer for it myself ;-)... Regards, Tobias
participants (3)
-
Joel de Guzman -
Pavel Chikulaev -
Tobias Schwinger