views:

59

answers:

4

Hello, here's what I am trying to do:

typedef uint16_t uchar16_t;
uchar16_t buf[32]; 
// buf will contain timezone information like GMT-6, Eastern Daylight Time, etc

char * str = "Test"; 

for (int i = 0; i <= strlen(str); i++)
     buf[i] = str[i];

I guess that's not correct since uchar16_t would contain 2 bytes and str contains 1 byte.

What is it that I am supposed to do ?

A: 

Your code will work, as long as str is ASCII; calling strlen() in the loop condition is probably a bad idea, though. It might be easier to just use swprintf() if it's available on your system:

uchar16_t buf[32];
char *str = "Test";
swprintf(buf, sizeof buf, "%s", str);
Carl Norum
Carl, what can I use in place of strlen instead - do I check for '\0'? My code does not work - when I print it, it prints all blank chars :(
Sagar Hatekar
@Sagar, What prints all blank chars?
Carl Norum
@Sagar: It is probably empty
0A0D
@Carl, after using swprintf, here's what I get:Cannot convert from uchar16_t to wchar_t.
Sagar Hatekar
+3  A: 

Strlen? buf[32]? Trying to destroy the universe?

You want to use a wstringstream.

std::wstringstream lols;
lols << "Test";
std::wstring cakes;
lols >> cakes;

Edit@Comment: You shouldn't use strlen because any decent string system allows embedded zeros, and strlen is seriously slow. In addition, you didn't resize your buffer as needed, so if you had a string of size > 31 you would get a buffer overflow. In addition, you would have to (if you did dynamically size your buffer) manually free it afterwards. Both of these things are serious failings of the C string system. My example code makes your standard library writer do all the work and avoid all these problems for you.

DeadMG
Well, I am learning - how will I learn unless you told me why is it wrong to do an strlen and what could be used in place of that? :)
Sagar Hatekar
@Sagar: For learning purposes, I suggest looking at this paper where Bjarne Stroustrup does a side-by-side analysis of "the C way" vs "the C++ way" of doing things (often the reason people think C is faster code is simply because you are omitting things that are required in order to be correct): http://www2.research.att.com/~bs/new_learning.pdf
Hostile Fork
@Hostile Fork: Thanks, that's really some valuable piece of information.
Sagar Hatekar
@DeadMG great info - thanks!
Sagar Hatekar
A: 

Have a look here.

Also, is there a good reason you are defining your own type?

If you have a (narrow) char string, you cannot convert it to a wchar_t string by setting your locale to "C" and then passing the string through mbstowcs(). That's because the "C" locale specifies a -particular- character encoding, and that encoding might not match the encoding of the execution character set, so mbstowcs() might map the characters to something unexpected, or could even fail (if the execution character set happened to use encodings that were incompatible with the encoding structure for the C locale character set.)

Thus, in order to convert a char string into a wider string, you have to copy the chars one by one into an array of wchar_t . If you need to work with Unicode or utf-16 or whatever after that, then wcstombs() is what you should look at.

Serapth
@Serapth Thanks for explanation. The typedef has been done in an existing library so I have to use it 'as-is'.
Sagar Hatekar
wcstombs outputs a char* - I need a uint16_t So when I do that, it gives me an error saying "cannot convert from char* to uchar16_t*"
Sagar Hatekar
+1  A: 

That's actually OK if your string will always be ASCII. To do it correctly, the portable function is mbstowcs which assumes you're converting from the default locale or if you're on Windows then there's API functions that let you specify the source code page explicitly.

Rup