[wx-dev] compilation errors

[Vaclav Slavik]

Vadim Zeitlin wrote:
> On Sun, 13 Apr 2008 14:41:35 -0700 Jeff Tupper
> <tupperlists at gmail.com> wrote:
>
> JT> Perhaps it is a good time to come full circle. I started this
> JT> thread after I noticed my code wouldn't compile under trunk.

(Jeff:: Unfortunately you never mentioned that the string changes 
broke your code in the bug you filed, you only said there should be a 
way for append() to append a substring...)

>  So now the question is whether we should also add an overload of
> append() taking "wxUniCharRef *" to allow the original code to
> compile. I think it should be possible to do it without introducing
> new overload ambiguities 

Me too, wxUniCharRef* is not "similar" to any other types used there. 
The problem is elsewhere: this would also need to work with 
operator[] const, which returns wxUniChar, not wxUniCharRef. As far 
as I can tell, that's only possible by either adding iterator field 
to wxUniChar (twice as much data to copy) or by using wxUniCharRef 
everywhere. But wxUniCharRef is less efficient -- it decodes the 
character when dereferenced and even though we could probably cache 
the returned value, it would still be more complicated and possibly 
harder to inline code.

In short it is doable, but it's not clear if it is worth the cost that 
would be imposed on all wxUniChar(Ref) uses.

>  Another thing we could do would be to add append(wxCStrData, int)
> overload to allow this
>
> 	some_string.append(other_string.c_str() + start, len)
>
> to compile. But this one would probably result in ambiguity
> problems due to the existing (const char *, int) and (const wchar_t
> *, int).

We already have such overload for assign(), so I think having it for 
append() would be OK too. I don't see how could it result in 
ambiguities with char* and wchar_t* versions (there's an ambiguity 
_now_, passing c_str() to append() won't compile because of missing 
wxCStrData overload I think). But there's only one way to know: I'll 
try adding it.

Regards,
Vaclav


-- 
PGP key: 0x465264C9, available from http://pgp.mit.edu/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wxwidgets.org/pipermail/wx-dev/attachments/20080414/894d813f/attachment.pgp