Getting into C++, Weird Problem [SOLVED]

starfreakclone · 2010-04-29 14:20:45

So I'm getting into C++, I have a good understanding about how OOL work because I programmed in C# a whole lot and I've done some Java. Anyway I don't know why this doesn't work in C++:

#include <iostream>
using namespace std;

class Rectangle
{
   int *x, *y;
  public:
   Rectangle (){ x = new int; y = new int;
                *x = 1;      *y = 0; }
   Rectangle(int,int);
   ~Rectangle();
   int area();
   friend Rectangle duplicate(Rectangle);
};

Rectangle::Rectangle(int a, int b)
{
   x = new int;
   y = new int;
   *x = a;
   *y = b;
}

Rectangle::~Rectangle()
{
   delete x;
   delete y;
}
int Rectangle::area ()
{
   return *x * *y;
}

Rectangle duplicate(Rectangle r)
{
   Rectangle tmp;
   cout << *(tmp.x) << endl;
   *(tmp.x) = *(r.x) * 2;
   *(tmp.y) = *(r.y) * 2;
   cout << *(tmp.x) << endl;
   return tmp;
}

int main()
{
   int a, b;
   cout << "Enter x: ";
   cin >> a;
   cout << "Enter y: ";
   cin >> b;
   Rectangle r(a, b);
   Rectangle cp;
   cp = duplicate(r);
   cout << "Area: " << cp.area() << endl;
   return 0;
}

It seems like it should work but I think the default constructor is messing it up somehow because when I step through it with gdb and print out *(tmp.x) it turns out to be mem address of 0x4 which doesn't seem valid, but it still is somehow able to print the right value at that last cout in the duplicate function ¯\(°_O)/¯

Anyway, any help is much appreciated.

Last edited by starfreakclone (2010-04-29 15:48:37)

drcouzelis · 2010-04-29 15:10:26

Please describe "doesn't work".

I don't even know how

cout << *(tmp.x) << endl;

is possible, since "x" is private in "Rectangle".

starfreakclone · 2010-04-29 15:14:58

drcouzelis wrote:

Please describe "doesn't work".
I don't even know how
cout << *(tmp.x) << endl;
is possible, since "x" is private in "Rectangle".

Well that works because duplicate is a friend of class Rectangle so it's able to see those variables. The thing that doesn't work it returning the tmp Rectangle to cp, for some reason I think that tmp is destructed before its returned and cp still has the null constructor values. I have no idea why this is happening.

falconindy · 2010-04-29 15:28:48

Why are you using pointers for non-arrayed primitives?

Why aren't you using the constructor for creating the new rectangle in duplicate and instead using 'friend'? Why isn't duplicate a method of the class?

You're making things needlessly complex.

Rectangle Rectangle::duplicate() {
  return Rectangle(this->x * 2, this->y * 2);
}

That's all your duplicate method needs to be once you get rid of the silly pointers.

draugdel · 2010-04-29 15:37:21

I think that´s what´s going on: The default assignment operator copies the members. In this case it copies x and y, which are pointers. Then the temporary Rectangle gets deleted, which deletes x and y. Then you try to access them. This won´t work.

1. Don´t use pointers, if you don´t need them!
2. If you think you need pointers, think again.
3. If you really need them, write a copy constructor and an assignment operator.

starfreakclone · 2010-04-29 15:37:28

falconindy wrote:

Why are you using pointers for non-arrayed primitives?
Why aren't you using the constructor for creating the new rectangle in duplicate and instead using 'friend'? Why isn't duplicate a method of the class?
You're making things needlessly complex.
Rectangle Rectangle::duplicate() {
  return Rectangle(this->x * 2, this->y * 2);
}
That's all your duplicate method needs to be once you get rid of the silly pointers.

I know that and I did make a method exactly like that in a similar program but I was getting used to the idea of friends and how they work first. I also wanted to get used to the new keyword and use it to allocate space for a pointer. What I am trying to understand is why its doing what its doing. I want to know why cp.area() comes out to be 0, when clearly at the end of the duplicate function *(tmp.x) turns out to be 6 if I enter 3 as an initial parameter of r.

starfreakclone · 2010-04-29 15:47:58

draugdel wrote:

I think that´s what´s going on: The default assignment operator copies the members. In this case it copies x and y, which are pointers. Then the temporary Rectangle gets deleted, which deletes x and y. Then you try to access them. This won´t work.
1. Don´t use pointers, if you don´t need them!
2. If you think you need pointers, think again.
3. If you really need them, write a copy constructor and an assignment operator.

Shoot, I totally forgot about that, the *x and *y are passed to cp by reference, and when the destructor is called their references are gone, XD I totally should've caught that. SOLVED.

Last edited by starfreakclone (2010-04-29 16:40:49)

Cyrusm · 2010-04-29 15:52:45

draugdel wrote:

I think that´s what´s going on: The default assignment operator copies the members. In this case it copies x and y, which are pointers. Then the temporary Rectangle gets deleted, which deletes x and y. Then you try to access them. This won´t work.
1. Don´t use pointers, if you don´t need them!
2. If you think you need pointers, think again.
3. If you really need them, write a copy constructor and an assignment operator.

I tend to disagree, pointers are one of the biggest advantages to c/c++! however, one should understand them and use them responsibly.

Trent · 2010-04-29 16:28:21

I would go further. Don't use OOP! It's marketed as some kind of be-all end-all solution to everything but in my experience its primary function is to make small projects more confusing. I don't use OOP for anything less than 1000 lines, and when it becomes apparent that a project is going in that direction, it's better to stick with just the minimum necessary. I.e., there's no need to use all the OOP techniques you know unless you encounter a specific problem that requires each one.

Of course, programming is about making good design decisions, and nobody can do that for you. All I'm saying is that OOP is usually, for the projects I work on, a bad design decision. (I write mostly Perl.)

starfreakclone · 2010-04-29 16:38:39

Trent wrote:

I would go further. Don't use OOP! It's marketed as some kind of be-all end-all solution to everything but in my experience its primary function is to make small projects more confusing. I don't use OOP for anything less than 1000 lines, and when it becomes apparent that a project is going in that direction, it's better to stick with just the minimum necessary. I.e., there's no need to use all the OOP techniques you know unless you encounter a specific problem that requires each one.
Of course, programming is about making good design decisions, and nobody can do that for you. All I'm saying is that OOP is usually, for the projects I work on, a bad design decision. (I write mostly Perl.)

I think OOP is extremely useful for a lot of things. For instance, can you imagine programming a simple tower defense game in a non OO language? That would suck! I need classes for individual entities, towers and weapons, it would be downright insane not to use OO in that type of situation. I do understand why one would never use OO in smaller things like command line utils and things of the like, but for projects like gaming, large scale projects and any type of state machine, you'd be killing yourself trying to implement it in anything other than a OOL.

the_isz · 2010-04-29 16:48:34

In my eyes, you shouldn't write a duplicate-function at all, because that's what
copy constructors and assignment operators are there for. That's unless you want
to create an abstract factory, but I think that'll be some time until you get to
that point

Also, you really should make members private and write accessor functions (get-
and set-functions), but I'll skip those in the example below for the sake of
brevity. They aren't necessary for the example anyway.

#include <iostream>

class Rectangle
{
  public:
    Rectangle ()
    : x_(1)
    , y_(0) {}

    Rectangle (const int x, const int y)
    : x_(x)
    , y_(y) {}

    Rectangle (const Rectangle& other)
    : x_(other.x_)
    , y_(other.y_) {}

    Rectangle& operator= (const Rectangle& other)
    {
      x_ = other.x_;
      y_ = other.y_;

      return *this;
    }

    int area () const
    {
      return x_ * y_;
    }

  private:
    int x_;
    int y_;
};

int main()
{
  using namespace std;

  int a, b;
  cout << "Enter x: ";
  cin >> a;
  cout << "Enter y: ";
  cin >> b;
  Rectangle r(a, b);
  Rectangle cp(r); // duplicate using copy constructor
  // Rectangle cp = r; // duplicate using assignment operator;
  cout << "Area: " << cp.area() << endl;
  return 0;
}

Have fun learning C++!

draugdel · 2010-04-29 18:46:19

Cyrusm wrote:

draugdel wrote:
I think that´s what´s going on: The default assignment operator copies the members. In this case it copies x and y, which are pointers. Then the temporary Rectangle gets deleted, which deletes x and y. Then you try to access them. This won´t work.
1. Don´t use pointers, if you don´t need them!
2. If you think you need pointers, think again.
3. If you really need them, write a copy constructor and an assignment operator.
I tend to disagree, pointers are one of the biggest advantages to c/c++! however, one should understand them and use them responsibly.

We meant the same thing: Use pointers where you really need them.

In this example I don´t really see the benefit of using pointers but instead only their disadvantages: slower, more complex, more memory consumption (on most architectures an int pointer is the same size as an int -> 2 times more memory needed).

In the end it comes down to using the right tool for the right job. Using the KISS approach helps a lot.

Last edited by draugdel (2010-04-29 18:49:45)

Trent · 2010-04-29 19:33:01

starfreakclone wrote:

I think OOP is extremely useful for a lot of things. For instance, can you imagine programming a simple tower defense game in a non OO language? That would suck! I need classes for individual entities, towers and weapons, it would be downright insane not to use OO in that type of situation.

You don't need classes. You need objects, and data abstraction. Those things have been around for decades longer than OOP.

I do understand why one would never use OO in smaller things like command line utils and things of the like, but for projects like gaming, large scale projects and any type of state machine, you'd be killing yourself trying to implement it in anything other than a OOL.

Ever played NetHack?

Data abstraction, information hiding, aggregate data types, composition relationships, code reuse, even operator overloading and some forms of polymorphism, and more things I don't care to mention, are not specific to object oriented design. It's possible to use all of the above in a language that does not explicitly support OOP, e.g. C. What I'm saying is that the ground-up design of programs using OO techniques often causes more harm than good, quite simply because most programs are not OO from the ground up.

I was going to go on, but I'm going to drop the topic because this isn't the appropriate place for it.

Arch Linux

#1 2010-04-29 14:20:45

Getting into C++, Weird Problem [SOLVED]

#2 2010-04-29 15:10:26

Re: Getting into C++, Weird Problem [SOLVED]

#3 2010-04-29 15:14:58

Re: Getting into C++, Weird Problem [SOLVED]

#4 2010-04-29 15:28:48

Re: Getting into C++, Weird Problem [SOLVED]

#5 2010-04-29 15:37:21

Re: Getting into C++, Weird Problem [SOLVED]

#6 2010-04-29 15:37:28

Re: Getting into C++, Weird Problem [SOLVED]

#7 2010-04-29 15:47:58

Re: Getting into C++, Weird Problem [SOLVED]

#8 2010-04-29 15:52:45

Re: Getting into C++, Weird Problem [SOLVED]

#9 2010-04-29 16:28:21

Re: Getting into C++, Weird Problem [SOLVED]

#10 2010-04-29 16:38:39

Re: Getting into C++, Weird Problem [SOLVED]

#11 2010-04-29 16:48:34

Re: Getting into C++, Weird Problem [SOLVED]

#12 2010-04-29 18:46:19

Re: Getting into C++, Weird Problem [SOLVED]

#13 2010-04-29 19:33:01

Re: Getting into C++, Weird Problem [SOLVED]

Board footer