rewrite const property through overloading

This is a discussion on rewrite const property through overloading within the C++ Programming forums, part of the General Programming Boards category; Hello everyone, I have tried compiler allows to change const property of an overloaded method. Here is my proof of ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    rewrite const property through overloading

    Hello everyone,


    I have tried compiler allows to change const property of an overloaded method. Here is my proof of concept code.

    My question,

    1. is it good code or good practice?
    2. It yse in (1), are there any practical usage of this type of "overloading"?

    Code:
    class Base {
    public:
    	const int foo() {return 200;};
    };
    
    class Derived : public Base {
    public:
    		int foo() {return 100;};
    };
    
    int main()
    {
    	Base b;
    	Derived d;
    	int rtn = b.foo();
    	rtn = d.foo();
    
    	return 0;
    }

    thanks in advance,
    George

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Your concept code doesn't tell me much.

    An integer called rtn is declared, and assigned 200 from b.foo(). Then it is assigned 100 from d.foo().

    The return type of foo (int or const int) has no relevance in this code: the return value is assigned to a simple non-const int and you can do anything you like with it. The code would compile the same if you swapped the calls to d.foo() and b.foo().
    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
    May 2006
    Posts
    1,579
    Hi anon,


    My bad example. I mean overriding, not overloading. I have tested we can change the parameter type from const to non-const (and vice versa) in base/derived class and it still works.

    1. is it good code or good practice?
    2. It yse in (1), are there any practical usage of this type of "overriding"?

    Code:
    class Base { 
    public: 
    const int foo () {return 200;} 
    const int goo (const int input) {return 200;} 
    }; 
    
    class Derived : public Base { 
    public: 
    int foo() {return 100;} 
    int goo (int input) {return 200;} 
    }; 
    
    int main() 
    { 
    Base b; 
    Derived d; 
    int rtn = b.foo(); 
    rtn = d.foo(); 
    
    return 0; 
    }

    regards,
    George

    Quote Originally Posted by anon View Post
    Your concept code doesn't tell me much.

    An integer called rtn is declared, and assigned 200 from b.foo(). Then it is assigned 100 from d.foo().

    The return type of foo (int or const int) has no relevance in this code: the return value is assigned to a simple non-const int and you can do anything you like with it. The code would compile the same if you swapped the calls to d.foo() and b.foo().

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Nothing has changed. The constness of primitive temporaries is irrelevant.

    Nor are you overriding anything, because the functions of the base class aren't virtual.

    But for what it's worth, with the exception of return type covariance, having overriding functions return a different type from the base versions is not only very, very bad practice, but also largely disallowed when actually overriding.
    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

  5. #5
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    Quote Originally Posted by CornedBee View Post
    Nothing has changed. The constness of primitive temporaries is irrelevant.
    primitive temporaries means temporary variable for POD types?

    Quote Originally Posted by CornedBee View Post
    But for what it's worth, with the exception of return type covariance, having overriding functions return a different type from the base versions is not only very, very bad practice, but also largely disallowed when actually overriding.
    What do you mean covariance?


    regards,
    George

  6. #6
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,762
    >> primitive temporaries means temporary variable for POD types?

    As far as I can tell.

    >> What do you mean covariance?

    Covariant return types are defined here in this discussion of the virtual constructor idiom. In a nutshell, the feature, when supported, allows a difference in return type for a function that you were supposed to implement for an instance of some (abstract) class. This is largely supported out of respect for type strictness, I believe.

  7. #7
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks citizen,


    Quote Originally Posted by citizen View Post
    >> What do you mean covariance?

    Covariant return types are defined here in this discussion of the virtual constructor idiom. In a nutshell, the feature, when supported, allows a difference in return type for a function that you were supposed to implement for an instance of some (abstract) class. This is largely supported out of respect for type strictness, I believe.
    It is good article and I take some time to study. Cool!!

    Sorry I am not English speaker, and I do not know what the word "CoVariant" means here. I have looked up dictionary and only find it is a math term. :-)

    It is appreciated if you could say in some other words about what CoVariant mean?


    have a good weekend,
    George

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    It's "covariant", not "CoVariant". If there was any need for weird capitalization, I'd have used it in my original post.

    Covariance is a term specific to type theory. As such, the likelihood that you'd find it in a dictionary is rather slim. The idea is that as one property varies, another varies along with it - it "co-varies", thus showing covariance.
    In return type covariance, the primary varying item is the class that contains the method, and the secondary varying item is the return type of the method. As the primary varying item descends a class hierarchy, the secondary does, too. Usually, it's the same class hierarchy, but it doesn't have to be.
    The opposite of covariance is contravariance. Like covariance, contravariance is about two variables changing together, but the secondary variable changes in a way that is contrary to the primary variable. In type theory, the most important instance is argument contravariance. It's best illustrated as a snippet of code:
    Code:
    class foo_base {};
    class foo_derived : public foo_base {};
    
    class bar_base
    {
    public:
      virtual void method(foo_derived&) = 0;
    };
    
    class bar_derived
    {
    public:
      void method(foo_base&);
    };
    Note that, as the implementation class descends in the bar hierarchy, the argument of the method ascends. That's contravariance.

    Don't be fooled by the C++ syntax of the snippet. Contravariance is not supported by C++. The likely reason is that the interactions with overloading and type-safe linking were too complicated.
    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

  9. #9
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    Quote Originally Posted by CornedBee View Post
    Covariance is a term specific to type theory. As such, the likelihood that you'd find it in a dictionary is rather slim. The idea is that as one property varies, another varies along with it - it "co-varies", thus showing covariance.
    In return type covariance, the primary varying item is the class that contains the method, and the secondary varying item is the return type of the method. As the primary varying item descends a class hierarchy, the secondary does, too. Usually, it's the same class hierarchy, but it doesn't have to be.
    The opposite of covariance is contravariance. Like covariance, contravariance is about two variables changing together, but the secondary variable changes in a way that is contrary to the primary variable. In type theory, the most important instance is argument contravariance. It's best illustrated as a snippet of code:
    So, covariance in section [20.8] What is a "virtual constructor"? of http://www.parashift.com/c++-faq-lit....html#faq-20.8

    means, in the base class create/clone has return type Shape* in class Shape, but in derived class Circle, create/clone has return return type Circle*, right? So, (class and return type) covariant -- cochange? :-)


    regards,
    George

  10. #10
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Yes, it's one instance of covariance.
    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
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee!


    This is what you mentioned before,

    --------------------
    But for what it's worth, with the exception of return type covariance, having overriding functions return a different type from the base versions is not only very, very bad practice, but also largely disallowed when actually overriding.
    --------------------

    I have made some test on this statement,

    Code:
    class Base {
    public:
    	virtual int foo() {};
    };
    
    class Derived : public Base {
    public:
    	virtual double foo() {};
    };
    Compile error message,

    1>d:\visual studio 2008\projects\test_overriding1\test_overriding1\ma in.cpp(9) : error C2555: 'Derived::foo': overriding virtual function return type differs and is not covariant from 'Base::foo'

    My question is, for the concept of covariant, when we change from base to derived (this is one aspect of variant, and to make it "co"-variant, we could also change something at the same time in derived class to make it co-variant -- having two variants?), how could we change something in foo method in derived class to make it work and have the covariant pattern?


    regards,
    George

    Quote Originally Posted by CornedBee View Post
    Yes, it's one instance of covariance.

  12. #12
    l2u
    l2u is offline
    Registered User
    Join Date
    May 2006
    Posts
    630
    You could use templates this way:

    Code:
    template <typename T>
    class base {
    	base() { }
    	virtual T foo() = 0;
    };
    
    class derived : base<double> {
    	derived() { }
    	double foo() { return 0.0 }
    };

  13. #13
    Registered User
    Join Date
    Jun 2005
    Posts
    6,646
    Quote Originally Posted by CornedBee View Post
    Covariance is a term specific to type theory.
    That's not formally true.

    Covariance is actually a mathematical term, and it is a measure of correlation between two random variables. The covariance of two random variables X and Y, Cov(X,Y), is defined as
    Code:
    E{(X-E{X})(Y-E{Y})}
    where
    Code:
    E{A}
    is the expected value of A (i.e. the statistical mean).

    Covariance in type theory, as you describe it, is actually a special case of the mathematical concept in which X and Y have discrete values (eg in return type covariance, X is the set of types of the object containing the method and Y is the set of return types of the method). Contracovariance simply means that the covariance Cov(X,Y) has a negative value.

  14. #14
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    I very much doubt that any type theoretician will agree that type covariance is really founded in stochastic covariance. The two concepts have similarities - thus the same name - but there is simply no practical value in treating one as the derivate of the other.
    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

  15. #15
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Hi CornedBee,


    I take time to re-study your post in #8. I found I re-learned new stuff. Cool! Three more comments,

    1. Beyond the pattern of decend/ascend in return type/class hierarchy as we pointed out, is it the only pattern of covariance? Are there any else patterns in C++ which could be called covariance?

    2. Interested in Contravariance sample, does it have practical usage scenario?

    3. about your comments,

    "As the primary varying item descends a class hierarchy, the secondary does, too"

    primary varying item is the class hierarchy base/derived class, and the secondary (varying item) is the return type (in derived class, using derived class type pointer, but in base class, using base class type pointer?)?

    Quote Originally Posted by CornedBee View Post
    I very much doubt that any type theoretician will agree that type covariance is really founded in stochastic covariance. The two concepts have similarities - thus the same name - but there is simply no practical value in treating one as the derivate of the other.

    Hi grumpy,

    Could you let me know how you get nagetive value in the case of contracovariance please? How do you assign value X and Y?

    Quote Originally Posted by grumpy View Post
    Contracovariance simply means that the covariance Cov(X,Y) has a negative value.

    regards,
    George

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Polynomials and ADT's
    By Emeighty in forum C++ Programming
    Replies: 20
    Last Post: 08-19-2008, 09:32 AM
  2. Undefined Reference Compiling Error
    By AlakaAlaki in forum C++ Programming
    Replies: 1
    Last Post: 06-27-2008, 12:45 PM
  3. Drawing Program
    By Max_Payne in forum C++ Programming
    Replies: 21
    Last Post: 12-21-2007, 05:34 PM
  4. Certain functions
    By Lurker in forum C++ Programming
    Replies: 3
    Last Post: 12-26-2003, 01:26 AM
  5. Half-life SDK, where are the constants?
    By bennyandthejets in forum Game Programming
    Replies: 29
    Last Post: 08-25-2003, 12:58 PM

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