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