bug with wxVariant
Alexander Vassilev
avasilev at voipgate.com
Mon Oct 23 10:28:38 PDT 2006
Hm, thats a good point. Not having wxString(int) is sometimes really
annoying. I wonder why this constructor wasn't defined simply as
explicit and left public. THis would solve both problems in my opinion.
Maybe a wxWidgets developer could comment on this?
Regards
Alex
Sebastien Senechal wrote:
> yeurk, my mistake. I meant:
>
> wxLogVerbose( "there is " + wxString(nb) + " items containing " +
> wxString(nb2) + "other items")
>
> will result in compiler complaing wxString(int) is private
> Although i find this is inconvenient, i found my answer in wxWidget code:
>
>
>
> // if we hadn't made these operators private, it would be possible to
> // compile "wxString s; s = 17;" without any warnings as 17 is implicitly
> // converted to char in C and we do have operator=(char)
> //
> // NB: we don't need other versions (short/long and unsigned) as attempt
> // to assign another numeric type to wxString will now result in
> // ambiguity between operator=(char) and operator=(int)
> wxString& operator=(int);
>
> // these methods are not implemented - there is _no_ conversion from int to
> // string, you're doing something wrong if the compiler wants to call it!
> //
> // try `s << i' or `s.Printf("%d", i)' instead
> wxString(int);
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-users-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wx-users-help at lists.wxwidgets.org
>
>
>
More information about the wx-users
mailing list