Is the following wrapper class an "OK" way of keeping an intermediate object with std::unique_ptr to access the me member without copying me?
Here is the example
#include <iostream>
#include <memory>
/* myobj from another library */
class myobj {
public:
std::string me; /* actual member of interest is larger and more
complicated. Don't want to copy of me or myobj */
/* more members in actual class */
myobj(std::string i_am) {
/* more stuff happens in constructor */
me = i_am;
}
~myobj(){
std::cout << me << ": Goodbye" << std::endl;
}
};
/* A function in another library */
void who_is_this(std::string *who){
std::cout << "This is " << *who << std::endl;
}
/* wrapper which I define */
class myobj_wrapper {
using obj_ptr = std::unique_ptr<myobj>;
obj_ptr ptr;
public:
std::string *who;
myobj_wrapper(std::string i_am):
ptr(new myobj(i_am)), who(&ptr.get()->me) {}
myobj_wrapper(myobj &the_obj): who(&the_obj.me) { }
};
int main()
{
{
myobj bob("Bob");
who_is_this(myobj_wrapper(bob).who);
}
who_is_this(myobj_wrapper("Alice").who);
return 0;
}
The resulting program yields
This is Bob
Bob: Goodbye
This is Alice
Alice: Goodbye
I define myobj_wrapper for multiple object to get the who pointer. What I am unsure of whether the object of interest (std::string in the above) will get destroyed before it is evaluated in the who_is_this function. It does not seem to from the above but should I expect this? Are there pitfalls with the above solution?
I am not sure, but here is my point of view:
who_is_this(myobj_wrapper("Alice").who);
This will create a wrapper object, that will take the string literal as its argument. Then, a myobj instance will be dynamically created, and handed over to a unique pointer. Via that instance, we get its data (the string), and make a traditional pointer from the wrapper class point to it. So, now who is pointing to me, i.e. Alice.
We pass who (which is a pointer) to:
void who_is_this(std::string *who)
which means that the function's parameter who is not a copy, but points to the original data.
So now the whole question is when the wrapper object will go out of scope (thus its data member (the unique pointer) will go out of scope too, meaning that the myobj instance which had been dynamically created will be garbage collected, which in turns means that me will go out of scope too, and so will who.
The wrapper object will go out of scope, after who_is_this() gets executed, which means that your code is OK.
Related
Is it in anyway possible (without using boost) to have a function in c++ as follows :
void foo(int x, classX &obj = *(new classX()))
The classX is used multiple times in my codebase and there are many such functions which have a similar signature (i.e. use this class object as a default argument). Is it possible to achieve this without an overloaded call?
The code that you provided certainly compiles and "works", but I strongly advise against such a thing.
The function returns void so that means the either referenced or allocated object (or its presumed owner) does not leave the function. It must thus, if allocated, be destroyed (otherwise, that's someone else's problem, outside that function).
However, that isn't even possible, there is nobody who owns the object, or has a pointer to it! So not only do you have a possible memory leak there, you have a guaranteed memory leak (in case no object is passed), unless you add yet another ugly hack that derives a pointer from the reference only to destroy the object. That's very unpleasant.
Plus, even if you get this done (in a no-leak way), you have useless object allocation and destruction for every function call. Although one shouldn't optimize prematurely, one also shouldn't pessimize prematurely by adding regular allocations and deallocations that are not just unnecessary but actually decrease code quality.
Something that's better would be:
//namespace whatever {
classX dummy;
//}
#include <memory>
void foo(int x, classX &obj = dummy)
{
if(std::addressof(obj) != std::addressof(dummy))
{ /* do something using object */ }
else
{ /* no object supplied */ }
}
Yep, that's a global used for a good cause. You can make the global a singleton if that makes you feel better, or a static class member, all the same. Either way, you have exactly one object, no allocations, no leaks, and you can still pass an object to the function if you wish. And, you can distinguish these two cases.
To use a global shared instance as default argument is possible.
With
extern inline classX globalClassX;
void foo(int x, classX &obj = globalClassX);
it should be accomplished.
However, I'm quite uncertain about the static initialization order fiasco which may interfere.
This can be solved using Meyers Singleton approach instead:
classX& getGlobalClassX()
{
static ClassX classX;
return classX;
}
void foo(int x, classX &obj = getGlobalClassX);
An MCVE for demonstration:
#include <cassert>
#include <iostream>
struct Object {
inline static unsigned idGen = 1;
unsigned id;
const std::string name;
explicit Object(const std::string &name = std::string()): id(idGen++), name(name) { }
};
Object& getGlobalObj()
{
static Object objGlobal("global");
return objGlobal;
}
void doSomething(int x, Object &obj = getGlobalObj());
#define PRINT_AND_DO(...) std::cout << #__VA_ARGS__ << ";\n"; __VA_ARGS__
int main()
{
PRINT_AND_DO(doSomething(0));
PRINT_AND_DO(Object obj("local"));
PRINT_AND_DO(doSomething(1, obj));
PRINT_AND_DO(doSomething(2));
}
void doSomething(int x, Object &obj)
{
std::cout << "doSomething(x: " << x << ", obj: Object("
<< obj.id << ", '" << obj.name << "'))\n";
}
Output:
doSomething(0);
doSomething(x: 0, obj: Object(1, 'global'))
Object obj("local");
doSomething(1, obj);
doSomething(x: 1, obj: Object(2, 'local'))
doSomething(2);
doSomething(x: 2, obj: Object(1, 'global'))
Live Demo on coliru
Another Q/A I consulted while writing:
SO: Are static data members safe as C++ default arguments?
I am currently reading the second edition of C++: A Beginner's Guide by Herbert Schildt.
In Module 9.4, he talks about returning objects:
Just as objects can be passed to functions, functions can return objects. To return an object, first declare
the function as returning a class type. Second, return an object of that type using the normal return
statement. The following program has a member function called mkBigger( ). It returns an object that
gives val a value twice as large as the invoking object.
This is the 'following program' he mentions:
// Returning objects.
#include <iostream>
using namespace std;
class MyClass {
int val;
public:
// Normal Constructor.
MyClass(int i) {
val = i;
cout << "Inside constructor\n";
}
~MyClass() {
cout << "Destructing\n";
}
int getval() { return val; }
// Return an object.
MyClass mkBigger() {
Myclass o(val * 2); // mkBigger() returns a MyClass object.
return o;
}
};
void display(MyClass ob)
{
cout << ob.getval() << '\n';
}
int main()
{
cout << " Before Constructing a.\n";
MyClass a;
cout << "After constructing a.\n\n";
cout << "Before call to display.\n";
display(a);
cout << "After display() returns.\n\n";
cout << "Before call to mkBigger().\n";
a = a.mkBigger();
cout << "After mkBigger() returns.\n\n";
cout << "Before second call to display.\n";
display(a);
cout << "After display() returns.\n\n";
return 0;
}
This gives us the following output:
Before Constructing a.
Inside constructor
After constructing a.
Before call to display.
10
Destructing
After display() returns.
Before call to mkBigger()
Inside constructor
Destructing
Destructing
After mkBigger() returns.
Before second call to display.
20
Destructing
After display() returns.
Destructing
Schildt then goes on to explain that the reason there are two 'Destructing' messages during the mkBigger() call is because of the fact that:
when an object is returned by a function, a temporary object is automatically created, which holds the return value. It is this object that is actually returned by the function. After the value has been returned, this object is destroyed.
I was actually surprised there wasn't 3 'Destructing' messages. I have the following issue: Given the definition of mkBigger(), a new MyClass instance is created, and it is that instance that is returned and placed in the address of a. Thus, when doing
a = a.mkBigger();
My impression is thus that the original object previously held in a is no longer referenced by a. Is this correct? If so, I then have the following issues:
I was told C++ has some minute notions of garbage collection. Would that object thus be garbage-collected? where is this object now? Is this an example of the possible feared memory leaks that many mention when talking about the 'dangers' of C++?
One of the destructor in mkbigger() is called on o, the MyClass instance passed in by value; it goes out of scope at the end of the function. The other is called on the temporary copy of o returned when it is destroyed. What else goes out of scope? Not a in main(); therefore you should not expect a third destructor to be called. C++ does not provide garbage collection outside of calling destructors when automatic objects go out of scope.
Unlike some other modern languages, a does not "hold a reference" to an object; a is the object, in that it is a certain number of bytes holding the raw data members. When you do a = a.mkBigger();, MyClass's default assignment operator is called, which simply copies the val inside the temporary object on the right hand side into the val inside a, overwriting the value that was already there. a = a.makeBigger() would be equivalent to a.val = a.makeBigger().val if val were public.
Memory leaks occur when you use new to allocate memory and then fail to use delete to deallocate that memory. For classes that do this internally, you must write at least your own copy constructor, assignment operator, and destructor.
I do not know what methodology they use since the code base is huge.
It defined a class like this:
class ABC {
member_func(string c);
};
main() {
ABC("").member_func("this random string");
}
What is the missing code that would enable us to call ABC("");?
I did not see any object of that class created anywhere.
That simply constructs an object of type ABC, but doesn't initialize any permanent memory location with that object. I.e., the initialized object the call to the ABC constructor creates is a temporary, and is lost after the call since it is not constructed in a memory location that can be accessed after the call such as an automatic variable on the stack, a static memory location, etc. So the "missing" code to make a call like that usable in the "real-world" is to actual name an object that is constructed so that it can be accessed later... for example, something like ABC my_object(""); or ABC my_object = ABC("");.
UPDATE: In the updated code you've posted, what's taking place is again a temporary object of type ABC is being constructed, and then a non-static method of class ABC called member_func is being called on the temporary that was created by the call to ABC's constructor. Of course for this code to have any meaning in the "real world", that call to member_func would have to contain some side-effect that would be visible outside of the class instance (i.e., the class instance could be containing a data-member that is a pointer to some shared memory object that the call then modifies). Since though from the code sample you've posted there does not seem to be any side-effects from the call, it's for all intents and purposes a non-operation ... a temporary ABC class instance is created, it has a method called on the instance, and then any reference to the instance is lost since it was not constructed in a memory location accessible from the current scope of main().
class ABC
{
std::string d;
public:
ABC(std::string x) // For the ABC("").
{ d = x; }
void foo(std::string x) // For the foo("").
{ std::cout << d << std::endl << x << std::endl; }
};
int main()
{
ABC("This creates a temporary object.").foo("This calls foo().");
// Is the same as...
{
ABC obj("This creates another object.");
obj.foo("This calls obj.foo().");
} // obj is destroyed.
return(0);
}
Self explanatory... I hope. :)
1st code:
#include <iostream>
using namespace std;
class demo
{
int a;
public:
demo():a(9){}
demo& fun()//return type isdemo&
{
return *this;
}
};
int main()
{
demo obj;
obj.fun();
return 0;
}
2nd code:
#include <iostream>
using namespace std;
class demo
{
int a;
public:
demo():a(9){}
demo fun()//return type is demo
{
return *this;
}
};
int main()
{
demo obj;
obj.fun();
return 0;
}
what is the difference between these two codes as both are working in gcc?i am new here so forgive me if my way of asking is wrong.
demo & fun() returns a reference to the current object. demo fun() returns a new object, made by copying the current object.
Both are valid but are different. In the first case demo& fun() a reference to the same object is returned, in the second case a new object is created. While both are the same, the semantics differ, run this example:
#include <iostream>
struct test {
int x;
test() : x() {}
test& foo() { return *this; }
test bar() { return *this; }
void set( int value ) { x = value; }
};
int main() {
test t;
t.foo().set( 10 ); // modifies t
t.bar().set( 5 ); // modifies a copy of t
std::cout << t.x << std::endl; // prints 10
}
Apart from what #Erik said about the return type, a little excursus on the this-pointer:
The following is equivalent:
struct my_struct{
my_struct* get_this() const { return this; }
};
my_struct obj;
my_struct* obj_this = ob.get_this();
std::cout << std::boolalpha; // to display true/false instead of 1/0
std::cout << "&obj == obj_this = " << &obj == obj_this << "\n";
The this pointer is just the pointer to that object, you can think of it as a hidden parameter. It's more understandable in the C way:
typedef struct my_struct{
int data;
// little fidgeting to simulate member functions in c
typedef void (*my_struct_funcptr)(struct my_struct*,int);
my_struct_funcptr func;
}my_struct;
// C++ does something similar to pass the this-pointer of the object
void my_struct_func(my_struct* this, int n){
this->data += n;
}
my_struct obj;
obj.data = 55;
// see comment in struct
obj.func = &my_struct_func;
obj.func(&obj, 15);
// ^^^^ - the compiler automatically does this for you in C++
std::cout << obj.data; // displays 70
Consider your function.
demo fun(){return *this;}
Here you are returning by value so one temporary object will be created which will be destroyed, once you assign the return value of fun to some other object.
While in case when you pass the reference, no object will be created newly, but it will pass actual object and even after assigning function return value object will not destroy till main object(used inside fun, in ur case its the object calling the function) won't go out of scope.
The concept you are trying to understand can be explained in more detail with other example.
consider function that is taking object as argument and returning object as argument.(also consider we have object that contains a pointer, we will assign value to pointer by first allocating memory to pointer and a destructor, which will free memory hold by pointer of object). Now when you return object as pass by value, temporary object will be created, that will have exact copy of main object(and temporary object's pointer will also point to same address or you can say holds the same address). Now inside main(), you assign/initialize any object with return value(object) of function. But when your temp object will be destroyed after assigning value, it will also free the memory because of destructor and when you try to fetch the same address value through assigned object(inside main() ) you will get error as that memory has been already freed.
But if you would have return value using reference, object returned by object won't destroy as main obj(inside function or through which we have called the function) is in scope and your pointer won't loose its memory. Making possible for assigned object to fetch address value through its pointer and avoid undesirable result.
In code 1 demo obj creates a fresh copy of demo. obj is initialised using demo's default constructor 'demo():a(9){}'. obj.fun() returns a reference to (already existing) obj.
In code 2 obj.fun() creates a new demo type object using demo's copy constructor (in your case it is compiler generated) and returns that copy to the caller.
Both code are valid.
1st code fun() is returning a reference to current object
2nd code fun() is returning the copy (by value) of the object
For 1st case, If you decide to return by value
then prefer to return a const
reference; i.e. const demo& fun();
and later you can copy it if needed.
Simply returning reference makes the
object modifiable, which may
accidently edit the content without
intent
For 2nd case, Do NOT return the object by value,
because it can create unnecessary
temporary copy which will effect
the memory/performance of your code
I have a Foo object, and a std::list holding instances of it. My problem is that when I add a new instance to the list, it first calls the ctor but then also the dtor. And then the dtor on another instance (according to the this pointer).
A single instance is added to the list but since its dtor (along with its parents) is called, the object cant be used as expected.
Heres some simplified code to illustrate the problem:
#include <iostream>
#include <list>
class Foo
{
public:
Foo()
{
int breakpoint = 0;
}
~Foo()
{
int breakpoint = 0;
}
};
int main()
{
std::list<Foo> li;
li.push_back(Foo());
}
When you push_back() your Foo object, the object is copied to the list's internal data structures, therefore the Dtor and the Ctor of another instance are called.
All standard STL container types in C++ take their items by value, therefore copying them as needed. For example, whenever a vector needs to grow, it is possible that all values in the vector get copied.
Maybe you want to store pointers instead of objects in the list. By doing that, only the pointers get copied instead of the object. But, by doing so, you have to make sure to delete the objects once you are done:
for (std::list<Foo*>::iterator it = list.begin(); it != list.end(); ++it) {
delete *it;
}
list.clear();
Alternatively, you can try to use some kind of 'smart pointer' class, for example from the Boost libraries.
You are creating a temporary Foo here:
li.push_back( Foo() )
push_back copies that Foo into its internal data structures. The temporary Foo is destroyed after push_back has been executed, which will call the destructor.
You will need a proper copy constructor that increases some reference count on the class members that you do not want to destroy early -- or make it private to force yourself on the pointer solution.
Use this object to understand:
class Foo
{
public:
Foo(int x): m_x(x)
{
std::cout << "Constructed Object: " << m_x << ")\n";
}
Foo(Foo const& c): m_x(c.m_x+100)
{
std::cout << "Copied Object: " << m_x << ")\n";
}
~Foo()
{
std::cout << "Destroyed Object: " << m_x << ")\n";
}
};
The First main
std::list<Foo*> li;
li.push_back(Foo(1));
Here we create a temporary Foo object and call push_back(). The temporary object gets copied into the list and the function returns. On completion of this statement the temporary object is then destroyed (via the destructor). When the list is destroyed it will also destroy all the obejcts it contains (Foo is an object with a destructor so destruction includes calling the destructor).
So you should see somthing like this:
Constructed Object: 1
Constructed Object: 101
DestroyedObject: 1
DestroyedObject: 101
In the second example you have:
std::list<Foo*> li;
li.push_back(new Foo(1));
Here you dynamically create an object on the heap. Then call the push_back(). Here the pointer is copied into the list (the pointer has no constructor/destructor) so nothing else happens. The list now contains a pointer to the object on the heap. When the function returns nothing else is done. When the list is destroyed it destroys (note the subtle difference betweens destroy and delete) the object it contains (a pointer) but a pointer has no destructor so nothing happens any you will leak memory.
So you should see somthing like this:
Constructed Object: 1
What actually happens here is that you store a copy of the passed object in the list, because you're sending it by value instead of by reference. So the first dtor that is called is actually called on the object you pass to the push_back method, but a new instance had been created by then and it is now stored in the list.
If you don't want a copy of the Foo object to be created, store pointers to Foo objects in the list instead of the objects themselves. Of course when doing it you will have to properly release memory on destruction of the list.
Making the list holding pointers instead of instances solves the problem with the destructor being called. But I still want to understand why it happens.
#include <iostream>
#include <list>
class Foo
{
public:
Foo()
{
int breakpoint = 0;
}
~Foo()
{
int breakpoint = 0;
}
};
int main()
{
std::list<Foo*> li;
li.push_back(new Foo());
}