Oh, so you were looking to set the value of the metaObject<int> subobject of the combined o object?
You were looking for metaObject< types<int, end> >.
Oh, so you were looking to set the value of the metaObject<int> subobject of the combined o object?
You were looking for metaObject< types<int, end> >.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
yes, but the specialization never resolves to the case where tail is of type end; like it's allegedly supposed to as per dr. dobb's example. it always resolves to this:
instead of the partial specialization where tail is end.Code:template<typename H>class metaObject {public:H* value; };
What do you mean? If you remove the reference to metaObject<int> and remove the definition of the unspecialized metaObject again, what happens?yes, but the specialization never resolves to the case where tail is of type end;
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
assuming i'm understanding you correctly - nothing happens. it's exactly the same as before. if i change the name of the unspecialized value to something else, surely enough, that is the variable stored in o.
consider:
am i correct? i appreciate the value of the socratic method (and i hope you're being socratic with me), but i've been thinking about this for a while and i just don't get it.Code:template<typename H>class metaObject { public: H* shouldNotGetHere; }; template<typename H,typename T>class metaObject< types<H,T> >: public metaObject<T> { public: H *headvalue; }; template<typename H>class metaObject< types<H,end> > { public: H *tailvalue; }; void test() { metaObject<types<int,double> >o; o.shouldNotGetHere; o.tailValue; }
aah the problem is that it just isn't recursing; adding 3 types yields metaObject<types<t1,t2,t3> >
sweet - i got an implementation basically working
Code://--------------------------------------------------------------------------- #ifndef typelistH #define typelistH template<typename H,typename T>struct typelist { typedef H head; typedef T tail; }; struct end { }; template<typename T1,typename T2 = end,typename T3 = end,typename T4 = end>struct types { typedef typelist < T1,typelist < T2,typelist < T3, typelist < T4,end > > > > type; }; template<typename T> struct types<T,end,end,end> { typedef typelist<T,end> type; }; template<typename T1,typename T2>struct types<T1,T2,end,end> { typedef typelist < T1,typelist < T2,end > > type; }; template<typename T1,typename T2,typename T3>struct types<T1,T2,T3,end> { typedef typelist < T1,typelist < T2,typelist < T3,end > > > type; }; #endifCode:#ifndef metaObjectH #define metaObjectH #include "typelist.h" template<typename T>class metaObject { public: metaObject() { } T* value; }; template<typename H,typename T>class metaObject< typelist<H,T> >: public metaObject<H>, public metaObject<T> { public: metaObject(): metaObject<H>(), metaObject<T>() { } }; template<typename H>class metaObject< typelist<H,end> > : public metaObject<H> { public: metaObject(): metaObject<H>() { } }; template<>class metaObject< end > { public: metaObject() { } }; void test() { metaObject< types<int,double>::type >o1; metaObject< types<int,double,char>::type >o2; } //--------------------------------------------------------------------------- #endif
edit: crap i take it back - it now works with 3 types, but cannot deduce which specialization to use with 2... bleah
edit2: changed the typelist definition back to be non-recursive and now the compiler can deduce properly.
Last edited by m37h0d; 01-14-2009 at 01:31 AM.
hmm...using multiple inheritance like above provides a nice clean interface to metaobject, in that you don't have to specify the entire child typelist to access it, but you can only have any 1 type appear in the list only once, unless you nest it within another metaobject as part of the typelist.
however, having access to the complete child typelist might make it easier to access members by an index...
hmm indeed. any thoughts?
You could look at the source code of Boost.Tuple.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
well, i didn't look at tuple, but i looked at function. i didn't know you could use the elipsis in a template declaration! this is getting very interesting
Huh? You can't. Not yet. Variadic templates are a C++0x feature.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
http://www.boost.org/doc/libs/1_37_0...t.function_hpp
darn. oh well. definitely sounds like a reason to upgrade my compiler.
hmm... MSVC10 will not support variadic templates, but maybe some new version of g++ supports that feature (or will soon support it).Originally Posted by m37h0d
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Sorry, but the page you linked to is illustrative for humans. It is not the actual source. You'll have to go deeper into the source and find the actual definitions to see how they do it.
Edit: I'm fairly certain that support for variadic templates have been in the repository for GCC for a long time. There is at least some support in the GCC 4.4 build I have installed.
Soma
Last edited by phantomotap; 01-14-2009 at 11:11 AM.
I think even GCC 4.3 has some support for them.
The ellipsis syntax in the documentation of Boost.Function is just convenience for the reader, by the way. The actual code looks ... a little different. It simulates variadic templates (up to 50 arguments) via the very powerful Boost.Preprocessor library. Powerful, but the syntax is a nightmare.
Last edited by CornedBee; 01-14-2009 at 11:26 AM.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
^_^Powerful, but the syntax is a nightmare.
I hereby award you the "Understated Certificate of Understatement".
Soma