how to work with pointers and references c++ and VALGRIND?

I have the following code:

[test.h]
class MyClass
{
public:
    string Name;
    MyClass();
    void method(MyClass &obj);
}

[test.cpp]
void MyClass::method(MyClass &obj)
{
    cout<<obj.Name<<endl;
}

[main.cpp]
#include "test.h"

void main()
{
    MyClass *class = new MyClass();
    class->Name="Foo";
    class->method(*class);

    delete class;
}

I would like to ask if this is the correct way for having method that contain objects send by reference. Did I correctly deallocate the memory allocated? I am asking this because for a similar example when testing wit valgrind I have this: conditional jump or mo开发者_开发技巧ve dependents on unitialised value(s).

I am working in c++ under Ubuntu. My compiler is g++. APPRECIATE!! EDIT!!

WHY CAN'T I PUT INT VALUE=0; in the test.h file?!

---

class is a reserved word in C++, you cannot use it as the name of your variables.

Moreover, there's no need to allocate the object dynamically unless you explicitly require that. If possible, just allocate it automatically:

MyClass x;
x.Name = "Foo";
x.method(x);

---

Why can't I put int VALUE = 0; in the test.h file?

If VALUE is part of class variables, then it is not allowed to initialize as a part of class declaration. Instead, constructor initializer list should be used.

// Constructor

MyClass :: MyClass() : VALUE(0) 
                  // ^^^^^^^^^^^ Initializer list
{ }

How ever, if VALUE is defined as a global variable then this too leads to problems. When you include test.h in multiple source files, it leads to multiple declaration errors. Define it in a source file and access across multiple translation units using the extern key word.

---

compile => valgrind g++ ./main and see if there is any memory leak.

be sure you have already installed valgrind, in other case you should install it by apt-get or ubuntu software center.

hope this helps..

---

I find it strange the compiler didn't yell that class is a reserved keyword.

Anyway, using method(MyClass &obj)is not a good idea in my opinion, since you already have a pointer, which is dereferences, and then taken by reference again. I just don't know what it is pointing at, and that may be why the warning appears.

Try the following and see if it still has the same warnings, I can't test it right now:

test.h
class MyClass
{
public:
   string Name;
    MyClass();
    void method(MyClass* obj);
}

test.cpp
void MyClass::method(MyClass* obj)
{
    cout<<obj->Name<<endl;
}

main.cpp
#include "test.h"

void main()
{
    MyClass *class = new MyClass();
    class->Name="Foo";
    class->method(class);

    delete class;
}

---

Looks like there is no memory leaks and use of uninitialized values. Name member will be initialized by it's default constructor. The errors reported by Valgrind may come from Standard Library or some other library you maybe used. Also note that this error not always indicate the bug in code.

---

it is correct. The only way to mess things up is by forgetting a delete, deleting more than once, or a mismatch between new and delete with or without brackets. However there are a few things to note:

In your exmpmle it is fine to pass the argument as a const ref, because you don't change it.

void method(const MyClass &obj) const;

and also in the cpp accordingly:

void MyClass::method(const MyClass &obj) const{ ... }

You don't need to allocate the object on the heap by using new at all. In fact you can almost always use sytax like that:

void main()
{
    MyClass obj; // <- allocates it on the stack
    obj.Name="Foo";
    obj.method(obj);
}
// class is properly deleted when it goes out of scope

Whenever you habe lots of raw data, classical arrays in particular, those usually are class members (and even this is a rare case, because of the awesome stl containers like vector) and you let that class deal with the memory management. This again allows creating those classes on the stack, cleaning up by letting them go yout of scope and teh class will take care that the huge amount of data is actually stored on the heap.

So while your code is correct, you seldom actually have to worry about that because you