Suddenly I see the problem. It is in the std::string, not in the AbstractObject.

std::string("print") creates a temporary object. In C++ you can pass a temporary object as a parameter to a function by value or by const&. You cannot pass it by non const &.

If you don't want to change the declaration of set(), you need to make the temporary object a local object instead, so the correct call would look like:

Notice the {} around the definition and use of local_string. Those make it just as temporary as the unnamed string in your version. But according to the language rules it is a local object, not a temporary object, so passing it by non const & is OK.

However, if I looked at your whole program I'd probably suggest changing the declaration of set() instead. Unless I'm totally wrong in guessing the nature of that function, passing it a std::string& is bad design. It should be std::string const&

What does that mean?

None.

I tried making it virtual to see if it would get rid of the error.

I thought it was a reasonable and relevant request for clarification of what you said in post #1. I'm surprised you don't understand what I was asking. But anyway don't worry about it, because I only asked that as a result of missing your post #13 (and thus fishing for unlikely complications).

In case you missed it while we were cross posting, read my post
http://www.linuxquestions.org/questi...6/#post4226427
for explanation of your coding error.

Hi, MTK358 -

No offense - but you really, REALLY need to step back and review a few more C++ basics before you continue on this course. A few book recommendations:

* Programming Principles and Practice Using C++: Bjarne Stroustrup

* The C++ Programming Language: Bjarne Stroustrup

* Effective C++: Scott Meyers


You're running up against my single biggest objection to C++: there are far too many subtleties that have nothing to do with the problem you're trying to solve, but everything to do with the (over-complicated) language.

Please do yourself a BIG favor and do some more background reading first. If you understand the difference between a public base class and a private base class (and why you almost always use the former), or why if you have a virtual base class, you should almost always have a virtual destructor - then you know you're probably heading in the right direction

Or you can just learn Java, Python or Free Pascal instead

IMHO .. PSM

2 members found this post helpful.

I also dislike C++ for the same reason and would like to use something else, but I don't see any other good choices.

My project is a simple language interpreter, now trying to implement scopes, functions, and objects (by storing scopes in varibles) rather than being limited to integers.

And, of course http://openassist.googlecode.com/fil...882%202003.pdf (the standard) - reading this I see quite a few really nasty gotchas, like, for example, initialization of structures with some static members - arrrgh !!!

I.e. I agree with paulsm4 regarding "(over-complicated) language".

I think learning by doing ends up working better. You make mistakes, such as the one I explained in post #16 of this thread, then you find out what is wrong, then hopefully you understand the issue next time.

Learning by reading books doesn't work as well.

I absolutely agree. That is what makes C++ a terrible language. Within that, the rules for matching the parameter types in a function call to the types in a function declaration (which tripped up the OP in this thread) may be the nastiest most over-complicated aspect of the language.

But despite being a terrible language, C++ is far better than any other popular programming language.

I almost always use public base classes. Many experts disagree and almost always use private base classes.

Most people would take that phrase to mean virtual inheritance of a base class. But I think you might mean simply having a base class that has virtual functions (very different from virtual inheritance).

For either meaning of the earlier phrase that is not a particularly helpful rule.

It's hard to even imagine the point you're trying to make with that.

IM~HO, none of those do the job C++ does.

check in/out params maybe set just expect different type.number of variables to call.
btw: gcc is pia if virtual is not defined in place virtual void mustbeset(){}; can be overloaded later.

Somehow I tried again today and it doesn't have that error. Now it says:

Where is the definition of that destructor?
I think you should read up this: http://www.crasseux.com/books/ctutor...html#Debugging

and it is also better to read the error message and try to Google first.

1 members found this post helpful.

Nowhere.

Very nice, did you click the link I posted?

I fixed it now.

That error at link time normally means that function has been declared but not defined.

If an ordinary function were used not declared, you would get an error at compile time not link time. So for an ordinary function that error would imply used and declared but not defined.

Failing to declare a destructor should not give an error at either compile or link time. The compiler provides a destructor if you don't declare one.

By declaring the destructor, you keep the compiler from providing it. Then by not defining it, you cause this error. (So details are different between ordinary and special functions but the bottom line of declared but not defined is the same).

Hopefully you won't need to ask such questions in the future. You posted a pretty clear error message implying the function wasn't defined. Before asking for any help, you should have looked at the definition of that function (in this case discovering you didn't have one).

There are obscure causes for almost any clear looking error message. So after you look into the obvious meaning of the error message, you might occasionally still need help. But don't make asking for help your first step in diagnosing a problem.

BTW, you might notice the error was reported for the constructor. A non virtual function declared but not defined is only an error if the function is also used. But your destructor is virtual. An virtual function declared but undefined causes an error at link time in the constructor (assuming the constructor is either defined or used).

2 members found this post helpful.

Just one more thing:

And when I call it:

It says:

But AbstractFunction is an abstract class, and I don't want call() defined.