Álvaro

Yet another solution (for this very specific case): Use an int to represent a date in yyyymmdd format. This works great to sort and it's trivial to see the value of a date in the debugger:

(gdb) bt
#0  day_of_the_week (yyyymmdd=20130522) at kk.cpp:4
#1  0x00000000004008df in main () at kk.cpp:11

 

This is a feature that pretty much no other representation of dates has.

Oh, here's an alternative that a lot of people won't like, but I am starting to like more and more:

 

bool operator<(const Date &input) const {
  return year  != input.year  ? year  < input.year
       : month != input.month ? month < input.month
       :                        day   < input.day;
}

 

What I like about it is that it's as easy to read as a if-elseif-else construction, but it is clear from the beginning that the only thing we are doing is returning a value.

My own style is very similar to Bacterius's:

bool operator<(const Date& input) const {
  if (year != input.year)
    return year < input.year;

  if (month != input.month)
    return month < input.month;

  return day < input.day;
}

Just as an addition, I always prefer using the C99 header stdint.h (also available as cstdint in C++) and the types uint8_t and similar and not handling this mess myself. In one company I worked for, this was not done and during a switch to 64 bit I had to update a whole bunch of header files with lots of #ifdefs to take care of this. Had the project used stdint, it would have saved me a whole day of debugging to find the problem and fix it.

 

I agree that stdint.h should be used, but before that was available I used to write a little program that would check the size of various integer types (using sizeof) and produce the text of a header file with those typedefs. The makefile knew to compile and run this program to generate the header file. I used that without problems for years.

 

 

#include <iostream>
#include <string>
#include <climits>
#include <cstdlib>

std::string find_type(int size) {
  if (CHAR_BIT * sizeof(char) == size) return "char";
  if (CHAR_BIT * sizeof(short) == size) return "short";
  if (CHAR_BIT * sizeof(int) == size) return "int";
  if (CHAR_BIT * sizeof(long) == size) return "long";
  if (CHAR_BIT * sizeof(long long) == size) return "long long"; // OK in gcc
  std::cerr << "ERROR: I couldn't find a " << size << "-bit type!\n";
  std::exit(1);
}

void define_signed_and_unsigned(int size) {
  std::cout << "typedef signed " << find_type(size) << " int" << size << ";\n";
  std::cout << "typedef unsigned " << find_type(size) << " uint" << size << ";\n";
}

int main() {
  define_signed_and_unsigned(8);
  define_signed_and_unsigned(16);
  define_signed_and_unsigned(32);
  define_signed_and_unsigned(64);
}
 

What's the question?

Write your code to be clear. If performance is a problem, use a profiler to see where the time is going. After that, if you find that traversing the tree is actually a performance bottleneck, then you can worry about this.

My first tool against memory leaks is discipline:

 (1) Use standard containers (of objects, not pointers) instead of rolling your own data structures.

 (2) Use a smart pointer (probably std::unique_ptr) when you need polymorphism.

 (3) Be very clear about which object owns which resource, and release the resource in the object's destructor.

 

Now that you already have a mess because you probably haven't followed the principles above, you can try to use tools like valgrind to help you find problems with how you are using memory. It is a pretty safe bet that `new' is involved.

 

Massive memory leaks should be easier to detect than small ones. There is also more of an incentive to fix them.

 

I am not very familiar with SFML, so I won't comment on the second part of your post.

Since m_pCall was declared as a pointer to the base class, and since the destructor was not declared virtual, only the base class destructor gets called. That means that any space allocated for the derived class over and above what is in the base class won't get freed.

 

You said this twice, but I don't think it's precise. Memory is allocated in blocks, and there is no such thing as freeing part of a block. I am not going to check the standard, but there is a good chance that deleting an object through a pointer that doesn't have the same type that was used when `new' was called is undefined behavior. But the practical reason why his code is leaking is that DrawFont has a member that uses dynamic memory allocation, whose constructor needs to be called for proper cleanup. If DrawFont only added plain-old-data members, this would probably not happen.

You need a virtual destructor for any class that you intend to inherit from. Or at least inherit publicly, which is the only type of inheritance I would use.

 

In your case, the member `stText' of type `std::wstring' probably holds a pointer to dynamically allocated memory. If you don't call the destructor for the right class, this member's destructor won't get called and you'll get a memory leak.

Ok so where do i get this rotation information if the only transformation information i have is stored in one matrix

The 4x4 matrix of an affine transformation is compose of a 3x3 matrix that represents a linear mapping (in the case of posture data this is a rotation) and a translation vector (a column to the right of the 3x3 matrix or a row below it, depending on whether you are using column vectors or row vectors). The other four components are always "0 0 0 1".

Extract the rotation and the translation separately and convert the rotation to a quaternion (see JTippetts's post above).

This took about 30 seconds using Google: http://www.codeforge.com/article/111194

Pointless but interesting extra maths fact: if A, B, C are transformed by a linear transformation represented by matrix M, the area will be multiplied by the determinant of M. (Note projection matrix is NOT a linear transform ;))

Replace "linear" with "affine" in that sentence, and then it makes sense.

These short questions are not going to get you anywhere. You get better by challenging yourself to write programs that do something that is near the edge of your abilities.

Forget about doing anything graphical for at least six months. Write console programs to do something challenging. Some examples of challenges:
* "Hello, world!"
* Print a multiplication table
* Calculator where the user is asked for operation and operands
* Print the calendar for any month in history
* Tic-tac-toe, two players
* Tic-tac-toe with AI
* Calculator where the user can enter any expression (e.g., "50*(4-2)+8*9")
* Interpreter for a simple scripting language
* Make the calculator above work with arbitrarily long numbers (if you use a library for this it's not very challenging, but still instructive because you'll learn how to interface with a library, and perhaps you'll get some ideas of how libraries should be written, which is how all code should be written.)
* Chess engine
* Relational database management system
* Compiler

I am sure you can write "Hello, world" and I am sure you can't write a compiler. So somewhere in that list there must be a challenge that is doable but not too too hard for you. Or you can make your own challenge, more in line with what interests you. Work on it. Don't give up, even if it's hard. Rinse. Repeat.

How are you representing the transformation that brings you from the frame of reference of the parent bone to the frame of reference of this bone? You probably want to use quaternions for the rotation part, and then use slerp or nlerp.

Trust me, draw it out on a big sheet of A4!

How big do sheets of A4 get where you live? We can only get A4 in A4 size in my country... ;)