wxUSE_STL - Discussion on what it does, pros, cons

This forum can be used to talk about general design strategies, new ideas and questions in general related to wxWidgets. If you feel your questions doesn't fit anywhere, put it here.
Post Reply
darlingm
In need of some credit
In need of some credit
Posts: 7
Joined: Sat Apr 11, 2015 7:27 pm

wxUSE_STL - Discussion on what it does, pros, cons

Post by darlingm »

Hoping there could be a discussion on wxUSE_STL, clarifying what it does, and the pros and cons to using it.

I've done a lot of searching, and haven't ran across something like this. Lots of discussions of build errors, how to set it, confusing statements whether the flag causes wxString to internally use or inherit from std::string, etc. Lots of discussions many many years old that are likely outdated.

Cross-Platform GUI Programming with wxWidgets says you can "use STL functionality" by setting wxUSE_STL, to base wxString and other containers on the STL equivalents. It mentions this can increase library size and compilation time, especially with GCC.

Setup.h itself says it maximizes interoperability with the STL, at the cost of backwards compatibility.

Those things are great to know, but as a first time wx user, I feel like I have no idea what the switch is really about. A statement of using STL functionality or maximizing interoperability with the STL leaves me not really know what difference it is going to make.

Is writing my code simpler one way or the other? Is one more efficient (faster) than the other? If I'm starting from scratch, and don't care about backwards compatibility, are there any reasons NOT to use wxUSE_STL? What things can I do with the flag, that I couldn't without it? What things can I do without the flag, that I can't with it? If I'm using std::string's elsewhere in my app and with other libraries, how does that affect my choice? Does wxUSE_STL allow wx to natively take std::string's without re-copying the actual data into a wxstring.
User avatar
eranon
Can't get richer than this
Can't get richer than this
Posts: 867
Joined: Sun May 13, 2012 11:42 pm
Location: France
Contact:

Re: wxUSE_STL - Discussion on what it does, pros, cons

Post by eranon »

Your question is very personal and you'll obtain very different answers depending on the profile of the developer who will *try* to reply to this large question. Looking the subject from the sky, I'll reply this : STL like Boost are large libraries providing facilities to erase/reduce some big points of difficulties about complexity, memory management, all these pieces of puzzle which are as many risk of errors. wxWidgets is presented as being a GUI toolkit but is in reality far more and provide a lot of classes overlapping what I talked about previously... So, knowing you start from scratch in your project (so you don't already relay on STL or Boost) and knowing you don't have habits, I'll go with wxWidgets as it is by default (ie. wxUSE_STL 0).

Here is what is said in Setup.h :

Code: Select all

// Recommended setting: 0 as the options below already provide a relatively
// good level of interoperability and changing this option arguably isn't worth
// diverging from the official builds of the library.
#define wxUSE_STL 0
And more generally, my own opinion is that we don't add any library (big major ones or specific feature oriented, whatever) if we don't really need it. So, if you don't know what a library does and succeed to live without it, there's no reason to use it. I know that a lot of developers go with their habits (e.g. because they are used to use Boost, they start every project adding Boost, whatever be the specific project, or they go with wxWidgets even if their project is not destinated to be cross-platform -- well, in this latter case, we never know, so it can be a precaution too, to keep an open future).

Two personal examples:

When I started my own wxWdgets-based project, I read everywhere that it's clever to not relay on the wxWidgets's classes about XML management. But, after checking that these classes will be perennial (otherwise, I changed my orientation), I decided to take a try... And I didn't encountered any big difficulty (just some key methods to add), so I preserved me from using an added third party library (ie. a piece more to build, follow, update from time to time).

During my development I needed to communicate with a server, so, in the same spirit, I started to try with the wxWidgets classes about communication (sockets, HTTP/FTP)... But it was too unstable (I did several attempts of course) and I quickly understood that it was not a priority in the wxWidgets roadmap to improve this field in a near future (after all, a GUI-oriented lib is not a communication one). Then, in this specific case, I added a dedicated library (i.e libcurl). But -- and this is my message -- because I needed it for sure in my concrete project, not because it's a common practice in the profession (it could be different if I was salaried, of course).

Well, but being back to STL, here are maybe two places for, I think, interesting reading : http://programmers.stackexchange.com/qu ... evelopment and http://engineering.adap.tv/listing/why- ... -or-boost/

I don't re-read ; 4:30 AM here and I'm a little bit zzzzzzzzzzz °O°
Good night/day...
[Ind. dev. - wxWidgets 3.0/3.1 under "Win 7 64-bit, TDM64-GCC" + "OS X 10.9, LLVM Clang"]
User avatar
tierra
Site Admin
Site Admin
Posts: 1355
Joined: Sun Aug 29, 2004 7:14 pm
Location: Salt Lake City, Utah, USA
Contact:

Re: wxUSE_STL - Discussion on what it does, pros, cons

Post by tierra »

I don't think Eranon is entirely clear on this either, so I'll give a shot at explaining it as I understand it.

The only difference that changing wxUSE_STL makes is whether or not core wxWidgets classes use STL internally. The STL "compatibility" API is provided regardless of this setting (but will use the core STL methods directly rather than methods provided by wxWidgets if wxUSE_STL is enabled). The wxUSE_STL setting was really only designed to be used by wxWidgets itself during development and testing of the new STL containers within the core wxWidgets containers classes. It's not terribly useful for application developers.

wxWidgets initially supported many compilers without support of STL for a long time (as well as compilers that did, but whose implementations of the STL were inadequate). For those cases, almost all of the wxWidgets containers were built to work without STL support at all (wxArray, wxList, wxHashMap, etc). After widespread adoption of STL, it became useful to build versions of these classes that simply used the equivalent STL containers, however, all API has maintained backwards compatibility. You have to remember that by the time this happened, there's already a massive amount of applications built on top of the wxWidgets versions, so it's just too late to simply remove these classes and tell everyone to simply use STL. That would break so many applications all at once.

The compatibility API is provided in order to make the process of switching any application code using either the wxWidgets containers or the STL containers easier. You could start out using wxWidgets containers, while strictly only using the equivalent STL methods on them, leaving you the option to easily switch them out in the future. Additionally, if you wanted to port over code using STL containers to use the wxWidgets ones instead (if say, you needed support for one of those older compilers), that would be easier as well.

That said, let me try to address your questions:
darlingm wrote:Is writing my code simpler one way or the other?
It's mostly the same, but it might be worth pointing out that STL provides significantly more types of containers with a larger range of flexibility than what wxWidgets provides, so you might want to stick with only using the STL just to be consistent throughout your code. This is a good option these days since there's really very few compilers without adequate support for the STL.
darlingm wrote:Is one more efficient (faster) than the other?
The longer build times specifically come from compiling code using C++ templates. The STL containers use templates heavily, but the non-STL versions of those wxWidgets containers don't. If you avoid wxWidgets data structures in your own code, this is only going to impact build times for the wxWidgets library itself, it won't affect your application in any way. If you use the wxWidgets containers in your application code, then enabling wxUSE_STL will slow down your application build times (but it's pretty negligible these days).

As far as runtime application performance, I really haven't heard any complaints about the performance, but I also haven't seen any benchmarks either. It should be pretty much the same though.
darlingm wrote:If I'm starting from scratch, and don't care about backwards compatibility, are there any reasons NOT to use wxUSE_STL?
Eranon covered this, sticking with the default option more reliably ensures compatibility with all distribution-provided libraries.
darlingm wrote:What things can I do with the flag, that I couldn't without it? What things can I do without the flag, that I can't with it?
Really nothing on either side. Regardless of whether wxWidgets uses STL or not, it doesn't prevent you from using STL in your application.
darlingm wrote:If I'm using std::string's elsewhere in my app and with other libraries, how does that affect my choice? Does wxUSE_STL allow wx to natively take std::string's without re-copying the actual data into a wxstring.
std::string is part of the C++ Standard Library, not the Standard Template Library. wxUSE_STL has no implications here.
User avatar
eranon
Can't get richer than this
Can't get richer than this
Posts: 867
Joined: Sun May 13, 2012 11:42 pm
Location: France
Contact:

Re: wxUSE_STL - Discussion on what it does, pros, cons

Post by eranon »

tierra wrote:I don't think Eranon is entirely clear on this either, so I'll give a shot at explaining it as I understand it.
Effectivelly, Bryan (tierra), you're right, since I thought the wxUSE_STL what about use or not use rather than direct or indirect use... But, reading you, still not sure to understand completely:

When wxUSE_STL is ON, it's OK, it will (I quote you) "use the core STL methods directly". This is clear enough! But, when wxUSE_STL is OFF (default setting), it's not clear for me if wxWidgets still relay on underlying STL or not. To re-use the words I used at the beginning of this message : does it's a USE/NOT-USE switch or a DIRECT*/INDIRECT one?

--
EDIT :
* Here "DIRECT" meaning "close to direct", of course, since pure direct would be simply without wxWidgets at all.
[Ind. dev. - wxWidgets 3.0/3.1 under "Win 7 64-bit, TDM64-GCC" + "OS X 10.9, LLVM Clang"]
User avatar
tierra
Site Admin
Site Admin
Posts: 1355
Joined: Sun Aug 29, 2004 7:14 pm
Location: Salt Lake City, Utah, USA
Contact:

Re: wxUSE_STL - Discussion on what it does, pros, cons

Post by tierra »

eranon wrote:But, when wxUSE_STL is OFF (default setting), it's not clear for me if wxWidgets still relay on underlying STL or not.
The library doesn't rely on STL if wxUSE_STL is off, however, it will still provide the compatibility API which is just a copy of STL API against the wxWidgets containers, without using STL. I'm just referring to how wxVector, wxStack, and wxList still mimic the equivalent STL API even when wxUSE_STL is disabled (but don't use the STL to do so).

The manual covers a bunch of this in the Containers Overview.
User avatar
eranon
Can't get richer than this
Can't get richer than this
Posts: 867
Joined: Sun May 13, 2012 11:42 pm
Location: France
Contact:

Re: wxUSE_STL - Discussion on what it does, pros, cons

Post by eranon »

OK, Tierra, thanks for this clarification. The last shadow area has been illuminated !
[Ind. dev. - wxWidgets 3.0/3.1 under "Win 7 64-bit, TDM64-GCC" + "OS X 10.9, LLVM Clang"]
Post Reply