invoking Base::virtualMethod() instead of Derived

This is a discussion on invoking Base::virtualMethod() instead of Derived within the C++ Programming forums, part of the General Programming Boards category; In my class Js ::Object I've an operator() overload which returns Js ::JType* all Other Classes in Js Namespace e.g. ...

  1. #1
    Registered User
    Join Date
    Jun 2007
    Posts
    219

    invoking Base::virtualMethod() instead of Derived

    In my class Js::Object I've an operator() overload which returns Js::JType*
    all Other Classes in Js Namespace e.g. Js::Number, Js::String etc.. even Js::Object inherits from Js::JType

    Code:
    Js::JType* &operator()(const string& key);
    source
    Code:
    /**
    typedef std::map<string, Js::JType*> ElemMap;
    */
    Js::JType* &Js::Object::operator()(const string& key){
    	ElemMap::iterator it=list.find(key);
    	if(it != list.end()){
    		return (Js::JType* &)(it->second);
    	}else{
    		Js::JType* x = new Js::JType;
    		list.insert(make_pair(key, x));
    		return x;
    	}
    }
    and this is how I am using it.

    Code:
    Js::Object o;
    o("math") = new Js::String("Hello World");
    Now If everything is ok.

    Code:
    o("math")->commit()
    should return "Hello World" (with quotes as std::string)

    then it will invoke Js::String::commit()
    But Its invoking Js::JType::commit()

    and thus its returning null (as std::string)

    e.g. in other words its invoking the commit() of grand parent Class not of the intended class.

    and yes commit is virtual.

    Hope I am able to clarify the problem.

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    You are returning a reference to a local pointer in the else case (and the compiler might be able to warn about that with warnings on). Instead you should probably return a reference to the pointer that is held in the map, because that is what you want to modify.

    In any case you are leaking memory: who's cleaning up the object allocated by operator() when you immediately assign it another pointer allocated with new.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #3
    Registered User
    Join Date
    Jun 2007
    Posts
    219
    Now I am using.
    Code:
    Js::JType* x = new Js::JType;
    list.insert(make_pair(key, x));
    return list[key];
    It fixes the problem and I think its might raise a null pointer issue which is not going to harm in my application.But I don't think it dies memory leak.

  4. #4
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    Quote Originally Posted by noobcpp View Post
    Now I am using.
    Code:
    Js::JType* x = new Js::JType;
    list.insert(make_pair(key, x));
    return list[key];
    It fixes the problem and I think its might raise a null pointer issue which is not going to harm in my application.But I don't think it dies memory leak.
    Insert returns an iterator, so better would be:
    Code:
    Js::JType* x = new Js::JType;
    return list.insert(make_pair(key, x)).second;
    Or at least, it wouldn't need the extra lookup . About not dying by memory leaks... well, memory leaks are still really bad. And yes, it *will* die from it if the program runs for too long. It's really advisable to fix it. A simple hack-fix would be to replace the pointers by reference counted pointers, which clean up their memory automatically if they are no longer required.

  5. #5
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,915
    Not a hack fix. A valid solution, actually. It recommended to use smart pointers as much as possible.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #6
    Registered User
    Join Date
    Jun 2007
    Posts
    219
    But using smart pointers increases syntactic complexity.
    even if I design a macro for general pointer to auto_ptr you still have to type the macro name.
    its not an automatic job.

  7. #7
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,915
    Syntactic complexity is hardly a convincing argument not to use a smart pointer.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #8
    Registered User
    Join Date
    Jun 2007
    Posts
    219
    One solution probabbly can do coertion
    If I've
    Code:
    operator std::auto_ptr<Class>(){
      return std::auto_ptr<Class>(this);
    }
    But is this solution recomendable ??

    and if all my functions take auto_ptr<> as argument it will automatically be converted.

  9. #9
    The larch
    Join Date
    May 2006
    Posts
    3,573
    I don't think auto_ptr's are versatile enough to solve all memory management issues.

    In any case, why can't you have two separate methods for getting and setting values?
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  10. #10
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Oh my god, you're overcomplicating this method. The correct implementation for operator() is :
    Code:
    Js::JType*& Js::Object::operator()(const string& key){
      return list[key];
    }
    This returns a null pointer if the object isn't in there yet, but if you ask me, that's preferable to a newly created JType.

    This leaves open the question whether this the right approach at all.
    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

  11. #11
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    CornedBee: Yes, that is what rip-off suggested to him on Gamedev.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  12. #12
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    How would I know?

    That's just why we discourage cross-posting here.
    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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 8
    Last Post: 06-03-2009, 04:00 PM
  2. deriving classes
    By l2u in forum C++ Programming
    Replies: 12
    Last Post: 01-15-2007, 05:01 PM
  3. Help accessing classes and derived classes
    By hobbes67 in forum C++ Programming
    Replies: 8
    Last Post: 07-14-2005, 03:46 PM
  4. Replies: 8
    Last Post: 07-27-2003, 02:52 PM
  5. Inheiritance and derived classes
    By pecymanski in forum C++ Programming
    Replies: 2
    Last Post: 12-09-2001, 03:50 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21