In my opinion following program should be crashed but its not only working but showing the right result("derv is called").
#include <iostream>
using namespace std;
class base
{
public:
virtual ~base(){}
};
class derv: public base
{
public:
void f() { cout << "derv is called" <<endl;}
};
int main() {
base* p = new base();
derv *d1 = dynamic_cast<derv*>(p);
// Since p point to base , so d1 should return nullptr
//calling any function using d1, should fail/crash
//but why the following line is working ??
d1->f();
}
Sorry I forgot to add few lines in my previous post: If I add a single data member and try to access it, gives me segmentation fault, which I think is the correct behavior. My Question is that why accessing data member changes the behavior ? When variable is not get accessed , calling "f()" function is successful while the same function "f()" gives segmentation fault when accessing with the data member? Is it the undefined behavior?
class derv: public base
{
public:
int x = 0 ; // Added new member, c++11
void f() { cout << "derv is called " << x << endl;} //access it here
};
It is undefined behavior in your program you dereferencing d1 which is a NULL pointer:
base* p = new base();
derv *d1 = nullptr;
d1 = dynamic_cast<derv*>(p);
if(nullptr == d1) // condition succeeds which means d1 is nullptr
cout << "nullptr" << endl;
A safe programming is the task of the programmer not the compiler's so a good program checks before uses:
// avoiding error prones and UBs
if(nullptr != d1)
d1->f();
f is not a virtual function. The program does not have to look for the virtual function table when trying to call f, so the method is called anyway.
If you try to check the pointer value of this inside of f, it will be nullptr.
Related
In the following example:
class A {
public:
virtual void f() { cout << "a" << endl; }
virtual void h() { cout << "A" << endl; }
};
class s1 : public A {
public:
virtual void f() { cout << "s1" << endl; }
};
class s2 : public A {
public:
virtual void h() { cout << "s2" << endl; }
};
class GS : public s1, public s2 {
public:
};
int main()
{
s1 *q = new GS;
q->h();//no problem
GS a;
a.h();//error
}
Why does a.h(); give an ambiguity error yet q->h(); doesn't?
Doesn't *q have an instance of GS which should cause the same ambiguity problem?
Your use of multiple inheritance causes two instances of A to appear in GS. When you use S1 *q to access the GS instance, it follows the A instance associated with S1. Since S1 does not implement h(), the output of q->h() will be the implementation provided by A itself.
If you want q->h() to use the implementation provided by S2, then you need to create a diamond using virtual inheritance. Doing so will also remove the ambiguity when using a.h(), since virtual inheritance will cause only one instance of A to appear in GS.
class s1 : virtual public A {
public:
virtual void f() { cout << "s1" << endl; }
};
class s2 : virtual public A {
public:
virtual void h() { cout << "s2" << endl; }
};
Name lookup is based on static type not dynamic type. (And it has to be, since it occurs at compile time not run time.)
Because your pointer is of type s1 so the compiler knows to call h() (inherited from class A). Try using a pointer of type GS and you'll get an error for the pointer too. In the case of GS you are inheriting from s1 and s2, both classes inherit from A and thus, multiple(2) definitions of h() are found which is ambigious. This is the dreaded diamond.
Ok, this is because when the compiler evaluates q->h(), q only has one function named 'h' in its scope since it is of type s1.
When the compiler evaluates a.h(), a has two functions named 'h' in its scope. The one from s1 and the one from s2.
The compiler doesn't know which one you wanted to use, so it throws an error.
*q doesn't give an ambiguity error because its type is s1*. This means that the compiler will call s1::h, which is unambiguous.
Here is my code:
#include<iostream>
using namespace std;
class Shape
{
char obj;
public:
int j;
Shape();
void displayModel();
};
class Line : public Shape
{
char obj;
public:
Line();
void displayModel();
};
Shape::Shape()
{
obj = 'S';
j = 1;
}
void ::Shape::displayModel()
{
cout << obj;
cout << " Shape j:" << j << endl;
}
Line::Line()
{
obj = 'L';
j = 5;
}
void Line::displayModel()
{
cout << obj;
cout << " Line j:" << j << endl;
}
int main()
{
Shape *objPtr = NULL, s;
Line l;
objPtr = &l;
s.displayModel();
l.displayModel();
objPtr->displayModel();
return 0;
}
My doubt is when objPtr->displayModel() is executed why does j=5 and not j=1? I know that objPtr is assigned to the address of object l. But I have not declared virtual keyword in Shape::displayModel(), so doesn't that mean that the compiler should check at the type of the object rather than what it points to? Or does that happen only for function calls when virtual keyword is declared and does not include variables?
So basically my doubt is why is objPtr->displayModel() printing j=5 instead of j=1?
Why should j be different? There's only one j, which is declared in Shape. When you're deriving from Shape, you're not adding more js, there would need to be some j declared in Line, too. On the other hand, you have separate obj for Shape and for Line, so that's why your program prints
S Shape j:1
L Line j:5
S Shape j:5
Note: If you make void Shape::displayModel() virtual, the call objPtr->displayModel(); will propagate to void Line::displayModel() instead, and you'll get two Ls:
S Shape j:1
L Line j:5
L Line j:5
LogicStuff is right.
Add markers, like cout << 'In Shape::displayModel() function' and cout << 'In Line::displayModel() function'
It should help you understand what append.
I haven't tried the code but at first glance I can tell you two things:
The first is that to use polymorphism in c++ you need to use the "virtual" keyword. Classes with virtual functions or virtual methods are termed polymorphic.
class Shape{
private:
char obj;
public:
int j;
Shape();
virtual void displayModel();
};
Second is that you should declare your object with the base static type and then use the derived dynamic type to instantiate it.
Shape *objPtr = new Line();
By using virtual functions the program "remembers" the dynamic type and can thus invoke specific methods even after the objects are upcasted to a more general type.
Keep in mind that the way the compiler does this is giving the classes a virtual table to the classes that have virtual functions and thus consume more memory.
Hope this helps
I decided to study/translate Head First Design Patterns' Java code to C++11, and I was able to implement most of the patterns using automatic memory management thanks to smart pointers. However, I have a problem with one of the examples. Here is my code:
#include <iostream>
#include <memory>
class AbstractBase {
public:
virtual void foo() = 0;
virtual ~AbstractBase() = default;
};
class A : public AbstractBase {
public:
void foo() override { std::cout << "Class A: foo() called" << std::endl; }
};
class B : public AbstractBase {
public:
void foo() override { std::cout << "Class B: foo() called" << std::endl; }
};
class FooDecorator : public AbstractBase {
public:
FooDecorator(AbstractBase *pBase): mpBase(pBase) { }
void foo() override
{
mpBase->foo();
++mNumberOfFooCalls;
}
static int getFooCalls() { return mNumberOfFooCalls; }
private:
static int mNumberOfFooCalls;
AbstractBase *mpBase;
};
class AbstractFactory {
public:
virtual std::unique_ptr<AbstractBase> createA() = 0;
virtual std::unique_ptr<AbstractBase> createB() = 0;
virtual ~AbstractFactory() = default;
};
class CountingFactory : public AbstractFactory {
public:
std::unique_ptr<AbstractBase> createA()
{
// auto pA = new A();
// return std::unique_ptr<AbstractBase>(new FooDecorator(pA));
std::unique_ptr<AbstractBase> pA(new A());
return std::unique_ptr<AbstractBase>(new FooDecorator(pA.get()));
}
std::unique_ptr<AbstractBase> createB()
{
// auto pB = new B();
// return std::unique_ptr<AbstractBase>(new FooDecorator(pB));
std::unique_ptr<AbstractBase> pB(new B());
return std::unique_ptr<AbstractBase>(new FooDecorator(pB.get()));
}
};
int FooDecorator::mNumberOfFooCalls = 0;
int main()
{
std::unique_ptr<AbstractFactory> pFactory(new CountingFactory());
std::unique_ptr<AbstractBase> pObjA = pFactory->createA();
std::unique_ptr<AbstractBase> pObjB = pFactory->createB();
pObjA->foo();
pObjB->foo();
std::cout << "Foo called " << FooDecorator::getFooCalls()
<< " times." << std::endl;
}
What this code does essentially is; there are two derived classes A and B; and they each have a single member function that shows which one has been called. There is also a decorator called FooDecorator that adds capability to count calls made to foo().
In addition to these, there is also CountingFactory which is used to get decorated objects directly.
In the main part, using this factory, I create an instance of A and an instance of B. Then call foo() from each.
When I compile this code using clang 3.5 and run it, I do not get any errors, but the result is a bit different than expected as it calls B::foo() twice:
Class B: foo() called
Class B: foo() called
Foo called 2 times.
On the other hand, when I compile the code using gcc 4.9.2 and run it, I get the following error:
pure virtual method called
terminate called without an active exception
It looks like the problem is the unique_ptrs inside the CountingFactory. My understanding is the pointer that's used to initialize the decorated object gets freed and it leads to either undefined behavior (clang case) or termination (gcc case).
As a result, I decided to use raw pointers and added the (commented-out above) lines:
auto pA = new A();
return std::unique_ptr<AbstractBase>(new FooDecorator(pA));
auto pB = new B();
return std::unique_ptr<AbstractBase>(new FooDecorator(pB));
Doing this, things worked successfully, I got the expected output from both compilers. However, now there is a memory leak, and the allocations must be deleted.
Having almost always found a solution with smart pointers to problems like these, I am struggling to come up with the best approach to this issue. I also tried replacing unique_ptrs with shared_ptrs, but to no avail, it did not work.
Can I still get away with smart pointers following a different approach? Or do I have to manually manage the memory I allocated inside the factory (not preferred)?
As I understand, you need FooDecorator to take ownership of pBase. You can achieve this by changing
AbstractBase *mpBase;
to
std::unique_ptr<AbstractBase> mpBase;
So you create FooDecorator in CountingFactory like this:
return std::unique_ptr<AbstractBase>(new FooDecorator(new A()));
Or in C++14:
return std::make_unique<FooDecorator>(new A());
The reason for the crash is that you just assign the inner pointer via get method.
std::unique_ptr<AbstractBase> pB(new B());
return std::unique_ptr<AbstractBase>(new FooDecorator(pB.get()));
Which means that when scope ends, the memory of your inner B (or A) is gets deleted.
What you can do is call release instead.
But yeah to avoid the leak you should have a unique_ptr in your FooDecorator as well.
Live on IdeOne
i was just reading this question here
https://stackoverflow.com/a/332086/2689696
and it tells that dynamic cast
You can use it for more than just casting downwards -- you can cast sideways or even up another chain. The dynamic_cast will seek out the desired object and return it if possible.
so what does this really mean and what are the limitations/ conditions under which this can happen.
and i assume this is what the statement means. And the cast happens and i get a segmentation fault too which is obvious.
#include <iostream>
class base
{
public:
virtual void print () = 0;
};
class childa : public base
{
public:
char c1;
virtual void print ()
{
std::cout << "childa\n";
}
void printout()
{
std::cout << "childa out\n";
}
};
class childb : public base
{
public:
int c2;
virtual void print ()
{
std::cout << "childb\n";
}
void printin()
{
std::cout << "childb in\n";
}
void printout()
{
std::cout << "childb out\n";
}
};
int main()
{
base* b = new childa;
b ->print();
dynamic_cast<childa*>(b)->printout();
dynamic_cast<childb*>(b)->printout(); // cast happens here and the output is printed
dynamic_cast<childa*>(b)->c1 = 'a';
dynamic_cast<childb*>(b)->c2 = 2; // segfault here
}
This is the output i get and a segfault occurs
childa
childa out
childb out
Process returned -1073741819 (0xC0000005) execution time : 5.844 s
Press any key to continue.
EDIT:
Yes it was foolish of me not to check for null value.
but i wanted to know more about the comment from the other question(Up/Down/Sideways)
You're hitting Undefined Behaviour here:
dynamic_cast<childb*>(b)->printout();
The cast actually fails (returns a null pointer). You never check the return value and call a member function through it. That's Undefined Behaviour and anything can happen. In your case, it seems that because the function does not access this in any way, it executes just fine even though invoked through a null pointer. But that's not guaranteed.
As for what a sideways cast (or cast up another chain) is, that needs a more complex inheritance hierarchy to demonstrate:
struct base1
{
virtual ~base1() {}
};
struct base2
{
virtual ~base2() {}
};
struct child1 : base1
{};
struct child2 : base2
{};
struct both : child1, child2
{};
int main()
{
child1 *c1 = new both();
static_cast<base1*>(c1); // ok
static_cast<both*>(c1); // ok
static_cast<child2*>(c1); // compile-time error, unrelated types
dynamic_cast<child2*>(c1); // succeeds, because the object is actually of type `both`, i.e. derived from `child2`; cast sideways
static_cast<base2*>(c1); // compile-time error, unrelated types
dynamic_cast<base2*>(c1); // succeeds, because the object is actually of type `both`, i.e. derived from `base2`; cast up another chain
base1 *b1 = new child1();
static_cast<child1*>(b1); // ok
static_cast<both*>(b1); // compiles, but produces UB, as the object is not of correct type
static_cast<base2*>(b1); // compile-time error, unrelated types
dynamic_cast<base2*>(b1); // fails (returns null pointer), because the object is not actually derived from `base2`.
}
dynamic_cast<T*>(a) returns a not null T* if and only if *a is instance of T; otherwise, it returns NULL.
Invoking a method or attribute from a null pointer produces an undefined behavior.
The usefulness of dynamic_cast is in his answer. With this code
int main()
{
base* b = new childa;
b ->print();
childa* testA = dynamic_cast<childa*>(b);
if (testA)
{
//Here you can be sure that your object is right
testA->printout();
testA->c1 = 'a';
}
else
std::cout << "Error casting b to testA" << std::endl;
childb* testB = dynamic_cast<childb*>(b);
if (testB)
{
//Here you can be sure that your object is right
testB->printout();
testB->c2 = 2;
}
else
std::cout << "Error casting b to testB" << std::endl;
}
you obtain the following output
childa
childa out
Error casting b to testB
I would like to know how to change the address of Test which is in the virtual table with that of HackedVTable.
void HackedVtable()
{
cout << "Hacked V-Table" << endl;
}
class Base
{
public:
virtual Test() { cout <<"base"; }
virtual Test1() { cout << "Test 1"; }
void *prt;
Base(){}
};
class Derived : public Base
{
public:
Test()
{
cout <<"derived";
}
};
int main()
{
Base b1;
b1.Test(); // how to change this so that `HackedVtable` should be called instead of `Test`?
return 0;
}
This works for 32-bit MSVC builds (it's a very simplified version of some production code that's been in use for well over a year). Note that your replacement method must explicitly specify the this parameter (pointer).
// you can get the VTable location either by dereferencing the
// first pointer in the object or by analyzing the compiled binary.
unsigned long VTableLocation = 0U;
// then you have to figure out which slot the function is in. this is easy
// since they're in the same order as they are declared in the class definition.
// just make sure to update the index if 1) the function declarations are
// re-ordered and/or 2) virtual methods are added/removed from any base type.
unsigned VTableOffset = 0U;
typedef void (__thiscall Base::*FunctionType)(const Base*);
FunctionType* vtable = reinterpret_cast<FunctionType*>(VTableLocation);
bool hooked = false;
HANDLE process = ::GetCurrentProcess();
DWORD protection = PAGE_READWRITE;
DWORD oldProtection;
if ( ::VirtualProtectEx( process, &vtable[VTableOffset], sizeof(int), protection, &oldProtection ) )
{
vtable[VTableOffset] = static_cast<FunctionType>(&ReplacementMethod);
if ( ::VirtualProtectEx( process, &vtable[VTableOffset], sizeof(int), oldProtection, &oldProtection ) )
hooked = true;
}
The V-Table is an implementation detail.
The compiler is not required to use one (it just happens to be the easiest way to implement virtual functions). But saying that each compiler can (and does) implement it slightly differently as a result there is no answer to your question.
If you ask how do I hack a vtable for a program built with:
Compiler <X> Version <Y> Build <Z>
Then somebody may know the answer.
void HackedVtable()
{
cout << "Hacked V-Table" << endl;
}
class Base
{
public:
virtual Test() { cout <<"base"; }
virtual Test1() { cout << "Test 1"; }
void *prt;
Base(){}
};
class Derived:public Base
{
public:
Test()
{
cout <<"derived";
}
};
typedef void (*FUNPTR)();
typedef struct
{
FUNPTR funptr;
} VTable;
int main()
{
Base b1;
Base *b1ptr = &b;
VTable vtable;
vtable.funptr = HackedVtable;
VTable *vptr = &vtable;
memcpy ( &b1, &vptr, sizeof(long) );
b1ptr->Test();
//b1.Test(); // how to change this so that HackedVtable() should be called instead of Test()
return 0;
}
Under Mac OS X 10.10.3 + gcc 4.8.3, following code works well.
void HackedVtable()
{
cout << "Hacked V-Table" << endl;
}
class Base
{
public:
virtual void Test() { cout << "base" << endl; }
virtual void Test1() { cout << "Test 1" << endl; }
void *prt;
Base(){}
};
class Derived : public Base
{
public:
void Test()
{
cout << "derived" << endl;
}
};
int main()
{
Base b1;
Base* pb1 = &b1;
*(*(void***)pb1) = (void*) HackedVtable;
pb1->Test();
//It works for all the Base instance
Base b2;
Base* pb2 = &b2;
pb2->Test();
//But Derived's virtual function table is separated from Base's
Derived d1;
Derived* pd1 = &d1;
pd1->Test();
*(*(void***)pd1) = (void*) HackedVtable;
pd1->Test();
return 0;
}
Its output:
$ g++ h.cpp; ./a.out
Hacked V-Table
Hacked V-Table
derived
Hacked V-Table
I test the same code under Ubuntu 12.04 + g++ 4.9.0. However, it does not work and arises segmentation fault.
It seems Linux assigns the virtual function table in a read only area (e.g. rodata) to forbid hacking.
I don't think there is a portable way. Mostly because of compiler optimization and different architecture ABI between every target.
But C++ provides you with that exact same capability, why not use it?
void HackedVtable()
{
cout << "Hacked V-Table" << endl;
}
class Base
{
public:
virtual Test() { cout <<"base"; }
virtual Test1() { cout << "Test 1"; }
void *prt;
Base(){}
};
class Derived : public Base
{
public:
Test()
{
HackedVtable(); // <-- NOTE
}
};
int main()
{
Derived b1; // <-- NOTE
b1.Test();
return 0;
}
Another way to achieve the same thing is by cheking similar code:
GObject:
http://en.wikipedia.org/wiki/Gobject
GLib:
http://en.wikipedia.org/wiki/GLib
Vala:
http://en.wikipedia.org/wiki/Vala_%28programming_language%29
Those guys wanted to work with a object and class oriented programming language, but "C++", didn't fit their requisites. Then , they took "plain C", and simulate objects withn records & pointers, including Virtual Method Tables. Eventually got a similar language called "Vala", their own "C++" alike language (with their own V.M.T.).
Another related links:
http://en.wikipedia.org/wiki/Virtual_method_table
http://www.artima.com/insidejvm/ed2/jvmP.html
Cheers.
well its quite easy to figure out. Find hte VTAble pointer (In visual studio its the first 4/8 bytes). Then step into a normal call of Test (into the assembler) and you'll see it jump to the Vtable and then to your test function. To override test just replace the pointer where you jumped from in the VTable.
This is usually called "virtual table hooking" or something like that.
If you are going to use it much, then I suggest the SourceHook library. It was developed for hacking closed source game engines in game mods. For instance, it was used in The Dark Mod before idTech4 became open source.
I don't think the vTable is in read only area because is it dynamically populated. The only way it can fail is when the compiler is absolutely sure which implementation will be called in compile time and skip the vTable lookup with direct function call(de-virtualization).
EDIT: As #groovyspaceman pointed out, I see that I used wrong wording. The vTable class member pointer is mutable, the vTable itself is compiler generated and it depends on the system and the compiler if it can, or cannot be modified.