Use of STL

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Post Reply
mubashar
Knows some wx things
Knows some wx things
Posts: 38
Joined: Mon Nov 01, 2004 3:26 am
Location: Lahore, Pakistan

Use of STL

Post by mubashar » Mon Nov 01, 2004 3:38 am

Hello every body :shock:

I m new to wxWidgets. i have an application already built in MFC 6.0 now i want to port all the source code in wxWidgets 2.4.2.

Now that application has much use of STL like vectors, maps, pairs, set etc etc. and i also ready in some tutor that wxWidgets do not support STL.
but i also saw a lot of code of wxWidgets on the net using STL structures and classes. i m in much confusion please show me some right path

i m using Visual Studio.Net 2003.


Thanksssss

SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am
Contact:

Post by SnakeChomp » Mon Nov 01, 2004 5:31 am

wxWidgets is beginning to move to implementing things via STL. Taken from setup.h:

//Set wxUSE_STL to 1 to derive wxList(Foo) and wxArray(Foo) from
// std::list<Foo*> and std::vector<Foo*>, with a compatibility interface,
// and for wxHashMap to be implemented with templates.

wxWidgets did not officially use STL before because it was said to be unportable and not widely supported by all compilers. But that was then, and this is now.

That being said, you can use STL stuff in your application all you want. Go ahead and derive a class from std::vector, wxWidgets won't care. It can't care. The one thing it technically doesn't support yet is c++ RTTI, as it uses its own macro based RTTI system. Although that may be changing as well? I'm not sure on that one.

And by the way, you should port into 2.5.3 instead of 2.4.2. No reason not to. (Note "unstable" means that the API may possibly change, as in removing, changing, or adding functions. Not that it crashes or is not for production use.)

mubashar
Knows some wx things
Knows some wx things
Posts: 38
Joined: Mon Nov 01, 2004 3:26 am
Location: Lahore, Pakistan

Post by mubashar » Mon Nov 01, 2004 6:02 am

Thanksss For you reply "SnakeChomp"

it seems that you offered me water of life :D .

but is there any efficiency leak in using STL as i aslo read on some forums and FAQs wxList is more faster then std::vector. and so on so on for other classes too.

and one more thing that i can't change libraray to 2.5.3 as i am advised 2.4.2 by our PM :shock: :shock:


Thanks anyway
i was master of wxWidgets just! forgotton how to build :(

HopeSeekr
Earned a small fee
Earned a small fee
Posts: 16
Joined: Sun Aug 29, 2004 1:07 pm
Contact:

Post by HopeSeekr » Mon Nov 01, 2004 6:22 am

regardless of what others may tell you, even if they are authoritative wx coders, from my own extensive research using real-time OS-wide profilers (notably oprofile), I can confirm that the usage of STL-specific code is far more efficient than wx's pre-ISO-C++ implementations of the same.

For instance, I recently converted all of xMule's ubiquitous wxLists to std::lists, wxMap to std::map, and wxArrays to std::vectors. Performance jumped due to these changes to about 1/20th of the CPU cycles of the wx-variants.

The only real argument for using wx variants is that some of them are 'easier'. This *is* true for one class in particular, wxString, which greatly extends the abilities of std::string; yet all the other wx ADT are about equally endowed and easy/hard to use as their ISO counterparts.

We found that wxString was still too much overhead and wrote a std::string derived wrapper that is backwards compatible with wxString functionality, but using pure ISO-c++ conventions wherever possible.

Besides, far more people willll understand/be able to suport ISO code, and ti is *far* easier to migrate away from wx if you use it ubiquitously.

mubashar
Knows some wx things
Knows some wx things
Posts: 38
Joined: Mon Nov 01, 2004 3:26 am
Location: Lahore, Pakistan

Post by mubashar » Mon Nov 01, 2004 7:26 am

HopeSeekr wrote:from my own extensive research using real-time OS-wide profilers (notably oprofile), I can confirm that the usage of STL-specific code is far more efficient than wx's pre-ISO-C++ implementations of the same.

And what about compatibility... can i use STL for all plateforms supported by wxWidgets???
i was master of wxWidgets just! forgotton how to build :(

geon
I live to help wx-kind
I live to help wx-kind
Posts: 189
Joined: Tue Sep 07, 2004 4:10 pm
Location: Sweden, Uppsala

Post by geon » Mon Nov 01, 2004 10:43 am

can i use STL for all plateforms supported by wxWidgets???
You can use STL on all platforms that "matters". And if you are speciffically developing for a platform that don't, you probably allready have the skills needed to port an existing STL implemetation.

Avi
Super wx Problem Solver
Super wx Problem Solver
Posts: 398
Joined: Mon Aug 30, 2004 9:27 pm
Location: Tel-Aviv, Israel

Post by Avi » Mon Nov 01, 2004 1:38 pm

Every good compiler today supports the STL library. STL classes/templates are very optimized and usually perform great. I suggest you learn how to use it, since even wxWidgets will use it. I personally know that it is supported under Linux/FreeBSD/Windows/MacOS X. I find it hard to believe you'll need more platforms than that anyway. :)

ezequielv
Earned a small fee
Earned a small fee
Posts: 19
Joined: Sun Oct 10, 2004 9:20 pm
Location: Berkshire, England

Post by ezequielv » Mon Nov 01, 2004 3:41 pm

Avi wrote:Every good compiler today supports the STL library. STL classes/templates are very optimized and usually perform great. I suggest you learn how to use it, since even wxWidgets will use it. I personally know that it is supported under Linux/FreeBSD/Windows/MacOS X. I find it hard to believe you'll need more platforms than that anyway. :)
What about future ports, such as Cobalt (Palm OS 6)? Not all the C++ compilers for pseudo-embedded systems have STL implementations nor will handle all required C++ template features.

Ryan Wilcox
I live to help wx-kind
I live to help wx-kind
Posts: 194
Joined: Mon Aug 30, 2004 1:26 pm
Location: PA, USA
Contact:

Post by Ryan Wilcox » Mon Nov 01, 2004 4:14 pm

mubashar wrote: And what about compatibility... can i use STL for all plateforms supported by wxWidgets???
Probably. There still are brain-dead compilers out there (VC 4? OpenWatcom?) but any modern compiler should have decent STL support.
Ryan Wilcox
Wilcox Development Solutions
http://www.wilcoxd.com

HopeSeekr
Earned a small fee
Earned a small fee
Posts: 16
Joined: Sun Aug 29, 2004 1:07 pm
Contact:

Post by HopeSeekr » Mon Nov 01, 2004 8:39 pm

What about future ports, such as Cobalt (Palm OS 6)?
In those cases, I would challenge the expediency of using wxWidgets in the first place. If the hardware is too dumb to support templates and std::vector, I'd *hate* to try to run any thing that even would need a wxArray :o

If it is not a hardware-specific problem, then it must be a bytecode problem. With the increasingly-dominant cross-compiler utilized for building objects for fringe environments like PalmOS, I would assume (in my naivete) that your host compiler would support ISO-C++ and produce suitable binaries for the target.

mubashar
Knows some wx things
Knows some wx things
Posts: 38
Joined: Mon Nov 01, 2004 3:26 am
Location: Lahore, Pakistan

Post by mubashar » Tue Nov 02, 2004 3:00 am

Thanks all of you

I have got enough now NO ONE can stop me from the using STL. 8) 8) 8)
i was master of wxWidgets just! forgotton how to build :(

geon
I live to help wx-kind
I live to help wx-kind
Posts: 189
Joined: Tue Sep 07, 2004 4:10 pm
Location: Sweden, Uppsala

Post by geon » Tue Nov 02, 2004 12:06 pm

the hardware is too dumb to support templates
Templates is just a language construct. There is no way a processor could not support them. If they are not supported on a certain platform, it's because the compiler has not implemented them.

I think the gcc compiler has become quite polpular on more obscure platforms, like playstation, since it allready has great c++ support and can be modified. Probably a better alternative than to write your own compiler.

Post Reply