Jump to content
  • Advertisement
Sign in to follow this  
jfalstaff

Is this a bad practice for defining a constructor?

This topic is 2515 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is it bad practice to define a constructor in terms of its mutators? I have this class:


class Line
{
private:
Point p[2];
protected:
public:
Line();
Line( Point p1, Point p2 ) { start( p1 ); end( p2 ); }
Line( const Line & );
void start( Point &point ) { p[0].X(point.X()); p[0].Y(point.Y()); p[0].Z(point.Z()); }
void end( Point &point ) { p[1].X(point.X()); p[1].Y(point.Y()); p[1].Z(point.Z()); }
};



I don't know if I've ever seen a constructor defined like this: so I have to wonder if this is a bad practice.

Line( Point p1, Point p2 ) { start( p1 ); end( p2 ); }

so I have to wonder if this is a bad practice.

Share this post


Link to post
Share on other sites
Advertisement
What ever works for you buddy. Some people may jump up and down saying NO NO dont do that, but I've found over the years that there is no right or wrong way, code the way you like as long as it compiles and runs :-) If your working in a team that may be a different story.

Share this post


Link to post
Share on other sites
It's not bad in and of itself, but I have to wonder why you just don't use = to assign the values and why your start() and end() functions use non-const references.

Share this post


Link to post
Share on other sites
It's fine as long as the methods that you're calling from the constructor are written in such a way that they will still work on a half-constructed class.

As a side note, you're inconsistent with the way you're passing Points around -- your constructor accepts them by value, but your setter functions accept them by (non const) reference.class Line
{
private:
Point p[2];
public:
Line( const Point& p1, const Point& p2 ) { start( p1 ); end( p2 ); }
void start( const Point& point ) { p[0] = point; }
void end( const Point& point ) { p[1] = point; }
};

Share this post


Link to post
Share on other sites
Truthfully guys, OO C is really difficult for me to grasp. I started with procedural C in '82 and it's simple for me to understand how it works, but OO C is freaking extending the development of simple utils into major projects by virtue of trying to learn OO C as I go.

I'll look at it closer and see what I can do, but I'm stumbling along here. I understand enough of it to use it, but not develop my own. I'm constantly getting tripped up on accesibility and other aspects of OO C. As far as a team is concerned, I've never been able to garner support for the project I want to do, so I expect to do that all on my own.

Share this post


Link to post
Share on other sites

Truthfully guys, OO C is really difficult for me to grasp.


<nitpick>OO C and OO C++ are two very different things (seeing as C and C++ are very different things). I'm going to assume you meant OO C++, simply due to the fact that you're using the "class" keyword, amongst other C++-only features.</nitpick>

It's ok if you're stumbling though! Nobody figured out the beast of C++ in a day (in fact, I wonder if anyone has ever truly figured out the beast of C++).

Share this post


Link to post
Share on other sites
Ok, I see OO C and C++ as synonymous. Back in the day, I would have defined all this simply as:

typedef struct
{
double x, y, z;
} POINT, VERTEX;
typedef struct
{
POINT p[2];
} LINESEG, VECTOR;
typedef struct
{
POINT p[3];
VECTOR normal;
} PLANE, TRIANGLE;


Then extend/expand as I needed, so perhaps a point/slope form structure for LINE, RAY, etc.

The procedures for this seemed so natural.

Share this post


Link to post
Share on other sites
For lines, points, vectors or other similar types there's really no need to go full blown class. Just make a POD type and be done with it. Where the whole class mechanism comes in play is when you have data types that have invariants. Then you have constructors that create instances that satisfy invariants and member functions that can modify the class while preserving invariants and then non-members don't need to worry about accidentally ruining class state.

Share this post


Link to post
Share on other sites

For lines, points, vectors or other similar types there's really no need to go full blown class. Just make a POD type and be done with it. Where the whole class mechanism comes in play is when you have data types that have invariants.


I think I understand. I want to make a list of triangles that define a closed 3D geometry, Then calculate spans that find the volume. From what you just said, it seems the triangles would be the classes/objects but keep the points, vectors/lines as structs within the class, since I don't want to change the triangles past the initial scaling upon load.

Share this post


Link to post
Share on other sites
I don't know what kind of semantics you'd want from your triangles, so I couldn't say whether or not they would be better implemented as a POD type or a full-scale class. If you want a non-mutable type then it's quite possible that your triangle type could have all members both public and const.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!