Dominique Devienne wrote:

On Fri, May 1, 2009 at 9:22 AM, Etienne Philip Pretorius wrote:

...

namespace unicode { typedef std::size_t code_point; class string : public std::basic_string {

Is "std::basic_string" not the same as "unicode::string"? If not why is it not?

Not strictly related to your question, but Unicode code points use a maximum of 21 bits currently (max code point is 0x0010FFFF), and are unlikely to ever overflow a 32-bit integer. Whereas size_t will be 64-bit when compiling for a 64-bit architecture, so you want to typedef unicode::code_point to unsigned int anyway. --DD

Good point, Thank you.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

How much time do we have to do that, boss? On Fri, May 1, 2009 at 11:49 AM, Etienne Philip Pretorius < icewolfhunter@gmail.com> wrote:

Please find attached the classes that I am working on. If someone could point out where I made the error, will appreciate it.

Etienne

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

I think I figured it out. Something wrong between the data types of what unicode::string::substring method returns and unicode::string. Etienne

Rodrigo Madera wrote:

I know this is not the best source, but it will shed some light:

http://msdn.microsoft.com/en-us/library/wt3s3k55(VS.80).aspx

You shouldn't be creating your own wide string class unless you have a really good reason not to use wstring.

Regards, Madera

Thank you. I figured it out. When I called the substr method of unicode::string is was accessing std::basic_string::substr and therefore returning std::basic_string type. I will just override that with my own class method. Wide chars as far as I know are different from platform to platform. Microsoft uses 16 bit wide chars while *nix uses 32 bit wide chars. And for unicode I need at least 21 bits. Etienne

On Fri, May 1, 2009 at 9:35 AM, Dominique Devienne wrote:

On Fri, May 1, 2009 at 9:22 AM, Etienne Philip Pretorius wrote:

...

namespace unicode {    typedef std::size_t code_point;    class string : public std::basic_string {

Is "std::basic_string" not the same as "unicode::string"? If not why is it not?

Not strictly related to your question, but Unicode code points use a maximum of 21 bits currently (max code point is 0x0010FFFF), and are unlikely to ever overflow a 32-bit integer. Whereas size_t will be 64-bit when compiling for a 64-bit architecture, so you want to typedef unicode::code_point to unsigned int anyway. --DD

Wouldn't then the OP rather use uint32_t or similar? I thought that int represented the natural word size of the architecture. If so, then wouldn't unsigned int be 64-bit on a 64-bit platform as well? Or did I miss something? -- Dan Day

Dominique Devienne wrote:

On Fri, May 1, 2009 at 10:32 AM, Dan Day wrote:

...

Wouldn't then the OP rather use uint32_t or similar?

AFAIK this type doesn't exist on all platforms portably.

#include boost::uint32_t

Dominique Devienne writes:

On Fri, May 1, 2009 at 10:32 AM, Dan Day wrote:

...

I thought that int represented the natural word size of the architecture. If so, then wouldn't unsigned int be 64-bit on a 64-bit platform as well?

I had heard this before as well. I took a quick look through c1x-1336 (current (?) draft of C) though, and I could not find anything to this effect. Of course, that doesn't say it's not there, and I did not check the C++ standard.

The few 64-bit platforms I've seen keep [unsigned] int at 32-bits. --DD

To be pedantic, this depends on the system's data model. http://en.wikipedia.org/wiki/64-bit#64-bit_data_models http://www.unix.org/version2/whatsnew/lp64_wp.html The first link does make some effort into listing which systems follow which models. Indeed, as Dominique says, most recent systems (e.g. Linux, Mac, and Windows on amd64) have chosen models which have kept int at 32bit. -tom