Hi all! Can anyone help me? I've got a problem with my library "Lazy". Here's the code: template<typename T, int N> class B {}; template<typename T> class C : B<T, max_possible_N_of_all_specializations_B<T> > {}; //The question is - How To write //max_possible_N_of_all_specializations_B? So, if I have these template specializations of B: template<> class B<int, 4> { enum { value = 4}; }; template<> class B<int, 920234> { enum { value = 920234 }; }; C<int>::value should be 920234. Does anyone knows how to do it? Thanks in advance. P.S. It's critical for my library to have max_possible_N_of_all_specializations_B. -- Pavel Chikulaev
I do not want to discourage your efforts, but comp.lang.c++ would be a better place for these kind of questions (IMO since I am not a moderator). Gennadiy
On 03/10/2005 03:29 PM, Gennadiy Rozental wrote:
I do not want to discourage your efforts, but comp.lang.c++ would be a better place for these kind of questions (IMO since I am not a moderator).
Well, I thought it was kinda an MPL question; hence, this would be the first place I'd ask such a question. However, I have no idea how to do what Pavel wants. And, not to be discouraging, but I doubt it can be done because... well I guess because the template doing the calculation would have to have some way to enumerate all the specializations, and there's know way to do that without examining all the code, and that's something only the compiler can do, AFAICT.
Pavel Chikulaev wrote:
Hi all!
Can anyone help me? I've got a problem with my library "Lazy". Here's the code:
template<typename T, int N> class B {};
template<typename T> class C : B<T, max_possible_N_of_all_specializations_B<T> > {};
//The question is - How To write //max_possible_N_of_all_specializations_B?
Look at this thread: http://lists.boost.org/MailArchives/boost/msg37791.php Jonathan
Jonathan Turkanis wrote:
Pavel Chikulaev wrote:
Hi all!
Can anyone help me? I've got a problem with my library "Lazy". Here's the code:
template<typename T, int N> class B {};
template<typename T> class C : B<T, max_possible_N_of_all_specializations_B<T> > {};
//The question is - How To write //max_possible_N_of_all_specializations_B?
Look at this thread: http://lists.boost.org/MailArchives/boost/msg37791.php
You're kidding, aren't you ?
Tobias Schwinger wrote:
Jonathan Turkanis wrote:
Pavel Chikulaev wrote:
Look at this thread: http://lists.boost.org/MailArchives/boost/msg37791.php
You're kidding, aren't you ?
I'm not sure what you mean. I don't believe it's possible to do what the OP wants; I just pointed to a thread which discusses a similar issue. Here's another one: http://lists.boost.org/MailArchives/boost/msg76091.php Jonathan
Jonathan Turkanis wrote:
Tobias Schwinger wrote:
Jonathan Turkanis wrote:
Pavel Chikulaev wrote:
Look at this thread: http://lists.boost.org/MailArchives/boost/msg37791.php
You're kidding, aren't you ?
I'm not sure what you mean. I don't believe it's possible to do what the OP wants; I just pointed to a thread which discusses a similar issue. Here's
It seemed to me as a suggested solution.
another one: http://lists.boost.org/MailArchives/boost/msg76091.php
Yeah, nice hacking! I guess this one will be another few minutes of fun (but I'll save it for tomorrow, because it's 2 AM here already and I have to get some sleep). Greetings, Tobias
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:d0qot3
Can you provide some background information ? Example one: same old class Matrix { Matrix(LAZY_OP((Matrix_ + Matrix_ ) * Matrix_)); Matrix(LAZY_OP(Matrix_ * ( Matrix_ + Matrix_))); }; //.. Matrix a, b, c, d, e; e = (a + b) * (c + d); //What to choose: first or second? //I mean //First: //Matrix t = c + d; //e = (a + b) * t; //Second: //Matrix t = a + b; //e = t * (c + d); //My idea is to add unique number to each n-arity operator //(some kinda weight of operator), and choose the n-arity operator //with maximum value. //So I really need that max_possible_N_of_all_B_specializations<T>::value.
Example two: same old class Matrix { Matrix(LAZY_OP((Matrix_ + Matrix_) * (Matrix_ + Matrix_))); Matrix(LAZY_OP(Matrix_ * (Matrix_ + Matrix_ * Matrix_)))); }; //.. Matrix a, b, c, d, e, f; f = (a + b) * (c + d * e); //Again: First or Second? -- Pavel Chikulaev
Pavel Chikulaev wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:d0qot3
Can you provide some background information ?
Example one: same old class Matrix { Matrix(LAZY_OP((Matrix_ + Matrix_ ) * Matrix_)); Matrix(LAZY_OP(Matrix_ * ( Matrix_ + Matrix_))); }; //.. Matrix a, b, c, d, e; e = (a + b) * (c + d); //What to choose: first or second? //I mean //First: //Matrix t = c + d; //e = (a + b) * t; //Second: //Matrix t = a + b; //e = t * (c + d); //My idea is to add unique number to each n-arity operator //(some kinda weight of operator), and choose the n-arity operator //with maximum value. //So I really need that max_possible_N_of_all_B_specializations<T>::value.
Honest answer: I belive this idea is no good.
Example two: same old class Matrix { Matrix(LAZY_OP((Matrix_ + Matrix_) * (Matrix_ + Matrix_))); Matrix(LAZY_OP(Matrix_ * (Matrix_ + Matrix_ * Matrix_)))); }; //..
Is it necessary to specify such rules ? Isn't it enough to tell your lib operator + and operator * are "expression object factories" rather than imperative routines ? It might be possible to partially allow stuff like this using overloading [ ref. 14.5.5.2 ], but the possibility of creating ambigous situations can't be fully eliminated.
Matrix a, b, c, d, e, f; f = (a + b) * (c + d * e); //Again: First or Second?
Neither, it is ambigous. Regards, Tobias
"Tobias Schwinger" wrote :
Honest answer: I belive this idea is no good.
If I need numbers It's doesn't mean that user will see them. I'm just going to put unique number to each tree shape. And use with maximum value to remove disambiguos situations.
Is it necessary to specify such rules ?
I don't know. Do you know any languages where n-arity operators are built-in? Actually C++ was going to have them, but it wasn't accepted. Gotta look at that paper.
Isn't it enough to tell your lib operator + and operator * are "expression object factories" rather than imperative routines ? Bad English. Please try again with simplier words :)
It might be possible to partially allow stuff like this using overloading [ ref. 14.5.5.2 ], but the possibility of creating ambigous situations can't be fully eliminated.
I'm already using this. But aforementioned examples were exclusions where that rule doesn't work. -- Pavel Chikulaev
Pavel Chikulaev wrote:
"Tobias Schwinger" wrote :
Honest answer: I belive this idea is no good.
If I need numbers It's doesn't mean that user will see them. I'm just going to put unique number to each tree
Oh, I've nothing against numbers in general ! ...and I wasn't concerned about hiding them from the user, either.
shape. And use with maximum value to remove disambiguos situations.
Problems like the one you describe here (like hitting the boundaries of the language) are usually solved best by stepping back and finding a way dodge around it instead of using hammer and crowbar to solve them. ( The design of a software component can be seen as a path through a decision tree. When encountering a leaf node and the design is not complete, it is necessary to ascend and take another branch. The boost mailing list is a forum where you can meet people very trained and experienced in traversing these trees. The right questions at the right nodes will literally boost the traversal process ;-) )
Isn't it enough to tell your lib operator + and operator * are "expression object factories" rather than imperative routines ?
Bad English. Please try again with simplier words :)
expression object factory: function (only) returning an expression object (to be evaluated later) imperative routines (in this context): function that does the calculation (and returns the result)
It might be possible to partially allow stuff like this using overloading [ ref. 14.5.5.2 ], but the possibility of creating ambigous situations can't be fully eliminated.
I'm already using this. But aforementioned examples were exclusions where that rule doesn't work.
That's why I called them ambiguous. Regards, Tobias
Pavel Chikulaev wrote:
"Tobias Schwinger" wrote :
Honest answer: I belive this idea is no good.
If I need numbers It's doesn't mean that user will see them. I'm just going to put unique number to each tree shape. And use with maximum value to remove disambiguos situations.
Is it necessary to specify such rules ?
I don't know. Do you know any languages where n-arity operators are built-in?
How about operator() () ? Jonathan
Pavel Chikulaev wrote:
"Tobias Schwinger" wrote :
Honest answer: I belive this idea is no good.
If I need numbers It's doesn't mean that user will see them. I'm just going to put unique number to each tree
Oh, I've nothing against numbers in general ! ...and I wasn't concerned about hiding them from the user, either.
shape. And use with maximum value to remove disambiguos situations.
Problems like the one you describe here (like hitting the boundaries of the language) are usually solved best by stepping back and finding a way to dodge around them instead of using hammer and crowbar to solve them.
Isn't it enough to tell your lib operator + and operator * are "expression object factories" rather than imperative routines ?
Bad English. Please try again with simplier words :)
expression object factory: function (only) returning an expression object (to be evaluated later) imperative routines (in this context): function that does the calculation (and returns the result)
It might be possible to partially allow stuff like this using overloading [ ref. 14.5.5.2 ], but the possibility of creating ambigous situations can't be fully eliminated.
I'm already using this. But aforementioned examples were exclusions where that rule doesn't work.
That's why I called them ambiguous. Regards, Tobias
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:d0spse$68t$1@sea.gmane.org...
Problems like the one you describe here (like hitting the boundaries of the language) are usually solved best by stepping back and finding a way to dodge around them instead of using hammer and crowbar to solve them.
Actually right now I know how write max_possible_N_of_all_T_specializations. So I don't need a hammer.
Isn't it enough to tell your lib operator + and operator * are "expression object factories" rather than imperative routines ?
I think no. I'll go further. As further as possible. -- Pavel Chikulaev
participants (5)
-
Gennadiy Rozental -
Jonathan Turkanis -
Larry Evans -
Pavel Chikulaev -
Tobias Schwinger