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

[Saxo]

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

 

[Victor Bazarov]

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

 

[Saxo]

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.

 

[Saxo]

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]

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 ;-).