Varargs overloading - overloading

I was just trying out few things using Varargs:
Just encountered with one problem:
class A {
public void func(int... a) {
System.out.println("int... a");
}
public void func(double... b) {
System.out.println("double... b");
}
}
public class B {
public static void main(String... args) {
A a = new A();
a.func(); //Getting no compilation error;instead func(int... a) is
//being called
}
}
where as if Class A is modified as :
class A {
public void func(int... a) {
System.out.println("int... a");
}
public void func(boolean... b) {
System.out.println("boolean... b");
}
}
Now i get the compile time error.
Just wanted to know why was this not happening earlier when used with int and double. But now this is happening with only int and boolean. I understand ambiguity but this should happen in the first case also.
I am using java 7.
Its happening only in boolean's case.
Would you please mind helping me providing the solution?
Thanks.

Related

Eliminating C++ diamond inheritance by passing a pointer to "this" to base constructor

I understand how C++ solves the diamond problem in multiple inheritance by using virtual inheritance. Suppose the following situation:
class A {
int num;
public:
int get_num() const { return num; }
};
class B : public A {
void foob() { int x = get_num(); }
};
class C : public A {
void fooc() { int x = get_num(); }
};
class D : public B, public C {
void food() { int x = get_num(); }
};
The get_num() call is ambiguous inside food(). I know I can fix it either by calling A::get_num() or by virtual inheritance using virtual public A. But I can see a third approach:
class A {
int num;
public:
int get_num() const { return num; }
};
class B : public A {
void foob() { int x = get_num(); }
};
class C { // won't inherit from A anymore
const A& base; // instead keeps a reference to A
void fooc() { int x = base.get_num(); }
public:
explicit C(const A* b) : base(*b) { } // receive reference to A
};
class D : public B, public C {
void food() { int x = get_num(); }
public:
D() : C(this) { } // pass "this" pointer
};
The external code doesn't need to consider C as an A.
Considering it has no impacts on my particular class hierarchy design, are there any advantages of the third approach over the virtual inheritance way? Or, in terms of cost, it ends up being the same thing?
Congratulations ! You've just re-invented the principle of composition over inheritance !
If this works with your design, it means that C was in fact not a kind of A, and there was no real justification to use inheritance in first place.
But don't forget the rule of 5 ! While your approach should work in principle, you have a nasty bug here : with your current code, if you copy a D object, its clone uses the wrong reference to the base (it doesn't refer to it's own base, which can lead to very nasty bugs...
Demo of the hidden problem
Let's make A::get_num() a little bit more wordy, so that it tells us about the address of the object that invokes it:
int get_num() const {
cout << "get_num for " << (void*)this <<endl;
return num;
}
Let's add a member function to C, for the purpose of the demo:
void show_oops() { fooc(); }
And same for D:
void show() { food(); }
Now we can experiment the problem by running this small snippet:
int main() {
D d;
cout<<"d is "<<(void*)&d<<endl;
d.show();
d.show_oops();
D d2=d;
cout<<"d2 is "<<(void*)&d2<<endl;
d2.show();
d2.show_oops();
}
Here an online demo. You will notice that d2 does produce inconsistent results, like here:
d is 0x7fffe0fd11a0
get_num for 0x7fffe0fd11a0
get_num for 0x7fffe0fd11a0
d2 is 0x7fffe0fd11b0
get_num for 0x7fffe0fd11b0
get_num for 0x7fffe0fd11a0 <<< OUCH !! refers to the A element in d !!
Not only do you refer to the wrong object, but if the d object would decease, you would have a dangling reference, so UB.

How to mock this class

class A
{
public:
void doFirstJob()
{
// Do first Job.
}
}
class B : public A
{
public:
virtual void doSecondJob()
{
// Do Second Job.
}
}
class C
{
public:
void doSomething() {
b->doFirstJob();
b->doSecondJob();
}
private:
B* b;
}
Now I should write unit test code for class C, then I'll write a mock for class B, but the problem is how to mock the method doFirstJob().
Bluntly, I want know how to mock the non-virtual method of the parent class???
Can any one help me ??
Typemock Isolator++ supports mocking non virtual methods of a parent class (same as faking a method of the class under test).
See following example:
class A
{
public:
int doFirstJob()
{
return 0;
}
};
class B : public A
{
};
class C
{
public:
int doSomething()
{
return b->doFirstJob();
}
void setB(B* to)
{
b = to;
}
private:
B* b;
};
In the test You create a fake of B -> change the behavior of doFirstJob to return 3 -> continue with your test as you would normally write it.
TEST_CLASS(NonVirtualMethod)
{
public:
TEST_METHOD(NonVirtualMethodTestOfBaseClass)
{
B* fakeB = FAKE<B>();
WHEN_CALLED(fakeB->doFirstJob()).Return(3);
C c;
c.setB(fakeB);
int first = c.doSomething();
Assert::AreEqual(3,first);
}
}
You can find more examples here.

C++ "Virtual arguments"

Consider the following code:
class A {
public:
virtual ~A() {}
};
class AA : public A {
};
////////////////////////////////////////
class B {
public:
virtual void f(const A &a) {
// code for A
}
};
class BB : public B {
public:
virtual void f(const AA &a) {
// code for AA
}
};
////////////////////////////////////////
int main() {
A *a = new AA;
B *b = new BB;
b->f(*a);
}
Obviously, the vtables are constructed such that when the above is run, // code for A is executed. I am looking for a way to be able to execute instead // code for AA.
The motivation is that this is for a library of code where the end-user will often have to write classes of the form BB, and I would like the process to be as easy as possible (i.e. the user should not have to use RTTI to figure out what derived class of A they are dealing with). Any ideas (and voodoo from any version of the C++ standard) are appreciated.
You can use RTTI and explicitly doing your own dispatching for that.
Co-Variant types only work for return types unfortunately.
Example:
class B {
void f_base(const A &a) {
// code for A
}
public:
virtual void f(const A &a) {
f_base(a); // Moved the base case outside
// to isolate the dispatching mechanism.
}
};
class BB : public B {
public:
virtual void f(const A& a) {
const AA* pAA = dynamic_cast<const AA*>(&a);
if(pAA) {
f(*pAA);
return;
}
f_base(a);
}
void f(const AA &a) {
// code for AA
}
};
More discussion of this type of dispatch as well of nicer packaging with templates is demonstrated here: "type-switch" construct in C++11
You need something that resembles the mechanism that is known as double dispatch, which in C++ can only be implemented indirectly:
class A {
public:
virtual callF(B & b) {
b.f(this);
}
virtual callF(BB & b) {
b.f(this);
}
};
class AA : public A {
public:
virtual callF(B & b) {
b.f(this);
}
virtual callF(BB & b) {
b.f(this);
}
};
This is horrible style but it seems you are under some tight constraints
#include <typeinfo>
// everything else unmodified
class BB : public B {
public:
virtual void f(const A& arg) override {
try { //try to convert to an AA&
const AA& a{dynamic_cast<const AA&>(arg)};
// code for AA
} catch (std::bad_cast) { // if it fails, pass it up to B::f as an A&
this->B::f(arg);
}
}
};
////////////////////////////////////////
int main() {
A *aa = new AA;
A *a = new A;
B *b = new BB;
b->f(*a); // code for A executed
b->f(*aa); // code for AA executed
}
as per Alan Stoke's comment, dynamic casting pointers is much faster when it fails, so you could alternatively use this if you expect failure regularly:
class BB : public B {
public:
virtual void f(const A& arg) override {
const AA* ap = dynamic_cast<const AA*>(&arg);
if (ap == nullptr) {
return this->B::f(arg);
}
const AA& a{*ap}; // get a reference, if you want to
// code for AA
}
};
The concept you are looking for is called double dispatch. Read more about it on http://en.wikipedia.org/wiki/Double_dispatch
It is not built into C++ but there are various ways to emulate it. One of them being the visitor pattern also found in the above link.
However you'll probably find all approaches lacking of elegance because you need to introduce AA to B, BB to A, or use RTTI and casts.

Constructor not called the expected number of times

Here is the code which causes a problem:
class Base
{
public:
virtual void fun()
{
cout<<"Base";
}
};
class Der:public Base
{
Base &pb;
public:
Der(Base&b):pb(b){}
virtual void fun()
{
cout<<"Der...";
pb.fun();
}
};
int main()
{
Der(Der(Base())).fun();
return 0;
}
Run this code,and the result shows "Der...Base..."! This is so amazing, I can't figure it out why the result is not "Der...Der...Base" which is logically right?!
Then I replace the member in class Der Base&pb with Base*pb and change the code into legal, finnaly the output is right which is "Der...Der...Base"!
I debug the code and find that when I use Base&pb, the constructor of Der only ran once while use Base*pb, the constructor ran twice correctly!
Any one who can explain to me what had happened and why?
In Der(Der(Base())).fun() expression the inner Der(Base()) yields an rvalue - the compiler optimizes the code by using copy elision and removes unnecessary copying of objects.
In addition to the #icepack's answer and the following discussion in the comments (summary: the code Der(der) is a cast, which may or may not be realized using constructor; in your case it's not), a workaround for you: you should make your intention clear by not using the constructor.
I would rewrite your code into something like this:
class Base
{
public:
virtual void fun()
{
cout<<"Base";
}
};
class Der:public Base
{
Base &pb;
Der(Base& b) : pb(b) {}
public:
static Der Decorate(Base&& b){ return Der(b); }
virtual void fun()
{
cout<<"Der...";
pb.fun();
}
};
int main()
{
Der::Decorate(Der::Decorate(Base())).fun();
return 0;
}
(outputs: Der...Der...Base).
Changing the code to accept the pointer is easy:
class Base
{
public:
virtual void fun()
{
cout << "Base";
}
};
class Der : public Base
{
Base* pb;
Der(Base* b) : pb(b) {}
public:
static Der Decorate(Base* b){ return Der(b); }
virtual void fun()
{
cout << "Der...";
pb->fun();
}
};
int main()
{
Der::Decorate(&Der::Decorate(&Base())).fun();
return 0;
}

Is there no way to upcast into an abstract class and not modify it each time a class is derived from it?

#include<iostream>
using namespace std;
class Abs
{
public:
virtual void hi()=0;
};
class B:public Abs
{
public:
void hi() {cout<<"B Hi"<<endl;}
void bye() {cout<<"B Bye"<<endl;}
};
class C:public Abs
{
public:
void hi() {cout<<"C Hi"<<endl;}
void sayonara() {cout<<"C Sayonara"<<endl;}
};
int main()
{
Abs *bb=new B;
bb->bye();
Abs *cc=new C;
cc->sayonara();
}//main
The compiler says
test2.cpp: In function ‘int main()’:
test2.cpp:26: error: ‘class Abs’ has no member named ‘bye’
test2.cpp:28: error: ‘class Abs’ has no member named ‘sayonara’
Because of this problem, I'll have to add functions to the Abs class each time I create a new derived class which inherits from it (Upcasting is compulsory for me to do. The program I'm planning requires it to be so). I don't want to touch the base class once it's created.
Doesn't this problem violate the principle that once you make a base class, you won't have to modify it ever. Any way to resolve this problem?
p.s: I've seen the factory design pattern and the prototype design patterns, but both of them can't seem to be able to solve it.
This is defeating the purpose of inheritance and abstract interfaces. bye and sayonara both do the same thing (saying goodbye), only in different languages. This means you should have an abstract say_goodbye method that gets overridden for subclasses. I suppose this is a simplified example, so maybe you could describe your actual scenario so we can provide more specific help.
Edit If you want to create a copy of the derived class through an abstract interface, check out this question. If you want to explicitly access the different attributes of your subclasses, you should be asking your self if subclassing es even appropriate here, since your classes don't seem to have much in common.
Well, i'm not sure to understand exactly what you want (and why you want it that way) but:
int main()
{
Abs *bb=new B;
static_cast<B*>(bb)->bye();
Abs *cc=new C;
static_cast<C*>(cc)->sayonara();
}//main
Will work.
You just have to be sure that bb is really a B* before you static_cast.
You may also use dynamic_cast which will return a null pointer if bb is not of the correct type.
int main()
{
B *bb = new B;
bb->bye();
C *cc=new C;
cc->sayonara();
}//main
This way modifications in the base class are no longer needed :)
Dynamic casting is a sensible option. If you're religious about dynamic casts, you can use the visitor design pattern:
struct Abs;
struct B;
struct C;
struct Visitor
{
virtual ~Visitor() {}
// Provide sensible default actions
virtual void visit(Abs&) const { throw "not implemented"; }
virtual void visit(B& b) const { visit(static_cast<Abs&>(b)); }
virtual void visit(C& c) const { visit(static_cast<Abs&>(c)); }
};
struct Abs
{
virtual ~Abs() {}
virtual void hi() = 0;
virtual void accept(Visitor const& v) { v.visit(*this); }
};
struct B : Abs
{
void hi() { ... }
void accept(Visitor const& v) { v.visit(*this); }
void bye() { ... }
};
struct C : Abs
{
void hi() { ... }
void accept(Visitor const& v) { v.visit(*this); }
void sayonara() { ... }
};
struct DoSayonara : Visitor
{
void visit(C& c) const { c.sayonara(); }
};
struct DoBye : Visitor
{
void visit(B& b) const { b.bye(); }
};
struct ByeOrSayonara : Visitor
{
void visit(B& b) const { b.bye(); }
void visit(C& c) const { c.sayonara(); }
};
and then you use
Abs* b = new B(); Abs* c = new C();
b->accept(DoSayonara()); // Throw an exception
c->accept(DoSayonara()); // Do what is expected
Do this only when you really need it.
If upcasting is compulsory and you need to call methods defined in the subclasses then You're Doing It Wrong.
However, at a given point in time, you either know that an object is a specific subclass, in which case you can dynamically cast to that type, or you don't and can't be sure you can call the function.
Assuming this is related to your other question, I've tried to explain a way to implement that particular problem in a different manner there.