Clever Geek Handbook

C ++ classes and utility functions

Therefore, I can use various functions that work on the line:

inline float yIntercept(const vec2& ptA, const vec2& ptB, float x);
inline float xIntercept(const vec2& ptA, const vec2& ptB, float y);
inline bool lineIntersection(const vec2& ptA0, const vec2& ptB0, const vec2& ptA1, const vec2& ptB1);

The functions take 2 points for each line that represents a line.

Or I can write a line class that has these 2 points and various useful line related methods.

struct Line {
    ... stuff

    inline float xIntercept(float y);
    inline float yIntercept(float x);

    inline bool lineIntersection(const Line& other);

    vec2 m_point[2];
};

One thing I was thinking about is doing the instantiation of this linear class every time I need to call one of these functions, just 2 points.

I can work on a list of points representing a polygon and no string instances are actually created.

At any time I can either call

yIntercept(somePointA, somePointB, 3.0f);

Or

Line(somePointA, somePointB).yIntercept(3.0f);  //I think this would compile

I like the idea of ​​having classes for things like this, not C style functions, but I was wondering if there is some performance limitation for instantiating a class like this rather than just passing dots straight to a function. Maybe the compiler is doing some optimization?

+3


source to share


2 answers


One thing I was thinking about is the performance of instantiating this line class every time I need to call one of these functions in just 2 points.

If this really is a problem in your application, then you are probably "doing it wrong". What I mean is that, done right, the code to create this object should be very lightweight. And even then, you would really need to create a lot of that object - do "things" that make up strings that don't get created over time, so the structure string might be included in the overriding object to some extent.

For example, in a polygon, you can create Line objects from your list and keep them around.



I would also start writing a general, well-functioning codebase and then optimize when things work. If you need to rewrite something, so be it. Hopefully you've made your interfaces generic enough not to rewrite too much OTHER code.

And whenever there is performance optimization, make sure you measure, measure again, and notice what you did to change it. I sometimes had several hundred rows in spreadsheets with "Tried modifying X", "Used a clever trick in function A", and the results are sometimes "5% lost" (or "500% lost"), but at least you then know what the result is. Using "I think the compiler will do this" requires a lot of experience with any compiler.

+1


source


Choose a solution based on other factors. Possibly engagement or readability.

The reason for this approach is because you are choosing between these two scenarios:

  • Additional work to create objects Line

    .
  • Doing extra work of passing more parameters to your functions.


The compiler can optimize by 1 or 2. And it can be. Or not. And it might help. Or not.

See this article to learn more about optimization solutions like yours. The author is fine.

http://www.codinghorror.com/blog/2009/01/the-sad-tragedy-of-micro-optimization-theater.html

+1


source






More articles:


All Articles