Jump to content
  • Advertisement

christopherg

Member
  • Content Count

    19
  • Joined

  • Last visited

Community Reputation

124 Neutral

About christopherg

  • Rank
    Member
  1. christopherg

    Getting Rid of "char*"

    Agreed.   I chose to present the problem as if I was rewriting the stl string class, because everyone is familiar with string. I never intended to actually rewrite the string class. I probably should never have chosen string to be a proxy for my issue in retrospect.   In general in C++ wrapping a fixed amount of memory of some kind, the amount of which is determined at compile time, into a class is a sort of new concept. Direct support for this was added to the stl in C++ 11 I believe though std::array (as was mentioned in this thread). (Although you could always have written a fixed allocator before that.) There isn't a perfect way to do it still unfortunately, as you have to pay the man one way or another. This thread has made it more clear what trade-offs you will have to make when representing a fixed array as a class, and a few different ways of going about it.   Classically, a fixed array would be manipulated using either an external editor class which you attach to the memory, functions which act similarly to the external class but you must supply the source memory with each function call, methods contained in the class which allocated it, or, more recently, using a template to wrap the memory itself into a class (which is the most object oriented way of going about it).   float[ Size ] textureMemory; MemoryEditor editor; editor.Attach( textureMemory ); editor.Edit( ... );   V.S. float[ Size ] textureMemory; EditFunction( textureMemory, ... );   V.S. class Texture { public: ... (memory editing methods go here)   private: float[ Size ] textureMemory; }   V.S. TextureMemory< Size > textureMemory; textureMemory.Edit( ... );   There really doesn't seem to be a right answer here that is always right, as with many things in programming. Several codebases that I am familiar with each take a different route, or mix them a bit. Each solution has tradeoffs, but if we understand them properly we can at least try and select the best tool for the problem. I think I understand them better now thanks to this thread.
  2. christopherg

    Getting Rid of "char*"

    Now you downvote my posts? After you have been so incredibly unhelpful?   I hope there is an ignore feature so I don't have to accidentally read one of your horrible posts again.
  3. christopherg

    Getting Rid of "char*"

    This has nothing to do with string or the STL in general, I have said that more than once in my recent posts.   Am I being trolled? lol   Either way I learned some stuff from this thread and worked my issue out. Thanks to everyone that posted with advice!
  4. christopherg

    Getting Rid of "char*"

    Actually, let's not pretend it's an issue, that's exactly what causes premature optimisation. Here is the procedure to "solve it".   First prove it is an issue, via profiling. You've either done that and not posted results, or you haven't done that. Either way there is more work required at this step.   After that, your first attempt at a resolution should be to see how you can use strings less. E.g. if profiling showed that you had a bottleneck when comparing your string object IDs, then perhaps you could switch to using enumerations instead of strings. Or, if you're getting too many string copies, perhaps there are some critical places where the string is passed by value instead of const-reference.   The next thing to do is to look for a replacement that already exists. That may be in the form of a more-specialised part of the same library, or a whole other library. There is plenty that you can research.   Next, in considering whether to write your own replacement, you need to understand that in proceeding down the path of making your own, you are assuming that you can do a better job than the expert standard library writers. You are then assuming that you are in the top few percent of all C++ coders. Most people like to think that they are in the top few percent of C++ coders, but obviously most aren't. The experts are those who have first learnt to use existing tools very effectively (e.g. strings). One must learn why all the parts of the string class work as they do, in order to not fall into traps that others have already solved.   The final thing to understand is that even when there is a bottleneck, and even when you've done your best to optimise all related code as much as you can, there is always going to be a bottleneck somewhere. It's even possible that no matter what changes you make to a program, string handling could be such an unavoidable bottleneck (although that is generally unlikely, depending on what the program does).   You should probably read the thread, or at least my posts before writing such a long post telling me string is fine as is.   It was a proxy problem for a different problem I am having whose solution was similar.   EDIT: Good advice re: optimization however.
  5. christopherg

    Getting Rid of "char*"

      Most std::string implementations keep small strings on on the stack for you automatically, and store larger strings in dynamically allocated memory. For example, with GCC they carefully chose what is best speed/size optimization tradeoff depending on whether your architecture is 32 bit or 64 bit. They decided that small strings up to ~10 characters work well for 32 bit machines, and small strings up to 22 characters work best with 64 bit machines, and give that optimization to you at virtually no cost.    This is very true! However my real problem is in regards to a drop-in replacement for statically sized arrays of a particular type that should all share the same interface. How to go about wrapping the statically allocated memory into a class properly.   So far the best solution seems to be using something akin to a static allocator, and incurring some penalty in the instruction cache for different sizes.   Wow! That's pretty interesting and sounds like exactly the thing Microsoft would do lol.   EDIT: Yes, this is for cache coherency. Also a minimum size isn't a bad idea, honestly.
  6. christopherg

    Getting Rid of "char*"

    I'm sorry, I misspoke when I said stack allocated and it caused allot of rightful confusion. Also, as stated earlier, the whole string thing is a proxy problem, and so the reasoning behind rewriting it is undefined heh.   std::array is pretty much exactly the type of thing I am going to use, however, the current issue I'm having with this is simply that I am potentially creating a completely different set of instructions for each size of 'std::array' am I not?
  7. christopherg

    Getting Rid of "char*"

    While a bit of a misnomer, what I mean when I say stack allocated is simply that the array has a static size, and so would be easily stack allocatable. Being easily stack allocatable is important for cache coherency. Let me give you a quick example:   struct MyStruct { int a; char b; float c[ 128 ]; };   V.S.   struct MyStruct { int a; char b; float* c; };   Where 'c' must now point to some other area of memory.   EDIT: I'm now realizing that I made a mistake and should have never called it 'stack allocated' as that's not quite what I meant. What I did mean is that it should be contiguous in memory with the object that created it, in other words, it must have fixed size.
  8. christopherg

    Getting Rid of "char*"

    I had considered something similar to this, although I will admit to not knowing that string_view was a thing. The idea being that you would make the memory elsewhere, and then attach a 'handler' class of some kind to it by passing in a pointer to the external memory during construction, and possibly the size. However, this just doesn't seem like the most elegant solution.   Having said that I have used this solution in multiple projects before, like attaching an 'editor' class to some memory, and then using that to interact with the memory. It is very nice and works quite well, and easily avoids the issues of instruction cache pollution. However, I'm hoping to find a different solution this time.     Generally, one would return a reference to MyString, but it depends on context.     This seems to be the most reasonable thing to do. The only issue comes if you use many different static sizes you will run into more instruction cache misses. In the extreme it might actually slow things down! I was thinking perhaps you could export some of the code that is exactly the same across different allocators into a separate base-class and inherit from that. I'm not sure if that would help however, as I'm not super versed in how instructions are stored in memory.     So, in summery we have 3 different solutions I think: 1) Use char* and forget about c++ for this. 2) Use class that is constructed with a pointer to the externally allocated memory, and its size. 3) Use a static allocator.   The only problem with 3, which is my current favorite, is instruction cache pollution if you go overboard. This may be completely unavoidable with this solution, but I'm all ears if someone knows of a way to reduce this side-effect. Seeing as we might be crating a completely different set of instructions for each memory size, and that's not cool.   I think perhaps 2 could also be used very happily. It would effectively be like wrapping the string manipulation functions into a class, although not very OOP, it is probably the fastest and most problem free solution.
  9. christopherg

    Getting Rid of "char*"

    Let's pretend it is an issue. How do you think you would solve it?   This question is a very triggering, but at least familiar, proxy for a more fundamental issue. However, solving this problem will also solve the real issue I'm having. The real issue is that there is no simple and obvious way to encapsulate what are effectively statically allocated arrays, where the static size may change throughout the code.   So, if you want to allocate some static memory, who's size is determined at compile time, and have an interface to it through class methods, you must jump through hoops and avoid major caveats. A simple example of this is the humble string class.
  10. christopherg

    Getting Rid of "char*"

    I think I detect a bit of sarcasm in the second paragraph, and I note the issue you point out. Thankfully, I only need roughly 3 different sizes throughout my entire application, and the instruction cache can more than handle that.   Having said that, I do wonder if there is a better way. In the end, I simply want a string which allocates on the stack like a char[ Size ] array. Funnily enough, I'm not sure C++ is up to the task without major drawbacks one way or another (for example instruction cache bloat if overused). Maybe that's why everyone just passes around char*.
  11. christopherg

    Getting Rid of "char*"

    I agree that replacing stl functions isn't necessary and will cost money and time, however, discussing when and how to do so is outside the scope of this thread.   As for the solution to my issue, it seems like the only way to do it is to use interfaces, as Ryan_001 suggested. This is because using template methods will not work with interfaces, and my interfaces need to be able to return strings.   Sadly, this precludes the use of template methods inside the MyString class as well, which thankfully in this case only adds a bit of extra header code.
  12. christopherg

    Getting Rid of "char*"

    Part of the reason I reimplemented std::string is because I wanted to have a string class that I could use as a replacement for preallocated character arrays, with the same performance characteristics and locality of memory.   To do that I require a string which allocates memory to the stack, and to specify the amount I want I need to pass it as a template parameter.   EDIT: Also, reimplementing std::string has little extra code due to it mostly calling into the methods of my reimplemented std::vector
  13. So, I would like to stop using char* and char[ size ] to allocate and pass around strings. Instead I want to use a string class.   The string class allocates some memory on the stack (like 25 characters worth or so) to optimize the use of small strings. I have written a class that works the same, however, it also allows you to set the amount of 'stack allocated memory' using a template parameter. Like so:   MyString< SIZE > string;   This allows it to function just as if you were pre-allocating a char array like so: char string[ SIZE ];   However, when I return a char array I just use a char*, and I don't need to know how much memory was allocated for that buffer. With MyString, when I return it I need to specify exactly how much memory was allocated for it, and it's a pain in the ass! Something like this:   const MyString< SIZE >& GetFaceName( );   Which is ridiculous, since I always have to know its exact size. How can I wrap char arrays into a class and make it not suck so bad? The only thing I can think of is to maybe have MyString inherit an interface IMyString and return that. But I'm not sure if that's the best way to solve this problem.       ALSO: Hope your Christmas was good!
  14. christopherg

    Locking Down an Application

    Relevant Origin EULA Snip: "[color="#1D1D1D"][font="Arial, sans-serif"]2. Consent to Collection and Use of Data.[/font][font="Arial, sans-serif"][color="#1D1D1D"]You agree that EA may collect, use, store and transmit technical and related information that identifies your computer (including the Internet Protocol Address), operating system, Application usage (including but not limited to successful installation and/or removal), software, software usage and peripheral hardware, that may be gathered periodically to facilitate the provision of software updates, dynamically served content, product support and other services to you, including online services. EA may also use this information combined with personal information for marketing purposes and to improve our products and services. We may also share that data with our third party service providers in a form that does not personally identify you. IF YOU DO NOT WANT EA TO COLLECT, USE, STORE, TRANSMIT OR DISPLAY THE DATA DESCRIBED IN THIS SECTION, PLEASE DO NOT INSTALL OR USE THE APPLICATION. This and all other data provided to EA and/or collected by EA in connection with your installation and use of this Application is collected, used, stored and transmitted in accordance with EA’s Privacy Policy located at www.ea.com. To the extent that anything in this section conflicts with the terms of EA’s Privacy Policy, the terms of the Privacy Policy shall control." [/font] Relevant Steam EULA Snip: (We can collect) "I[color="#1D1D1D"][font="Arial, sans-serif"]nformation regarding Steam billing, your Steam account, your Internet connection and the Valve software installed on your computer are uploaded to the server in connection with your use of Steam and Valve software.”[/font] [color="#1D1D1D"][font="Arial, sans-serif"] [/font] [color="#1D1D1D"][font="Arial, sans-serif"]Hmm...[/font]
  15. christopherg

    How to take map image for mini-map

    It depends how much dynamic detail you want. You could make smaller versions of each tile and make a tile-based minimap. To represent enemy buildings you could either have simple colored squares (like Warcraft 3), or you could use small images or icons representing the building type. For units you could just use colored 'blips'. EDIT: For performance reasons, you will want to generate the minimap to a texture. Except of course for the buildings/units and other dynamic content.
  • 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!