Can this be done with a conversion operator in C++ ?

Discussion in 'C++' started by Saxo, Dec 14, 2012.

  1. Saxo

    Saxo Guest

    Hello,

    I'm admittedly not very proficient in C++. This is why I post my question here for the expert can give me an accurate answer :).

    I have this piece of Scala code:

    class A {
    def foo() {
    println("foo")
    }
    }

    class B {
    def bar() {
    println("bar")
    }
    }

    object Test
    {
    implicit def aToBWrapper(a: A) = {
    println("before")
    a.foo
    println("after")
    new B()
    }

    def main(args: Array[String])
    {
    val a = new A
    a.bar
    }
    }

    I guess it is not that hard to see what it does. When executed it prints:

    before
    foo
    after
    bar

    My question is whether this could be done with in C++ as well using a conversion operator. The point is that no change is made to class A.

    I could figure out myself. It would just take ages as I'm not familiar with C++.

    Reagrds, Oliver
     
    Saxo, Dec 14, 2012
    #1
    1. Advertising

  2. On 12/14/2012 11:20 AM, Saxo wrote:
    > I'm admittedly not very proficient in C++. This is why I post my question here for the expert can give me an accurate answer :).
    >
    > I have this piece of Scala code:
    >
    > class A {
    > def foo() {
    > println("foo")
    > }
    > }
    >
    > class B {
    > def bar() {
    > println("bar")
    > }
    > }
    >
    > object Test
    > {
    > implicit def aToBWrapper(a: A) = {
    > println("before")
    > a.foo
    > println("after")
    > new B()
    > }
    >
    > def main(args: Array[String])
    > {
    > val a = new A
    > a.bar
    > }
    > }
    >
    > I guess it is not that hard to see what it does. When executed it prints:
    >
    > before
    > foo
    > after
    > bar
    >
    > My question is whether this could be done with in C++ as well using a conversion operator. The point is that no change is made to class A.
    >
    > I could figure out myself. It would just take ages as I'm not familiar with C++.


    Generally speaking the objects that are born to be of type T1 live out
    their lives as objects of type T1 and die as objects of type T1 in C++,
    which is what it means for the language to be "strongly typed". It is
    possible to reuse the memory allocated for one object to create another
    object, generally of any other type that fits, and it's done sometimes,
    but in all honesty, I've not seen it done often, barely ever.

    In your program I couldn't understand where and by whom the function
    'aToBWrapper' is called. I don't know Scala, could it be that it's done
    somehow implicitly? Also, in your 'main' function there is no
    indication that it is 'B' that you somehow want. What if there is
    another class with its own method 'bar' defined and for which there is a
    conversion from an A object, would it represent an ambiguity?

    Anyway, back to "conversion". It is possible to do make an object of
    one unrelated class to behave as if it were an object of another class,
    but it's A BAD IDEA(tm) in C++. Again, the paradigm is that C++ is a
    "strongly typed language". Objects don't mutate.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Dec 14, 2012
    #2
    1. Advertising

  3. Saxo

    Saxo Guest

    >C++ is a strongly typed language,

    Scala is statically typed as well. It even tries to get the utmost out of static typing. See the explanation below.

    >You want to instantiate an object of type A, but get an object of
    >unrelated type B instead? How does that even make any sense?


    I should have explained what is happening in the Scala code: The compiler sees that class A has no method named bar(). Before it flags an error it looks for any conversion from class A to anything else and finds this here:

    implicit def aToBWrapper(a: A) = {
    println("before")
    a.foo
    println("after")
    new B()
    }

    So it carries out the conversion and checks after that whether the compilererror is gone. As this is the case, things are fine and the Scala compilercontinues. In case the implicit conversion (hence the keyword implicit in Scala) does not fix the problem, the Scala compiler stops and raises an error. If it tried another conversion the compilation run could really continue for a long time and even run wild.

    @Paavo: Thanks for the C++ code snippet. Clever approach.

    I was just asking here, because I saw something about a C++ conversation operator and thought it might be able to do the same thing as Scala implicits.. From what I found meanwhile on the Internet it seems that conversion it C++ can only be to an built-in type.







    > This is not directly possible with C++ as in C++ the static type of a
    >
    > variable (like a) is fixed at compile time, and this type must have a
    >
    > method called bar, again at compile-time. At run-time the types and
    >
    > actually called methods can be different, but only in a controlled way
    >
    > (inherited classes and overridden virtual functions only).
    >
    >
    >
    > Nevertheless, also in C++ one type of object can be converted implicitly
    >
    > into another type. Here is a way to get the same printout as in your
    >
    > example:
    >
    >
    >
    > #include <iostream>
    >
    >
    >
    > class A {
    >
    > public:
    >
    > void foo() {
    >
    > std::cout << "foo\n";
    >
    > }
    >
    > };
    >
    >
    >
    > class B {
    >
    > public:
    >
    > B(A a) {
    >
    > std::cout << "before\n";
    >
    > a.foo();
    >
    > std::cout << "after\n";
    >
    > }
    >
    > void bar() {
    >
    > std::cout << "bar\n";
    >
    > }
    >
    > };
    >
    >
    >
    >
    >
    > void bar(B b) {
    >
    > b.bar();
    >
    > }
    >
    >
    >
    > int main() {
    >
    > A a;
    >
    > bar(a);
    >
    > }
     
    Saxo, Dec 15, 2012
    #3
  4. Saxo

    Saxo Guest


    > class A {
    >
    > operator B() const {return B(...);}
    >
    > };
    >
    >
    > However, this needs to be placed in the converted-from class, which
    > contradicts your earlier requirement that class A should not be modified.


    I see that you were getting the point I tried to make in my post.

    > I guess it is possibly quite hard to maintain a
    > large Scala codebase over time, is this so?


    The piece of Scala code I pasted in this thread was the second Scala program I wrote the first one being the mandatory "hello world" program. I just wrote the sample code in this topic to verify that I got the point with implicits in Scala. So I can't even make a qualified guess to answer your question. Well, what I can say is that the Scala books recommend to handle implicits with care. So the problems seems to be understood. One of the biggest Scala apps seems to be Akka (akka.io). But these guys will for sure tell you nothing else except for that Scala is fantastic ;-).

    > The implicit conversion operators in Scala seem to be much more automatic
    > and actually quite scary.


    I'm currently looking at Kotlin (http://kotlin.jetbrains.org/) where implicits are explicitly not part of the language and at Scala as some replacement for Java which just cannot keep pace with other modern programming lanugages out there.

    Currently, I'm trying to make up my head whether implicits are an argument for or against Scala. It is easy to jump to conclusions, but it is not easyto make a well-based decision. I did a lot of development in Smalltalk. InSmalltlak you can do something like this:

    2 become: 3

    This will make every number with the value 2 in your system change to 3. Inevitably, your system will shut down after evaluating this line of code. Nevertheless, Smalltalk IMHO is a very sound language. But I agree that thosethings are scary and should be handled with great care.

    Regards, Oliver
     
    Saxo, Dec 16, 2012
    #4
  5. Saxo

    Saxo Guest


    >
    > OTOH I am not quite sure if the
    >
    > possibility of redefining 2 to 3 is a good idea (maybe it is if prohibiting
    >
    > this would only make the language rules more complex).


    Well the example is maybe not so well chosen. The real purpose is to be able to say something like "aB becomes: aC". With class B and C being user-defined classes. I only had to do a become: a single time within 10 years and my collegue and me were looking for a long time for ways to avoid it ;-).
     
    Saxo, Dec 16, 2012
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Arvid Requate
    Replies:
    2
    Views:
    1,020
    Alf P. Steinbach
    Jun 23, 2006
  2. hurcan solter
    Replies:
    3
    Views:
    754
    Cholo Lennon
    Aug 29, 2007
  3. , India
    Replies:
    2
    Views:
    506
    Fraser Ross
    Sep 15, 2009
  4. cronusf
    Replies:
    12
    Views:
    509
  5. Zhidian Du
    Replies:
    0
    Views:
    178
    Zhidian Du
    Feb 21, 2004
Loading...

Share This Page