Well, I can''t tell if my suggestions totally got missed, but if they did, I''ll just point out again that you do not need to convert anything to a null-terminated string when using std::string::insert(). I illustrated two ways to do it that are in most likelihood just as fast or faster than adding a ''\0'' onto the end of a 2-byte array or anything else I can think of.
Of course, at the same time, insert() isn''t really all that fast of a function anyway, since you''re going to have to copy on average half of the characters of the string into which you''re inserting a char. Finding a better way of getting all the characters where you want them, if possible, would be much more effective, at least in this specific case. Or maybe finding a way to be able to simply use append() instead of insert().
(Note that I mostly agree with you xorjesus, in reference to learning how to automatically/subconsciously apply micro-optimizations. Specific to this example, though, a macro-optimization, if possible, would be significantly more noticeable.)
What is the best way to Convert a char to a char *
Author
Agony, your suggestion was not missed, as a matter of fact I''m using the overloaded version of insert you suggested. I didn''t fully understand how it worked before. I assumed insert(how many copies I want, char) was actually insert(index posisition, char). That''s why when I was testing insert(0, char) and it worked, I got stumped when I tested insert(n, char) where n > 0. Your right about the macro optimization in finding a solution to my problem, one where I do not use std::strings. Though the reason I turned to strings in the first place was an easy and elequent way to deal with memory leaks. You see my functions return c-strings before I had a chance to delete the memory. In my list of solutions, I wanted to gain some experience working with strings, so I went to work rebuilding my functions with strings in the place of my original dynamically allocated c-strings.
not to stride too far from the question, but since the OP led us down this path, you'll find that micro optimisations usually makes no noticable difference. After you're done with your program and run it through an optimiser (or whatever technique you like to use) you'll find that 90% of your code is probably spent in the same 2 or 3 functions. So, you end up spending hours getting a 1% gain in performance at an area your program spends .5% of it's runtime in for an overall gain of .005%. And that's if you're lucky. In the meantime, you've butchered the readability of your program and you're not gonna be able to easily expand it or take care of unforeseen circumstances. In the end, your micro optimisations have ended up preventing a program from even being completed.
And so, the conclusion, is that readablility and algorithm design are the most important aspects of programming. All the optimisation in the world won't overcome a bad algorithm, and all the speed in the world won't overcome a cryptic program when it comes time to expand or debug. Too many things can go wrong and there's too little to gain. It seems like the fastest and most readable solution to your problem would be to find a way to avoid this conversion all together. Read your character into th 0th position of a length 2 array. Then you've got a char* in the array and, if you ever need the character, just use the subscript. Then you'll have eliminated the need for a conversion all together and it will be obvious what the code is doing.
[edited by - kdogg on May 26, 2004 10:41:24 PM]
And so, the conclusion, is that readablility and algorithm design are the most important aspects of programming. All the optimisation in the world won't overcome a bad algorithm, and all the speed in the world won't overcome a cryptic program when it comes time to expand or debug. Too many things can go wrong and there's too little to gain. It seems like the fastest and most readable solution to your problem would be to find a way to avoid this conversion all together. Read your character into th 0th position of a length 2 array. Then you've got a char* in the array and, if you ever need the character, just use the subscript. Then you'll have eliminated the need for a conversion all together and it will be obvious what the code is doing.
[edited by - kdogg on May 26, 2004 10:41:24 PM]
quote:Original post by xorjesus
I respectfully, disagree with you Rune Caster.
RuneCaster? Who the fuck is that?
I used to share your philosophy. Then I realized I was wrong, plain and simple.
The only place where microoptimizations are worthwhile is in a very, very tight loop. If you have a full-screen per-pixel graphic effect, even at 800x600 it would be called 480,000 times per frame. Something that takes 0.0001 millisecond would make a rather huge difference here (48 ms; which means a max of 20 FPS even if there's no additional overhead at all from anything else) In such a situation, yes, it's worth it.
However, outside of tight loops, you're just wasting your time. You could have an algorithm that's allright, and micro-optimize it to perfection. Then you might end up seeing a less than 0.1 FPS increase if it's moderately important to your game. OR, you can replace it with a better algorithm, and gain a few extra FPS.
You might figure, well, why not micro-optimize every function like this and end up gaining maybe 1-2 FPS from unimportant, time-consuming decisions on wether your loop that fills an array with numbers from 1 to 100 should be done via (i=0;i<100;i++) or (i=100;i--;; ). Why not just replace them all by better algorithms and gain a couple dozen FPS more, then?
Finally, there's readability issues. Using the two for loop examples I've provided up there, which seems easier to read? Unless you've been doing the latter frequently, the first would be more intuitive: you're counting from 0 to 100 exclusively. The latter, personally, makes me intuitively feel as though someone forgot to put an escape condition in their for loop and messed up with their semi-colons, at first glance.
I doubt any post here will change your mind. Just know that unless you're working in a tight loop, you're wasting your time and won't see any difference, and will eventually decide to spend time on more "macro" optimizations. Try this... write a game. Don't micro-optimize. Now make a copy and micro-optimize. Make sure they're only micro-optimizations, no other form of optimization is allowed. Compare.
Good luck on your projects!
Edit: STOP. CHANGING. MY. DAMN. ; ). TO. A.
. YOU. STUPID. BOARD!! :x Gah! -_- [edited by - RuneLancer on May 26, 2004 11:08:58 PM]
Author
quote:
I doubt any post here will change your mind.
On the contrary, I''m a very open minded person, I''ve found this has helped my success in the real world quite a bit.(school, job, hobbies, social interactions) I''ve learned quite a bit from this thread alone, and it''s reinforced some ideas I''ve had, but I doubted the ideas within myself. I needed some good arguments/opinions/facts. I have a better idea of what true productivity is; based on possible bonuses/loses vs time spent implementing code. I''ve a clear difference of micro optimazation vs macro optimization thanks to most of the respondents, espcially kdogg and you. I now realize where my optimization time should be spent, and the importance of readability(makes lots of sense). I will continue to make my general code effiecient, but if it''s not part of the code that gets called 90% of the time, or I completely obliviate any form of readability, i''ll take a step back and think about what I''m doing. Thanks for all replies. You all stated your arguments and suggestions extremely clearly. I really do appreciate the help. GL to you all.
-xorjesus
Of course, it pays to know the fastest way to do stuff and to try to do it as a habit, but the compiler often does that on its own. I myself pretty much always write bitshifts instead of multiplications and divisions, even though it''s less readable and the compiler does it when it can anyways. Still, it can pay to try to find the fastest way to do even simple things, just so long as that knowledge is put to use right.
While pretty much everyone have argued microoptimization is not a very worthwhile thing to do, you should still clean up here and there. But only after you''re done with everything else. The "polishing off" phase of programming is a little different from the "making it work" phase, during which you should focus your efforts on the more important things.
Good luck with your project; may the coffee be with you!
While pretty much everyone have argued microoptimization is not a very worthwhile thing to do, you should still clean up here and there. But only after you''re done with everything else. The "polishing off" phase of programming is a little different from the "making it work" phase, during which you should focus your efforts on the more important things.
Good luck with your project; may the coffee be with you!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement