J. Kanze wrote in message ...
>AllanW@my-dejanews.com writes:
>
>All I can say to this is that it happens some years back, and the market
>for third party GUI libraries has matured.  Companies like ILog are big
>enough, and have been around enough (and have big enough customers) for
>this not to be a problem.  They're not start-ups any more.

Perhaps as a footnote to this discussion, Rogue Wave has just announced that
they are discontinuing further development of their C++ GUI library zApp,
concentrating instead on their JAVA based products.

Regards,
Daniel Parker danielp@anabasis.com



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6obh99$2qf$1@shell7.ba.best.com>,
  ncm@nospam.cantrip.org (Nathan Myers) wrote:
> J. Kanze<kanze@gabi-soft.fr> wrote:
> >I know of one company that did everything using MFC, ...
> >they had initially used a third party GUI library, and were
> >seriously stung when the library vendor when out of business.
> >Their choice was based on the somewhat reasonable assumption
> >that whatever the intrinsic quality of their software,
> >Microsoft would not go bankrupt.
>
> This is a strong argument for using a library whose definition
> is in the public domain.
>
> Companies don't only "go bankrupt"; they destroy products, cancel
> them, render then unrecognizable, change license terms, and what-have-
> you.  Microsoft, though unlikely to go bankrupt, has done all these
> things, and will again because their primary motivation must always
> be to maintain their monopolyi (until they lose it).  Your needs as
> a developer (just as for a user) are incidental to this goal.
>
> This argues for using standard interfaces (e.g. ISO & Posix),

Definitely.  Failing an official standard, an industry standard can also
be useful ; a standard embraced by several competing companies being
obviously preferable to one imposed by a single company.  Still, as I
think I pointed out, when a UNIX port was required, the company in question
was able to find a third party implementation of MFC for UNIX/X.  (I presume
that the implementors did this with Microsoft's blessing, but I really
don't know.)  The more people using a library, the more effective it
is as a pseudo-standard.

And as always, there are trade-offs involved.  The standard X-Windows
API, as well as MFC, is very low level -- the added risk of using a library
like ILog is, IMHO, more than paid for by the increased level of abstraction,
permitting faster development times.

> and
> also for using free libraries.  With a free library there is nobody
> to "go bankrupt" and nobody to make the product unusable for you.

Depending on what you're doing, the "free" library may already be unusable
because of copyright restrictions -- the GPL is about the most restrictive
license I know of.

Globally, licensing, etc. are just more elements to consider during the
evaluation.

Typically, if your vendor doesn't appear too stable, you will probably
be able to get sources.  If he goes under, you may also be able to get
someone to fix the code.  On the other hand, just having the sources
doesn't ensure that you will get a bug fix when you need it.  If it's
a week from delivery, it may be a little late to try and start understanding
the 100KLOC library that was previously a black box.

> Of course a free standard-conforming library is best.

The presence of a second source is an advantage for any library, standard
or not.  Whether the second source is free or not is not really that
significant.

> You can
> always find somebody to maintain it for you, even if not for free.

Perhaps.  Another factor to consider in the evaluation.

> There are not yet (and never will be) an acceptable free counterpart
> for _every_ proprietary library, but when there is, that's the safe
> way to go.

I don't think that the answer is that cut and dried.  There are a number
of factors to consider.  For a standard library, I'd go with the OS/
compiler provider -- even g++ uses the library provided by the OS for
Posix, and I find it hard to imagine a case where I would not use the
standard library provided by the compiler (provided it was provided,
of course).  For an extension library, the stability of the library
and the length of time it has already been around and been maintained
(as an indication of the probability of it continuing to be around and
maintained) would probably be the most important criteria.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:

|>  [Repeat Rediculously Hyped Bait] MFC is a cross-platform portable C++
|>  GUI library. HA HA HAW! [End Repeat of Rediculously Hyped Bait]  Did that
|>  one sound more believable?  If I repeat it enough, it will, right?  Hehehe...

Just for the record (and it's not a route I would take knowingly): I
know of one company that did everything using MFC, then had to port to
UNIX and X.  They were able to find a third party implementation of MFC
for UNIX.  (I have no idea how good it was, however, or who made it.)

The reason they did everything in MFC to begin with is actually the
reason that touched off this sub-thread--they had initially used a third
party GUI library, and were seriously stung when the library vendor when
out of business.  Their choice was based on the somewhat reasonable
assumption that whatever the intrinsic quality of their software,
Microsoft would not go bankrupt.

All I can say to this is that it happens some years back, and the market
for third party GUI libraries has matured.  Companies like ILog are big
enough, and have been around enough (and have big enough customers) for
this not to be a problem.  They're not start-ups any more.

When choosing a library, risk analysis should be a definite part of the
decision process.  Don't just read the manual, find out about the
company, and evaluate the risks and costs of 1) its going under, and 2)
it's product simply not conforming to the advertising literature (and to
what degree).

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

J. Kanze<kanze@gabi-soft.fr> wrote:
>I know of one company that did everything using MFC, ...
>they had initially used a third party GUI library, and were
>seriously stung when the library vendor when out of business.
>Their choice was based on the somewhat reasonable assumption
>that whatever the intrinsic quality of their software,
>Microsoft would not go bankrupt.

This is a strong argument for using a library whose definition
is in the public domain.

Companies don't only "go bankrupt"; they destroy products, cancel
them, render then unrecognizable, change license terms, and what-have-
you.  Microsoft, though unlikely to go bankrupt, has done all these
things, and will again because their primary motivation must always
be to maintain their monopolyi (until they lose it).  Your needs as
a developer (just as for a user) are incidental to this goal.

This argues for using standard interfaces (e.g. ISO & Posix), and
also for using free libraries.  With a free library there is nobody
to "go bankrupt" and nobody to make the product unusable for you.

Of course a free standard-conforming library is best.  You can
always find somebody to maintain it for you, even if not for free.
There are not yet (and never will be) an acceptable free counterpart
for _every_ proprietary library, but when there is, that's the safe
way to go.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 18 Jun 1998 15:24:30 GMT, jkanze@otelo.ibmmail.com wrote:

>
>With regards to the problem of using the lowest common denominator, at
>least between the windowing systems I used, Windows NT is the lowest common
>denominator -- any X-Window system offers all of the functionality of
>Windows, plus some.
>
I must be missing something. Can you please tell me (us?) how to do
something like DDE or OLE with plain X?

Martin
------------------------------------------------
Martin Aupperle 1xx754.273x@compuserve.com
(replace x with 0 - fight spamming)
------------------------------------------------


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Daniel Parker wrote:
...
> no longer in business or no longer enhance their products.  It's unlikely in
> the future that there will be a very large market for C++ based GUI tools,
> so that's unlikely to change.

Are you predicting the death of C++, or the death or GUI interfaces, or
are you predicting that C++ will be relegated to the ghetto of non-GUI
applications? I expect the C++ GUI market to be large and expanding,
myself. If there's limited competition in that market, I'd blame
Microsoft's anti-competitive practices.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote in message <358FC7F7.167E@wizard.net>...
>Daniel Parker wrote:
>...
>> no longer in business or no longer enhance their products.  It's unlikely
in
>> the future that there will be a very large market for C++ based GUI
tools,
>> so that's unlikely to change.
>
>Are you predicting the death of C++, or the death or GUI interfaces,

No.

>or are you predicting that C++ will be relegated to the ghetto of non-GUI
>applications?

I would be the last person in the world to regard non-GUI software as a
ghetto, having spent the last year or so developing numerical and simulation
libraries in C++.  But as far as C or C++ on the GUI side, I think you'll
find that that already accounts for a very small percentage of GUI
development, it's small compared to Visual Basic or products like Power
Builder and Oracle Forms, and to a lessor but growing extent, JAVA.

I expect the C++ GUI market to be large and expanding,
>myself. If there's limited competition in that market, I'd blame
>Microsoft's anti-competitive practices.
>
I wouldn't.  I'd blame the lack of imagination of Microsoft's competitors,
who can't seem to develop anything overwhelmingly superior, and keep going.
"Just as good" or "a little bit better" willn't do.  [Begin Bait] It's only
software; it's not as if Bill owns the railroad beds or anything. [End Bait]


I would certainly like to see a standard specification for a cross platform
C++ GUI library, as has been suggested in other threads in comp.std.c++.
There are certainly areas where nothing else will do, and if there was a
standard there might be some hope that the little vendors could do something
here.

--
Regards,
Daniel Parker danielp@no_spam.anabasis.com.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 [Moderator's note: this subthread seems to be drifting off-topic.
 Please keep followups relevant to C++ standardization. -fjh.]

Daniel Parker <danielp@nospam.com> wrote:
: jkanze@otelo.ibmmail.com wrote in message

: >With regards to the problem of using the lowest common denominator, at
: >least between the windowing systems I used, Windows NT is the lowest common
: >denominator -- any X-Window system offers all of the functionality of
: >Windows, plus some.

: But X is slow compared to Windows, for obvious reasons.

Theoretically yes, because it does more. In practice, however,
Unix+X definitely have far superior performance on the same hardware
then Windows.

: Sun and HP
: workstation applications feel sluggish compared to Windows applications.

My experience was directly opposite. I also have the benefit
of comparing the two on the same hardware dozens of times.

: And the X API is not, how should I put it, one of the great API's.

X is not an API. X is a protocol. Xlib is a library dealing with
the protocol. API is called Xaw, Xt, Intrinsics, Motif, wxWindows,
Ilog Windows, Qt, GTK, Tk, Xforms, ... (add 30 more here).
Not all of them are great API's, but many is far superior to
MS windows.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Martin Aupperle wrote:
>
> I must be missing something. Can you please tell me (us?) how to do
> something like DDE or OLE with plain X?

Do you consider DDE and OLE as GUI features ?
I thought they were OS features (like pipes are OS features in Unix
and other OS) rather than GUI features. Maybe I am wrong.

Marc
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Martin Aupperle <1xx754.273x@compuserve.com> wrote:
: On 18 Jun 1998 15:24:30 GMT, jkanze@otelo.ibmmail.com wrote:

: >
: >With regards to the problem of using the lowest common denominator, at
: >least between the windowing systems I used, Windows NT is the lowest common
: >denominator -- any X-Window system offers all of the functionality of
: >Windows, plus some.
: >
: I must be missing something. Can you please tell me (us?) how to do
: something like DDE or OLE with plain X?

X is not a kitchen sink of all the features in the world.
There is no reason to put any of this stuff in X. DDE and OLE
on Unix is spelled CORBA.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Martin Aupperle wrote:
>
> On 18 Jun 1998 15:24:30 GMT, jkanze@otelo.ibmmail.com wrote:
>
> >
> >With regards to the problem of using the lowest common denominator, at
> >least between the windowing systems I used, Windows NT is the lowest common
> >denominator -- any X-Window system offers all of the functionality of
> >Windows, plus some.
> >
> I must be missing something. Can you please tell me (us?) how to do
> something like DDE or OLE with plain X?

You forget that Windows NT, despite it's name, is not just a
windowing system. For example it also has functions to open a file
- something nobody would see as part of a windowing system. It's
part of the OS interface. And DDE isn't part of the windowing system
either. This can already be seen in the name: Dynamic *Data* Exchange.
It's about exchanging data between applications. X, OTOH, is just a
windowing system, nothing more. Therefore it won't contain anything
which doesn't relate to windowing (like file handling -> OS,
DDE -> IPC libraries, ...). Also, I'd not expect to do COM with help
of X - there's f.ex. CORBA for such things. (OTOH, it's possible to
build windowing systems *on top* of such libraries; the Berlin project
f.ex. builds upon CORBA. In this case all programs using the windowing
system automatically use that library as well - however this is a
side-effect, and doesn't make the library a part of the windowing
system any more than f.ex. <string> is a part of <stdexcept>).

However, it seems that the discussion is getting rather off-topic...


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6moued$o53$1@news.interlog.com>,
  "Daniel Parker" <danielp@nospam.com> wrote:
>
> I would be the last person in the world to regard non-GUI software as a
> ghetto, having spent the last year or so developing numerical and simulation
> libraries in C++. But as far as C or C++ on the GUI side, I think you'll
> find that that already accounts for a very small percentage of GUI
> development, it's small compared to Visual Basic or products like Power
> Builder and Oracle Forms, and to a lessor but growing extent, JAVA.

I've worked for three different companies doing GUI development.  One was
straight C only, one was C and C++, and the latest is 80% C++, 15% Visual
Basic, and 5% Java.

Open your newspaper and turn to the jobs for programmers.  The number of
jobs for C++ that seem to expect GUI experience will roughly equal the
number of jobs for Visual Basic (which by definition always involves a GUI).
Now scale the number of C++ jobs up, to reflect the fact that a lower
percentage of C++ jobs than VB jobs make the newspaper, because VB jobs
often pay less...

(Not that VB jobs *should* pay less, but that's a whole other topic.)

> I expect the C++ GUI market to be large and expanding,
> >myself. If there's limited competition in that market, I'd blame
> >Microsoft's anti-competitive practices.
> >
> I wouldn't.  I'd blame the lack of imagination of Microsoft's competitors,
> who can't seem to develop anything overwhelmingly superior, and keep going.
> "Just as good" or "a little bit better" willn't do.  [Begin Bait] It's only
> software; it's not as if Bill owns the railroad beds or anything. [End Bait]
>
> I would certainly like to see a standard specification for a cross platform
> C++ GUI library, as has been suggested in other threads in comp.std.c++.
> There are certainly areas where nothing else will do, and if there was a
> standard there might be some hope that the little vendors could do something
> here.

[Begin Rediculously Hyped Bait] Microsoft's position: There already is a
cross-platform C++ GUI library.  It's called MFC. HEHEHEHEEE!  [End
Rediculously Hyped Bait] Sorry I couldn't say that without laughing...
I need to practice that part...

[Repeat Rediculously Hyped Bait] MFC is a cross-platform portable C++
GUI library. HA HA HAW! [End Repeat of Rediculously Hyped Bait]  Did that
one sound more believable?  If I repeat it enough, it will, right?  Hehehe...

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com wrote in message
<6mb5v9$c85$1@nnrp1.dejanews.com>...
>In article <roWh1.16257$08.3851508@newscene.newscene.com>,
>  Al Stevens <alstevens@midifitz.com> wrote:
>>
>> >I've never used MFC, so I really can't comment here.  Generally, I would
>> >avoid MFC like the plague, if only for portability reasons.  (I've also
>> >heard nothing but bad about it...
>>

Like a lot of API's Microsoft provides, it's not pretty, not elegent, but it
is usable - you can write great looking Windows applications with it fast.
I certainly wouldn't recommend using any of the general purpose classes in
MFC in general purpose libraries, though, for obvious portability reasons.


>> If you want to exploit all the latest Win32 and
>> ActiveX features (and want to use a C++ framework), MFC used to be your
only
>> real choice because the others are usually behind Microsoft in new
feature
>> support.

The main issue from my point of view is the longevity of the companies that
supply these tools.  I can recall doing comparison reviews of these products
in the past, and many of the vendors that looked good at the time are either
no longer in business or no longer enhance their products.  It's unlikely in
the future that there will be a very large market for C++ based GUI tools,
so that's unlikely to change.

>With regards to the problem of using the lowest common denominator, at
>least between the windowing systems I used, Windows NT is the lowest common
>denominator -- any X-Window system offers all of the functionality of
>Windows, plus some.

But X is slow compared to Windows, for obvious reasons.  Sun and HP
workstation applications feel sluggish compared to Windows applications.
And the X API is not, how should I put it, one of the great API's.
>
--
Regards,
Daniel Parker danielp@no_spam.anabasis.com.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <roWh1.16257$08.3851508@newscene.newscene.com>,
  Al Stevens <alstevens@midifitz.com> wrote:
>
> >I've never used MFC, so I really can't comment here.  Generally, I would
> >avoid MFC like the plague, if only for portability reasons.  (I've also
> >heard nothing but bad about it...
>
> Then you are practicing selective listening. :-) There has lots of good said
> about MFC, particularly when it is being compared to its competition.
> Portability? If you are looking for cross-GUI solutions, then you are stuck
> with developing applications that offer the lowest common denominator of
> user interface features. If you want to exploit all the latest Win32 and
> ActiveX features (and want to use a C++ framework), MFC used to be your only
> real choice because the others are usually behind Microsoft in new feature
> support. I'm not familiar with the ILog Views library you mention, though,
> and perhaps there is another choice.
>
> Who publishes ILog Views?

ILog, of course (http://www.ilog.com).  They're not the only company to
offer such products, only the only one I've used.

With regards to the problem of using the lowest common denominator, at
least between the windowing systems I used, Windows NT is the lowest common
denominator -- any X-Window system offers all of the functionality of
Windows, plus some.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>I've never used MFC, so I really can't comment here.  Generally, I would
>avoid MFC like the plague, if only for portability reasons.  (I've also
>heard nothing but bad about it...

Then you are practicing selective listening. :-) There has lots of good said
about MFC, particularly when it is being compared to its competition.
Portability? If you are looking for cross-GUI solutions, then you are stuck
with developing applications that offer the lowest common denominator of
user interface features. If you want to exploit all the latest Win32 and
ActiveX features (and want to use a C++ framework), MFC used to be your only
real choice because the others are usually behind Microsoft in new feature
support. I'm not familiar with the ILog Views library you mention, though,
and perhaps there is another choice.

Who publishes ILog Views?



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi all,
  Please excuse me if I am posting to the wrong group but after looking at the
faqs for both comp.std.c++ and comp.lang.c++, I couldn't find what I wanted.

  I have finished reading the classic "STL Tutorial and Reference Guide" by
Musser and Saini and have plans to use STL in my next big software project.
Previously, I have always used MFC from Microsoft in MS VC++. The reason why
I would like switch to use STL (at least for the data structures) is to
provide more portability if we were to run the software in any other
platforms.

  However, after trying several examples cited in the book on MSVC++5.0, I
think I would like to have a second opinion about the switch:  -- has anyone
who has done substantial work on MFC use STL and decided that it was worth
it?  -- Does anyone think that MSVC++5.0 provides a good implementation of
STL? Or for that matter, does anyone think that MS provides a good
implementation of the standard C++ library? In one of the examples in the
book, I was given the impression that the class string has a standard
string-to-vector<char> conversion. And of course, it was not so in MSVC5.0. I
had to provide a function that does the supposedly implicit conversion.

  Any feedback on the subject matter, however remote, would be greatly
appreciated.

thank you very much from Singapore, Han Ming



-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

hanming@krdl.org.sg wrote in article <6m2afs$9e2$1@nnrp1.dejanews.com>...
>   I have finished reading the classic "STL Tutorial and Reference Guide" by
> Musser and Saini and have plans to use STL in my next big software project.
> Previously, I have always used MFC from Microsoft in MS VC++. The reason why
> I would like switch to use STL (at least for the data structures) is to
> provide more portability if we were to run the software in any other
> platforms.
>
>   However, after trying several examples cited in the book on MSVC++5.0, I
> think I would like to have a second opinion about the switch:  -- has anyone
> who has done substantial work on MFC use STL and decided that it was worth
> it?  -- Does anyone think that MSVC++5.0 provides a good implementation of
> STL? Or for that matter, does anyone think that MS provides a good
> implementation of the standard C++ library?

Having supplied the Standard C++ library, including STL, to Microsoft, I'm
obviously biased. I can tell you that it is a faithful snapshot of the
draft C++ Standard, compromised only to deal with shortcomings of the VC++
compiler.  Please note, however, that the C++ Standard went through three
drafts per year until very recently, so you are bound to find considerable
variation in what compilers and various implementations of STL currently
provide.

> In one of the examples in the
> book, I was given the impression that the class string has a standard
> string-to-vector<char> conversion. And of course, it was not so in MSVC5.0.
> I had to provide a function that does the supposedly implicit conversion.

If such a conversion was ever in the draft C++ Standard, it didn't last more
than a few months. Musser & Saini carries a 1996 copyright, but I know that
it was mostly written circa 1994. It certainly reflects the structure of the
original Hewlett-Packard implementation far more than the version made
part of the C++ Standard.

In summary, you should not judge VC++, or any other current implementation
of STL, on how well it matches Musser & Saini. Take all information on STL
with a large grain of salt. It's a powerful kit of tools, but it still
comes in many flavors.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]