Currently using C++20.
I'm trying to share data from an instance of class A to its member instances of B and C during initialization. Rather than using getter/setters, singletons, dependency injections, etc, I was thinking of just sharing the data by passing them as arguments in the constructors of the member class variables, where each member instance would hold their share of data via some mean (e.g. reference, raw pointer, shared pointer, void pointer, etc).
Classes B and C are intended to always be initialized as members of class A. Ultimately, A should be the last 'owner' of the data such that when A gets deallocated during destruction, the shared data should be deallocated with it. With that in mind, which of these approaches would be acceptable; not violating any major rules and ensuring encapsulation?
A stores and passes the data as shared pointers. B & C stores the arguments as shared pointers.
A stores the data as normal variables, and passes them as void pointers. B & C stores the arguments as void pointers.
A stores the data as normal variables, and passes them as references. B & C stores the arguments as references.
A stores the data as normal variables, and passes them as raw pointers. B & C stores the arguments as raw pointers.
Pseudocode:
class B
{
private:
// Some variable that holds the shared data
};
class C
{
private:
// Some variable that holds the shared data
};
class A
{
private:
// Data to be shared to
B b;
C c;
// Data to be shared
SomeDataType first;
SomeDataType second;
public:
A()
: b{first, second}, c{first}
{
}
};
A stores and passes the data as shared pointers. B & C stores the arguments as shared pointers.
No. A owns the data, no ownership is shared. ("[...], A should be the last 'owner' of the data such that when `A? gets deallocated during destruction, the shared data should be deallocated with it.", if it is the last and first then it can be the only one, no need to share.)
A stores the data as normal variables, and passes them as void pointers. B & C stores the arguments as void pointers.
No. void* is not a solution to a problem you do not have. When in the past one had to use void* there are better alternatives now. Though as there is no need here in the first place this is beyond the scope of this answer.
A stores the data as normal variables, and passes them as references. B & C stores the arguments as references.
No, maybe yes. Reference members have implications. The compiler cannot generate copying for you.
A stores the data as normal variables, and passes them as raw pointers. B & C stores the arguments as raw pointers.
That sounds reasonable. It is raw owning pointers that should be avoided. A raw non-owning pointer that never gets invalid (because the owner is destroyed after observers) is fine. The only phases during which you need to be careful not a not yet valid or not anymore valid pointer is during construction and destruction. It is worth mentioning that during construction of A it is ok to take pointers to members, but only after the member has been initialized you may safely dereference the pointer.
Related
Could you please clear up a question for me regarding pointer vs object in C++. I have the below code that has a class called "person" and a list that allows for 100 objects of that class type.
class person {...}
int main {
person* mylist;
mylist = new person[100];
mylist[0].set_name("John")
// ...
}
In this code I can call a method of the class by mylist[0].set_name() meaning (by my understanding) that mylist[0] is an object (hence the . operator to call a method). The code works fine.
I have another project where the "person" class is used as a base class to derive classes "carpenter" and "welder". The derived classes simply overwrite a virtual function called salary in the base "person" class to allow for a different calculation of salary.
person* mylist[100];
mylist[0] = new carpenter;
mylist[0]->set_name("John");
This code works fine as well. My question is - why in the first code I can call the set_name method using the . (meaning mylist[0] is an object) and in the second code I have to use the -> operator (meaning mylist[0] is a pointer to the object)?
T* represents a pointer type, which represents a variable that contains a "reference" (usually a memory address) to some instance of type T. Using a real world comparison, a T* pointer stands to T like a street address stands to a building.
Pointers allow you to refer to some instance owned by some other variable, and you can use a valid, non null instance of T* to read and write on a T. In this, they are similar to another C++ concept, references (written as T&), which allow you to alias variables, but differ significantly from pointers by not being objects in their own regard.
A pointer is, in fact, an object itself, with each pointer variable having its own unique address and being thus storable and referenceable. For instance, you can have pointers to pointers (T**) and references to pointers (T*&), but not pointers to references - pointers exist, while references may not (they are usually implemented as pointers underneath though).
To reflect the this "indirect" nature of pointers, C and C++ provide you with two different operators which allow you to dereference a pointer (* and ->), and to reference a variable (&).
For instance, you may do the following:
struct A { int x; };
// ...
A a {};
A *aptr { &a }; // `&` takes the address of `a` and stores it into the `aptr` variable of type `A*`
aptr->x = 33; // `->` is equivalent here to `(*aptr).x`, a.x is now 33
A a2 {};
A **aptrptr { &aptr }; // pointer to pointer
*aptrptr = &a2; // `aptr` now points to `a2`
operator-> is basically syntactic sugar that avoids you some cumbersome expressions like (*aptr).x.
References, being basically just aliases to something else, do not need any special syntax at all, and are always converted transparently when neeeded:
int x { 33 };
int &xref { x }; // `xref` refers to `x`
xref = 12; // `x` is now 33
int y = xref; // copies `x` into `y`, no special syntax needed
Pointers are also used in the C language to access arrays, which always decay to a pointer as soon as they are referred to in expressions. This is messy and it's one of the reasons std::vector and std::array should always be used in their place when feasible.
int x[33];
x[3] = 44; // equivalent to `*(&x[0] + 3) = 44`
Finally, the "indirect" nature of pointers and references allow C++ to convert a Derived* to a Base*, given that a derived class contains a full instance of its base (it gets more complicated with multiple inheritance though).
Every class that inherits or contains from another class containing virtual methods will include a hidden pointer to a _Virtual Method Table`, a list of pointers to functions which will be used to dispatch the virtual methods to the correct implementation.
PS: in modern C++, you should rarely need raw pointers. The correct approach is to use containers such as std::vector, std::array and std::string, and special pointer-like wrappers called smart pointers (like std::unique_ptr) every time you need a pointer for some reason. These will handle the lifetime of a pointer for you, avoiding memory leaks and vastly simplifying memory handling. For the same reason, the new operator should be mostly considered as being deprecated and should not be used at all (unless in placement new expressions, are potentially dangerous if used improperly).
basically the first case works like this: you have an array of objects. To access the object fields and methods you use . operator.
In the second case you have an array of pointers to an object. Pointer is just a memory address, that points to an object of some type. In your case, this is an array of pointers to class person. By default, these pointers are invalid; you have to set them to the address of some existing object. new creates an object on the heap, and returns you an address of that object. In order to access the value behind the pointer, you have to de-reference it. The syntax is this:
some_type obj;
some_type* ptr = &obj; // get the address of the object
(*ptr).some_method(); // de-reference the pointer and call it
ptr->some_method(); // same
Playing around with C++ after a longer break.
I have a std::vector of unique pointers to objects through which I iterate, calling a function that takes as argument the base class from which the objects in the vector are derived, like so:
for (auto const& object : objects)
{
_process(object);
}
where objects would be:
std::vector<std::unique_ptr<Derived>>
I would like to understand how would I enforce polymorphic behavior to call the function:
_process(std::unique_ptr<Base> base)
std::unique_ptr represents ownership, and therefore can not be copied.
That means that _process(std::unique_ptr<Base> base) is a sink, i.e. it consumes the object (it can destroy it or store it somewhere, but the caller has no control over it anymore). In order to call it you'd have to use std::move:
_process(std::move(object))
that way you explicitly reject the ownership over the object and essentially remove it from your container - the pointer will be reset to nullptr.
Naturally that can only be done via non-const reference.
If you don't want to transfer the ownership and just want to do something with the object - which the name _process seem to imply - you're supposed to pass the regular raw pointer:
_process(Base* base);
...
for (auto const& object : objects)
{
_process(object.get());
}
Raw pointers are still great for everything except controlling the lifetime of your objects.
In both cases (raw pointer and unique_ptr) there should be absolutely no problem with implicitly converting from Derived to Base.
I have a design which includes 3 classes as my data structures. Let's call the classes A, B, and C.
I have to instantiate objects of A, B, and C while parsing my input. Each object of class C needs to keep track of the corresponding objects in classes A and B. My current implementation looks like this:
class C {
private:
A* a;
B* b;
public:
void setA(A* a);
void setB(B* b);
}
I assign a and b when I create the objects of A and B using new operator. The problem is that I do not want an object of class C to be able to modify a and b. In fact, I only need to know which a and b correspond to a specific c.
One solution could be to define a and b as const pointers/object references. However, in the case of object references, I need to define them as soon as I declare them. The problem is that I am parsing several files and I cannot assign the proper references to a and b when I define them. In other words, a and b are created at different times in my program and may not be available when I create c.
Recently, I read that it's better to avoid raw pointers as much as possible and that's why I'm trying to implement this using object references instead of pointers. Actually, this is giving me a hard time to figure out which one to use at different stages of my program.
My questions are as follows:
1) Is it better to use object references instead of pointers in this specific question?
2) While this approach works for pointers, what should I do to assign constant references to a and b if I prefer to use object references instead of pointers?
3) If I use unique_ptr for a and b, what would be the solution to this problem?
It is good modern C++ style to avoid using raw pointers. See
Chapter 4 of Effective Modern C++ by Scott Meyers for details.
However, this doesn't mean you cannot use pointers. I'd also recommend the reading Effective C++, More Effective C++, and Effective STL.
So nomenclature wise, the reference or pointer are both pointing
to the same object. Under the covers, you are copying around memory
addresses of the object in question.
Now to use a const pointer (or reference) the object itself doesn't
have to be const. If the function takes a const type* or const
type&, the type system will tack on the const for you.
What I think you want is a const pointer. Here the item being
pointed to is const, and not the memory address, so you do not have
to initialize the parameters on construction. Issue with the const
reference is what would you initialize it as? The const type* can
be set to nullptr on construction, but a reference doesn't have a
way to have a null value. I'd say this is important here because
you will want to be able t tell if the caller assigned a value to a
or b. If they didn't, and you properly initialized the member
variables to nullptr, you can test against that to know they weren't
set.
So in this case, the actual memory to be owned by a
std::unique_ptr<> and you would pass down a reference or pointer to
the object. In your situation, sending down the address/pointer is
the only reasonable thing to do. you'll want to initialize the
value to nullptr on construction. Then you'll be able to tell if
the caller assigned a value, because the pointer is not null. If
you wanted to use a const type&, you'd have to set a valid value at
construction time, and since their is no null&, their is no obvious
way to do it.
Also, though this wasn't part of your question, I would document who really owns the memory. One thing I like about using std::unique_ptr<> is that is makes ownership obvious.
Your updated example:
class C {
private:
const A* a;
const B* b;
public:
void setA(const A* a);
void setB(const B* b);
}
The problem is that I do not want an object of class C to be able to modify a and b. In fact, I only need to know which a and b correspond to a specific c.
Use a const pointer:
A const* a;
A const* b;
Then deference them, and they will be objects.
Use pointers instead of references, as if you have an instance of C in either class A or B, you will get an error. Using pointers avoids that
(1)It does not matter; you should use pointers because it is easier to see when you are passing a reference. For example:
function(a); // Not sure if it is a reference
function(&a); // You know it is that actual object
(2) Deference the const pointer, and it will make it a const "reference"
Good morning. I am having trouble understanding the logic behind deep and shallow copying with objects in C++ in a shared project, so I have created the following example.
int main() {
ObjectAType* objecta = ObjectAType::New();
ObjectBType* objectb = ObjectBType::New();
// some operation to populate data members of object a
objecta->Operation();
// assume I have accessors to return datamembers of object a
// I wish to make a deep copy of SOME of those data members into object b
objectb->AlignWithA(objecta);
objecta->Delete();
objectb->Delete();
return 0;
}
Now given the object b class function as follows:
public:
void ObjectBType::AlignWithA(ObjectAType* objecta) {
this->ObjectBDataMember = objecta->DataAccessor();
}
protected:
int ObjectBDataMember;
And the data accessor is just something like this within the class def,
public:
int ObjectAType::DataAccessor() {
return this->ObjectADataMember;
}
protected:
int ObjectADataMember;
I have a few resulting questions.
1) Since in object b, the data member is declared as
int ObjectBDataMember;
and not as
int *ObjectBDataMember;
why is the data member accessed as
this->ObjectBDataMember
and not as
this.ObjectBDataMember
?
2) Is this a deep or shallow copy?
I apologize if I have left out important bits. I'm not much of a programmer so things like this easily confuse me. The literature has just confused me further. Thank you for your time.
In C++, this is defined as being a (non-modifiable) pointer to the current object. For that reason, you use this->aMember to access aMember. This is independent of the type that aMember has. (Note: Using this->aMember is equivalent to just using aMember as long as there are no local variables or function parameters using that same name).
Because ObjectBDataMember is an int, copying it is not referred to as either shallow or deep. Those concepts are only used in the context of copying pointers.
For example:
ObjectBType* b1 = new ObjectBType();
ObjectBType* b2 = b1; // shallow copy. b1 and b2 refer to the same object.
ObjectBType* b3 = new ObjectBType(*b1); /* deep copy. b1 and b3 refer to
different objects that happen to have the same value. */
"Why is the data member accessed as this->ObjectBDataMember and not as this.ObjectBDataMember?"
That's because this is a pointer, and the -> operator follows the pointer that comes before it to access the member that comes after it.
"Is this a deep or shallow copy?"
If you mean the copy of the integer variable, you can call that a shallow copy, but there's no need to qualify it as such because int is not a data structure.
The term "deep copy" refers to a recursive copying of all objects associated to the object being copied: if a data structure S contains member variables which are pointers, deep copying an instance of S (say, s1) into another instance of S (say, s2) means recursively copying each object pointed by variables of s1 so that s2 will be associated to copies of those objects, rather than to the same objects to which s1 is associated (that would be the case for shallow copying).
Here, you do not have any pointer member variables, so the concept of "deep" vs "shallow" copy loses its meaning in this context.
You use -> when you have a pointer, and . when you have a reference. The data member is accessed as this->ObjectBDataMember because this is a non-modifiable pointer to self. Therefore you need the -> (offset) operator to access its ObjectBDataMember. It should be noted that you don't have to use the self-reference this pointer to access an object's own data members. It is just a style used to emphasis that the code is accessing the object's own data member. Useful when you are accessing another object's data members and they have the same members (due to being the same object type).
These objects have no allocated objects, merely plain old data types. So it is a shallow copy. A shallow copy of an object copies its values but doesn't allocate any new objects. It only copies the pointers to any allocated objects. A deep copy makes a copy of all value type members, as well as creating its own allocated objects (usually copying over the values in the source copied objects sub objects).
this->ObjectBDataMember has nothing to do with deep or shallow copy. this is a pointer so it's members are always accessed through ->. Well, you could do (*this).ObjectBDataMember.
The difference between
int ObjectBDataMember;
and
int *ObjectBDataMember;
is if you want to set it's value you'd do:
this->ObjectBDataMember = 5;
vs
*(this->ObjectBDataMember) = 5;
because this is ObjectBType* (pointer), so to access its members you need to specify ->. BTW, this is implicit variable in member functions and you can omit it: ObjectBDataMember = objecta->DataAccessor();
The type of ObjectADataMember is int, it's fundamental type (not compound), so it's just a copy. Temp "deep copy" is applicable to compound types.
I'd recommend first to finish any good C++ book, this will resolve tons of potential questions like this one
This is one topic that is not making sense to me. Pointers to data members of a class can be declared and used. However,
What is the logic that supports the idea ? [I am not talking about the syntax, but the logic of this feature]
Also,if i understand this correctly, this would imply an indefinite/variable amount of memory being allocated at the pointer initialization as any number of objects may exist at that time. Also, new objects may be created and destroyed during runtime. Hence, in effect, a single statement will cause a large number of allocations/deallocations. This seems rather counter-intuitive as compared to the rest of the language. Or is my understanding of this incorrect ? I dont think there is any other single initialization statement that will implicitly affect program execution as widely as this.
Lastly, how is memory allocated to these pointers ? Where are they placed with respect to objects ? Is it possible to see physical memory addresses of these pointers ?
A single declaration of a pointer to a data member, creates pointers for every object of that class.
No, it does not. A pointer to a member is a special object that is very different from a pointer; it is a lot more similar to an offset. Given a pointer to an object of the class and a member pointer, you'd be able to get the value of a member; without the pointer to an object of a class a pointer to a member is useless.
Questions 2 and 3 stem from the same basic misunderstanding.
A single declaration of a pointer to a data member, creates pointers for every object of that class.
No. It creates a pointer to a member (which can be though of as an offset from the base of object)
You can then use it with a pointer to an object to get that member.
struct S
{
int x;
int y;
};
int S::* ptrToMember = &S::x; // Pointer to a member.
S obj;
int* ptrToData = &obj.x; // Pointer to object
// that happens to be a member
Notice in creating the pointer to a member we don't use an object (we just use the type information). So this pointer is an offset into the class to get a specific member.
You can access the data member via a pointer or object.
(obj.*ptrToMember) = 5; // Assign via pointer to member (requires an object)
*ptrToData = 6; // Assign via pointer already points at object.
Why does this happen as opposed to a single pointer being created to point to only one specific instance of the class ?
That is called a pointer.
A similar but parallel concept (see above).
What is the logic that supports the idea ?
Silly example:
void addOneToMember(S& obj, int S::* member) { (obj.*member) += 1; }
void addOneToX(S& obj) { addOneToMember(obj, &Obj::x);}
void addOneToY(S& obj) { addOneToMember(obj, &Obj::y);}
Also,if i understand this correctly, this would imply an indefinite/variable amount of memory being allocated at the pointer initialization as any number of objects may exist at that time.
No. Because a pointer to a member is just an offset into an object. You still need the actual object to get the value.
Lastly, how is memory allocated to these pointers ?
Same way as other objects. There is nothing special about them in terms of layout.
But the actual layout is implementation defined. So there is no way of answering this question without referring to the compiler. But it is really of no use to you.
Is it possible to see physical memory addresses of these pointers ?
Sure. They are just like other objects.
// Not that this will provide anything meaningful.
std::cout.write(reinterpret_cast<char*>(&ptrToMember), sizeof(ptrToMember));
// 1) take the address of the pointer to member.
// 2) cast to char* as required by write.
// 3) pass the size of the pointer to member
// and you should write the values printed out.
// Note the values may be non printable but I am sure you can work with that
// Also note the meaning is not useful to you as it is compiler dependent.
Internally, for a class that does not have virtual bases, a pointer-to-member-data just has to hold the offset of the data member from the start of an object of that type. With virtual bases it's a bit more complicated, because the location of the virtual base can change, depending on the type of the most-derived object. Regardless, there's a small amount of data involved, and when you dereference the pointer-to-data-member the compiler generates appropriate code to access it.