I was wondering how you can do polymorphism with references, as opposed to pointers.
To clarify, see the following minimal example:
class A;
class B {
public:
A& a; ///////////////// <- #1
B();
void doStuff();
};
class A {
public:
virtual void doSmth() = 0;
};
void B::doStuff() {
a.doSmth();
}
class A1 : public A {
public:
void doSmth() {
}
};
B::B() : a(
* ////////////// <- #2
(new A1) /////////// <- #3
) {
}
This compiles and works, but as the most important point here is that a in line #1 is a reference, so in order to be able to use it polymorphically (is that an actual word?), as shown in line #3 I have to "convert a pointer to a reference" by dereferencing it.
This strikes me as a bit odd, and I was wondering if there is a better (in the sense of cleaner) way. Is it just me?
Rationale
It would be great if I didn't need a new at all, but when declaring (!) B I have no clue how to create an instance of A1 (!) as A is a forward declaration -- A1 is implemented in the same compilation unit as B. Still, is there a real need for dynamic memory allocation in this case? How would you do this?
Sorry for the slightly twofold question.
Edit
Note: B is huge (and I cannot make a template class of it), and will go out of scope precisely when the program terminates -- a is small and makes two big modules talk to each other, it will be needed as long as the instance of B lives (there is only one).
Edit 2
I just realised, that since both A and B are effectively singletons, I can simply create a static instance of A1 in the compilation unit of B, avoiding dynamic memory allocation (even if there were two Bs they could easily use the same instance of A). To be fair, I did not post this as answer, but will accept the answer that prompted me to come up with this solution.
There's nothing odd. Polymorphisms works both for pointers and references:
struct Base { };
struct Derived : Base;
void foo(Base &);
int main() {
Derived x;
foo(x); // fine
}
You're conflating this with another issue, namely creating a reference to a dynamic object:
T * pt = new T;
T & rt = *pt;
T & x = *new T; // same effect
Note that it's generally very bad style to track a dynamic object only by reference, because the only way to delete it is via delete &x;, and it's very hard to see that x needs cleaning up.
There are two immediate alternatives for your design: 1) make a a member object in B, or 2) make a a shared_ptr<A> or unique_ptr<A> and change the initalizer to a(new A1). It all depends on whether you actually need the polymorphic behaviour, i.e. if you have other constructors for B which assign a different derived class to a other than A1.
This is indeed a bit odd. If you want a member-variable of type A1 (rather than a reference), why not just rearrange your code so that the definition of A1 appears before the definition of B?
Still, is there a real need for dynamic memory allocation in this
case?
No. Just define A1 first and then make it a normal member of B.
Polymorphism works just fine with both references and pointers.
Erm, is this not sufficient?
#include <iostream>
struct A;
struct B
{
B(A& a);
void foo();
A& _a;
};
struct A
{
virtual void foo() =0;
};
struct A1 : public A
{
virtual void foo() { std::cout << "A1::foo" << std::endl; }
};
B::B(A& a) : _a(a) {}
void B::foo() { _a.foo(); }
int main(void)
{
A1 a; // instance of A1
B b(a); // construct B with it
b.foo();
}
Still, is there a real need for dynamic memory allocation in this case?
Either the dynamic memory allocation or injecting the reference into B's ctor.
It's no stretch to imagine why references can work polymorphically like pointers (not to mention references are often implemented as pointers anyway). Here's a quick example:
class Base {
public:
virtual void something() { }
};
class Derived : public Base {
public:
void something() { }
};
Base& foo() {
static Derived d;
return d;
}
foo().something(); // calls Derived's something
Also why are you allocating dynamic memory for a reference? You probably shouldn't be using a reference in this case at all. Also, writing classes with reference members effectively prevents assignment (as I heard someone say quite well).
I realize this is a really old post but there is another option you have for handling references for dynamically allocated objects. You can assign a reference to the dynamically allocated object. Below is some dummy code to give you an idea of how this works.
struct A
{
int b;
virtual void print();
A(int val):b(val) {}
};
struct A_child:public A
{
A_child(int val):A(val) {}
void print();
};
void A:print()
{
cout<<"parent\n";
}
void A_child:print()
{
cout<<"child\n";
}
struct test_ref
{
A *& ref;
test_ref(A * ptr) : ref(ptr)
}
int main()
{
test_ref parent(new A(12));
parent.ref->print();
test_ref child(new A_child(15));
child.ref->print();
}
To be honest I am not certain when this is a good idea. I just wanted to show an alternative approach where you dont have to dereference the dynamically allocated memory when initializing an object.
I am also pretty certain dynamically allocating a pointer while initializing a class where the pointer is stored as a reference pointer will probably lead to a memory leak unless you can delete the reference pointer.
Related
I was looking to create a function that is capable of working with any Derived Object of A.
However in this example, I can't seem to be able to use B Object in a function that has a A Typing on it. Is there any way I pass B into the Function?
class A {
public:
A() {
}
};
class B :A {
public:
B() {
}
};
void function(A a) {
return;
}
int main(void) {
B b();
function(b);
}
I've commented on the fixes needed inline:
class A {
public:
A() {}
};
class B : public A { // public inheritance or A will be an inaccessible base of B
public:
B() {}
};
void function(const A& a) { // take a reference to an A to avoid copy-slicing
// ... work with the A part of the object you reference with `a`
}
int main() { // void not needed (but not an error as such)
B b; // not a function declaration anymore
function(b);
}
Actually you are lucky. You made two mistakes that caused passing b to the function fail, while in fact without that other mistakes you can pass b to the function but it would do the wrong thing silently.
First the two mistakes: B b(); declares a function. To declare a default constructed B you write B b;. Then B inherits privately, hence you cannot convert a B to an A. Thats what the error your code causes have told you.
However, after fixing those (and removing user declared constructors taht shouldnt be there when they do nothing)...
class A {};
class B : public A {};
void function(A a) {}
int main(void) {
B b;
function(b); // object slicing !!
}
This code compiles without errors, but usually it does the wrong thing!
Any B can be converted to an A because the inheritance is public, but what happens is object slicing: What is object slicing?. If B had any members not in A then they would all be lost when passing it to function. Its not an issue here because neither A nor B have any members, but in general you want to avoid objects to get sliced.
TL;DR: References / pointers are needed for polymorphism. Pass by (const) reference:
void function(const A& a) {} // does not modify a
void function(A& a) {} // modifies a
I have to work with a tree based hierarchy of objects where I need to access the deepest element that contains the data required by the application. I'm not sure if the previous statement explains in its best the problem itself so its better to present it with an example. Given the following scenario:
class A {
private:
B* _b;
public:
B* getB() {return _b;}
};
class B {
private:
C* _c;
public:
C* getC() {return _c;}
};
class C {
private:
int _n;
public:
int getN() {return _n;}
};
The desired operation would be to access n via A. So I would call the following:
A foo;
foo.getB()->getC()->getN();
The problem comes when any of the parts of the path are null we end up having a core dump. In the above scenario if B is null we end up in a core dump scenario.
Therefore I seek help and advice on any strategy or pattern that I can use to avoid this core dumps scenarios. If the path is extremely big I end up checking every single pointer if its valid and end up having really ugly code and also risk that I might have missed checking a part of the path. Note: I do not have access to change the implementation of the hierarchy of classes (A,B,C) as they are generated code and I do not have access to change the generator. Changing the previous would be my preferred solution but unfortunately I cannot.
In order to avoid having null pointers, you may want to establish a class-invariant that the member is never null. This can be achieved with following steps:
Encapsulate access to the member so that nothing outside the class can set the member. You've already achieved this through the use of private access. Just make sure that you pass/return a reference or a pointer to the member from a member function to the outside.
Ensure that no member nor friend function ever sets the member to null.
Also ensure that the member is always initialised. This is achieved by use of a custom constructor. Example:
class A {
B* b;
public:
A(B* b) : b(b) {
if (!b) {
// unlike indirection through null pointer, an exception can
// be caught and (potentially) handled gracefully at runtime
throw std::runtime_error("Naughty!");
}
}
// following prevents passing null literal at compile time
A(std::nullptr_t) = delete; // nullptr
A(int) = delete; // 0
// since it is never null, we can safely return a reference
B& getB() {return *b;}
}
While references have the nice property of not being ever null, they are tricky as members, since they are also not assignable. As an argument to a constructor, they are tricky since it is generally not conventional or expected for a class object to keep references to objects passed into a constructor. As such, I advocate the use of pointers in this case even when null is undesirable.
Note: I do not have access to change the implementation of the hierarchy of classes (A,B,C) as they are generated code and I do not have access to change the generator.
In this case you may instead wrap the generated classes with better classes:
class AWrapper {
A a;
// custom implementation that encapsulates A
}
If null pointers are valid values that cannot be avoided, then such invariant is of course not possible. In such case, you must always check whether the pointer is null before indirecting through it:
if (B* b = foo.getB())
if (C* c = b->getC())
c->getN();
Another thing that you might consider is whether all these pointers are necessary. Perhaps it would be simpler if the classes contained each other instead of indirectly referring to one another.
You need to test all along the way:
A foo;
B* BPrt = foo.getB();
if (BPrt)
{
C* CPtr = BPrt->getC();
if (CPtr)
{
int n = CPtr->getN();
...
Here's how I solved the problem:
#include <iostream>
using namespace std;
class C {
private:
int _n;
public:
int getN() {return _n;}
};
class B {
private:
C* _c;
public:
C* getC() {return _c;}
};
class A {
private:
B* _b;
public:
B* getB() {return _b;}
};
int main(void);
int main() {
static B b;
static C c;
static A foo;
unsigned int n;
B *bPtr; C *cPtr;
/* --RECODE (CHAIN-CALL): foo.getB()->getC()->getN();-- */
bPtr = (B *) (foo.getB());
cPtr = (C *) (bPtr ? bPtr->getC() : 0);
n = (int) (cPtr ? cPtr->getN() : 0);
/* --USE (CAST) and (TERNARY) instead of (CHAIN-CALL)-- */
cout << n << endl;
return n;
}
If the classes cannot be changed then the checking could be done via a template:
template <typename T, typename A, typename ...Args>
auto recurse(T t, A a, Args... args)
{
if (!t)
throw std::exception{};
auto next = (t->*a)();
if constexpr (sizeof...(Args) > 0)
return recurse(next, args...);
else
return next;
}
Then call as follows:
recurse(&foo, &A::getB, &B::getC, &C::getN);
The problem is not with a pointer being null. That is in-fact good as it mostly crashes at runtime. What if it's not null but has been previously freed/deleted ? The usage will probably lead to Undefined Behaviour.
A better way would be to use references if you can:
class A
{
private:
B& _b;
public:
A(B& b): _b{b} {}
B& getB ()
{
return _b;
}
};
Or something like that. Then you at-least don't have anything dangling (unless you are also using pointers somewhere).
If you have to use pointers then use one of the smart-pointers - see if std::unique_ptr solves if for you. If not then for shared ownership use std::shared_ptr and so on. Also ensure the way you initialise objects don't lead to a default null there.
You can make sure that your pointers are always initialized, if possible:
class C {
private:
int _n = 0;
public:
int getN() {return _n;}
};
class B {
private:
static C default_c;
C* _c = &default_c;
public:
C& getC() {return *_c;}
};
C B::default_c; // An out-of-line static member definition is required.
class A {
private:
static B default_b;
B* _b = &default_b;
public:
B& getB() {return *_b;}
};
B A::default_b; // An out-of-line static member definition is required.
int main() {
A a;
std::cout << a.getB().getC().getN() << '\n';
}
Note that pointers make better members than references because the references break value semantics and make your class non-assignable.
Did you consider:
try {
foo.getB()->getC()->getN();
}
catch(...)
{
//Here you know something is Null
}
That seems the simplest safest,when dealing with existing code.
I have classes A, B, C.
B and C are derived from A. B has a function foo().
If I make an A* array and fill it with B*-s and C*-s then I can't call foo() on the B* element because the compiller will search for it in A.
Is there a way to do it, or A must contain a foo() function too?
The function foo() is only known for B objects. This means that you have a pointer to A, you can't be sure the object has such a function or not. This is why the compiler will complain with an error.
The solution to your issue is polymorphism.
Alternative 1: make the function virtual in A
With this approach, you'd have an empty foo() function that does nothing for all A and C objects, but you'd override with the correct function in B.
Example:
struct A {
virtual void foo () { cout<<"nothing!"<<endl; }
};
struct B : A {
void foo () override { cout<<"this is a B object: foo!"<<endl; }
};
struct C : A {};
int main() {
vector<A*> va;
va.push_back (new A);
va.push_back (new B);
va.push_back(new C);
for (auto x : va)
x->foo();
}
Here the online demo
For the records, I've use a vector of pointers instead of an array. But the principle is the same.
Note also that a rule of thumb is that, if you have a virtual function in a class, you should have a virtual destructor as well (I omit it here for the sake of simplicity).
Alternative 2: make the class polymorphic and use dynamic_cast
With this approach, you'd define the foo() only for B object. The trick is when you iterate through your container, you check if the object is a B (this requires the object to be polymorphic), and if yes, you invoke the function.
Example:
struct A {
virtual ~A() {}; // to make A and its descendents polymorphic, you need at least one virtual function
};
struct B : A {
void foo () { cout<<"this is a B object: foo!"<<endl; }
};
struct C : A {};
int main() {
vector<A*> va;
va.push_back (new A);
va.push_back (new B);
va.push_back(new C);
for (auto x : va) {
auto maybe = dynamic_cast<B*>(x);
if (maybe) // yes, it's a B*
maybe->foo();
else cout << "still not a B"<<endl;
}
return 0;
}
Here the online demo
The dynamic_cast is an intelligent cast: if the type of the object pointed doesn't match the target type, then dynamic_cast returns nullptr.
Alternative 3: not recommended
The last alternative can be considered if A can't be polymorphic, but if you have a mean knowing an A* to determine if the object is in reaity a B or not. This could be the case, if in A you'd have some information about the type of the object. In this case you could consider a static_cast.
This is however not recommended:
you'd have to manage yourself a way to know the type of the object (so you'd manage manually, what the compiler does automatically when the types are polymorphic).
if you'd make an error in your static_cast, i.e. you think the object is a B but in reality it is not, you'd have an undefined behavior.
Are pointers to pointers legal in c++? I've come across this SO question: Pointer to Pointer to Pointer
But the answers aren't clear if it is legal c++ or not. Let's say I have:
class A{
public:
void foo(){
/* ect */
}
};
class B{
public:
A* a;
/* ect */
};
void Some_Func() {
B *b;
// besides this looking ugly, is it legal c++?
b->a->foo();
};
Is the line b->a->foo() OK to write? Is there a better way to represent this expression?
This is perfectly valid.But the term you are using "pointer to pointer" is wrong.
the term means a double pointer like **P,a pointer which holds the address of another pointer.
but your case is the pointer(of class A) is an member of a class whose pointer(of class B) is created by you in some_func
It is legal but in your example your program will crash (if you could compile it since your members are private) because you did not create an instance of B
void Some_Func() {
B *b; // uninitialized B ptr should be B* b = new B;
// legal
b->a->foo();
};
Although you may want to reconsider accessing variables directly as you do and instead have getter/setters to access private member variables.
Illegal, "a" is private. So is "foo".
If corrected to "public" then they're legal constructs.
From your code its hard to find a "better" way. BUT You can modify the code to make the code look much clearer:
class A{
public:
void foo(){ cout << "Work";}
};
class B{
private:
A *a;
public:
A& getA(){
return *a;
}
};
void SomeFunction()
{
B *b = new B();
B& bRef = *b;
bRef.getA().foo(); //better looking code?
delete b;
}
Yes but then you have to use pointer to pointer like **P.Actually if we want to access a pointer which is holding another pointer then we can do this.This is allowed in c++ but keep in mind that only in case if you have assigned a pointer to pointer p
class A;
class B {
public:
B(A& a) : a(a) {}
private:
A& a;
};
/* Method 1 */
/* warning C4355: 'this' : used in base member initializer list */
/*
class A {
public:
A() : b(*this) {}
private:
B b;
};
*/
/* Method 2 */
/* But I need to manually perform memory dellocation. */
class A {
public:
A() { b = new B(*this); }
~A() { delete b; }
private:
B* b;
};
int main() {
}
Currently, when I try to initialize the reference in B, I am using Method 1. However, Method 1 will flag me warning which is understandable.
Hence, I have to fall back using Method 2, by using dynamic memory allocation.
Is there any better way I can use, without the need of manual memory allocation/ dellocation (OK. I know smart pointer)?
I prefer Method 1, just that I am not comfortable with the warning.
Note this is a warning (so it is dangerous not illegal).
What the compiler is worried about is that you are passing a pointer for an object that has not been fully initialized. Thus if the pointer is used in the B class constructor you are in undefined behavior.
So if you do use this the only thing you can do is assign the pointer to a member variable (reference or pointer). But note be careful of the assignment to a variable as you may invoke an implicit cast (I am not sure if that is actually a problem but the RTTI is not available until the object is fully formed).
What are you trying to achieve by storing the reference?
Doing this is valid.
However, you must ensure (I mean by yourself, there's no way the compiler can do this) that the this is not used to call virtual functions until the object is fully constructed.
Depending on what you're doing, a method might be to factor out the parts of A that B needs, than have A inherit from the part.
struct bar_base; // interface foo wants
struct foo
{
foo(bar_base& pX) :
mX(pX)
{}
bar_base& mX;
};
struct bar_base
{
/* whatever else */
protected:
bar_base& get_base(void)
{
// getting `this` went here; safe because bar_base is initialized
return *this;
}
};
struct bar : bar_base
{
bar(void) :
// bar_base is already initialized, so:
mX(get_base())
{}
foo mX;
};
Obviously, this depends on what you're doing. This makes sure you never get undefined behavior.
But really, it's just warning. If you promise to never use this in B's constructor, you're fine, and can silence the warning this way:
struct bar;
struct foo
{
foo(bar& pX) :
mX(pX)
{}
bar& mX;
};
struct bar
{
bar(void) :
mX(self())
{}
foo mX;
private:
bar& self(void)
{
// fools the warning
return *this;
}
};
Make sure you know what you're doing, though. (Perhaps it could be re-designed?)
Well, one obvious way to avoid the warning is to make B store a pointer-to-A, then you don't have to initialise it in B's constructor/A's initialiser list, and can wait until the body of A's constructor is executing....
Take this warning seriously. Your this object is not yet fully constructed and passing around is not safe (if you ever accidentally call a function on this you invoke UB). Also, there are other techniques for memory management. Try looking up the STL design of allocators.
You could also use RAII/smart pointers to achieve the same effect.
Or, are you trying to write a garbage collector/memory profiler of sorts?