What is the best way to Convert a char to a char *

Started by
14 comments, last by xorjesus 19 years, 11 months ago
What''s the best way in GAME PROGRAMMING(i.e. fastest) way to convert a char to a char *. I need to do this so I can use string.insert() with a functiont that returns a char. Thank you for any replies.
I study day and night, memorizing the game.
Advertisement
A function asking for a char* wants a zero-terminated string. For instance...

''H'', ''e'', ''l'', ''l'', ''o'', 0

That''s a char[6] containing "Hello"

A char* is a pointer to the first element of this string. So you''d pass &YourChar[0]. However, since an array is already a pointer, you can just pass YourChar.

If you meant a regular char as opposed to an array of chars, then you can''t. You''ll have to make it at least an array with two elements, since these functions expect to have a 0 to tell them when to stop reading stuff from memory.
You need to be a bit more clear as to what you want here. Do you want a pointer to a char or a null terminated string? If it is to a null terminated string then simply create an array:

char c[2].
c[0] = somefuncthatreturnachar();
c[1] = 0;
string.insert(c);

If this isn't what you wanted you need to explain the situation a bit more.

EDIT: typo

[edited by - SoulSpectre on May 26, 2004 2:50:19 PM]
Why do you need this to be fast, anyways? You''re stressing the fact it has to be the fastest way to do it, but really, this is a trivial operation. Optimizing the way your game appends strings to each other is the least of your worries. This is what we call microoptimization.

Of course, it depends what you use it for, but I can''t really think of a reason why it would be such a performance issue. So don''t worry about it.
  char c = ''A'';  char s[32] = "";    strcpy( s, &c );


This compiles and works.

--
You''re Welcome,
Rick Wong
- Google | Google for GameDev.net | GameDev.net''s DirectX FAQ. (not as cool as the Graphics and Theory FAQ)
2 easy ways:

std::string.insert() can take two parameters (beyond the first parameter of insert location), a number, and a char. The number represents how many of that char to insert.

std::string.insert() can also take two parameters (again, beyond the first one), a char* and a number. The number specifies how many characters to copy, and doesn''t need a null-terminated string.
std::string s;s = "blah";char AChar;AChar = FunctionReturnsChar();s.insert(2, 1, AChar);  // s == "bl?ah"s = "blah";AChar = FunctionReturnsChar();s.insert(2, &AChar, 1); // s == "bl?ah"s = "blah";s.insert(2, 1, FunctionReturnsChar(); // s == "bl?ah"
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas only, and not for things themselves." - John Locke
quote:
If you meant a regular char as opposed to an array of chars, then you can''t. You''ll have to make it at least an array with two elements, since these functions expect to have a 0 to tell them when to stop reading stuff from memory.

Yes I meant just a char, not an array of char.

quote:
You need to be a bit more clear as to what you want here. Do you want a pointer to a char or a null terminated string? If it is to a null terminated string then simply create an array

Yes I meant to a null terminated string.

quote:
Why do you need this to be fast, anyways? You''re stressing the fact it has to be the fastest way to do it, but really, this is a trivial operation. Optimizing the way your game appends strings to each other is the least of your worries. This is what we call microoptimization.

Of course, it depends what you use it for, but I can''t really think of a reason why it would be such a performance issue. So don''t worry about it.

I respectfully, disagree with you Rune Caster. We can have a good argument/discussion about this, If argument/discussions are as stimulating to you as they are to me. I agree with you that microoptimazation is a lower priority in a game when compared to higher levels of optimzation. I disagree with you when you tell me not to worry about it. My philosphy about speed is this. I feel throughout the development process, if enough microoptimaztions are applied to the game, it can possibly equate to half the gain of a large optimzation, or maybe even more. The amount of ms(micro second) speed gain is proportional to the amount of microoptimazations applied. The magnitude of speed gain is significantly scaled propotionaly based on the hardware your developing for, and the running time of your program. A few ms could be nill in a single player shooter that is hosted on a p4 3 gig uber comp. But on a tool that that runs week long tests on the physics of stars colliding, or a game boy advance trying render mario 3d, I believe those speed gains are very important. I''m also just a guy interested into doing things in a speedy way :] If I unify these microoptimazation concepts into the foundation of my programming, I''ll be cranking out uber effiecent code that will be viable on many more systems, instead of just the newest uber super computer.
I study day and night, memorizing the game.
quote:
I respectfully, disagree with you Rune Caster. We can have a good argument/discussion about this, If argument/discussions are as stimulating to you as they are to me. I agree with you that microoptimazation is a lower priority in a game when compared to higher levels of optimzation. I disagree with you when you tell me not to worry about it. My philosphy about speed is this. I feel throughout the development process, if enough microoptimaztions are applied to the game, it can possibly equate to half the gain of a large optimzation, or maybe even more. The amount of ms(micro second) speed gain is proportional to the amount of microoptimazations applied. The magnitude of speed gain is significantly scaled propotionaly based on the hardware your developing for, and the running time of your program. A few ms could be nill in a single player shooter that is hosted on a p4 3 gig uber comp. But on a tool that that runs week long tests on the physics of stars colliding, or a game boy advance trying render mario 3d, I believe those speed gains are very important. I''m also just a guy interested into doing things in a speedy way :] If I unify these microoptimazation concepts into the foundation of my programming, I''ll be cranking out uber effiecent code that will be viable on many more systems, instead of just the newest uber super computer.

Micro optimisations are just that, micro. However, the same operation may or may not be considered a micro optimisation depending on where it is within the code. For example, a simple char -> string operation by itself is a micro optimization, but if you had that same optimization in a tight loop then you''d probably want to optimise it. The reason you shouldn''t bother optimising it if it doesn''t matter, because you''ll end up spending a bunch of time on something that gives you absolutely no gains.
Well every (main loop) iteration, the conversion will take place serveral times. It's not like it's happening just once. But that brings me to one of the points in my argument. If you have many different operations that only have happen once in a while, and they're all optimized to begin with. I would consider that a worthy speed gain, overall. In learning the process of game programming, I see no problem in taking the time to learn to subconciously/automatically write your code with micro optimizations applied.

[edited by - xorjesus on May 26, 2004 8:40:42 PM]
I study day and night, memorizing the game.
In practice, productivity is also an issue. When you''re programming at home as a hobby, you really have all the time in the world to experiment with optimizations, trying to write the fastest rasterizer or square root function, etc. But in a professional environment, there are deadlines that have to be met, and not a lot of time to tinker with how fast you can optimize everything you write. Only code that is run most often should receive the benefit of an intense optimization stage.

You have to weigh the benefits of a slightly faster optimization with how long it takes to implement. If there''s an obviously faster way to do something than the current way you''re doing it, then you should go ahead and do that (like doing i = j rather than i = sqrt(j)*sqrt(j)). But if you spend too much time optimizing something that doesn''t give you any notable speed games overall, then you really shouldn''t worry about it. Sometimes, too many micro-optimizations can actually hurt performance, as you could inadvertently inhibit the compiler''s ability to detect places where it can make its own optimizations. And more recent compilers do a very good job at optimizing.

In this specific instance, converting a single character to a null-terminated string can only be broken down into a small series of atomic operations, so there shouldn''t be too much dispute over which is fastest. I''d second what SoulSpectre suggests. You really can''t make it much faster.

This topic is closed to new replies.

Advertisement