I've tested some code on gcc in debug mode, but not sure it will work correct for other compilers.
My question is how will any compiler optimize the following c++ code (make_auto macro):
class A
{
private:
void *ptr;
public:
A(void* _ptr) {ptr = _ptr;}
~A() {free(ptr);}
};
#define make_auto(ptr) A(ptr)
int main ()
{
char *a = (char*)malloc(sizeof(char)),*b = (char*)malloc(sizeof(char));
make_auto(a);
make_auto(b);
return 0;
}
Will it always call constructor and destructor of A? Or will compiler optimize this code in any case and delete A(ptr) calls, because it can think that it will not be used more.
UPD:
I know about boost and std::auto_ptr. I have own memory manager that is controlling fragmentation of memory and helps to avoid memory leaks. Now I want to "teach" my memory manager to create auto_ptrs like it is doing in boost and stl.
UPD2:
Here is complete code, that i'm using and that i thought is working correct:
class AutoPtr
{
private:
void *ptr;
Application *app;
public:
AutoPtr(Application *_app,void *a)
{
printf("constructor called\n");
ptr = a;
app = _app;
}
~AutoPtr()
{
fast_free(app,ptr);
printf("destructor called\n");
}
};
#define make_auto_ptr(app,ptr) AutoPtr(app,ptr)
static void AutoPtrTest1()
{
test_declare_app
char *a = fast_alloc(app,char,20);
char *b = fast_alloc(app,char,11);
{
make_auto_ptr(app,a);
make_auto_ptr(app,b);
}
test_free_app
printf("Autoptrtest1 passed\n");
}
Output:
constructor called destructor called constructor called destructor called Autoptrtest1 passed
So it doesn't work correct as i thought (i didn't check destructor calls). But it calls constructors twice as i said before . How to change make_auto_ptr for auto-declaring auto-ptrs?
Nothing happens, because your code is ill-formed. A(a); and A(b); declare a and b. Since a has already been declared, and A in any case has no default constructor, the compiler shall emit a diagnostic.
If you fix these issues, then the compiler is allowed to optimize away these, if the malloc and free you are using are the Standard libraries' functions, because that code really has no observable side effects.
An optimizing compiler should know about the special meaning of malloc and free, and I wouldn't be surprised to see it optimize this away. But for whatever reasons there might be, I can also imagine the compiler doesn't optimize it away. It really depends on your compiler and the flags it uses, but the Standard definitely allows it to optimize here.
Here is the code that clang -O2 -emit-llvm -S main1.cpp -o - outputs:
define i32 @main() nounwind {
ret i32 0
}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With