Thread: My 3D Vector class

  1. #46
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,793
    What's this doing on GD?....moved to proper forum

  2. #47
    S Sang-drax's Avatar
    Join Date
    May 2002
    Location
    Göteborg, Sweden
    Posts
    2,072
    Some quick comments:

    operator= should return Vector3D&, not Vector3D.

    The + - * / operators should return a const Vector3D.

    The length() function should be made const.

    ohh i wasn't getting at performance, it's just a retarded idea
    It is actually a good idea, not a retarded.
    Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling

  3. #48
    Banned
    Join Date
    Jan 2003
    Posts
    1,708
    no it isn't

  4. #49
    The Defective GRAPE Lurker's Avatar
    Join Date
    Feb 2003
    Posts
    949
    Originally posted by Sang-drax
    operator= should return Vector3D&, not Vector3D.
    I don't have an operator=.... I don't really think its needed, do you?
    Originally posted by Sang-drax

    The + - * / operators should return a const Vector3D.

    The length() function should be made const.
    Just like this:
    const Vector3D &Vector3D:perator+(const Vector3D &v) const;
    ?? Thanks for the input !
    Do not make direct eye contact with me.

  5. #50
    Registered User
    Join Date
    May 2003
    Posts
    1,619
    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
    You have never worked on a large project with multiple designers, have you?

    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.

  6. #51
    S Sang-drax's Avatar
    Join Date
    May 2002
    Location
    Göteborg, Sweden
    Posts
    2,072
    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...
    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
    You obviously have a lot to learn about C++ and object oriented programming.
    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.
    Originally posted by Silvercord
    I don't have an operator=.... I don't really think its needed, do you?
    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).
    Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling

  7. #52
    S Sang-drax's Avatar
    Join Date
    May 2002
    Location
    Göteborg, Sweden
    Posts
    2,072
    Originally posted by Lurker

    const Vector3D &Vector3D:perator+(const Vector3D &v) const;
    ?? Thanks for the input !
    "const Vector3D", not "const Vector3D&"
    Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling

  8. #53
    The Defective GRAPE Lurker's Avatar
    Join Date
    Feb 2003
    Posts
    949
    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).
    Well yes, technically I do . But not an OVERLOADED one. I'll make it AGAIN...I took it out before (see the UPLOADED class).
    Do not make direct eye contact with me.

  9. #54
    The Defective GRAPE Lurker's Avatar
    Join Date
    Feb 2003
    Posts
    949
    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.

  10. #55
    The Defective GRAPE Lurker's Avatar
    Join Date
    Feb 2003
    Posts
    949
    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.

  11. #56
    The Defective GRAPE Lurker's Avatar
    Join Date
    Feb 2003
    Posts
    949
    Vector.h:
    Do not make direct eye contact with me.

  12. #57
    The Defective GRAPE Lurker's Avatar
    Join Date
    Feb 2003
    Posts
    949
    Matrix.cpp:
    Do not make direct eye contact with me.

  13. #58
    The Defective GRAPE Lurker's Avatar
    Join Date
    Feb 2003
    Posts
    949
    Matrix.h:
    Last edited by Lurker; 11-15-2003 at 06:59 PM.
    Do not make direct eye contact with me.

  14. #59
    Banned
    Join Date
    Jan 2003
    Posts
    1,708
    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.

    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.
    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.

    Actually you do have an operator=
    you know i meant outside of the fact that you can assign objects of classes by value if they are the same data type

    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.

  15. #60
    Registered User
    Join Date
    May 2003
    Posts
    1,619
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. 3D Network Analysis Tool
    By durban in forum Projects and Job Recruitment
    Replies: 1
    Last Post: 11-08-2005, 06:33 PM
  2. A 3D Program for my 3D models...?
    By Rune Hunter in forum C++ Programming
    Replies: 26
    Last Post: 08-19-2004, 10:04 AM
  3. 3D starfield
    By VirtualAce in forum Game Programming
    Replies: 6
    Last Post: 06-26-2003, 12:40 PM
  4. 3D SDK for C++ programmers
    By chand in forum Game Programming
    Replies: 2
    Last Post: 05-20-2003, 07:38 AM
  5. 3d engines
    By Unregistered in forum Game Programming
    Replies: 7
    Last Post: 12-17-2001, 11:19 AM