rozz666

Members
  • Content count

    387
  • Joined

  • Last visited

Community Reputation

896 Good

About rozz666

  • Rank
    Member
  1.   If you need to cast, then you should review your design. The point of an abstraction not to depend on concrete types. E.g. your GraphicsFactory::init accepts and interface, but inside you assume it's a specific class. What if I derive another class from IInitiationSettings? init will probably crash, even though init declaration told me I can pass anything that's an IInitiationSettings.   Of course, IInitiationSettings should be a data object, but this has already been address in other posts.
  2.   While this is true for operator<, std::less for pointer guarantees correct ordering (source: http://en.cppreference.com/w/cpp/utility/functional/less).
  3. Yes, I agree with fastcall22.
  4.   Python reference are C++ pointers (they are also garbage collected, of course).
  5. Have a look at Boost.MPL: http://www.boost.org/doc/libs/1_55_0/libs/mpl/doc/refmanual.html It provides among other things containers and algorithms for types.
  6. Why does an Entity has to know about the Scene?
  7. In my experience when I started using Unit TDD and Accepance TDD, I've never had to step through every line. That's what my tests are doing.   I'm also surprised that no one mentioned that writing unit tests improves the design of the application. It enforces separation of concerns, single responsibility principle, dependency inversion, etc., because it becomes difficult to unit test classes if they violate these principles. This, in turn, improves maintainability.
  8. Very good article. Good emphasis on the importance of naming things correctly instead of commenting them.
  9. If I understood correctly, you have a shadow function that depends on time (let's call it s(t)) and you want to describe this function. For this, you want to make is a smooth step function (_/---) so you just need to store the coefficients. Keep in mind though, that you need more than 2 values. s(t) looks more like this (sunrise ___/--day--\___ sunset), so you need at least 4 values. Still, it should be pretty easy to implement. This, of course, assumes fixed relation between the ground and the sun.
  10. I would split the algorithm into the smallest pieces that are reasonable and unit test every possible scenario. Then the only bugs that could occur would be integration errors, which I would cover with module tests.
  11. I disagree. This is a tutorial meant for beginners and suggesting bad coding practices in the examples can be harmful.
  12. Please, drop the Hungarian notation.
  13. Using the union solution also causes undefined behaviour. You are only allowed to read the last assigned member (with few exceptions, not applicable here).
  14.   Then it should be mentioned in the article that the code is not C++ compliant and will only work with given compilers that support such extensions.
  15. This: union { float f; unsigned char b[4]; } dat1, dat2; dat1.f = f; dat2.b[0] = dat1.b[3]; dat2.b[1] = dat1.b[2]; dat2.b[2] = dat1.b[1]; dat2.b[3] = dat1.b[0]; return dat2.f; is undefined behaviour in C++. You are allowed to read only from the union member that has been assigned last (with few exceptions not applicable here). This pointer cast: byte SwapTest[2] = { 1, 0 }; if( *(short *) SwapTest == 1 ) is also undefined behaviour. Additionally, it also assumes sizeof(short) == 2 and that it uses 2's complementary encoding which is not guaranteed.   What you could do is use std::memcpy: float f1, f2; std::array<char, sizeof(float)> buf; std::memcpy(buf.data(), &f1, sizeof(f1)); std::reverse(buf.begin(), buf.end()); std::memcpy(&f2, buf.data(), sizeof(f2));  However, it seems awkward that you would keep "reversed" floats around. This should be handled by your deserialization layer, so you should never end up with a need to swap bytes in primitive types.