#if USE_WXWIDGETS
#include <wx/wx.h>
#define string wxString
#else
#include <string>
#endif
2. wx containers suck really bad. You cannot typedef them, you cannot declare them inside a class, they use obscure macros... Standard containers work really well.
The picture is:
wxWidgets containers sucks.
STL containers are great.
wxString is great.
STL string sucks (written by english people, for english people).
So I agree with thomas: using STL containers, and using wxString, but trying to use the STL string compatible functions.
Mm, what kind of problems you had? I mean, STL containers + wxString, instead of wxWidgets+std::string.
And anyways, wxWidgets 3.0 is planned to be release the next year, which will be very STL friendly.
wxWidgets currently advices not to use STL mainly because at the time of 2.0 release, the STL implementations were really bad, especially the MSVC6 one. But now the situation is better (less people using MSVC6 :)).
There is nothing to stop an application using templates or the string class for its own purposes. With wxWidgets debugging options on, you may find you get errors when including STL headers. You can work around it either by switching off memory checking, or by adding this to a header before you include any STL files:Code#ifdef new
#undef new
#endif
I think they redefine (by default) the new operator, for debugging purposes, which I think can be safely turned off.
I use STL a lot, because I hate wx containers. The blockallocator in Code::Blocks uses STL, the SVN plugin does, the Uservariable manager does... we compile tinyXML in STL mode, too (although we could do otherwise). Rick uses STL in his new tree class, the AStyle plugin uses STL if I remember correctly... just try and do a "find in files" on the project.That's is interesting. My doubts are vanishing :D. Probably, the problems I have had by using STL and wxWidgets have another source(s).
If you want to improve CB, toward what's the best CodeCompletion systems today, then orient yourself instead on Visual Slick Edit (http://www.slickedit.com/content/view/73/60/) (go to Cool Demos). Not on an outdated VC plugin!
I began a project this summer for my employer to reimplement a server written in Perl on a new machine in C++. Target machine is Solaris10-Sparc. So I thought: Great I can develop on Windows with CodeBlocks and just move the files over and compile them there. But apart from the lack of Makefile support the biggest downer for me was the very incomplete support for CodeCompletion that helps you with new Code and Libraries!
So, after 3 weeks of struggling with CB I gave up and bought the excellent Visual Slick Edit.
I have used VSE for some years and have not come across a more convenient Editor since, including VisualC 6-8 ! So I really think that you should let yourself be influenced by this editor as the top notch on the market. Because I would love to use CB for everything as soon as possible!
One key of success is the excellent Tagging-System in VSE which allows you to add new interfaces anytime!
May be better use sqlite (www.sqlite.or) for store current project information (parsed function, variable and so on). Back-end in background get all information and write it to database. Only back-end may write and delete information from sqlite database. Front-end(s) use database for reading. Front-end(s) can get information in one transaction (for get consistent information).
With this scheme developers can integrate other back-end (other parse engine) into CB. And plugin-developer can also easy get needed info from parser.