lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Safe to substitute std::string for wxString?


From: Greg Chicares
Subject: Re: [lmi] Safe to substitute std::string for wxString?
Date: Thu, 30 Mar 2006 14:14:10 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

On 2006-3-30 11:00 UTC, Vadim Zeitlin wrote:
> On Thu, 30 Mar 2006 03:08:56 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> However, I guess that change would force us to use '--enable-stl'
> GC> (or at least the weaker use-std-string option) always.
> 
>  I'm confused -- isn't it already the case that lmi requires --enable-stl?

Yes, I believe lmi requires '--enable-stl' already. I just feel that
I should think twice before replacing
  code that works without that configuration option
with
  code that works only with that configuration option
in this particular module. I tend to think that, well, this is 2006,
and it's okay to require a C++ standard library implementation, for
lmi at least. But of course wx is different, and tries much harder
to maintain compatibility with outdated tools.

> GC> Is there a way to avoid forcing that requirement? Has wx evolved
> GC> conversion operators that make this work automagically?
> 
>  The sole presence of the conversion ctor wxString(std::string) in the
> library forces to link in libstdc++ which is something some people want to
> avoid when creating statically linked applications under Unix.

Let me make sure I understand this. I think you're saying that they

 - don't use anything in libstdc++ in their application code

[I guess they use only wxString, wx containers, and wx streams--or
do they just not use anything in the C++ standard library at all?]

 - and therefore don't want wx to require libstdc++ either.

Is that right? If so, then they couldn't use lmi at all that way,
because lmi uses many C++ standard-library features. I just want
to be sure I'm not creating an actual inconvenience for anyone
who could use lmi on a different platform.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]