Home > Archive > VC STL > April 2005 > Why use STL?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Lisa Pearlson 2005-04-11, 4:04 pm |
| Hi,
Occasionally I find code that uses STL (same as STD::<function> right?).
Usually these are vectors and occasionally strings.
What other classes does STL provide? Where can I find a list of them?
And why do people use STL? I thought that STL was a library that uses OS
neutral code, and can be compiled on other platforms more easily, such as
unix / linux.
Is this correct? I guess STL may also be a little faster. Is there any other
reason to use STL?
Lisa
| |
| Lisa Pearlson 2005-04-11, 4:04 pm |
| The reason why I ask this, is because everything you can do with STL, you
can do with MFC classes such as CArray, CString, CMap, etc.
So, why use STL?
| |
| Tom Widmer 2005-04-11, 4:04 pm |
| Lisa Pearlson wrote:
> The reason why I ask this, is because everything you can do with STL, you
> can do with MFC classes such as CArray, CString, CMap, etc.
>
> So, why use STL?
- portable
- standard
- generic
- clean design (in contrast to MFC)
- value based rather than reference based (also a di vantage, but
mitigated by various boost libraries)
- well documented (e.g. www.dinkumware.com, http://www.sgi.com/tech/stl/
msdn.microsoft.com, etc.)
- many books on the subject
- encourages efficient programming (e.g. std::remove_if rather than
O(n*n) iteration).
- as fast as hand-coded, non-generic alternatives in many case
- exception based error reporting
- future-proof (as much as C++ is)
- highly extensible - it is as much a library of concepts as a source
code library.
- many extensions available (particularly www.boost.org)
I'm sure there are further advantages. There are a few divantages of
course:
- std::string isn't very well designed in hindsight
- some of the concepts need further refinement, and some new concepts
are needed (e.g. moveable, property maps, etc.)
- possible code bloat from multiple instantiations (this may apply to
MFC too)
- unfamiliar concepts to some programmers
- a lot of software isn't of great algorithmic complexity, and thus
doesn't benefit as much as it might from the iterator/algorithm abstraction
And others, no doubt.
Tom
| |
| Stephen Howe 2005-04-11, 4:04 pm |
| > The reason why I ask this, is because everything you can do with STL, you
> can do with MFC classes such as CArray, CString, CMap, etc.
Not everything can be done with the MFC container classes.
In particular the MFC does not make the same big-O guarantees on various
operations and it is weak when it comes to providing algorithms.
The STL comprises 3 things of major importance that are designed to work
together in a consistenct fashion:
template containers, iterators and algorithms.
The template containers consist of
vector
deque
list
set
multiset
map
multimap
string
In addition, various vendors provide other container classes as extensions
like
rope
slist (single-linked list, list above is double-linked)
hashset
hashmap
hashmultiset
hashmultimap
> So, why use STL?
In more ways than one, they are superior to the MFC container classes:
- better overall design
- better documented behaviour if your class throws exceptions
- better documented performance guarantees
- an incredible choice of algorithms
A minimum requirement is whatever objects you store in the containers are
assignable and copyable.
Stephen Howe
| |
| Lisa Pearlson 2005-04-11, 4:04 pm |
| Thank you for your reply Tom.
Few questions regarding your answers follow:
> - value based rather than reference based (also a divantage, but
> mitigated by various boost libraries)
What's the advantage of value based?
What's wrong with MFC way ? :
CArray<CMyObj,CMyObj&> ar;
CMyObject o;
ar.Add(o);
CMyObject o2 = ar[0];
> - highly extensible - it is as much a library of concepts as a source code
> library.
Could you elaborate on this statement a bit more? How this is different from
MFC template classes?
I do understand in *some* cases STL is more efficient. Most software
written, is specifically written for WinOS platform and it being cross
platform isn't really significant. MFC is extensible too.. (yes, not always
clean and efficient)
Lisa
| |
| Lisa Pearlson 2005-04-11, 4:04 pm |
| I appreciate you listing the common template containers.
Seems STL is cleaner design (except string class?), faster, more predictable
performance and error states, cross platform.
As for extensibility.. MFC is is extensible too.
I'm guessing there are Win32 API (non MFC) based replacements for windows
controls like CListCtrl, which use STL for better performance, sorting,
etc.?
Lisa
"Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom> wrote in message
news:%23sAjwzpPFHA.3076@TK2MSFTNGP12.phx.gbl...
>
> Not everything can be done with the MFC container classes.
> In particular the MFC does not make the same big-O guarantees on various
> operations and it is weak when it comes to providing algorithms.
>
> The STL comprises 3 things of major importance that are designed to work
> together in a consistenct fashion:
> template containers, iterators and algorithms.
>
> The template containers consist of
> vector
> deque
> list
> set
> multiset
> map
> multimap
> string
>
> In addition, various vendors provide other container classes as extensions
> like
> rope
> slist (single-linked list, list above is double-linked)
> hashset
> hashmap
> hashmultiset
> hashmultimap
>
>
> In more ways than one, they are superior to the MFC container classes:
>
> - better overall design
> - better documented behaviour if your class throws exceptions
> - better documented performance guarantees
> - an incredible choice of algorithms
>
> A minimum requirement is whatever objects you store in the containers are
> assignable and copyable.
>
> Stephen Howe
>
>
| |
| Tom Widmer 2005-04-11, 4:04 pm |
| Lisa Pearlson wrote:
> Thank you for your reply Tom.
>
> Few questions regarding your answers follow:
>
>
>
>
> What's the advantage of value based?
> What's wrong with MFC way ? :
>
> CArray<CMyObj,CMyObj&> ar;
> CMyObject o;
> ar.Add(o);
> CMyObject o2 = ar[0];
That's value-based in any case, so actually value-based vs
reference-based isn't a difference between MFC and STL in any case.
>
>
> Could you elaborate on this statement a bit more? How this is different from
> MFC template classes?
You can easily add new algorithms to the algorithms library, and the new
algorithms will work with iterators meeting the algorithm's
requirements. MFC is a similar library to the containers part of the
STL, but the STL's most important libraries are the iterators and
algorithms, which MFC doesn't cover at all!
> I do understand in *some* cases STL is more efficient. Most software
> written, is specifically written for WinOS platform and it being cross
> platform isn't really significant.
While the majority of desktop applications are probably Windows only,
I'm not sure that covers the majority of applications (e.g. servers,
embedded devices, internet and network infrastructure).
Tom
| |
| Tom Widmer 2005-04-11, 4:04 pm |
| Lisa Pearlson wrote:
> I appreciate you listing the common template containers.
> Seems STL is cleaner design (except string class?), faster, more predictable
> performance and error states, cross platform.
>
> As for extensibility.. MFC is is extensible too.
Indeed, but the STL includes many more extensible generic concepts
(containers, algorithms, iterators, functors, traits, etc.).
> I'm guessing there are Win32 API (non MFC) based replacements for windows
> controls like CListCtrl, which use STL for better performance, sorting,
> etc.?
Many C++ GUI libraries exist, some of which use STL. But the most
popular ones don't use it (WxWindows, QT, MFC).
http://www.atai.org/guitool/ provides a list of libraries. I notice that
"Whisper" is explicitly mentioned as using the STL.
Tom
| |
| Igor Tandetnik 2005-04-11, 4:04 pm |
| "Lisa Pearlson" <no@spam.plz> wrote in message
news:eDku1BqPFHA.1392@TK2MSFTNGP10.phx.gbl
> I'm guessing there are Win32 API (non MFC) based replacements for
> windows controls like CListCtrl, which use STL for better
> performance, sorting, etc.?
MFC control wrappers have nothing to do with MFC containers. The two
could as well be two separate libraries.
CListCtrl is just a wrapper around ListView standard control. Sorting
and other processing tasks are implemented inside the OS, MFC just
forwards the calls to Win32 API. Whether this internal implementation
uses MFC, STL or something else is irrelevant (I doubt either MFC or STL
is used).
If you are interested in convenient standard control wrappers other than
those in MFC, look at WTL:
http://wtl.sourceforge.net/
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
| |
| Stephen Howe 2005-04-11, 4:04 pm |
| > I'm guessing there are Win32 API (non MFC) based replacements for windows
> controls like CListCtrl, which use STL for better performance, sorting,
> etc.?
Well no. You need 3rd-party for that.
Stephen Howe
| |
| Ian Semmel 2005-04-11, 9:01 pm |
| I'm using STL on a project because it is eventually going to run on linux.
I wouldn't bother with it for a Windows project.
Lisa Pearlson wrote:
> Hi,
>
> Occasionally I find code that uses STL (same as STD::<function> right?).
> Usually these are vectors and occasionally strings.
>
> What other classes does STL provide? Where can I find a list of them?
>
> And why do people use STL? I thought that STL was a library that uses OS
> neutral code, and can be compiled on other platforms more easily, such as
> unix / linux.
>
> Is this correct? I guess STL may also be a little faster. Is there any other
> reason to use STL?
>
> Lisa
>
>
| |
| Lisa Pearlson 2005-04-12, 4:00 am |
| I like cross platform coding. But usually, code that is intended for cross
platform compile, seems to be in C rather than C++, so I've noticed.
I'd love to code flexible and cross platform, but I think it will be
terribly hard to not use windows specific stuff. Most of my applications
revolve around the GUI, and the GUI is quite platform specific (unless we
use cross platform toolkits, which I imagine are a kind of proxy classes
that wrap native controls via standard interfaces, such as WTL??? (not sure
if WTL is about that)).
I find it extremely hard to even develop MFC-free applications. CString is
one I usually miss too much. And using windows controls by SendMessage is
quite cumbersome. So I think using wrappers is quite essential for any
decent coding effort, but using libraries providing a standard interface
(function, not COM) would be nice..
Lisa
"Ian Semmel" <isemmel@removejunkmailrocketcomp.com.au> wrote in message
news:%23tPluetPFHA.2468@tk2msftngp13.phx.gbl...[color=darkred]
> I'm using STL on a project because it is eventually going to run on linux.
>
> I wouldn't bother with it for a Windows project.
>
> Lisa Pearlson wrote:
| |
| Simon Trew 2005-04-12, 4:00 am |
| "Tom Widmer" <tom_usenet@hotmail.com> wrote in message
news:O068wTqPFHA.1176@TK2MSFTNGP12.phx.gbl...
> While the majority of desktop applications are probably Windows only, I'm
> not sure that covers the majority of applications (e.g. servers, embedded
> devices, internet and network infrastructure).
I think you're about right there. Our desktop clients are mostly Windows (we
have a couple of Mac apps and are porting our client to Qt to use
non-windows clients) but our non-UI software is virtually all
cross-platform. We take it for granted that the STL (C++ Standard Library,
whatever) works as advertised on whatever platform we choose. We have a
Windows compatibility library (i.e. implement a handful of non-UI Windows
APIs in platform-independent terms, in preference/deference to changing the
existing code), but on the whole prefer platform-independent code written
against the STL and other portable runtime libraries. We test code mostly on
Windows, as it has a far superior interactive debugging environment to our
other platforms, and only debug on the other platforms when things work
differently. (We have reasonably comprehensive unit tests and regression
tests etc. which run on all platforms as part of our nightly builds, too, so
the risk of doing this is not as high as it might be. Anyway, I think that
writing or converting code to work cross-platform generally increases its
quality.)
The only exception I would take is about embedded platforms. Perhaps because
of the code bloat you alluded to, I believe that embedded platforms often do
not ship with a decent or complete STL. I could well be wrong here as I've
not done embedded myself for a few years now.
S.
| |
| Simon Trew 2005-04-12, 4:00 am |
| "Lisa Pearlson" <no@spam.plz> wrote in message
news:eDku1BqPFHA.1392@TK2MSFTNGP10.phx.gbl...
>
> I'm guessing there are Win32 API (non MFC) based replacements for windows
> controls like CListCtrl, which use STL for better performance, sorting,
> etc.?
As Igor said, CListCtrl is simply a wrapper for the common "listview"
control which has been around since Win95 (and similarly for CTreeCtrl etc
as you implied).
Rarely is Igor wrong or unclear, so I hesitate to add that the sorting of
data in such controls is usually implemented by a callback function, and you
can implement this in terms of STL or MFC or roll-your-own code, however you
wish. Preciently, the requirements of the sorting callbacks are hardly
stronger than those of operator< that most sorted STL containers require of
their elements, so they are very easy to implement in STL terms.
For list controls in particular, it's common to specify a callback for
sorting, since one often wants to sort on columns (sub-items) other than the
first.
| |
| Simon Trew 2005-04-12, 4:00 am |
| "Lisa Pearlson" <no@spam.plz> wrote in message
news:%237KhKQvPFHA.2972@TK2MSFTNGP14.phx.gbl...
>I like cross platform coding. But usually, code that is intended for cross
>platform compile, seems to be in C rather than C++, so I've noticed.
I think there is a significant amount of cross-platform C++ around. I'd hate
to mention boost, since it has numerous (thousands) of platform-dependent
workarounds (not its fault), but there are many other significant codebases
that use C++ cross-platform. And have been doing so since at least '88 when
I started using VxWorks for embedded systems, cross-platform. (And we didn't
have a standard then, or the STL).
I'm very impressed with Qt (www.trolltech.com) as a cross-platform GUI, but
there's no point in using it if your desktop apps are exclusively Windows.
As others have mentioned, Qt also eschews the STL and implements its own
containers etc, but as far as I see, it does this as it has a strong
customer base in the embedded platform space (I assume mostly mobile
consumer devices) and as I mentioned before I believe that often these
platforms do not have an STL readily available. In my own company, I'm
strongly advocating Qt as a cross-platform GUI but also ring-fencing its use
to that and, even within the GUI, not using Qt-based containers where STL
ones can be reasonably used instead. I think the same would apply to MFC,
stripped of the cross-platform argument. Remember, MFC's containers were
implemented before STL was born-- not to say that's bad, just that they were
written to fit a need that now does not exist.
S.
| |
| Lisa Pearlson 2005-04-12, 4:00 am |
| Any clue how STD and .NET relate? In other words, is STD still useless in
the .NET world?
I am seeing fewer job openings for C++ all the time, because now they all
want .NET/C# developers.
What do you guys think of this development? Are we C++ programmers going to
become the ADA or COBOL programmers of today, in 5 years? Even though much
of it stays the same, be it C# or Java syntax. But learning all new
libraries and classes is cumbersome.
Also, much on win platform deals with COM and ActiveX. Is there a cross
platform equivalent to those technologies? Qt have any support for that? I'm
not familiar with Qt so I may be talking crap.
Lisa
"Simon Trew" <ten.enagro@werts> wrote in message
news:OdwYJivPFHA.1884@TK2MSFTNGP15.phx.gbl...
> "Lisa Pearlson" <no@spam.plz> wrote in message
> news:%237KhKQvPFHA.2972@TK2MSFTNGP14.phx.gbl...
>
> I think there is a significant amount of cross-platform C++ around. I'd
> hate to mention boost, since it has numerous (thousands) of
> platform-dependent workarounds (not its fault), but there are many other
> significant codebases that use C++ cross-platform. And have been doing so
> since at least '88 when I started using VxWorks for embedded systems,
> cross-platform. (And we didn't have a standard then, or the STL).
>
> I'm very impressed with Qt (www.trolltech.com) as a cross-platform GUI,
> but there's no point in using it if your desktop apps are exclusively
> Windows. As others have mentioned, Qt also eschews the STL and implements
> its own containers etc, but as far as I see, it does this as it has a
> strong customer base in the embedded platform space (I assume mostly
> mobile consumer devices) and as I mentioned before I believe that often
> these platforms do not have an STL readily available. In my own company,
> I'm strongly advocating Qt as a cross-platform GUI but also ring-fencing
> its use to that and, even within the GUI, not using Qt-based containers
> where STL ones can be reasonably used instead. I think the same would
> apply to MFC, stripped of the cross-platform argument. Remember, MFC's
> containers were implemented before STL was born-- not to say that's bad,
> just that they were written to fit a need that now does not exist.
>
> S.
>
| |
| Stephen Howe 2005-04-12, 4:00 am |
| > I wouldn't bother with it for a Windows project.
A console application _IS_ a Windows project.
I certainly would use the STL for that.
Stephen Howe
| |
|
| "Lisa Pearlson" <no@spam.plz> wrote in message
> The reason why I ask this, is because everything you can do with STL, you
> can do with MFC classes such as CArray, CString, CMap, etc.
>
> So, why use STL?
STL is the base.
STL does not have the Windows/MFC overhead.
STL is available on many platforms.
STL is freely available.
STL is available in source.
STL is ANSI/ISO standardized part of the C++ language.
A program which uses STL will compile on most platforms.
Professionals like standards.
Professionals don't like proprietary solutions.
| |
| adebaene@club-internet.fr 2005-04-12, 8:59 am |
|
Lisa Pearlson wrote:
> Any clue how STD and .NET relate? In other words, is STD still
useless in
> the .NET world?
They are 2 different things with unrelated purposes, so they don't
really compete IMHO.
..NET is no *only* an algorithms and containers library, it is also a
managed environnment of execution and much more, but I won't cover it
here. Even if you do consider only the .NET library, it concerns a much
broader scope of functionnalties that the STL, but it doesn't offer
- the extensibilty of STL (generics will partially correct this in .NET
2.0, but only partially).
- it's efficiency (template code can generally be aggressively
optimized by the compiler).
- it's complexity guarantees (big O).
> I am seeing fewer job openings for C++ all the time, because now they
all
> want .NET/C# developers.
It's true in part, but there is also much oversized hype around .NET.
> What do you guys think of this development? Are we C++ programmers
going to
> become the ADA or COBOL programmers of today, in 5 years?
It depends on what you do in C++. I believe .NET has some real
advantages for simple stuff such as GUI, database clients, etc... but
as soon as you've got complex algorithms, communications management and
the like, C++ still shine. Also, for now .NET is (practically) limited
to the Windows world.
Also, there is what is now called managed C++ (and soon will be
C++/CLI, when VS2005 is released). This brings you the best of both
worlds. Although the actual managed C++ has some serious drawbacks
(ugly syntax, too much C++ idioms are unusuable, etc...), C++/CLI
promises much. Among other things, it will come with a library called
STL.NET that will allow you to use the STL on managed types.
>
> Also, much on win platform deals with COM and ActiveX. Is there a
cross
> platform equivalent to those technologies?
The closest thing is probably Corba, which is a very powerfull but also
very complex remote objects infrastructure.
Arnaud
MVP - VC
| |
| Daniel James 2005-04-12, 4:01 pm |
| In article news:<eCBmegqPFHA.3336@TK2MSFTNGP09.phx.gbl>, Tom Widmer
wrote:
> Many C++ GUI libraries exist, some of which use STL. But the most
> popular ones don't use it (WxWindows, QT, MFC).
wxWidgets (as wxWindows is now called) can be compiled to use standard
library containers (as the STL container classs are now knows) in place
of the wx-specific ones. There is some talk of making this the default,
but I'm not sure what the current thinking on that is.
Cheers,
Daniel.
| |
| Duane Hebert 2005-04-12, 4:01 pm |
|
"Lisa Pearlson" <no@spam.plz> wrote in message
news:eLiZ7wvPFHA.204@TK2MSFTNGP15.phx.gbl...
> Also, much on win platform deals with COM and ActiveX. Is there a cross
> platform equivalent to those technologies? Qt have any support for that?
I'm
> not familiar with Qt so I may be talking crap.
A quick search in QtAssistant returns 367 hits for COM. I haven't used
any ActiveX or Com in my Qt projects yet but it seems to be there. You
could check at http://trolltech.com for more info.
[color=darkred]
cross[color=darkred]
Our stuff builds on win32 and linux for the most part. It's all c++.
| |
| Duane Hebert 2005-04-12, 9:02 pm |
|
"Simon Trew" <ten.enagro@werts> wrote in message
news:OdwYJivPFHA.1884@TK2MSFTNGP15.phx.gbl...
> I'm very impressed with Qt (www.trolltech.com) as a cross-platform GUI,
but
> there's no point in using it if your desktop apps are exclusively Windows.
> As others have mentioned, Qt also eschews the STL and implements its own
> containers etc, but as far as I see, it does this as it has a strong
We use MSVC7.1 because it's a very good compiler wrt standard compliance.
We don't use MFC or managed anything. We use Qt/Boost/STL stuff. Qt has
its own containers but we normally don't use them. Their stuff works well
with
STL stuff.
| |
| Ian Semmel 2005-04-12, 9:02 pm |
| Not being too pedantic, I regard a Windows project as one which has source
coding that requires Windows to run (ie processes Windows messages, uses MFC
etc), rather than a program that can run on Windows.
I use the same source (with only very minor conditional compilation) in VS and
gcc under CygWin.
Stephen Howe wrote:
>
>
> A console application _IS_ a Windows project.
> I certainly would use the STL for that.
>
> Stephen Howe
>
>
| |
| Simon Trew 2005-04-13, 4:02 am |
| "Lisa Pearlson" <no@spam.plz> wrote in message
news:eLiZ7wvPFHA.204@TK2MSFTNGP15.phx.gbl...
> Any clue how STD and .NET relate? In other words, is STD still useless in
> the .NET world?
I think yes, more or less. .NET has generics now, but this does not have the
same power as C++ templates.
> I am seeing fewer job openings for C++ all the time, because now they all
> want .NET/C# developers.
> What do you guys think of this development? Are we C++ programmers going
> to become the ADA or COBOL programmers of today, in 5 years?
No. Although I've done ADA and COBOL and many other languages
professionally, and I agree with you that to a great extent we can all learn
new languages and the libraries (and some new concepts) are the real
difficulty. But I think C++ is still the most powerful 3GL and will not be
going out of fashion any time soon. .NET is a very powerful platform, and
good at what it does, but there are many many reasons for not using it, too
(as for any other platform or implementation). I doubt it will ever become
universal; even if it becomes universal within Microsoft, I believe the
"lock-in" arguments will mean that more support will then be given to
non-Microsoft platforms. I am not anti-Microsoft but I would definitely like
to see more overt support for non-.NET technologies in Microsoft publicity.
> Also, much on win platform deals with COM and ActiveX. Is there a cross
> platform equivalent to those technologies? Qt have any support for that?
> I'm not familiar with Qt so I may be talking crap.
Qt has limited support for it on Windows platforms, but non-Windows
platforms don't really support it. We use (a nontrivial wrapper round) Xpcom
as a way to support COM interfaces on non-Windows platforms; Xpcom is (was?)
part of Mozilla. I don't mean to suggest we support COM in its entirety, but
we find IDL useful as a way to specify interfaces (um.. IDL stands for...)
and then use Xpcom to implement essentially the registry, class factories
and ithe interface dispatch.
| |
| Simon Trew 2005-04-13, 4:02 am |
| "Stephen Howe" <sjhoweATdialDOTpipexDOTcom> wrote in message
news:uGU44CwPFHA.3596@TK2MSFTNGP15.phx.gbl...
>
> A console application _IS_ a Windows project.
> I certainly would use the STL for that.
>
> Stephen Howe
I meant that I wouldn't use Qt for a Windows-only project, be it a console
app, service or GUI. It's good, but the Windows-specific APIs and libraries
such as MFC are also good if you are targetting Windows only.
| |
| Simon Trew 2005-04-13, 4:02 am |
| "Daniel James" <wastebasket@nospam.aaisp.org> wrote in message
news:VA.00000af6.4db0c738@nospam.aaisp.org...
> In article news:<eCBmegqPFHA.3336@TK2MSFTNGP09.phx.gbl>, Tom Widmer
> wrote:
>
> wxWidgets (as wxWindows is now called) can be compiled to use standard
> library containers (as the STL container classs are now knows) in place
> of the wx-specific ones. There is some talk of making this the default,
> but I'm not sure what the current thinking on that is.
>
> Cheers,
> Daniel.
Yes, I think this is the same for Qt. I'm not trying to advocate Qt here
particularly (it would be the wrong place to do so), but was trying to give
a few comparisons to MFC (which has no option to base CString on
stl::string, etc). I mentioned that I believe Qt has its own container
implementations mainly to support platforms that don't have them; in some
cases I believe that they have come to different conclusions with respect to
e.g. thread safety and copy-on-write, and again I believe this is down their
being a popular implementation on embedded platforms.
| |
| Jerry Coffin 2005-04-13, 4:02 am |
| In article <eDku1BqPFHA.1392@TK2MSFTNGP10.phx.gbl>, no@spam.plz
says...
> I appreciate you listing the common template containers.
> Seems STL is cleaner design (except string class?), faster, more predictable
> performance and error states, cross platform.
>
> As for extensibility.. MFC is is extensible too.
Almost anything is extensible to some degree in some fashion. What
the standard library provides is different from MFC in two ways:
granularity and integration.
By granularity, I mean that it provides a greater ability to extend
it by writing ONLY the bits of code that are really specific to your
extension.
By integration I mean the ability for that extension to be used
seamlessly with the existing pieces.
For example, MFC provides an array (CArray) but no deque container.
If I decide to write a deque container, I can do that, but most code
would have to be rewritten to use it.
The standard library already provides a deque, but even if it didn't
I'd be able to write one and as long as I followed it rules for how
to do so, most code that current works with a vector could also work
with my deque as well.
That's a large part of what helps the granularity -- the standard
library provides a number of algorithms, and as long as I follow the
"rules", I can easily apply those algorithms to my own containers.
Likewise, I can write new algorithms to work on existing container.
--
Later,
Jerry.
The universe is a figment of its own imagination.
| |
| Daniel James 2005-04-13, 8:59 am |
| In article news:<#y9fE77PFHA.1268@TK2MSFTNGP14.phx.gbl>, Simon Trew wrote:
> I am not anti-Microsoft but I would definitely like to see more overt
> support for non-.NET technologies in Microsoft publicity.
Hear! Hear!
(as long as it's not VB <smile>!)
Cheers,
Daniel.
| |
| Jerry Coffin 2005-04-14, 4:01 am |
| In article <ubRQ3epPFHA.3788@tk2msftngp13.phx.gbl>, no@spam.plz
says...
> The reason why I ask this, is because everything you can do with STL, you
> can do with MFC classes such as CArray, CString, CMap, etc.
>
> So, why use STL?
One reason is because the standard library includes a number of
things that are not available in MFC. Obvious examples include the
deque and priority_queue containers as well as most of the standard
library's algorithms.
--
Later,
Jerry.
The universe is a figment of its own imagination.
| |
| Lisa Pearlson 2005-04-20, 9:00 pm |
| What's wrong with
std:string design?
Better to use CString or does boost provide a better alternative?
Lisa
"Tom Widmer" <tom_usenet@hotmail.com> wrote in message
news:uDlRltpPFHA.904@TK2MSFTNGP10.phx.gbl...
> Lisa Pearlson wrote:
>
> - portable
> - standard
> - generic
> - clean design (in contrast to MFC)
> - value based rather than reference based (also a divantage, but
> mitigated by various boost libraries)
> - well documented (e.g. www.dinkumware.com, http://www.sgi.com/tech/stl/
> msdn.microsoft.com, etc.)
> - many books on the subject
> - encourages efficient programming (e.g. std::remove_if rather than O(n*n)
> iteration).
> - as fast as hand-coded, non-generic alternatives in many case
> - exception based error reporting
> - future-proof (as much as C++ is)
> - highly extensible - it is as much a library of concepts as a source code
> library.
> - many extensions available (particularly www.boost.org)
>
> I'm sure there are further advantages. There are a few divantages of
> course:
>
> - std::string isn't very well designed in hindsight
> - some of the concepts need further refinement, and some new concepts are
> needed (e.g. moveable, property maps, etc.)
> - possible code bloat from multiple instantiations (this may apply to MFC
> too)
> - unfamiliar concepts to some programmers
> - a lot of software isn't of great algorithmic complexity, and thus
> doesn't benefit as much as it might from the iterator/algorithm
> abstraction
>
> And others, no doubt.
>
> Tom
| |
| Carl Daniel [VC++ MVP] 2005-04-20, 9:00 pm |
| Lisa Pearlson wrote:
> What's wrong with
> std:string design?
http://gotw.ca/gotw/084.htm
> Better to use CString or does boost provide a better alternative?
CString is worse.
-cd
| |
| Lisa Pearlson 2005-04-20, 9:00 pm |
| > STL, but the STL's most important libraries are the iterators and
> algorithms, which MFC doesn't cover at all!
Iterators? You mean nothing more than "start()" and "end()" and ++ ?
I apologize for my ignorance, but can't you simply build a simple wrapper
around CArray like this:
class CMyArray<TX,TY> : CArray<TX,TY>, i(-1)
{
private:
int i;
....
void Start() { i = GetSize() - 1; }
void End() { i = GetSize(); }
int operator++ ... i++ // forgot the exact syntax, but you know what I mean
....
}
Of course this doesn't fix the inefficiencies of CArray implementation, but
it's this easy to implement itterated access.
Or am I completely misunderstanding what "iterators" are all about?
Lisa
| |
| Lisa Pearlson 2005-04-20, 9:00 pm |
| If you develop windows applications, isn't 95% GUI and other stuff that is
windows specific anyway?
Using STL for compatibility won't help you much there, would it?
Only if you can seperate 'algorithms' or other GUI-less code from the rest
of the app. But my experience is that 95% or more of any windows application
deals with GUI.
"Simon Trew" <ten.enagro@werts> wrote in message
news:%23eWTrYvPFHA.2560@TK2MSFTNGP14.phx.gbl...
> "Tom Widmer" <tom_usenet@hotmail.com> wrote in message
> news:O068wTqPFHA.1176@TK2MSFTNGP12.phx.gbl...
>
> I think you're about right there. Our desktop clients are mostly Windows
> (we have a couple of Mac apps and are porting our client to Qt to use
> non-windows clients) but our non-UI software is virtually all
> cross-platform. We take it for granted that the STL (C++ Standard Library,
> whatever) works as advertised on whatever platform we choose. We have a
> Windows compatibility library (i.e. implement a handful of non-UI Windows
> APIs in platform-independent terms, in preference/deference to changing
> the existing code), but on the whole prefer platform-independent code
> written against the STL and other portable runtime libraries. We test code
> mostly on Windows, as it has a far superior interactive debugging
> environment to our other platforms, and only debug on the other platforms
> when things work differently. (We have reasonably comprehensive unit tests
> and regression tests etc. which run on all platforms as part of our
> nightly builds, too, so the risk of doing this is not as high as it might
> be. Anyway, I think that writing or converting code to work cross-platform
> generally increases its quality.)
>
> The only exception I would take is about embedded platforms. Perhaps
> because of the code bloat you alluded to, I believe that embedded
> platforms often do not ship with a decent or complete STL. I could well be
> wrong here as I've not done embedded myself for a few years now.
>
> S.
>
>
>
| |
| Carl Daniel [VC++ MVP] 2005-04-20, 9:00 pm |
| Lisa Pearlson wrote:
>
> Iterators? You mean nothing more than "start()" and "end()" and ++ ?
> I apologize for my ignorance, but can't you simply build a simple
> wrapper around CArray like this:
>
> class CMyArray<TX,TY> : CArray<TX,TY>, i(-1)
> {
> private:
> int i;
> ...
> void Start() { i = GetSize() - 1; }
> void End() { i = GetSize(); }
> int operator++ ... i++ // forgot the exact syntax, but you know what
> I mean ...
> }
>
>
> Of course this doesn't fix the inefficiencies of CArray
> implementation, but it's this easy to implement itterated access.
> Or am I completely misunderstanding what "iterators" are all about?
>
Iterators are easy.
It's the fact that STL container classes don't implement any algorithms (in
general - there are a few exceptions). Rather, there are stand-alone
algorithm implementations that work generically on iterators. They can
operate on the standard containers and on any other containers you'd care to
create.
-cd
| |
| Lisa Pearlson 2005-04-21, 4:02 am |
| I'm guessing Qt is intended for cross platform too, like STL, but deals with
user interfaces, windows, etc.?
Is STL built using native C/C++ ?
Is Qt merely a wrapper around native windowing API's?
If so, I'm sure MFC is more efficient than Qt in general, since platform
specific code is generally more efficient than wrappers around the platform
specific code.
Lisa
"Simon Trew" <ten.enagro@werts> wrote in message
news:%233pjP97PFHA.1172@TK2MSFTNGP12.phx.gbl...
> "Stephen Howe" <sjhoweATdialDOTpipexDOTcom> wrote in message
> news:uGU44CwPFHA.3596@TK2MSFTNGP15.phx.gbl...
>
> I meant that I wouldn't use Qt for a Windows-only project, be it a console
> app, service or GUI. It's good, but the Windows-specific APIs and
> libraries such as MFC are also good if you are targetting Windows only.
>
>
| |
| Felipe Magno de Almeida 2005-04-21, 4:02 am |
| Lisa Pearlson wrote:
> I'm guessing Qt is intended for cross platform too, like STL, but deals with
> user interfaces, windows, etc.?
>
> Is STL built using native C/C++ ?
> Is Qt merely a wrapper around native windowing API's?
>
> If so, I'm sure MFC is more efficient than Qt in general, since platform
> specific code is generally more efficient than wrappers around the platform
> specific code.
MFC is a wrapper either, but I dont know which is more efficient...
>
> Lisa
>
>
> "Simon Trew" <ten.enagro@werts> wrote in message
> news:%233pjP97PFHA.1172@TK2MSFTNGP12.phx.gbl...
>
>
>
>
--
Felipe Magno de Almeida
UIN: 2113442
email: felipe.almeida at ic unicamp br, felipe.m.almeida at gmail
com, felipe at synergy com
I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer
from synergy, and Computer Science student from State
University of Campinas(UNICAMP).
To know more about :
Unicamp: http://www.ic.unicamp.br
Synergy: http://www.synergy.com.br
current work: http://www.mintercept.com
| |
| Lisa Pearlson 2005-04-21, 9:00 am |
| Then what is the best alternative, or most commonly used one, out there?
Does BOOST provide one?
Lisa
"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
wrote in message news:Ob9jNifRFHA.2604@TK2MSFTNGP10.phx.gbl...
> Lisa Pearlson wrote:
>
> http://gotw.ca/gotw/084.htm
>
>
> CString is worse.
>
> -cd
>
| |
| Tom Widmer 2005-04-21, 9:00 am |
| Lisa Pearlson wrote:
> Then what is the best alternative, or most commonly used one, out there?
> Does BOOST provide one?
Boost doesn't provide one. The Str library is one commercial
possibility: http://www.utilitycode.com/str/, but most of us just
struggle on with std::string (at least it's portable). Boost does have a
powerful string algorithms library, which obviously works with
std::string (and any other sequence of characters - see
http://www.boost.org/doc/html/strin...ing_algo.string
).
Tom
| |
| Tom Widmer 2005-04-21, 9:00 am |
| Lisa Pearlson wrote:
> I'm guessing Qt is intended for cross platform too, like STL, but deals with
> user interfaces, windows, etc.?
Right, http://www.trolltech.com/products/qt/index.html. It's not free
for commercial use though. WxWidgets is.
> Is STL built using native C/C++ ?
Yes, it is typically written in pure C++, though it doesn't have to be
(one could use assembler to optimize certain parts, for example).
> Is Qt merely a wrapper around native windowing API's?
Yes.
> If so, I'm sure MFC is more efficient than Qt in general, since platform
> specific code is generally more efficient than wrappers around the platform
> specific code.
However, MFC is merely a wrapper around a native windowing API (Win32)
as well. I think the main performance difference between the two is
likely to be in their event handling - MFC uses message maps, while Qt
uses signals and slots.
Tom
| |
| Carl Daniel [VC++ MVP] 2005-04-21, 4:02 pm |
| Tom Widmer wrote:
> Lisa Pearlson wrote:
>
> Boost doesn't provide one. The Str library is one commercial
> possibility: http://www.utilitycode.com/str/, but most of us just
> struggle on with std::string (at least it's portable). Boost does
> have a powerful string algorithms library, which obviously works with
> std::string (and any other sequence of characters - see
> http://www.boost.org/doc/html/strin...ing_algo.string
> ).
I believe there's been talk of a boost::immutable_string class as well, but
nothing's been accepted into boost to date. Aside from the plethora of
algirhtms that are needlessly built-into std::basic_string, another major
argument is that it's not possible to implement std::basic_string as
efficiently as people would like. Many have suggestd that breaking
std::basic_string into two classes - one mutable (the current) and one
immutable would improve the efficiency of many program since most strings
are never modified after construction. It's interesting to note that both
Java and .NET chose to make their strings immutable and provide a stirng
builder class instead of a mutable string.
-cd
| |
| Stephen Howe 2005-04-21, 8:59 pm |
| > Iterators? You mean nothing more than "start()" and "end()" and ++ ?
It is more than that in the STL. Iterators in the STL fall into various
categories:
Input
Output
Forward
Bidrectional
Random
Forward supports ++ operator but not -- operator
Bidirectional supports ++ and -- operator but not += or -=.
Random supports += and -= and [].
Random is Bidirectional and Bidirectional is Forward
AFAIK, all the algorithms in header <algorithm> work with various iterator
categories. The algorithms don't know _ANYTHING_ about the containers. And
that is what gives the power.
For example sort() requires random iterators to do its job. Since vector,
deque & string have random iterators, you can pass iterators into a vector
to sort() and it will sort that portion of the vector. But it won't work
with list as list only gives back Bidirectional iterators and sort()
requires better than that.
But it also means that if you wrote a brand new container, different from
vector and deque, it satisified the requirements as an STL container and
your new container's iterators were random, then, hey presto, your container
could be sorted with sort(). And all the other algorithms like reverse(),
remove(), lower_bound() etc would work with your new container.
_THAT_ is extensibility.
_THAT_ is real power.
Stephen Howe
| |
| David Olsen 2005-04-21, 8:59 pm |
| Carl Daniel [VC++ MVP] wrote:
> It's interesting to note that both
> Java and .NET chose to make their strings immutable and provide a stirng
> builder class instead of a mutable string.
But Java and .Net had a very good reason for making string immutable
which does not apply to C++.
In Java and .Net, String is a reference class. That means it is trivial
for there to be multiple references to a single a string object. It
would be bad if changing the value of a string object in one place
caused the value seen by others to change as well. If string were
mutable then it would also have to be clonable, and any piece of code
that recieved a reference to a string from somewhere else and wanted to
hold on to it for a while would need to clone the string first to make
sure the string object's value wasn't changed. Making strings immutable
greatly simplifies code by getting rid of any of the worries about who
else might have a reference to your string object.
In C++, string classes always have value semantics, which means copies
of the string are usually passed around. (Certain implementations of
string may use copy-on-write or other techniques to save some of the
physical copying. But it is the responsibility of the implementation,
not the user, to make sure the class behaves as if it had been copied.)
So when a string is changed, it should only affect the value of that
particular copy.
--
David Olsen
qg4h9ykc5m@yahoo.com
| |
| Stephen Howe 2005-04-21, 8:59 pm |
| > Any clue how STD and .NET relate? In other words, is STD still useless in
> the .NET world?
> I am seeing fewer job openings for C++ all the time, because now they all
> want .NET/C# developers.
C# - temporary phenomona.
..NET - no, you can do this with C++.
I am here at the ACCU conference in Oxford, UK and many ISO C++ standards
guys are here as well as Microsoft.
Bjarne Stroustrup talked this morning. Herb Sutter gave a session on Java
Generics vs C# Generics vs C++ Generics for .NET vs C++ templates - very
very interesting. Even from Microsoft guys the sense is that C++ is the
premier language for .NET development. But then - they have done a lot of
work on it.
2 years ago, the sense was otherwise.
See
http://www.accu.org/conference/
and schedule
https://www.accu.org/conference/prog.html
The future is bright :-)
Nope, stick with C++, get very proficient at it and you will have a job for
life (maybe not always with the same people but you will be employable).
Stephen Howe
| |
|
|
| Carl Daniel [VC++ MVP] 2005-04-21, 8:59 pm |
| David Olsen wrote:
> Carl Daniel [VC++ MVP] wrote:
>
> But Java and .Net had a very good reason for making string immutable
> which does not apply to C++.
>
> In Java and .Net, String is a reference class. That means it is
> trivial for there to be multiple references to a single a string
> object. It would be bad if changing the value of a string object in
> one place caused the value seen by others to change as well. If
> string were mutable then it would also have to be clonable, and any
> piece of code that recieved a reference to a string from somewhere
> else and wanted to hold on to it for a while would need to clone the
> string first to make sure the string object's value wasn't changed. Making
> strings immutable greatly simplifies code by getting rid of
> any of the worries about who else might have a reference to your
> string object.
And that same benefit would be useful in C++.
> In C++, string classes always have value semantics, which means copies
> of the string are usually passed around. (Certain implementations of
> string may use copy-on-write or other techniques to save some of the
> physical copying. But it is the responsibility of the implementation,
> not the user, to make sure the class behaves as if it had been
> copied.) So when a string is changed, it should only affect the value
> of that particular copy.
Therein lies the problem - COW strings don't work well in multi-threaded
environments because of the need to lock the shared content. An immutable
string could use a reference counted body with only simple locking
(interlocked increment/decrement) and no need to ever copy the content.
-cd
| |
| Simon Trew 2005-04-21, 8:59 pm |
| "Lisa Pearlson" <no@spam.plz> wrote in message
news:OJVKWkfRFHA.3288@TK2MSFTNGP14.phx.gbl...
> If you develop windows applications, isn't 95% GUI and other stuff that is
> windows specific anyway?
> Using STL for compatibility won't help you much there, would it?
> Only if you can seperate 'algorithms' or other GUI-less code from the rest
> of the app. But my experience is that 95% or more of any windows
> application deals with GUI.
Probably no more than 20% of our apps are GUI, the rest is 'algorithms'.
S.
| |
| Simon Trew 2005-04-21, 8:59 pm |
| "Stephen Howe" <noone@nowhere.com> wrote in message
news:4268031b$0$564$ed2e19e4@ptn-nntp-reader04.plus.net...
>
> Nope, stick with C++, get very proficient at it and you will have a job
> for life
Oooh, when's the next epoch bug? I'll be 65 in 2037!
S :)
| |
| Simon Trew 2005-04-21, 8:59 pm |
| "Tom Widmer" <tom_usenet@hotmail.com> wrote in message
news:OqT6molRFHA.3336@TK2MSFTNGP09.phx.gbl...
> However, MFC is merely a wrapper around a native windowing API (Win32) as
> well. I think the main performance difference between the two is likely to
> be in their event handling - MFC uses message maps, while Qt uses signals
> and slots.
Very coy. I think in principle (and we all know what that means) Qt should
be faster here, since it fixes up the signal to the slot during the connect
call, and then essentially just has a virtual function call between the two,
whereas MFC (and ATL) have to do a large switch statement for every message.
No doubt the compiler is optimised for switch statements on integer types
(table lookup or even heaven forbid PGO), though, so in practice I wonder
how much difference it makes. Responsiveness certainly doesn't seem to be a
problem in real life.
| |
| Carl Daniel [VC++ MVP] 2005-04-22, 4:00 am |
| Simon Trew wrote:
> "Tom Widmer" <tom_usenet@hotmail.com> wrote in message
> news:OqT6molRFHA.3336@TK2MSFTNGP09.phx.gbl...
>
> Very coy. I think in principle (and we all know what that means) Qt
> should be faster here, since it fixes up the signal to the slot
> during the connect call, and then essentially just has a virtual
> function call between the two, whereas MFC (and ATL) have to do a
> large switch statement for every message. No doubt the compiler is
> optimised for switch statements on integer types (table lookup or
> even heaven forbid PGO), though, so in practice I wonder how much
> difference it makes. Responsiveness certainly doesn't seem to be a
> problem in real life.
MFC builds a table of message -> caller dynamically so it should be as
efficient as the Qt solution (it only has to wind through the message maps
once, IIUC).
ATL (via WTL, since ATL doesn't "do windows") builds executable thunks on
the heap for the same purpose, so it too should be quite efficient.
I'd be very surprised to see any significant (perhaps even any measurable)
difference in message dispatch speed beteween these three.
-cd
| |
| David Olsen 2005-04-22, 4:00 am |
| Carl Daniel [VC++ MVP] wrote:
> David Olsen wrote:
>
>
> And that same benefit would be useful in C++.
An immutable string may indeed be useful in C++, but not for the same
reason. Assume you have some code that makes extensive use of strings
without ever modifying them. In C++, your code would look the same
whether the string class is mutable or immutable, because, the string
class being a value type, the code would always be making (logical)
copies of the string object and would never have to worry about
aliasing. In Java or a .Net language, the code would look different,
because with a mutable string class the code would need to worry about
cloning the strings and about who else might have a reference to the
string object.
>
>
> Therein lies the problem - COW strings don't work well in multi-threaded
> environments because of the need to lock the shared content. An immutable
> string could use a reference counted body with only simple locking
> (interlocked increment/decrement) and no need to ever copy the content.
The problems with mutable strings in C++ (such as the copy-on-write
string in a multi-threaded environment) are primarily problems of
implementation and performance. They are not problems with the
interface or usability. (std::string's interface is bloated, which does
affect its usability. But I would argue that the bloated-ness has
nothing to do with the string being mutable.)
The fact that std::string is mutable does not make it more difficult for
programmers to use. It just makes it more difficult for implementers to
implement efficiently for all possible uses.
I won't stop you from arguing that C++ should have an immutable string
class. Just don't use Java and .Net as examples, because their reasons
don't apply.
--
David Olsen
qg4h9ykc5m@yahoo.com
| |
| Carl Daniel [VC++ MVP] 2005-04-22, 4:00 am |
| David Olsen wrote:
> I won't stop you from arguing that C++ should have an immutable string
> class. Just don't use Java and .Net as examples, because their
> reasons don't apply.
I don't believe I ever claimed that the reasons were the same, nor that
making an immutable string would address all of the complaints about
std::basic_string - I merely pointed out that it was interesting that two
major newer platforms chose to make their built-in string type immutable.
-cd
| |
| Jeff F 2005-04-22, 4:04 pm |
|
"Simon Trew" <ten.enagro@werts> wrote in message
news:%23mv4WcsRFHA.2664@TK2MSFTNGP15.phx.gbl...
....
> No doubt the compiler is optimised for switch statements on integer types
> (table lookup or even heaven forbid PGO
What is PGO?
Thanks, Jeff
| |
| Carl Daniel [VC++ MVP] 2005-04-22, 4:04 pm |
| Jeff F wrote:
> "Simon Trew" <ten.enagro@werts> wrote in message
> news:%23mv4WcsRFHA.2664@TK2MSFTNGP15.phx.gbl...
>
> ...
>
>
> What is PGO?
Profile Guided Optimization - new feature in VC++ 2005 [1] (although it's
been around in other compilers, such as IBM Visual Age, Intel C++, Metaware
High C++ for ages - over a decade I think).
-cd
[1]
http://msdn.microsoft.com/library/d...ptimization.asp
| |
| Igor Tandetnik 2005-04-22, 9:00 pm |
| "Carl Daniel [VC++ MVP]"
<cpdaniel_remove_this_and_nospam@mvps.org.nospam> wrote in message
news:uJExMHuRFHA.2528@TK2MSFTNGP10.phx.gbl
> ATL (via WTL, since ATL doesn't "do windows")
Actually, it's the other way round. ATL implements the low level
plumbing - window procedures and message maps. WTL implements
application-level services (MDI, toolbars, status updates and so on) on
top of it. ATL had to "do windows" since it supports developing ActiveX
controls which typically need to have windows.
> builds executable
> thunks on the heap for the same purpose, so it too should be quite
> efficient.
ATL's thunk is very small and simple, all it does is replace HWND handle
with 'this' pointer in the stack frame, so that the static window proc
can forward to a member function. Message map is indeed implemented as a
big switch statement, thunks have nothing to do with it.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
|
|
|
|
|