0

I have the following exercise:

Add code to make it run properly.

class MyInt
{
public:

private:
    int* MyValue;
}

int main(int argc,char** argv)
{
 MyInt x(1);
 ...//a bit more code where the actual value of x is going to be used.
 return 0;
}

I added as a private property

int val;

and a public constructor

Myint(int x)
{
    val = x;
    MyValue = &val;
}

I added the int val as a way for the constructor to assign to MyVal an address of an object that is not temporary, as the x.

Is there a neat(er) way to answer this exercise?

Kae
  • 279
  • 2
  • 10

3 Answers3

3

I don't see anything in your original problem statement that requires the pointer to be initialized to the address of an int. The minimal code required to fix the example would be to add a constructor that takes an int, and initialize MyValue to nullptr.

class MyInt
{
public:
    MyInt(int) {}
private:
    int* MyValue = nullptr;
};

int main(int argc,char** argv)
{
 MyInt x(1);
 return 0;
}

If your compiler doesn't support C++11 then

class MyInt
{
public:
    MyInt(int) : MyValue(NULL) {}
private:
    int* MyValue;
};
Praetorian
  • 106,671
  • 19
  • 240
  • 328
  • This solution is correct but I wanted the code to have a meaningful output as well. The given problem actually have more stuff in the main and the value initialized in the constructor is used later for further computation. Let me add it to the statement. – Kae Jul 21 '14 at 20:42
  • 1
    Actually, adding the 0-init for the pointer member is not neccessary. – Deduplicator Jul 21 '14 at 20:45
  • @Deduplicator It's not necessary, but usually considered good style so that it's clear that the value was intentionally left set to ``NULL`` – aruisdante Jul 21 '14 at 20:46
  • @Deduplicator I don't think it's that cut and dry. What if the uninitialized pointer happens to hold some trap representation? Will the implicitly generated constructors and assignment operators trip over something like that? I don't know, and don't really care to dig through the standard to figure it out. It's best not to leave pointers uninitialized. – Praetorian Jul 21 '14 at 20:49
  • @aruisdante: So, it is good style to suppress compiler warnings? Doing unneccessary work is not good style, especially if it suppresses useful warnings. Also, it somehow conflicts with the rest of the answer, which tries to limit itself to the absolute minimum to fulfill the letter of the question (though not neccessarily the spirit). Regarding the indeterminate value the member retains: It's not a problem here. – Deduplicator Jul 21 '14 at 20:49
  • @Deduplicator No, suppressing compiler warnings is a terrible idea. Why would you get that idea from me saying it's good style to explicitly initialize an unused pointer to ``NULL``? – aruisdante Jul 21 '14 at 20:52
  • @Praetorian, They would "fail" (UB) if used to read from the pointer, but nothing like that happens in your example. – chris Jul 21 '14 at 20:59
1

Another way:

MyInt(int x) : MyValue(new int(x)) {}

This doesn't require the additional member. However, you have to make sure that you deallocate the memory in the destructor.

~MyInt() { delete MyValue; }
R Sahu
  • 204,454
  • 14
  • 159
  • 270
  • In this solution, how should I understand the int created by new int(x)? Where is it stored? How can it be accessed? It is not part of the object MyInt, isn't it? – Kae Jul 21 '14 at 20:57
  • @Karene, It's stored in the address that `MyValue` holds. It's accessed through `MyValue`. – chris Jul 21 '14 at 20:59
  • @Karene, `new int(x)` allocates memory for an `int`, initializes that memory with `x`, and returns that memory. You can access the memory using `MyValue`. – R Sahu Jul 21 '14 at 21:00
  • You need to add more code to fix the memory leak you introduced. – juanchopanza Jul 21 '14 at 21:10
  • Another question. This memory where new int(x) is stored, does it belong to some object (MyInt, myValue, or other)? Maybe it doesn't have to be the case that everything in C++ must conceptually belong to certain object. – Kae Jul 21 '14 at 21:10
  • @juanchopanza, I had that caveat in the textual part of the answer. I added the code now. – R Sahu Jul 21 '14 at 21:13
  • @Karene, `MyInt.MyValue` points to that memory. Dynamic memory management is a large subject on its own. However, you have the right hunch about memory conceptually belonging to a certain object. – R Sahu Jul 21 '14 at 21:16
  • @RSahu right hunch conceptually, wrong hunch in actuality, which is why you get memory leaks if you don't free at object deletion. – aruisdante Jul 21 '14 at 21:21
1

I'm not really sure why you want to store a pointer to an int inside a class, rather than just storing the value directly (and not have a pointer be the input to the constructor), but assuming you do actually want that, here's how you'd do it:

MyInt(int x):MyValue(new int(x)){}

But this is really, really terrible style, and you have to have a good reason for doing it. You also need to remember to free the pointer at class destruction:

~MyInt(){delete MyValue;}
aruisdante
  • 8,875
  • 2
  • 30
  • 37
  • It is an exercise. It is given as such and the statement allows me to *add* code only. – Kae Jul 21 '14 at 20:46