In article <memo.19991025132153.15133B@btinternet.com>,
  brangdon@cix.co.uk wrote:

Sorry for the delay in the reply, but I was on my Honeymoon.  I believe
this post deserves a reply any way, so I'm replying late...

> sirwillard@my-deja.com () wrote:
> > > When you include headers like <vector>
> > > together with MFC headers, you get a lot of error messages.
> >
> > Name one.  Many of us use MFC and the standard libraries together
on a
> > daily basis and have never encounted a single compilation error.
I've
> > got several MFC applications that #include <vector>, all compiling
with
> > out a single error, and to the best of my knowledge operating
without a
> > single bug.
>
> Are you setting the warning level to the highest (4, I believe)? And
are
> you setting the "treat warnings as errors" option? I consider both
> settings to be important for professional-level code.

Of course I'm not.  Most level 4 warnings are, at best, indications of
a rare and usually inconsequential idiom.  In the VAST majority of
cases such warnings should be ignored (as in possibly one in a million
such occurences will lead to code you didn't expect).  Further,
treating warnings as errors is, IMHO, idiocy.  At best I'd say "you
should eliminate all warnings", which is NOT the same thing as "treat
all warnings as errors".  If you wish to follow these rules, that's
fine, but you can't make the claim that "MFC and STL don't mix" because
of these claims.

> With those settings I need to disable several warnings. With the
right
> pragmas added to Microsoft's include files, it works fine.

Pure folly.  Never modify header files from another library.  For one
thing, this is likely to cause violations of the "one definition
rule".  For another, it's not needed in this case.  Add the #pragma to
your own code, not the libraries headers.

> I don't want to
> disable the warnings globally (because I want to be warned if I make
those
> mistakes myself), and I do want to use STL, so editing Microsoft's
files
> is the lesser evil.

No, it's not.  Putting the pragma in the libraries headers *IS* a
global change.  Unless you change the state back within the same header
you are as guilty of this folly as you would have been by using the
pragma in your own code.  If you put the pragma in your own code you
can as easily revert the state back within your code as you could have
by doing so in the library's header.  It's beyond evil to modify a
header you don't own.

> > This particular problem doesn't exist with the STD provided with
VC++,
> > since it defines the function as _cpp_min and _cpp_max because of
this
> > very problem.  Even with out this work around you should not see any
> > ill effects because of the conflict in name, since the macro
performs
> > the same operation as the template (the only problems you'll
encounter
> > are in the lack of strong type checking).
>
> Code like min( x++, y++ ) will behave differently. Code like min(
func1(),
> func2() ) may behave differently and will probably be much less
efficient
> even if the functions are side-effect free.

They behave differently because of macro side effects, yes.  But *MOST*
code is going to be free from this problem.  If and when you run up
against code that's not then you have several alternatives... including
the one prescribed by the help files for the STD provided with VC++,
i.e. use _MIN and _MAX instead.

> This is really not acceptable. My current solution is to define my
own Min
> and Max and not use the standard names at all.

This is already done for you by the STD library provided by the
compiler.  Use either _MIN and _MAX or _cpp_min and _cpp_max.  Another
alternative is to simply #undef min and max.

> > > (AFAIK COM relies on a layout of the vtbl which is not
> > > compatible with RTTI).
> >
> > I don't believe this is true.  Even if it is true it's irrelevant.
> > RTTI has nothing at all to do with the standard library.
>
> Agreed.
>
> MFC defines its own runtime information scheme, based around macros,
a
> universal base class CObject, and CRuntimeClass.

The point of discussion was COM and RTTI, not MFC and RTTI.  Don't mix
your concepts here.  Even if we were discussing MFC...

> If you use this, you
> arguably don't need the standard version as well and VC++ will
disable it
> by default for MFC applications.

No, it won't.  MFC doesn't disable anything.  The IDE by default
creates projects with RTTI disabled, but this is for all project types,
not just MFC projects.  The reason for this is because most code does
not require RTTI, and including RTTI in a project would then add
unnecessary code bloat.  It's a simple matter to change the project
settings to use RTTI for any project type, and many of us have used
RTTI with MFC applications with no ill effects.

> Thus most naive users will find standard
> RTTI will not work in MFC apps.

No, they won't.  As I stated, RTTI, if it's enabled for the project,
works just fine with MFC.  If it's not enabled then the compiler issues
diagnostics when code attempts to use it.  This is all standards
conforming behavior and is unrelated to MFC.

> This is just an efficiency hack, but it
> may have led people to think there is some deep incompatibility.

Only if said people have a great lack of understanding about the C++
language, the compiler, and the libraries they are using.

> > > You often have no other choice than to use, say, CList,
> > > because std::list will give compile errors.
> >
> > Again, give a single example.
>
> >From deque I get 4146 "Unary minus ignored on unsigned type". From
vector
> I get 4018 "Signed/Unsigned mismatch" and 4663 "C++ language change".
From
> map I get 4786 "Identifier truncated in debug". From utility I get
4505
> "Unreferenced local function removed".

Those are *ALL* warnings, not errors.  This does not make the
implementation non-conforming, nor dangerous to use.  In fact, Plauger
has an implementation available that's the same implementation but with
pragmas to turn off all such warnings.  If you don't like the warnings
and don't want to turn them off yourself, buy the upgrade from
Dinkumware.

In any event, these warnings occur regardless of whether or not a
project uses MFC and so even if someone could buy that "warnings are
the same thing as errors" you still couldn't make the declaration that
MFC and the STD are incompatible.


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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              ]

sirwillard@my-deja.com () wrote:
> If you wish to follow these rules, that's fine, but you can't make
> the claim that "MFC and STL don't mix" because of these claims.

I wasn't trying to make aggressive claims. I was trying to understand why
my setup behaved differently to yours. The difference in compiler options
could explain an otherwise puzzling discrepancy.

I've read the rest of your post. Although I sometimes disagree, there are
also points where you seem to have misunderstood what I wrote. I think it
would be tedious for me to clarify them one by one. In any case, much of
it would be off-topic here, dealing with the vagarities of a specific
compiler. So I won't reply in detail.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."


[ 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              ]

Dave Harris <scorp@btinternet.com> wrote in message
news:memo.19991107162613.52851D@btinternet.com...
> erikf@visi.com (Erik Funkenbusch) wrote:
> > There is no need to edit the Microsoft files.  You can include the
> > #pragma warning (disable: xxx) in your code where necessary and
> > reenable them when unnecessary.
>
> In practice that would mean pragmas in a great many user source
files. I
> dislike pragmas. I prefer to include them just once near the code
they
> affect.

The problem with editing the Microsoft files is that if MS releases a
patch, the patch will not be applied to a modified file.

Will you be able to remember each file you've modified and restore
it's backup prior to applying a patch?

> > you can #undef min in your code that uses std::min to disable the
> > global min macro.
>
> I don't want to rely on programmers remembering to add a #undef to
every
> source file. I don't want to add it to stdafx.h because that would
effect
> other, possibly 3rd party headers #included after it.

Well, if you don't add it, your code will not compile.  Though it will
give you a cryptic message.

> > I believe the STL included with VC already provides alternate
names.
>
> Yes, but they are not portable. They are also rather long and ugly
(eg
> _cpp_min).

So now you have 3 definitions for the same call.  I thought you didn't
like polluting the namespace?
---
[ 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              ]

The June 1999 issue of ACM Sigplan Notices has an article entitled
"The Integration of STL and the Microsoft Foundation Class".  I haven't
investigated this in detail.

The article presents a small example of a Windows application using
the STL containers in place of the corresponding MFC containers. The
program is the standard MFC sample "Scribble", as modified by the
authors of the paper.
---
[ 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              ]

Dave Harris <scorp@btinternet.com> wrote in message
news:memo.19991107162613.52851D@btinternet.com...
> erikf@visi.com (Erik Funkenbusch) wrote:
> > There is no need to edit the Microsoft files.  You can include the
> > #pragma warning (disable: xxx) in your code where necessary and
> > reenable them when unnecessary.
>
> In practice that would mean pragmas in a great many user source files. I
> dislike pragmas. I prefer to include them just once near the code they
> affect.
>
>
There is an easier way to accomplish what you want.  MS added a
#pragma warning (push, <n>)

and
#pragma warning (pop)

These set the warning level for code between the brackets.

So, I end up compiling all the code at /W4.  In the stdafx.h file, I reset
the warning level to 3,
and further disable a few other select warnings.

-bill

Below is a sample of one of my stdafx.h files:

----------------------code start
#ifdef _DEBUG
#pragma warning( disable : 4127 ) // conditional expression is constant.
// I would like to catch this with the compiler, but the ASSERT macro
// generates it.

// By putting this in the #ifdef, I catch it in release builds.
#endif

#pragma warning( disable : 4514 ) // Inline function removed.
#pragma warning( disable : 4710 ) // inline function not inlined.
#pragma warning( disable : 4786 ) // identifier too long.  (This is mostly
an STL
// based warning.  It does have meaning.  It is harder for the debugger to
// look at these.  However, there is nothing I can do in the code.
// So, leave it.

#pragma warning( push, 3 )

#include <afx.h>
#include <afxwin.h>
#include <afxdisp.h>

// C++ Standard Headers:
#include <string>
#include <vector> // STL Vector class.

// etc...

#pragma warning ( pop )

------------------code end.



[ 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              ]

wags@ic.net (Bill Wagner) wrote:
> There is an easier way to accomplish what you want.

That involves indirectly including a bunch of headers in files that don't
need them. I'd rather not do that. I prefer each source and header file to
be explicit about its own dependencies. When I've tried your trick in the
past, it's created problems when using headers from one project in another
project with a different stdafx.h

Also I'd rather disable each warning individually, after studying what it
means, than lower the whole warning level even for a stretch of other
people's code.

I'm surprised people are so interested in this. I don't see it as a big
deal. I certainly don't let it stop me using the STL. I expect Microsoft
will fix their code eventually, if they haven't already (and another
poster says the latest version is fine).

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."
---
[ 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              ]

Jerry Coffin <jcoffin@taeus.com> wrote in message
news:MPG.127e240dbfa4ba9b989769@news.mindspring.com...
> In article <jBYQ3.5457$S7.441014@newscene.newscene.com>,
> alstevens@midifitz.com says...
> > >Here is an example:
> > >
> > >#include <vector>
> > >#include "stdafx.h"
> > >static std::vector<double> tst;
> > >
> > >My compiler counts 11 errors.
> >
> > Reverse the order of the includes and do a build all. Because of
the way
> > they do precompiled headers, stdafx.h needs to be the first
include, I
> > think.
>
> Make that last, not first.  OOTC: if you want conforming behavior
from
> the compiler, you can't use its "manual" pre-compiled headers.  You
> have to either use "automatic" pre-compiled headers, or else tell it
> not to use pre-compiled headers at all.

No.  When using precompiled headers, all text before #include
"stdafx.h" will be ignored by the compiler.  Thus, the #include must
come first, before any other includes or code.

Also, using the "automatic" form of pre-compiled headers will slow
your build down by orders of magnitude.  I have one project that went
for over 90 minutes to 7 minutes simply by switching to "Use
precompiled header file (.pch) Through header: stdafx.h"
---
[ 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              ]

Dave Harris <scorp@btinternet.com> wrote in message
news:memo.19991025132153.15133B@btinternet.com...
> With those settings I need to disable several warnings. With the
right
> pragmas added to Microsoft's include files, it works fine. I don't
want to
> disable the warnings globally (because I want to be warned if I make
those
> mistakes myself), and I do want to use STL, so editing Microsoft's
files
> is the lesser evil.

There is no need to edit the Microsoft files.  You can include the
#pragma warning (disable: xxx) in your code where necessary and
reenable them when unnecessary.  Although frankly, I doubt you'll ever
personally need to have the 255 character debuggng info truncation
warning enabled for any reason.

> Code like min( x++, y++ ) will behave differently. Code like
in( func1(),
> func2() ) may behave differently and will probably be much less
efficient
> even if the functions are side-effect free.

you can #undef min in your code that uses std::min to disable the
global min macro.

> This is really not acceptable. My current solution is to define my
own Min
> and Max and not use the standard names at all.

I believe the STL included with VC already provides alternate names.
---
[ 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              ]

erikf@visi.com (Erik Funkenbusch) wrote:
> There is no need to edit the Microsoft files.  You can include the
> #pragma warning (disable: xxx) in your code where necessary and
> reenable them when unnecessary.

In practice that would mean pragmas in a great many user source files. I
dislike pragmas. I prefer to include them just once near the code they
affect.


> you can #undef min in your code that uses std::min to disable the
> global min macro.

I don't want to rely on programmers remembering to add a #undef to every
source file. I don't want to add it to stdafx.h because that would effect
other, possibly 3rd party headers #included after it.


> I believe the STL included with VC already provides alternate names.

Yes, but they are not portable. They are also rather long and ugly (eg
_cpp_min).

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."
---
[ 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 <7uqldc$i2p$1@nnrp1.deja.com>, sirwillard@my-deja.com writes:
>In article <380ef1b1@webpc1.vai.co.at>,
>
>> When you include headers like <vector>
>> together with MFC headers, you get a lot of error messages.
>
>Name one.  Many of us use MFC and the standard libraries together on a
>daily basis and have never encounted a single compilation error.  I've
>got several MFC applications that #include <vector>, all compiling with
>out a single error, and to the best of my knowledge operating without a
>single bug.
>

Here is an example:

#include <vector>
#include "stdafx.h"
static std::vector<double> tst;

My compiler counts 11 errors.

Helmut

--
---
[ 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              ]

sirwillard@my-deja.com () wrote:
> > When you include headers like <vector>
> > together with MFC headers, you get a lot of error messages.
>
> Name one.  Many of us use MFC and the standard libraries together on a
> daily basis and have never encounted a single compilation error.  I've
> got several MFC applications that #include <vector>, all compiling with
> out a single error, and to the best of my knowledge operating without a
> single bug.

Are you setting the warning level to the highest (4, I believe)? And are
you setting the "treat warnings as errors" option? I consider both
settings to be important for professional-level code.

With those settings I need to disable several warnings. With the right
pragmas added to Microsoft's include files, it works fine. I don't want to
disable the warnings globally (because I want to be warned if I make those
mistakes myself), and I do want to use STL, so editing Microsoft's files
is the lesser evil.


> This particular problem doesn't exist with the STD provided with VC++,
> since it defines the function as _cpp_min and _cpp_max because of this
> very problem.  Even with out this work around you should not see any
> ill effects because of the conflict in name, since the macro performs
> the same operation as the template (the only problems you'll encounter
> are in the lack of strong type checking).

Code like min( x++, y++ ) will behave differently. Code like min( func1(),
func2() ) may behave differently and will probably be much less efficient
even if the functions are side-effect free.

This is really not acceptable. My current solution is to define my own Min
and Max and not use the standard names at all.


> > (AFAIK COM relies on a layout of the vtbl which is not
> > compatible with RTTI).
>
> I don't believe this is true.  Even if it is true it's irrelevant.
> RTTI has nothing at all to do with the standard library.

Agreed.

MFC defines its own runtime information scheme, based around macros, a
universal base class CObject, and CRuntimeClass. If you use this, you
arguably don't need the standard version as well and VC++ will disable it
by default for MFC applications. Thus most naive users will find standard
RTTI will not work in MFC apps. This is just an efficiency hack, but it
may have led people to think there is some deep incompatibility.


> > You often have no other choice than to use, say, CList,
> > because std::list will give compile errors.
>
> Again, give a single example.

>From deque I get 4146 "Unary minus ignored on unsigned type". From vector
I get 4018 "Signed/Unsigned mismatch" and 4663 "C++ language change". From
map I get 4786 "Identifier truncated in debug". From utility I get 4505
"Unreferenced local function removed".

I don't get warnings from std::list itself.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."
---
[ 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              ]

>Here is an example:
>
>#include <vector>
>#include "stdafx.h"
>static std::vector<double> tst;
>
>My compiler counts 11 errors.

Reverse the order of the includes and do a build all. Because of the way
they do precompiled headers, stdafx.h needs to be the first include, I
think.
---
[ 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 <jBYQ3.5457$S7.441014@newscene.newscene.com>,
alstevens@midifitz.com says...
> >Here is an example:
> >
> >#include <vector>
> >#include "stdafx.h"
> >static std::vector<double> tst;
> >
> >My compiler counts 11 errors.
>
> Reverse the order of the includes and do a build all. Because of the way
> they do precompiled headers, stdafx.h needs to be the first include, I
> think.

Make that last, not first.  OOTC: if you want conforming behavior from
the compiler, you can't use its "manual" pre-compiled headers.  You
have to either use "automatic" pre-compiled headers, or else tell it
not to use pre-compiled headers at all.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.
---
[ 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              ]

Dave Harris wrote:

>
> From deque I get 4146 "Unary minus ignored on unsigned type". From vector
> I get 4018 "Signed/Unsigned mismatch" and 4663 "C++ language change". From
> map I get 4786 "Identifier truncated in debug". From utility I get 4505
> "Unreferenced local function removed".

Interesting.  I used deque, map, and queue all the time with and without MFC
and haven't had a warning, error, fatal, or even informational message.  You
are using MSVC++ v6.0 with at least the second service pack aren't you?

Michael
---
[ 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              ]

>> >#include <vector>
>> >#include "stdafx.h"
>> >static std::vector<double> tst;
>> >
>> >My compiler counts 11 errors.
>>
>> Reverse the order of the includes and do a build all. Because of the way
>> they do precompiled headers, stdafx.h needs to be the first include, I
>> think.
>
>Make that last, not first.  OOTC: if you want conforming behavior from
>the compiler, you can't use its "manual" pre-compiled headers.  You
>have to either use "automatic" pre-compiled headers, or else tell it
>not to use pre-compiled headers at all.

Make that first, not last, with precompiled headers option set not to
Automatic... but instead to "Use precompiled header file (.pch) Through
header: stdafx.h"

At least that's the way I get VC++ 5.0 to work with all the Plauger std::
stuff mixed in with MFC--although I am not as concerned with "conforming
behavior" as I am with getting programs to work. I don't think you can get
"conforming behavior" out of a compiler that refuses to conform.
---
[ 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              ]

rob wrote in message <7uo4r3$ef1$1@sass1828.sandia.gov>...
>If you've decided to use MFC in general (CWnd, CDocument, etc...),
>there isn't much benefit in deciding to avoid a few MFC container classes
>in particular (CString, CList)

I have found *huge* benefits in using STL containers over CList and CArray.
The whole library of generic functions is an example. Another obvious
benefit is that if you are successful in using encapsulation to separate
platform-dependent code from problem domain-specific code, using standard
classes instead of MFC classes increases the portability of the
problem-domain stuff to other platforms.
---
[ 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 <7uo02k$qmb$1@panix3.panix.com>, comeau@panix.com says...
> In article <drGP3.13228$803.848198@newscene.newscene.com> "Al Stevens" <alstevens@midifitz.com> writes:
> >MFC might actually predate the formation of the committee itself.
>
> I cannot recall if MFC came with the first MS C++, but that latter was
> first released in early 1992.

Yes -- MFC 1.0 came along with MS C/C++ 7.0.  It must have been _very_
early 1992 when it was released -- all the documentation has a
copyright of 1991.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.
---
[ 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              ]

Dave Hardenbrook <daveh47@mindspring.com> wrote in message
news:MPG.1277ff4467264319989751@news.mindspring.com...
> I'm writing Windows/MFC programs and I'd just like to know: Is there any
> real reason to use Microsoft's classes such as CString, CList, CArchive,
> etc. instead of the Standard Library equivalents?

One reason is that MFC predated STL.

There's no serious reason to use MFC parts that have STL counterparts, and
you can use STL with pretty much any other library.

Actually, there's no serious reason to use MFC at all. We are not using it.
Instead, we use ATL plus some homegrown extensions (that of course use STL
wherever possible), and everything runs really smooth.

I wouldn't use MFC anymore but with a gun pointed at my head, a gun that has
all the six bullets in it, one bullet ready to go, and the safety pulled.

Other than that, to be fair, I don't think MFC is part of a concerted effort
of "undermining the C++ standard". I just think it's a proof of sheer
incompetence.


Andrei
---
[ 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 <380ef1b1@webpc1.vai.co.at>,
  zeisel@vai.co.at wrote:
> I think the main problem is that MFC is not (yet) compatible
> to ISO C++.

Don't confuse MFC with VC++.

> When you include headers like <vector>
> together with MFC headers, you get a lot of error messages.

Name one.  Many of us use MFC and the standard libraries together on a
daily basis and have never encounted a single compilation error.  I've
got several MFC applications that #include <vector>, all compiling with
out a single error, and to the best of my knowledge operating without a
single bug.

> Some of these errors might be easily solveable
> (I think, e.g., that MFC defines "min" as macro, which conflicts
> with the "min" template,...),

This particular problem doesn't exist with the STD provided with VC++,
since it defines the function as _cpp_min and _cpp_max because of this
very problem.  Even with out this work around you should not see any
ill effects because of the conflict in name, since the macro performs
the same operation as the template (the only problems you'll encounter
are in the lack of strong type checking).  In any event, the min macro
is a result of the Win32 headers, not the MFC headers.

> others have no obvious solution
> (AFAIK COM relies on a layout of the vtbl which is not
> compatible with RTTI).

I don't believe this is true.  Even if it is true it's irrelevant.
RTTI has nothing at all to do with the standard library.

> You often have no other choice than to use, say, CList,
> because std::list will give compile errors.

Again, give a single example.


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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              ]

Dave Hardenbrook <daveh47@mindspring.com> wrote in message
news:MPG.1277ff4467264319989751@news.mindspring.com...
> I'm writing Windows/MFC programs and I'd just like to know: Is there any
> real reason to use Microsoft's classes such as CString, CList, CArchive,
> etc. instead of the Standard Library equivalents?  Why use CArchive, for
> instance, rather than just reading/writing files with iostreams?  Are
> these MFC "clones" of the Standard classes really useful or is it just
> Microsoft doing everything that is humanly and inhumanly possible to
> undermine the C++ Standard?

I only use Microsoft's components when they are called for by workign with
the MFC interface.

Most of MFC predates the Standard by several years, so I consider it prior
art as opposed to it being a plot by Microsoft. The *real* plot by Microsoft
is their unwillingness to implement Standard C++. I have *no* problem with
vendors extending a language with optional features; I have a *big* problem
when they implement a broken subset of the language.


--
  *     Scott Robert Ladd
  *     Coyote Gulch Productions - http://www.coyotegulch.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 <MPG.1277ff4467264319989751@news.mindspring.com>,
daveh47@mindspring.com says...
> I'm writing Windows/MFC programs and I'd just like to know: Is there any
> real reason to use Microsoft's classes such as CString, CList, CArchive,
> etc. instead of the Standard Library equivalents?  Why use CArchive, for
> instance, rather than just reading/writing files with iostreams?  Are
> these MFC "clones" of the Standard classes really useful or is it just
> Microsoft doing everything that is humanly and inhumanly possible to
> undermine the C++ Standard?

I'm not sure how much this really has to do with the C++ standard, but
some of these provide advantages of their own, while I'd guess others
continue to be supported primarily because they've been around a long
time and MS can't simply drop them overnight.  Keep in mind that the
majority of MFC predates the standard by a wide margin.  IIRC, when
CString and MS' original collection classes were written, std::string
and most of the collections in the standard library were barely into
the planning stage.

To hit some specifics: CString's major advantage is integration with
the rest of the library -- e.g. when/if you want to open a file using
one of the MFC file classes, you can use a CString as the name of the
file to open.

CArchive has only minimal relationship with iostreams.  A CArchive is
supposed to provide permanent storage for an object so you can
reconstitute the object later.  For the most part, it's just a binary
storage capability with very little buffering and no formatting at
all.  iostreams are mostly about formatting, with some buffering
ability added for fstreams and such.  It's only when you get to the
fstream's that you're really working with files at all.

Ultimately, the standard library provides a (mostly) cleaner approach
than most of the MFC classes that do roughly similar things.  OTOH, it
also requires quite a bit out of the compiler's implementation of
templates, and MS didn't support enough of the language to do the
right things until quite recently; unless I'm badly mistaken, the
compiler STILL doesn't support enough to do the standard library
completely correctly.

IIRC, MS has also said that some of this dichotomy should disappear in
VC++ 7, though I'm not sure that they've given a lot of details.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.
---
[ 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 <drGP3.13228$803.848198@newscene.newscene.com> "Al Stevens" <alstevens@midifitz.com> writes:
>MFC might actually predate the formation of the committee itself.

I cannot recall if MFC came with the first MS C++, but that latter was
first released in early 1992.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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              ]

If you've decided to use MFC in general (CWnd, CDocument, etc...),
there isn't much benefit in deciding to avoid a few MFC container classes
in particular (CString, CList)

rob.

Dave Hardenbrook wrote in message ...
>I'm writing Windows/MFC programs and I'd just like to know: Is there any
>real reason to use Microsoft's classes such as CString, CList, CArchive,
>etc. instead of the Standard Library equivalents?  Why use CArchive, for
>instance, rather than just reading/writing files with iostreams?  Are
>these MFC "clones" of the Standard classes really useful or is it just
>Microsoft doing everything that is humanly and inhumanly possible to
>undermine the C++ Standard?
>--
>
>                              -- Dave
>---
>[ 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              ]
---
[ 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              ]

Zeisel Helmut wrote in message <380ef1b1@webpc1.vai.co.at>...
>I think the main problem is that MFC is not (yet) compatible
>to ISO C++.

For full compatibility with old code, MFC cannot ever be compatible
with ISO C++. However, it is only a library and you can ignore it if
you like. The underlying compiler is a greater scandal.

>(AFAIK COM relies on a layout of the vtbl which is not
>compatible with RTTI).
You've been misled. The RTTI implementation used by MSVC does
not obstruct COM in any way. I use both quite happily.

Its funny how MS attract this sort of urban myth. (Another poster
asked why OWL doesn't get flamed in the same way.) It seems
that people simply know that MS are evil and therefore the rumour
is probably true. There is a kind of justice here, since MSVC is
*defiantly* non-compliant in places (for scopes, and the inability
to actually ship Dinkumware's fixes to the library), but it still offends
my sense of intellectual honesty!
---
[ 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'm writing Windows/MFC programs and I'd just like to know: Is there any
real reason to use Microsoft's classes such as CString, CList, CArchive,
etc. instead of the Standard Library equivalents?  Why use CArchive, for
instance, rather than just reading/writing files with iostreams?  Are
these MFC "clones" of the Standard classes really useful or is it just
Microsoft doing everything that is humanly and inhumanly possible to
undermine the C++ Standard?
--

                              -- Dave
---
[ 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              ]

Dave Hardenbrook wrote in message ...
>I'm writing Windows/MFC programs and I'd just like to know: Is there any
>real reason to use Microsoft's classes such as CString, CList, CArchive,
>etc. instead of the Standard Library equivalents?  Why use CArchive, for
>instance, rather than just reading/writing files with iostreams?  Are
>these MFC "clones" of the Standard classes really useful or is it just
>Microsoft doing everything that is humanly and inhumanly possible to
>undermine the C++ Standard?
>--

    I agree with the second ...

    Even more: if you read a number from a file and you store it in a
CString, you have some chances to read it right ... the chances to read it
wrong are higher if you simply change your regional settings !!! =8-O

    You know that depending on regional settings the decimal point may be a
point or a comma. If your regional settings use commas you will get the
wrong number when you read a float number from a file !!!

    The best option: use C++ standard types and forget the MFC ones ...

    Funny, isn't ? ...
---
[ 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              ]

daveh47@mindspring.com (Dave Hardenbrook) wrote:
> I'm writing Windows/MFC programs and I'd just like to know: Is there
> any real reason to use Microsoft's classes such as CString, CList,
> CArchive, etc. instead of the Standard Library equivalents?  Why use
> CArchive, for instance, rather than just reading/writing files with
> iostreams?  Are these MFC "clones" of the Standard classes really
> useful or is it just Microsoft doing everything that is humanly and
> inhumanly possible to undermine the C++ Standard?

Firstly, Microsoft wrote those classes before the standard existed, and
also before the Microsoft compiler supported templates (circa 1992?).
Microsoft must keep them around for the sake of compatibility with their
customer's old source code, if for no other reason.

For new code, judge each case on its merits. CArchive provides binary,
machine readable storage, whereas iostreams are formatted, human readable.
They are not doing the same thing. For example, CArchive will store
pointers to objects and rebuild a network of links when it reads the
archive back in, including coping with circular links and including
constructing the objects with the right classes. This is useful stuff not
duplicated by the standard library. On the other hand, CArchive has
various design flaws (for example to do with versioning) so perhaps should
be avoided for that reason.

I wouldn't use CList in new code myself. I see no reason to. CString is
borderline. It is what the rest of MFC expects, and as far as I know is a
reasonable design. I use CString myself to avoid having several different
kinds of string floating about.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."
---
[ 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 <MPG.1277ff4467264319989751@news.mindspring.com>, daveh47@mindspring.com (Dave Hardenbrook) writes:
>I'm writing Windows/MFC programs and I'd just like to know: Is there any
>real reason to use Microsoft's classes such as CString, CList, CArchive,
>etc. instead of the Standard Library equivalents?  Why use CArchive, for
>instance, rather than just reading/writing files with iostreams?  Are
>these MFC "clones" of the Standard classes really useful or is it just
>Microsoft doing everything that is humanly and inhumanly possible to
>undermine the C++ Standard?

I think the main problem is that MFC is not (yet) compatible
to ISO C++.
When you include headers like <vector>
together with MFC headers, you get a lot of error messages.

Some of these errors might be easily solveable
(I think, e.g., that MFC defines "min" as macro, which conflicts
with the "min" template,...), others have no obvious solution
(AFAIK COM relies on a layout of the vtbl which is not
compatible with RTTI).

You often have no other choice than to use, say, CList,
because std::list will give compile errors.

Helmut


--
---
[ 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 <MPG.1277ff4467264319989751@news.mindspring.com>,
  daveh47@mindspring.com (Dave Hardenbrook) wrote:

> I'm writing Windows/MFC programs and I'd just like to know: Is there
> any real reason to use Microsoft's classes such as CString, CList,
> CArchive, etc. instead of the Standard Library equivalents?

Off hand, the only reason I can think of is that the other functions in
MFC expect these types. If you're building up a string to pass to some
visual component, it is probably simpler to build it as a CString than
to use std::string, and then convert it to a CString when finished.

Otherwise, I'd just stick with the standard components for the
functionality that is available in both libraries.

> Why use
> CArchive, for instance, rather than just reading/writing files with
> iostreams?  Are these MFC "clones" of the Standard classes really
> useful or is it just Microsoft doing everything that is humanly and
> inhumanly possible to undermine the C++ Standard?

To be fair to Microsoft, MFC predated the standard by quite some time.
There was, of course, already a proposed standard string class, but it
has changed so much since then that, in retrospect, doing their own
thing and giving it a different name was probably the wisest decision
that they could have made.

--
James Kanze                    mailto:James.Kanze@dresdner-bank.com
Conseils en informatique orient=E9e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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              ]

Dave Hardenbrook wrote in message ...
>I'm writing Windows/MFC programs and I'd just like to know: Is there any
>real reason to use Microsoft's classes such as CString, CList, CArchive,
>etc. instead of the Standard Library equivalents?  Why use CArchive, for
>instance, rather than just reading/writing files with iostreams?  Are
>these MFC "clones" of the Standard classes really useful or is it just
>Microsoft doing everything that is humanly and inhumanly possible to
>undermine the C++ Standard?

I can't answer that last question in general because I don't work for MS,
but with respect to the string and container classes you mention, the answer
is "no." Those MFC classes predate the standard by many moons. MFC supported
them long before Stepanov introduced STL to the committee and before a
standard string class was defined. Microsoft must continue to support them
because of all the legacy code that breaks them. I'm not sure, but MFC might
actually predate the formation of the committee itself.

On new programs I use standard containers and strings wherever possible. As
I maintain old programs, I convert them if only to eventually get to a point
where I need to remember only one set of classes.

To answer your first question: You can use the standard classes in place of
the custom MFC ones except for those cases where an MFC API includes an MFC
class object, reference, or address as a parameter and there is no
corresponding conversion. CString is usaully no problem because it converts
between char* and std::string has c_str(). CArchive is a part of the MFC
app/document/view paradigm and the MFC classes that support it. You can use
iostreams but you forsake some of the automatic stuff that the framework
provides.

Remember, there is still an OWL framework out there being used, too, and it
has similar classes that are not standard. Why aren't you asking the same
questions about Inprise nee Borland?
---
[ 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              ]