slimshader

Members
  • Content count

    0
  • Joined

  • Last visited

Community Reputation

164 Neutral

About slimshader

  • Rank
    Newbie
  1. Why Is It Building So Long?

    It is important to note that a class that has unique_ptr<> member must also have explicit destructor defined (even if just an empty one) if a pointed-to class is only forward-declared.   Reason is that for safety reasons unique_ptr's d-tor makes sure it knows pointed-to class' size (to make sure it does not try to delete incomplete class). This is only possible if full class declaration is known.
  2. I just found this great VC plugin for gtest integration: http://visualstudiogallery.msdn.microsoft.com/f00c0f72-ac71-4c80-bf8b-6fe381548031/view/Discussions   solves my issue with cmake-generated solution not playing as nicely with VS as handmade one (with custom post build step).   It does not work perfectly when working with cmake (plugin only looks for .pdb files in default location atm) but is still pretty great.   btw. just-released cmake 2.8.11 supports toolset selection for VC and XCode so it is now possible to create applications targeting win XP with VC2012.
  3. Modern Garbage Collectors under the Hood

      C++ doesn't do reference counting, shared_ptr<> does, and it is a standard type since 2011. Before that every C++ programmer was using boost version before that. Another type of standard "smart" pointer is unique_ptr<> that is the sole owner of pointed-to object (new version of std::auto_ptr<>). Resetting (assigning "nullptr" (not "NULL" also since 2011)) all shared_ptr<>s pointing to the same object (or a unique_ptr<>) will delete pointed-to object.   Using them instead of raw pointers guarantees no memory leaks even in case of exceptions (weak_ptr<> is sometimes needed to break circular references).   And yes, both of them were added to standard to make C++ programming easier for beginners.
  4. Modern Garbage Collectors under the Hood

      As far as I know C/C++ does not have Garbage Collector. This will simply crash after many iterations: void foo(){ MyClass *a = new MyClass(); a = NULL; } int main(){ while(true){ foo(); } }   You need to use boost::shared_ptr<> for C++03 or std::shared_ptr<> in C++11 to get reference counting
  5. I like some of your ideas but I can't help but to think that your idea of decoupling is making all functions take void* arguments and making all UDTs char buffers or possibly PODs that are easily castable to continuous memory blocks.   Also calling this solution Duck Typing is a big stretch to say the least. Duck Typing is about behavior not data. It should "walk" and "quack" like a duck and not be "memory access optimized map". std::map<> is not a DT representative nor is presented solution.   Also, it would be nice to see the code that shows how you could replace presented python snipped in C++ with 2 example "types" that share "interface" based on your proposed solution.   Please don't get me wrong. I like the article very much, in fact I try to read everything you write and I am now also thinking how to wrap your "dynamic type" in templates to make a nice interface to underlying buffer. Would kindof be similar to boost::flat_map i suppose in which key-value pairs are stored in a vector (instead of a node-based tree) for the best cache usage.
  6. OK, it was about time I upgraded my VC. Now all works fine in 2012. Do you plan more articles in this series?   Do you have a CMake-based solution for external libs like zlib and libpng? Which OpenGL windowing lib/framework (I assume you are using OGL to be portable) are you using for your projects?   Awesome series! Thanks again!
  7. boost::function<> actually also uses C function pointer underneath instead of usually suspected virtual function call:   http://www.boost.org/doc/libs/1_53_0/doc/html/function/misc.html#idp59642640   In fact that is preferable implementation of standard std::function<>
  8. Getting 2 errors on VC2008 SP1:   1) Error 1 fatal error C1083: Cannot open include file: 'stdint.h': No such file or directory d:\devel\withsimdandios\libraries\core\include\core\Config.hpp 15 Math   2) Error 2 error C2908: explicit specialization; 'std::tr1::tuple<>' has already been instantiated D:\devel\WithSIMDAndiOS\External\gmock-1.6.0\fused-src\gtest\gtest.h 736 _TestCore   which is described here:   https://groups.google.com/forum/#!msg/googletestframework/KmifcmdemHQ/mboT8-34zL0J   solution appears to be:   #  define GTEST_USE_OWN_TR1_TUPLE 0
  9. This series is pure gold (or bitcoins;)). Please keep them coming.
  10. The default behavior for GMockGTest is to dump the test output to std::cout and it doesn't know about OutputDebugString.  I was considering adding an example of how to do that but this article was already quite large so skipped it.  I should have probably mentioned that the way I usually work in Windows is to just set a break point at the end of the main, not a great solution but you can tab back to the output and see if the tests completed and all passed.   For #2, GMock/GTest catch and eat all errors, even full on program crashes are usually caught correctly and simply output as a failed test, which is proper.   Actually that is not what I meant. ATM my VS build is configured in this pretty sweet way: http://leefrancis.org/2010/11/17/google-test-gtest-setup-with-microsoft-visual-studio-2008-c/ gtest_main executable is executed as post-build step of dependent target which most importantly causes fail of main build (tests binary returns non-zero to VS) on failed test. On top of that, since testing is now part of the build, every test result is displayed in "Output" window and on error you can just double-click in it and it jumps to failed ASSERT/EXPECT (like wit normal errors and warnings).
  11. Since you mentioned ADD_DEFINITIONS...: how do you deal with #defines that have to be added only in specific variant of the build (like debug)?
  12. I might be missing something but: 1) should gmock/gtest results be displayed in VS "Output" window during the build? 2) breaking a test (say: Math::Vector3f test0( 0.0f, 0.0f, 0.0f ); EXPECT_EQ( 1.0f, test0.X() ); ) does not break the build and basically all looks OK. Is that desired behavior?
  13. Last few weeks I am moving from Win-only (Visual Studio) build to portable CMake version. One of few things to still figure out is unit testing integrated into the process. I came back after Easter and see this series - best gift I could ask for :) Great work and thanks for doing this!