By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,820 Members | 1,189 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,820 IT Pros & Developers. It's quick & easy.

confusion..

P: n/a
class myPoly
{
private:
int nv;
double *x, *y;
int *p;

public:
myPoly()
{
x = new double (0);
y = new double (0);
p = new int (0);
nv = 0;
}

myPoly(int n) // number of vertices
{
nv = n;
}

~myPoly()
{
delete x;
delete y;
delete p;
}

void Draw()
{
Read("poly.dat");
for ( int k = 0; k<nv ; k++)
{
int p2 = abs(*p);
if (p2 == nv)
{
for (int l = 0; l<nv;l++)
{
if (*p>0)
{
glBegin(GL_LINES);
glVertex2i(*x,*y);
}
}
glEnd();
}
}
}
}
this is my class, and I wonder how come my pointer doesn't point to the
allocated memory?
the nv determines the allocation of memory of each x,y obtained from
the file.

Jul 23 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Mona wrote:

class myPoly
{
private:
int nv;
double *x, *y;
int *p;

public:
myPoly()
{
x = new double (0);
y = new double (0);
p = new int (0);
nv = 0;
}

myPoly(int n) // number of vertices
{
nv = n;
}

~myPoly()
{
delete x;
delete y;
delete p;
}

void Draw()
{
Read("poly.dat");
for ( int k = 0; k<nv ; k++)
{
int p2 = abs(*p);
if (p2 == nv)
{
for (int l = 0; l<nv;l++)
{
if (*p>0)
{
glBegin(GL_LINES);
glVertex2i(*x,*y);
}
}
glEnd();
}
}
}
}
this is my class, and I wonder how come my pointer doesn't point to the
allocated memory?
the nv determines the allocation of memory of each x,y obtained from
the file.
Well, nothing in your code gives a hint of what you actually want to do.
From the part you posted, everything seems to suggest that this
class wants to hold only *one* x/y coordinate.

.... x = new double (0); ....
This allocates *1* double, and initializes it with 0.0

.... delete x; ....
This deletes *1* double

.... glVertex2i(*x,*y); ....
This puts *1* point coordinate into OpenGL. Since neither x nor y get altered anywhere
you do this a number of times (dependend on the exact values of nv and *p

.... Read("poly.dat");

....
You don't show the implementation of that, but I guess that it does some memory allocations.
So when asking the question: Why your pointer doesn't point to the allocated memory, you
should look in this function, because that function will have to allocate the memory
when the file gets read.

class myPoly
{
private:
int nv;
double *x, *y;
int *p;

public:
myPoly()
{
x = NULL;
y = NULL;
p = NULL;
nv = 0;
}
void myPoly(int n) // number of vertices
{
delete [] x; // realease the previously allocated arrays
delete [] y;
delete [] p;

// and allocate new ones, which reflect the required number of vertices
nv = n;

x = new double [ nv ];
y = new double [ nv ];
p = new int [ nv ];

// better initialize the arrays here with some valid values. What that values
// are is up to you.
}

~myPoly()
{
delete [] x;
delete [] y;
delete [] p;
}

void Draw()
{
// I could not figure out, what exactly your original draw function wants do
// to. So I wrote a new one which most likely does what I think you want to do
//
// Also: Why a function "Draw" has to read some data from a file is not understandable
//
// Read("poly.dat");

glBegin(GL_LINES);
for ( int k = 0; k<nv ; k++)
{
glVertex2i( x[k], y[k] );
}
glEnd();
}
};
From the posted snippets it seems that your experience with dynamic allocation is
very weak. So why don't you use std::vector for all of that and safe yourself the
hassle of dynamic allocations until your C++ knowlege gets better and you actually
have no other choice then to go through all of this.

Also note:
There are literally a gazillion things that can go wrong when doing graphics.
So trying to learn C++ and doing graphics at the same time isn't a very good idea.
May I suggest a step-by-step plan.
You first step is: read the polygon and output the numbers you read from the file
in plain text through std::cout. In this way you can easily check if the read code
works as expected, if your memory management is correct and things like that.
Only after that works perfectly switch to OpenGL. In this way you know that
when you don't see anything in the graphics output that it was not because of
you not reading the file correctly or that something is wrong in the memory management
and so on. Then you can concentrate on the graphics aspect of your program: Is
OpenGL initialized correctly? Do I have a valid drawing space? Is the coordinate
system setup correctly? Do I draw outside the drawing space? Do I draw with black
ink on a black piece of paper? Things like that.

You need to learn to walk before you can learn to run. Doing graphics is not
only running, but is running the New York marathon.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 23 '05 #2

P: n/a
Karl Heinz Buchegger wrote:

<snip>
class myPoly
{
private:
int nv;
double *x, *y;
int *p;

public:
myPoly()
{
x = NULL;
y = NULL;
p = NULL;
nv = 0;
}
void myPoly(int n) // number of vertices
{
delete [] x; // realease the previously allocated arrays
delete [] y;
delete [] p;


<snip>

Karl, usually I like your posts, but this one, I simply don't
understand. Why delete members in a *constructor*?

--
Peter
Jul 23 '05 #3

P: n/a
Peter Kragh wrote:
Karl Heinz Buchegger wrote:

<snip>
class myPoly
{
private:
int nv;
double *x, *y;
int *p;

public:
myPoly()
{
x = NULL;
y = NULL;
p = NULL;
nv = 0;
}
void myPoly(int n) // number of vertices
{
delete [] x; // realease the previously allocated arrays
delete [] y;
delete [] p;

<snip>

Karl, usually I like your posts, but this one, I simply don't
understand. Why delete members in a *constructor*?


With all due respect to both o'yous, it's not a constructor. Constructors
don't have return value types...

I wonder what Karl wanted to demonstrate (and whether it actually *was*
Karl posting that "code"). The use of assignment instead of initialiser
lists is another indicator of a rather strange behavior of *our* Karl,
which might suggest something's wrong there...

V
Jul 23 '05 #4

P: n/a
Victor Bazarov wrote:

With all due respect to both o'yous, it's not a constructor. Constructors
don't have return value types...


Missed that one. However, it made me wonder. Is it legal to name a
member function the same name as the class? I searched the standard, but
couldn't find any limitations.

I tried to compile it, and both my compilers choked on it. Comments?

--
Peter
Jul 23 '05 #5

P: n/a
Peter Kragh wrote:
Victor Bazarov wrote:

With all due respect to both o'yous, it's not a constructor.
Constructors
don't have return value types...

Missed that one. However, it made me wonder. Is it legal to name a
member function the same name as the class? I searched the standard, but
couldn't find any limitations.

I tried to compile it, and both my compilers choked on it. Comments?


A member function that has the same name as the class is a constructor
(by inversion of the definition of a constructor). Constructors shall not
have return value types.

V
Jul 23 '05 #6

P: n/a
Peter Kragh wrote:

Karl Heinz Buchegger wrote:

<snip>
class myPoly
{
private:
int nv;
double *x, *y;
int *p;

public:
myPoly()
{
x = NULL;
y = NULL;
p = NULL;
nv = 0;
}
void myPoly(int n) // number of vertices
{
delete [] x; // realease the previously allocated arrays
delete [] y;
delete [] p;
<snip>

Karl, usually I like your posts, but this one, I simply don't
understand. Why delete members in a *constructor*?


Because I didn't notice that it was a constructor. That's why
I also added the return type of void which of course is nonsense
for a constructor. I was a little bit in a hurry. Sorry for that.

--
Peter

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 23 '05 #7

P: n/a
Victor Bazarov wrote:

Peter Kragh wrote:
Karl Heinz Buchegger wrote:

<snip>
class myPoly
{
private:
int nv;
double *x, *y;
int *p;

public:
myPoly()
{
x = NULL;
y = NULL;
p = NULL;
nv = 0;
}
void myPoly(int n) // number of vertices
{
delete [] x; // realease the previously allocated arrays
delete [] y;
delete [] p;

<snip>

Karl, usually I like your posts, but this one, I simply don't
understand. Why delete members in a *constructor*?


With all due respect to both o'yous, it's not a constructor. Constructors
don't have return value types...

I wonder what Karl wanted to demonstrate (and whether it actually *was*
Karl posting that "code").


Yes it was me.
But it wasn't my best day. I had a little bit of stress in my own
project. Usually I answer posting during compiler runs but this time
I didn't pay close attention to the details. Actually I was thinking what
all those loops in the Draw() function could be intended for and did the
rest mechanically.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 23 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.