# rozz666

Member

387

896 Good

• Rank
Member
1. ## Documentation Driven Development

Are you proposing to write the comments for Fibonacci and A* instead of unit test? If yes, then there is a high risk they will quickly get out-of-date. If no, then what value do they add? For fibonacci I would make 3 UTs, e.g. in RSpec: describe :fibonacci do it "should return 0 for 0" do expect(fibonacci(0)).to eq(0) end it "should return 1 for 1" do expect(fibonacci(1)).to eq(1) end it "should return fibonacci(n-1) + fibonacci(n-2) for positive n" do expect(fibonacci(2)).to eq(fibonacci(1) + fibonacci(0)) expect(fibonacci(8)).to eq(fibonacci(7) + fibonacci(6)) end end  For A*: describe :AStarPathFinder do # setup it "should return nil if a path cannon be found" do expect(@finder.findPathBetween(STARTING_POINT, UNREACHABLE_POINT)).to be_nil end it "should return points traced along the path" do expect(@finder.findPathBetween(STARTING_POINT, FINAL_POINT).to eq(PATH_POINTS) end end
2. ## An Open Letter to Young Programmers

Very good article. Good emphasis on the importance of naming things correctly instead of commenting them.
3. ## The Lua Tutorial

I disagree. This is a tutorial meant for beginners and suggesting bad coding practices in the examples can be harmful.

5. ## Writing Endian Independent Code in C++

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.
6. ## Writing Endian Independent Code in C++

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.
7. ## Configuration And Tweaking

This is a very common misunderstanding. When using DI correctly you pass Configuration only to the objects that need it and as you mentioned, there will be few of them. Using a singleton would cause coupling. Using DI (and preferably an interface) you don't have coupling. Have a look here: http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/
8. ## Configuration And Tweaking

It doesn't. Why not just create one instance? Dependency Injection would be a much better solution here.I'm not sure what language you think this is written for but it is C++ which doesn't have a reasonable solution for injections. Even with that, it would still be a singleton, there is only a single instance of the DB required for the program, anymore than that and it would cause problems. class Something { public: Something(boost::shared_ptr<Configuration> configuration); private: boost::shared_ptr<Configuration> configuration; };It's good enough. And it's DI. And I want to create more than one instance of Configuration: in unit tests I want to create a new instance for each test. Same for module tests. I also want to test classes that use Configuration, so I will either: a) create an instance of Configuration and pass it to the class under test; or b) create a mock object (e.g. using Google Mock) to pass it to the class under test I don't gain anything by making Configuration a singleton. On the contrary, I only get problems. EDIT: code formatting
9. ## Configuration And Tweaking

It doesn't. Why not just create one instance? Dependency Injection would be a much better solution here.
10. ## Design Patterns: Singleton Basics

Please, stop teaching people about singletons. Why not something more useful like Dependency Injection? They aren't. They cause coupling and make other classes difficult to unit-test among other things (which are listed in the post above). I refused to write it ;-) (And got the job)
11. ## Building a First-Person Shooter Part 1.2: The Player Class

I see several problem with the Player class: 1) The class is too big. It has 29 members including arrays! It has too many responsibilities: mouse speed, camera, physics, sound, etc. 2) Manual memory management. std::unique_ptr (or boost::scoped_ptr) would be a lot better. 3) It creates its own dependencies instead of using Dependency Injection. It creates coupling an block the possibility of unit testing the class. 4) The meaning of the last parameter of entity->SetPosition is not clear. 5) Not all members are initialized in the constructor. 6) Constructor is not exception safe (assuming ::Create can throw std::bad_alloc).   Such code smells in an article can teach people really bad habbits.
12. ## C++: Custom memory allocation

Starting functions, etc with an underscore is generally frowned upon, but it is not forbidden.  Most compilers reserve the prefix underscore. Starting with an underscore and a lower case letter is permitted, but an underscore followed by a capital letter is reserved for the compiler implementation.   both "_Capital" and "__whatever" are reserved. more often though, "_Capital" is used for the language-standards to add more keywords, where it is more "__whatever" being used by the compilers (for example: "_Complex" or "_Generic" vs "__declspec" or "__attribute__"). Agreed.
13. ## C++: Custom memory allocation

Starting functions, etc with an underscore is generally frowned upon, but it is not forbidden.  Most compilers reserve the prefix underscore. Starting with an underscore and a lower case letter is permitted, but an underscore followed by a capital letter is reserved for the compiler implementation.
14. ## C++: Custom memory allocation

If the derived classes do not update these variables, maybe that's because they provide their own leak detection system? That's why the base class shouldn't assume anything about leak detection.
15. ## C++: Custom memory allocation

It is forbidden to start identifier names with an underscore followed by a capital letter (e.g. _UsedMemory, _NumAllocations). Also, leak detection (ASSERT(_NumAllocations == 0 && _UsedMemory == 0);) should be delegated to derived classes, since there is no guarantee that a derived class would update these variables.