What's this doing on GD?....moved to proper forum
What's this doing on GD?....moved to proper forum
Some quick comments:
operator= should return Vector3D&, not Vector3D.
The + - * / operators should return a const Vector3D.
The length() function should be made const.
It is actually a good idea, not a retarded.ohh i wasn't getting at performance, it's just a retarded idea
Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling
no it isn't
I don't have an operator=.... I don't really think its needed, do you?Originally posted by Sang-drax
operator= should return Vector3D&, not Vector3D.
Just like this:Originally posted by Sang-drax
The + - * / operators should return a const Vector3D.
The length() function should be made const.
const Vector3D &Vector3D:perator+(const Vector3D &v) const;
?? Thanks for the input !
Do not make direct eye contact with me.
You have never worked on a large project with multiple designers, have you?Originally posted by Silvercord
In fact I think the private keyword should be removed from C++ because it is one of the most pointless and least useful keywords in existence...if anyone is dumb enough to need their own data hidden from you then you shouldn't be allowed to program or operate a motor vehicle
The idea of data hidden behind an interface is one of the singular best ways to prevent bugs. When you code, you create the interface first, and fully specify what each method should do. This interface is a promise to the other designers and anyone else who uses your class -- a promise that, barring some horrible oversight, these methods will always do what they are supposed to do, no matter what. Addition is OK, but deletion, or altering the effects of a methods, are no-nos.
This programming concept makes it easier to change one part without affecting anything else. Each class is a "black box" -- as long as the class performs its functions, who cares how it does it?
An example: Say I create a class and publically expose member variables, and other code uses those members. Now, later I realize for some efficiency reason, the mechanism I used to represent that data is inefficient and must be changed, or a last-minute change in requirements comes up. For example, say I used a red-black tree to map data, but then need to change it to use a hash table instead.
If I make any changes to the member variables, I have to change ALL the code that modifies them. I may have to hunt through hundreds of thousands of lines of code to find the changes that need to be made. Chances are, by making that one change, I will introduce many bugs.
By hiding implementation behind the public and protected interfaces, I can make as many optimizations/changes/corrections to the class, so long as those changes don't affect the results of any method (they may cause the methods to be more efficient, but the result of the call is the same). I can make ONE change, not a hundred changes, and my changes are limited to one source file, they don't span hundreds of files.
On large projects, and on projects with multiple designers, separating implementation and interface is absolutely necessary. As a group you fully specify the interface of every major class, and then divide up the work. Each person can work on their own classes, while knowing that, however the other designers might choose to implement things, they can trust the interface of the other classes.
Further, it allows better versioning -- an updated version of the class can be dropped in, and as long as the methods that made up the old interface are still intact (which a good versioning should enforce) the new version can be used with nothing more than one recompile.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
Originally posted by Silvercord
In fact I think the private keyword should be removed from C++ because it is one of the most pointless and least useful keywords in existence...You obviously have a lot to learn about C++ and object oriented programming.Originally posted by Silvercord
i think using a template class for something as basic as this is a bad idea.
[...]
ohh i wasn't getting at performance, it's just a retarded idea
Why do you think it is such a retarded idea? It doesn't obfuscate the code and it makes the type more useful and flexible.
Actually you do have an operator= And yes, I do think it is needed. With these kinds of classes, it is always good to mimic the behaviour of simple data types (thus my suggested changes above).Originally posted by Silvercord
I don't have an operator=.... I don't really think its needed, do you?
Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling
"const Vector3D", not "const Vector3D&"Originally posted by Lurker
const Vector3D &Vector3D:perator+(const Vector3D &v) const;
?? Thanks for the input !
Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling
Well yes, technically I do . But not an OVERLOADED one. I'll make it AGAIN...I took it out before (see the UPLOADED class).Originally posted by Sang-drax
Actually you do have an operator= And yes, I do think it is needed. With these kinds of classes, it is always good to mimic the behaviour of simple data types (thus my suggested changes above).
Do not make direct eye contact with me.
So this would be the prototype for the operator+ function:
const Vector3D operator+(const Vector3D &v) const
? Thanks !
Do not make direct eye contact with me.
I've edited the vector3D class files and also started work on a 3 by 3 matrix class. The files will be included in next few posts.
Do not make direct eye contact with me.
Matrix.cpp:
Do not make direct eye contact with me.
Matrix.h:
Last edited by Lurker; 11-15-2003 at 06:59 PM.
Do not make direct eye contact with me.
H.o.l.y C.r.a.p you guys need to calm down...drink some tea or something . For one I'm not really serious about removing the private keyword, lmao. I don't use it, but I'm not on a large project. Well, it is a huge project, but I'm the only developer. If it involved others, well I'd basically do what Cat desribed (interface vs implementation, don't obfuscate the two). I just found my own projects constantly needed accessor functions, which I thought were dumb, so I just basically made everything structures.
Again, calm down, I don't see anything negatively catastrophic with doing that, just seems you don't get anything good out of it, and doesn't seem necessary.Why do you think it is such a retarded idea? It doesn't obfuscate the code and it makes the type more useful and flexible.
you know i meant outside of the fact that you can assign objects of classes by value if they are the same data typeActually you do have an operator=
Lurker, would you like to see some math stuff from my own vector class, i.e some hard math stuff including arbitrary axis rotation, quaternions, and spherical coordinates, or the mirror vector function (flips a unit vector about a plane normal so the angle of incidence equals angle of reflection). You can AIM me if you want me to explain any of it. Otherwise it looks like you generally have a good start, and can start using the class shortly. Do you plan on making a game? I assume you are, but you could also be doing something like a CAD program.
Even in my own huge projects, I liberally separate interface and implementation. Plus, for the most part, a good class doesn't need many functions whose sole purpose is to get/set a data member.
I do use struct-like things for moving data, when I am 100% sure nothing about them will ever change for any reason, but typically my classes need, at most, 1 or 2 functions that only return or set a data member. And 99% of the time, I want to do validity checking on the input, so I need a method anyhow.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.