1

I'm trying to thoroughly learn and understand the proper designs and techniques of freeing memories.

I wrote a very simple test class and a main function:

#include <iostream> 
using namespace std;

class TestClass{
public:
  bool *state;
  void setState (bool b) {*state = b;}
  TestClass(){state = new bool(false);
              cout << "new object created in heap;state is pointing to it." << endl;}
  ~TestClass(){delete state; 
               state = NULL;
               cout << "object deleted. " << endl;
               cout << "pointer variable set to NULL."<< endl;
               cout << "memory should be freed." << endl;}
};

int main(void){
  TestClass obj; //default constructor called automatically
  cout << "before:" << * (obj.state) << endl;
  obj.setState(true);
  cout << "after:" << * (obj.state) << endl;
  return 0;
  //destructor called automatically to destroy obj
}

As you see, I wrote a testClass with a Boolean pointer variable, a default constructor, a void function that changes state, and a destructor.

The output seems to work very well.

However, when I run this on valgrind to check memory leak, it says possibly lost: 72 bytes in 3 blocks. Though my definitely lost bytes and indirectly lost bytes were both 0(good).

I'd like to know what more I need to do to fix the possibly lost, or how to change my program overall to make it better in the first place.

Current update: I'm checking out how to wrap a function, smart pointer, and rule of five/zero.

Current Update 2: it's definitely the valgrind installed on my mac that has all these problems...Should immediately uninstall.

here's my actually reliable valgrind check:

==17388== 
==17388== HEAP SUMMARY:
==17388==     in use at exit: 0 bytes in 0 blocks
==17388==   total heap usage: 2 allocs, 2 frees, 72,705 bytes allocated
==17388== 
==17388== All heap blocks were freed -- no leaks are possible
==17388== 
==17388== For counts of detected and suppressed errors, rerun with: -v
==17388== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
xsx
  • 163
  • 1
  • 8
  • Post compilable code please. One of the `testClass` is improperly capitalized. – user202729 Feb 08 '18 at 06:59
  • 2
    See [What is a smart pointer and when should I use one?](https://stackoverflow.com/q/106508/1896169). – Justin Feb 08 '18 at 06:59
  • I have a hard time seeing one bool pointer inflating to 72 bytes. You may be looking at something else. – user4581301 Feb 08 '18 at 07:00
  • user202729: sorry I messed up during the copy and pasting from my editor to here. Now should be compilable. – xsx Feb 08 '18 at 07:00
  • ... the code looks perfect. I have no idea what can be wrong. Probably `valgrind` is wrong. – user202729 Feb 08 '18 at 07:04
  • OT: [Why is “using namespace std” considered bad practice?](https://stackoverflow.com/q/1452721/1896169), please learn to indent your code consistently (the indentation for your constructor and destructor is insane), [don't use `std::endl`](https://stackoverflow.com/a/214076/1896169), don't use `int main(void)` (that's a C-ism, just write `int main()`), and you can omit the `return 0;` from `main` (it's implied) – Justin Feb 08 '18 at 07:05
  • Read about [The Rule of Three](https://stackoverflow.com/questions/4172722/what-is-the-rule-of-three) and [its extension for C++11](https://stackoverflow.com/questions/4782757/rule-of-three-becomes-rule-of-five-with-c11). – R Sahu Feb 08 '18 at 07:06
  • 1
    I don't think you have a memory leak, although it's hard to be confident as you aren't using the Rule of 3. IIRC, valgrind might give the leak report before the program actually terminates. What if you wrapped every line of main but the `return 0;` in a block, to force the destructor to run earlier? – Justin Feb 08 '18 at 07:08
  • Learn the rule of three, then the rule of five and finally the rule of zero (google these terms). Stick to the last one. – n. m. could be an AI Feb 08 '18 at 07:11
  • 3
    In modern C++: Use containers and smart pointers. Not manual `new`/`delete`. – Jesper Juhl Feb 08 '18 at 07:11
  • 2
    In c++11 and later, the good practice doesn't use the `new` operator at all. You can use **smart pointers** instead. But in this case, your code looks like a right. Can show the Valgrind output? – voltento Feb 08 '18 at 07:11
  • 2
    As for the valgrind report, try running a hello world program with no dynamic allocations and see what happens. – n. m. could be an AI Feb 08 '18 at 07:14
  • 1
    On my system valgrind reports zero lost bytes in your program, so there must be something wrong with either your installation or your procedures. – n. m. could be an AI Feb 08 '18 at 07:19
  • Maybe it's the valgrind installed on my mac that has problems. I will look to fix that first – xsx Feb 08 '18 at 07:24
  • Just don't use `operator new.` It is radioactive. There are plenty of STL containers that handle memory management automatically, notably std::vector. On the rare occasions when you do really need pointers, use `std::make_unique` or `std::make_shared`. – Jive Dadson Feb 08 '18 at 07:26

0 Answers0