🔒 Locked

Parse Tree Conversion

Started by ndwork Dec 23, 2008 at 2:40 PM 3 replies 700+ views

Original Post

Dec 23, 2008 at 2:40 PM

I have used parse trees to implement the '*' operator for my templated container class. The problem is that the parse tree node is not converted back to a container class until the assignment occurs. So the following code causes an error:


int out = myFunc( container1 * container2 );

I am using visual studio 2005. The error code is:

Quote:
error C2784: 'T myFunc(const container &)' : could not deduce template argument for 'const container &' from 'parseTreeNode'

The method that I used to implement the parse tree was described in 'http://www.oonumerics.org/blitz/docs/', for those who are interested. Does anyone have any suggestions?

visitor

Dec 23, 2008 at 2:46 PM

You can probably give container a constructor that accepts a template expression.

ndwork

Dec 23, 2008 at 2:48 PM

Thank you for your suggestion. I should have mentioned it earlier. I have already implemented a copy constructor in the container class that accepts a parseTreeNode. Did you mean something other than that?

visitor

Dec 23, 2008 at 3:03 PM

I think this is a simplified case of what you are dealing with.

#include <iostream>template <class N>struct Y{    N n;    Y(N n): n(n) {}};template <class T>class X{    T value;public:    X(const T& value): value(value) {}    X(const Y<T>& y): value(y.n) {}    friend std::ostream& operator<< (std::ostream& os, const X<T>& x) { return os << x.value; }};template <class T>void foo(const X<T>& x){    std::cout << x << '\n';}int main(){    Y<int> y(2);    //foo(y);    foo<int>(y);}

It indeed won't be able to deduce the required type of X in the foo call, unless the template type is explicitly given. Can't really think of a way to make that happen implicitly.

ndwork

Dec 30, 2008 at 2:38 PM

The source code that you've written is exactly my problem.

Had foo accepted a member of type Y, there would not be a compiler error. Foo could deduce its argument from the input parameter.

In this case, though, there is a copy constructor that is being called. Is this the reason why an ambiguity occurs?

Does anyone know a way around this without explicitly defining the type in the function call?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.