Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Nov 2008
Online Last Active Today, 05:42 AM

Posts I've Made

In Topic: how to delete two objects that are circularly linked

08 January 2014 - 03:29 AM

Are the references actually circular or are you just talking about a node which may belong to multiple entities? To handle the latter you can use a std::shared_ptr wrapper for your node objects. It will automatically count the number of references to the node and call the delete operator when the object containing the last reference is deleted.


Dealing with circular references is much harder. Some approaches are to use weak pointers (std::weak_ptr) to allow an object to know about another without having ownership (i.e. holding the weak reference will not prevent the object from being deleted). If you can't design the solution in this way, there are more elaborate methods where you scan your objects, detect the circular reference and delete objects which are unreachable in the graph. But it's normally much simpler to just not use (strong) circular references at all.

In Topic: make an object that is pointing in a direction rotate to point in another dir...

24 February 2013 - 01:15 AM

You have your old and new direction vectors, so the problem is simply a matter of building the rotation matrix to rotate the first vector onto the second. You use the cross and dot product to get the rotation axis and angle.


Assuming that oldV and newV are normalised:

axisOfRotation = crossProduct(oldV, newV).normalise(); // Depending on whether your library requires normalised rotation axes

angleOfRotation = arccos(dotProduct(oldV, newV));


Whatever library you're using should have a function that builds a rotation matrix from an axis and angle of rotation, so there's no need to manually code a whole bunch of math.

In Topic: Calculating angles of rotation

01 November 2012 - 07:32 AM

I'd do it like this:

1) Project the destination vector onto the XZ axis. Do this simply by setting the y component to zero. The projected vector will no longer be normalised.
2) Get the angle between the object's vector and the vector resulting from 1), and rotate around the y axis by this amount.
3) Now you can rotate your object onto the destination vector using the method outlined earlier in this thread (cross product vectors to get rotation axis, dot product to find angle). This will cause the object to point at the destination vector without any undesired rotation along the object's local x axis.

In Topic: Bit Flags vs. Boolean

13 October 2012 - 09:26 PM

One thing to keep in mind is that accessing bit fields will require the compiler to produce additional bit masking instructions, which will *increase* the memory footprint of your instruction code. If you try to use bit fields as a general rule instead of a situational optimisation, you'll end up with slower code.

Also, the alignment issues are subtle. Most types want to align on 4 byte boundaries, so AFAIK if you have a structure containing, say, an integer, and any less than 5 flags, then converting these flags to single bits won't save any space at all.

In Topic: Is that way of using constructor really better ?

05 October 2012 - 11:40 PM

Most modern compilers will optimize the trivial stuff. So I only stick important things (large items, parent classes, references, ect...) in the initializer list, as I really don't like them. My big issue is that the order items are initlialized in the initializer list is not the same order as they are listed. Which for dependent items can really lead to some hard to track down bugs.

Why is this being voted down? His gripe about the initialiser list order not being the actual initialisation order is perfectly valid. It's intuitive to assume that the variables are going to be initialised in the order that the initialisation code is written - which is exactly the case whenever you initialise something using the equals sign.

Also mentioned in this topic, ordering your members for alignment or caching reasons can potentially break your code if one member was initialised using the value of another. And since headers are used, the potential error will not even be visible in the file where the initialisation code is actually written.

Personally if I have primitive variables that I need to initialise in a specific order, I'm not going to rely on the class definition order to do it, and that means good old fashioned assignment with the = operator.