Jump to content

TheoLogic

Members
  • Content Count

    142
  • Joined

  • Last visited

Community Reputation

4 Neutral

About TheoLogic

  • Rank
    Advanced Member
  • Birthday 06/20/1986

Profile Information

  • Gender
    Male
  • Location
    Belgium
  1. Or use auto if your compiler support this C++11 feature std::vector<Resolution*> ResolutionList; //... for(auto it(ResolutionList.begin()); it != ResultionList.end(); ++it) { /*...*/ }
  2. It is not stupid, and clearly defined in the standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf (23.4.4.3 map element access)
  3. There are 2 raknet plugins which may interest your: - http://www.jenkinssoftware.com/raknet/manual/directorydeltatransfer.html - http://www.jenkinssoftware.com/raknet/manual/filelisttransfer.html Never used them, so feedback if you do would be great! If you use C++ on Windows only I propose: http://www.codeproject.com/Articles/7530/Zip-Utils-clean-elegant-simple-C-Win32
  4. TheoLogic

    Relay

    I used Boost on Nintendo Nitro, iOS, OSX, Windows and Android. No problems at all!
  5. TheoLogic

    Relay

    Calling Boost ****, shame yourself! Boost developers are mostly active in the C++ ISO committee and create great libraries which eventually may end up in the standard. Best examples are the new C++11 smart pointers and hash containers. I agree with the fact that you don't want to use Boost, it's pretty cumbersome do yet it deployed, but calling it **** crosses the line.
  6. Agreed, your animation example is a good one. I might state as: * Static: use enumerations * Dynamic: use strings for debug, used hashes in release. You can fairly implement such system that in debug you have access to the actual string value (member of your hash object), but in release it's a hashed version only.
  7. Vector is not a linked list, an element in a vector does not know the next element... Lists are double linked lists. Indeed, maps is probably the most used container after vectors for the reasons you state. I have to agree partially with Josh's comment that you should probably use an "integer type". I suspect he means static const integers, but I would strongly suggest enumerations. Depends, it's rather a design principle. If you don't design your object to be inherited from, just make all members private, else make the members required in the subclass protected. You should never have globals (and if you have them please do add them to a namespace) and public datamembers. Really, a book to read for everyone working with C++! It's "just" 101 rules, short book, but very handy.
  8. You should really read this book: http://www.amazon.co...s/dp/0321113586 Everything you are stating here will gently be countered in 101 rules by Herb Sutter, C++ ISO chairman, and Andrei Alexandrescu. 2 veteran C++ developers! You are burning yourself to the very things they are warning about. For example: 7. Know when and how to code for scalability. 14 10. Minimize global and shared data. 19 11. Hide information. 20 41. Make data members private, except in behaviorless aggregates (C-style structs). 72 76. Use vector by default. Otherwise, choose an appropriate container. 150 77. Use vector and string instead of arrays. 152 78. Use vector (and string::c_str) to exchange data with non-C++ APIs. 153 Really, don't take this the wrong way. I broke myself on endless nights, making the same assumptions as you make. That's just what's making C++ so hard!
  9. Oh boy (going off topic). Iterating over vectors is faster as over a list. List is node based and vector is a contiguous blocks of memory, which the CPU loves... That's also the reason that C# containers are slower as C++ containers, in C# all (except arrays) are node based. And be honest, what do you use the most? Inserting and removing or iterating? * render all items * update all items Simple examples, this is where you need the performance! Not in that rare case where you need to add or remove for example, this could be done during loading! And even most of the time if you require adding, vector push_back is as fast as list push_back. And OK, you have a case where you have both: often iterate and often remove in the middle for example. Use move semantics! Sorry Josh, but you need to work on your C++ skills. * Using std::map (red-black binary tree) for entity management? Use objects, or at least std::unordered_map (C++11 hash map) if you really, really, really want to use an ID * Using std::list where you want std::vector * Public datamembers, just wtf. Encapsulation my friend!
  10. Yep, indeed a C++11 feature. Finally a way to express temporaries! EDIT: Have an article on rvalue references and move semantics for the interested: http://www.benoitroosens.com/articles/rvalue-references-and-move-semantics
  11. Why would that be? Just one example how you can handle it: for(auto it(myVector.begin()); it != myVector.end(); ) { if(must_remove_this_element) { myVector.erase(it++); } else ... } std::vector can reserve capacity, so knowing the maximum number of elements can indeed be a nice thing. However, with move semantics you are able to just move elements on resizing. STL has been modified to support this, so std::vector<std::string> for example will not copy on reallocation, but move. You can write your own move constructor and assignment operator if this is your bottleneck.
  12. First question, do you require a linked-list, or a dynamic array? In my experience, std::vector covers 90% of the container use cases. List: http://www.cplusplus.com/reference/stl/list/ Vector: http://www.cplusplus.com/reference/stl/vector/ Next some remarks on Roland's code: for(auto it(myList.begin()); it != myList.end(); ++it) { cout << *it << endl; } 1. Use auto to define iterator types (if you have a C++11 enable compiler). Saves you time, and you can change the container type as you like and don't break your code. 2. Use '++'-like prefix, especially for iterators. http://thunderguy.com/semicolon/2002/08/13/prefer-prefix-operators-over-postfix/
  13. Webservices are indeed web applications... If you run VS2010 in administrator mode it should work just fine.
  14. I tried but the link pointed to my blog entry... Strange, I may have made a mistake: http://www.codersource.net/c/c-miscellaneous/c-virtual-destructors.aspx @Roland: I don't say that you are wrong, making all destructors virtual is just not the right solution. Your base destructor should ALWAYS be virtual, just like you stated. It is a good practise to also make your derived destructor virtual to state that you inherit from a base. If you don't want that your class is inherited from, you shouldn't do that however... Maybe to remove the confusion, it's the same idea as: class Base { public: virtual ~Base(); virtual void Foo(); }; class Derived { virtual ~Derived(); virtual void Foo(); }; In Derived, you don't need the virtual keywords. But it shows that you overwrite a base implementation of Foo for example.
  15. Sorry, but that's what you say to school developers in the first year C++ . There is a huge performance impact as from you have 1 virtual function. It should actually be the other way around, If you inherit or want you class to be inherited from, make your destructor virtual... A() { _pmem = new char[1024]; } A() : _pmem(new char[1024]) { } //No default initialization. Modern compilers should optimize this...
×
×
  • Create New...