Jump to content
  • Advertisement

Pink Horror

  • Content Count

  • Joined

  • Last visited

Community Reputation

2459 Excellent

About Pink Horror

  • Rank
  1. For me, using move semantics in the context of this is somewhat equivalent to using reserve on a collection class like vector. I just get some efficiency for a little bit of additional thinking/design overhead. So yes, whenever possible (in places where it can matter) I tend to move expensive temporaries (like string, vector, ...). However this mostly means that I adjusted my design. IE, where you would usually see something like this: Foo foo;std::string& string = foo.GetString();string = "Test";string.append("whatever"); Or something along those lines, I would instead do: std::string string = "Test";string.append("whatever");Foo foo(std::move(string)); I find the latter much cleaner, especially in non-fabriacted examples :D Obviously you could have done this before without the move-semantics, but it would have most likely invoked a copy operation for the content of the string. EDIT: i think i misread your question. Anybody who is actively using C++11 surely has at least a basic understanding of how and when to use move-semantics. Anyone else wouldn't have that knowledge, so its probably a matter of who you target.   I know this isn't important to the example, but I feel obligated to point out that a 12-character string isn't really a compelling use of std::move, considering the popularity of small string optimization.
  2. Pink Horror

    Recent Graduate Looking For Advice

      That is the role.     You are not going to get an entry level job as a designer.  Game designer is a senior role, it is a person who is figuring out the core of a multi-million dollar project. You don't give multi-million dollar projects to entry level workers.   There were intern game designers at one company I used to work for. There's a lot of little stuff to design that the senior people don't want to have to do.
  3. I wonder what percentage of new C++ games are being made with exceptions and RTTI turned off.
  4. Pink Horror

    Getting Objects To Not Lose Scope?

    I just want to point out, if you are debugging a problem and a raw pointer is NULL, that doesn't mean the object has been destroyed or has gone out of scope. A pointer to something keeps its value until you overwrite it. It isn't going to change just because the object it's pointing to isn't valid any more. It'll keep pointing to the same memory address. So, if you're working on a problem and you see a NULL pointer, look for places in your code that modify the pointer itself, not the value it references.
  5. You're not transcending the boundaries of C++ and OOP. You're just achieving your goal of caching these numbers with the smallest, easiest edit possible. There's no balance here. There's no actual concern for legibility that I can see. You're modifying your code in the same way practically every modification is made to so-called OOP C++ programs out there - in whatever way lets the programmer move on to the next task and keep collecting paychecks. Please do not act like this is something special. You are not challenging conventional thinking. You are demonstrating it.
  6. First, how much faster did your program get because of this? That's how you measure performance gain, not cache hits. Second, no, not many veteran programmers I know appreciate functions that look like they should be pure functions, and unexpectedly read and write from static variables. These "creative" solutions are very annoying when you finally figure out what's causing the rare animation bug in a multi-threaded application. I hope no beginners copy this approach. If you want to make an optimization, hacks like this should be the last resort, ideally only made on a "release" version of your game, not on code you would continue to use in future products. You should be willing to refactor your code and actually change where the function calls are made, if the performance gain is meaningful.  
  7. Pink Horror

    Hashing by key range

    How do you expect to compare a pair of iterators to only one iterator with just the == operator? I'm normally for using auto in cases like this, but if people cannot understand what's going on because of the lack of readable type information, I'm beginning to wonder whether it's made C++ worse.
  8. Pink Horror

    Microsoft Checked C

    And of course, if it "has to be" written in C, you cannot write it in Checked C.
  9. Pink Horror

    Microsoft Checked C

    Are you sure? When reading it through, it looked like ptr<T> was designed to NULL out when the original data was invalid. That is the functionality from std::weak_ptr<T> that would be very nice. C++ can't solve this issue because it itself is based upon potentially dangerous C libraries. As a library consumer, C++ (even Java and C#) seem better than C but remembering that underneath all their hoods, the same dangers can (and almost certainly do) still lurk, it removes all the fun ;). Plus these languages end up running more C than a C program due to their additional layers written in C so they are still not ideal. Checked C aims to remove these issues at a much lower level than possible by just bolting on another random language.   The paper says it is about bounds-checking. a weak_ptr has nothing to do with bounds checking. The introduction is entirely about bounds-checking. It mentions problems such as using already-deleted memory are beyond the scope of Checked C. C++ can at least partially solve the issue, because you can use templates to create the checked pointer classes. That's what the team who made this did as a prototype. Just building with Checked C instead of C gets you nothing. You have to use the new types. Converting one of those potentially dangerous libraries to Checked C means putting in the correct changes to use bounds-checking everywhere they would belong, and making no mistakes or oversights while doing so. As long as you're rewriting chunks of the library, why not rewrite them in C++? What's the difference? How does the library go from potentially dangerous to knowing it's safe? How do you know you did the conversion correctly? How do you know the library isn't dangerous because of something that wasn't covered, like memory allocation? If, for some reason, you have a code base that's in C, and you're willing to rewrite every part of it that uses pointers, and compiling it in C++ scares you and/or you're not willing to create the helper templates yourself, but compiling it in a new version of C from Microsoft is something you're willing to do, and you're having trouble with buffer overflows, and compile-time checks will help or run-time crashing is ok, than sure, Checked C might solve a problem for you.
  10. So, you're saying that Tangletail's game's DB performance will be similar to a 40TB database, and that one frame of a typical  video game happens in tens of nanoseconds?
  11. I don't know what database you're using, but on the servers I typically work with, the complete round-trip time of sending a simple, plain-text SQL query over the network to another server, processing it, and getting the result back often takes less than one millisecond. I'm sure a game could do it even faster with a local, in-memory database. And actually, I know that's true, because I've also worked on a game that did that.
  12. Pink Horror

    use ID or Pointers

    You can add integer ID's (and void* ID's!) to the C++ type system like this, in order to maintain type safety: struct PrimitiveBase {}; template<class T, class Name> struct PrimitiveType : PrimitiveBase { typedef T Type; PrimitiveType() : value() {} explicit PrimitiveType(T v) : value(v) {} operator const T&() const { return value; } operator T&() { return value; } private: T value; }; #define MAKE_PRIMITIVE_U64(name) struct tag_##name; typedef PrimitiveType<u64,tag_##name> name; #define MAKE_PRIMITIVE_U32(name) struct tag_##name; typedef PrimitiveType<u32,tag_##name> name; #define MAKE_PRIMITIVE_U16(name) struct tag_##name; typedef PrimitiveType<u16,tag_##name> name; #define MAKE_PRIMITIVE_S16(name) struct tag_##name; typedef PrimitiveType<s16,tag_##name> name; #define MAKE_PRIMITIVE_U8(name) struct tag_##name; typedef PrimitiveType<u8,tag_##name> name; #define MAKE_PRIMITIVE_S8(name) struct tag_##name; typedef PrimitiveType<s8,tag_##name> name; #define MAKE_PRIMITIVE_PTR(name) struct tag_##name; typedef tag_##name* name; MAKE_PRIMITIVE_U32( MyObjectId ); class Foo { MyObjectId Create(); void Release( MyObjectId ); }; What does PrimitiveBase do for you in this case?
  13. Is it bad if every time I see the whole IO "<<" overload I vomit in my mouth a little?   Vomit all you want. I just personally think that "vomit in my mouth a little" is extremely overused. I still manage to keep my stomach acid down when I read it.
  14. Pink Horror

    Memory Leaked even a CComPtr is used?

    I think only around 2% of these types of questions asked on here actually post the code that's responsible for the problem. You've showed us where this thing is allocated. Great. Now show us where it is de-allocated. And I don't mean just in the CComPtr. Give us the whole call stack for how it'll get there. Where are those member variables stored? Where does that parent class live? When is it destructed? Can you put a breakpoint where that happens?
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!