General C++: Class Method Signatures Miss-Match
Hello list, I know this is not boost related, but I will appreciate it if anyone could shed some light on what is happening here? Compiler error: xml.cpp: In member function ‘xml::document& xml::document::parse(std::vector<unsigned char, std::allocator<unsigned char> >&)’: xml.cpp:25: error: no matching function for call to ‘xml::document::characters(std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >)’ xml.hpp:24: note: candidates are: virtual void xml::document::characters(unicode::string) unicode::string definition starts: namespace unicode { typedef std::size_t code_point; class string : public std::basic_string<code_point> { Is "std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >" not the same as "unicode::string"? If not why is it not? Etienne
On Fri, May 1, 2009 at 9:22 AM, Etienne Philip Pretorius <icewolfhunter@gmail.com> wrote:
namespace unicode { typedef std::size_t code_point; class string : public std::basic_string<code_point> {
Is "std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >" 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
Dominique Devienne wrote:
On Fri, May 1, 2009 at 9:22 AM, Etienne Philip Pretorius <icewolfhunter@gmail.com> wrote:
namespace unicode { typedef std::size_t code_point; class string : public std::basic_string<code_point> {
Is "std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >" 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
Please find attached the classes that I am working on. If someone could point out where I made the error, will appreciate it. Etienne
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
Rodrigo Madera wrote:
How much time do we have to do that, boss?
I am just worried that I did not give enough information for someone to tell me where the fault is. You could ignore me, and that is fine. I am not telling anyone to help me... I was just wandering since classes are data types and the error that the compiler throws out is saying that they are not the same type. So looking at the class definitions I can not see where I made my mistake. Etienne
I think I figured it out. Something wrong between the data types of what unicode::string::substring method returns and unicode::string. Etienne
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 On Fri, May 1, 2009 at 12:24 PM, Etienne Philip Pretorius < icewolfhunter@gmail.com> wrote:
I think I figured it out. Something wrong between the data types of what unicode::string::substring method returns and unicode::string.
Etienne _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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<unicode_point>::substr and therefore returning std::basic_string<unicode_point> 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 10:38 AM, Etienne Philip Pretorius <icewolfhunter@gmail.com> wrote:
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.
It's not only a question of char size, the encoding matters. I don't know for sure, but I bet Windows' can represent all code points by using pairs of 16-bit wide chars (surrogate pairs). As long as you have a way to convert the current wstring instances to a know encoding like UTF-8, UTF-16 (bom, le, be), or UTF-32 for wire transport or persistence, the actual representation of wstring doesn't matter. Of course I don't know what the encoding conversion methods would be for Windows and Linux and *nix in general. Does Boost.IOStream provide those in a portable fashion? I'd be interested on pointers on this topic if you know about those methods. Thanks, --DD
On Fri, May 1, 2009 at 9:35 AM, Dominique Devienne <ddevienne@gmail.com> wrote:
On Fri, May 1, 2009 at 9:22 AM, Etienne Philip Pretorius <icewolfhunter@gmail.com> wrote:
namespace unicode { typedef std::size_t code_point; class string : public std::basic_string<code_point> {
Is "std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >" 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
On Fri, May 1, 2009 at 10:32 AM, Dan Day <coolmandan@gmail.com> wrote:
Wouldn't then the OP rather use uint32_t or similar?
AFAIK this type doesn't exist on all platforms portably.
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?
The few 64-bit platforms I've seen keep [unsigned] int at 32-bits. --DD
Kenny Riddile wrote:
Dominique Devienne wrote:
On Fri, May 1, 2009 at 10:32 AM, Dan Day <coolmandan@gmail.com> wrote:
Wouldn't then the OP rather use uint32_t or similar?
AFAIK this type doesn't exist on all platforms portably.
#include <boost/cstdint.hpp>
boost::uint32_t
Thank you. Will use it instead of 'unsigned int'
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Dominique Devienne <ddevienne@gmail.com> writes:
On Fri, May 1, 2009 at 10:32 AM, Dan Day <coolmandan@gmail.com> 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
unicode::string definition starts:
namespace unicode { typedef std::size_t code_point; class string : public std::basic_string<code_point> {
Is "std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >" not the same as "unicode::string"?
No.
If not why is it not?
Because unicode::string is a descendant of std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >, so these are 2 distinct types. If you want just to alias an existing type, use "typedef" instead of inheritance.
participants (1)
-
Dan Day -
Dominique Devienne -
Etienne Philip Pretorius -
Igor R -
Kenny Riddile -
Rodrigo Madera -
tom fogal