In article <362DF90D.63E5E6B1@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
>
> alanstokes@my-dejanews.com wrote:
> > I believe that should be "/Dfor=if(0);else for"
>
> You're right - however, your option probably won't work
> (unless Win95/NT has built-in quoting, or VC++ handles quoting
> itself; I'll assume that Win command line is equivalent to
> DOS command line). The problem is the space between the else
> and the for. However, that space can probably be removed as
> well by doing /Dfor=if(0);else/**/for

I added
    for="if(false);else for"
to the list of defines in the project settings dialog box, and it works
fine.

--
Adam P. Jenkins
ajenkins@javanet.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <70l6ja$ahk$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:
> In article <70g6d3$225$1@nnrp1.dejanews.com>,
>   markw65@my-dejanews.com wrote:
>
> Mark, I've often been one to stand up and say "let's not bash
> Microsoft for the sake of bashing Microsoft." But in this case
> you're just wrong.

No. I am not.

>
> > I hate to stand up for microsoft on this one... but the only problems Ive
been
> > able to find are to do with changes in the C++ standard, such as requiring
> > typename for dependant names (ie the compiler is correctly enforcing the
> > standard, as requested by the /Za switch). I have yet to see a single header
> > fail to compile because of microsoft specific keywords.
>
> Then you are not using the Microsoft header files, such as iostream.

Yes I am.

>
> You can't use /Za because the program #include's <iostream>. Go ahead
> and try it, to see what I mean. The guards are there, so it doesn't
> complain about invalid keywords -- but it does complain about invalid
> syntax.

And just how is this different from what I said above?

All I said was that grepping for ms specific keywords is not going to tell you
which headers will and will not compile. Lots of headers *contain* ms specific
keywords. None of them (that I can find) fail to compile because of them.

Mark Williams

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

In article <70g6d3$225$1@nnrp1.dejanews.com>,
  markw65@my-dejanews.com wrote:
> In article <70ei33$m95$1@nnrp1.dejanews.com>,
>   ajenkins@javanet.com wrote:
> > P.S. Here's the output of
> >     grep -l '\<__stdcall\|__cdecl\|__declspec\>' *
> > in VC++'s include directory.  (For the grep deprived, this lists all the
files
> > which contain any of these keywords).  Many of these are either standard
> > headers, or included by standard headers.
> >
> [long list of files snipped]
>
> Very clever. But what grep doesnt tell you is that they are all guarded, so
> that they do _not_ cause errors when using /Za (or indeed when using a
> non-microsoft compiler).
>
> I hate to stand up for microsoft on this one... but the only problems Ive been
> able to find are to do with changes in the C++ standard, such as requiring
> typename for dependant names (ie the compiler is correctly enforcing the
> standard, as requested by the /Za switch). I have yet to see a single header
> fail to compile because of microsoft specific keywords.

What you say is correct.  I hadn't looked into why the standard headers can't
be used with /Za, and assumed it was the non-standard keywords; now I see
that it's due to other errors. The fact remains though that most of the
standard headers can't be used with /Za.  Neither can the Win32 headers, so
by extension neither can MFC, so /Za can't be used anywhere in practice
except in toy programs.

For example, the following program gets around 30 errors when compiled with
    cl /GX /Za tmp.cpp
(/GX turns on exception handling).

--- tmp.cpp ---
#include <set>

int main()
{
 std::set<int> aSet;
 return aSet.size();
}
--- end tmp.cpp ---

--
Adam P. Jenkins
ajenkins@javanet.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

Fergus Henderson wrote:
>
> Does this really apply to ISO C and C++ standard headers such as <stdlib.h>?
> Or is it only Microsoft header files such as <windows.h> that cause
> the problem?
>
> If the former, then VC++ with the /Za switch is not a conforming
> implementation.

If you look in Microsoft's web site, you will find that not being able
to compile the STL headers with
/Za is listed as a known bug.

- Anthony


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

alanstokes@my-dejanews.com wrote:
>
> In article <3624A22C.79DFDD20@physik.tu-muenchen.de>,
>   Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
>
> > However, the following switch should work:
> >
> > /Dfor=if(1)for
> >
>
> I believe that should be "/Dfor=if(0);else for"
>
> Otherwise
>    if (0)
>       for(;;);
>    else
>       VeryImportant();
>
> won't work, because the else will match the wrong if.

You're right - however, your option probably won't work
(unless Win95/NT has built-in quoting, or VC++ handles quoting
itself; I'll assume that Win command line is equivalent to
DOS command line). The problem is the space between the else
and the for. However, that space can probably be removed as
well by doing /Dfor=if(0);else/**/for

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]



[ 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 <70ei33$m95$1@nnrp1.dejanews.com>,
  ajenkins@javanet.com wrote:
>
> In article <706vr9$mna$1@mulga.cs.mu.OZ.AU>,
>   fjh@cs.mu.OZ.AU (Fergus Henderson) wrote:
> > ajenkins@javanet.com writes:
> > >> /Za /D__cdecl= /D__declspec= /D__stdcall=
> > >
> > >Nice try, but it won't work either.  It may make the code compile, but it
> > >won't run correctly because the calling conventions will be different in
your
> > >code and the standard libraries you link with. Face it, with VC++, you
can't
> > >use standard headers when the compiler is in standard-conforming mode!
> Aargh

I'm confused. Did Microsoft claim that VC++ is fully compliant?

For those who need a closer approximation to standard, don't even
bother with /Za. The thing is to make sure that VC++ doesn't recognize
any of it's old "backwards compatible" keywords that don't start with
underscores. But there aren't that many of them.
    /Dfar=_notkwd_far /Dnear=_notkwd_near
I'm sure there are half a dozen others. Probably the best way to find
them is to compile your compliant code, and when you discover a new
symbol that produces problems, add it to the list.
    /Dfoo=_notkwd_foo /Dbar=_notkwd_bar

This won't solve 100% of all cases of contrived code:
    #include <iostream>
    int far(int foo, int bar) { return foo+bar; }
    #define far(x) far(2,x)
    int main() { std::cout << far(5) << std::endl; }
This example can't be fixed by /D-switches at all, because it uses both
a function name and a macro. But this is fairly rare...

> > Does this really apply to ISO C and C++ standard headers such as <stdlib.h>?
> > Or is it only Microsoft header files such as <windows.h> that cause
> > the problem?
>
> VC++'s standard C and C++ headers are littered with these keywords, so yes,
> VC++ with /Za is not a conforming C++ compiler at all. It's almost as
if /Za
> were just added for show, since almost no standard, or even MS, header file
> can be included with /Za.

/Za, as currently implemented, is pretty useless. But since these
keywords almost all have reserved-for-vendor names, they shouldn't cause
a problem in code that doesn't use them. As for the remainder, there are
usually ways other than /Za to solve the same problem in real (read:
not contrived) code.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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 <70g6d3$225$1@nnrp1.dejanews.com>,
  markw65@my-dejanews.com wrote:
> In article <70ei33$m95$1@nnrp1.dejanews.com>,
>   ajenkins@javanet.com wrote:
>
> > VC++'s standard C and C++ headers are littered with these keywords, so yes,
> > VC++ with /Za is not a conforming C++ compiler at all. It's almost as
> if /Za
> > were just added for show, since almost no standard, or even MS, header file
> > can be included with /Za.
> >
> > --
> > Adam P. Jenkins
> > ajenkins@javanet.com
> >
> > P.S. Here's the output of
> >     grep -l '\<__stdcall\|__cdecl\|__declspec\>' *
> > in VC++'s include directory.  (For the grep deprived, this lists all the
files
> > which contain any of these keywords).  Many of these are either standard
> > headers, or included by standard headers.
> >
> [long list of files snipped]
>
> Very clever. But what grep doesnt tell you is that they are all guarded, so
> that they do _not_ cause errors when using /Za (or indeed when using a
> non-microsoft compiler).

Mark, I've often been one to stand up and say "let's not bash
Microsoft for the sake of bashing Microsoft." But in this case
you're just wrong.

> I hate to stand up for microsoft on this one... but the only problems Ive been
> able to find are to do with changes in the C++ standard, such as requiring
> typename for dependant names (ie the compiler is correctly enforcing the
> standard, as requested by the /Za switch). I have yet to see a single header
> fail to compile because of microsoft specific keywords.

Then you are not using the Microsoft header files, such as iostream.

As an exercise, try to make this program compile and link without
making any source changes. You may use any compile switches you like:

    #include <iostream>

    // Declare a function named "far" to prove it works
    void far(const char*c) {
        std::cout << c << std::endl;
    }
    #define far(c) far("Hello " c "!")

    int main() {
        far("world");
        return 0;
    }

You can't use /Za because the program #include's <iostream>. Go ahead
and try it, to see what I mean. The guards are there, so it doesn't
complain about invalid keywords -- but it does complain about invalid
syntax.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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 <3624A22C.79DFDD20@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:

> However, the following switch should work:
>
> /Dfor=if(1)for
>

I believe that should be "/Dfor=if(0);else for"

Otherwise
   if (0)
      for(;;);
   else
      VeryImportant();

won't work, because the else will match the wrong if.

> (This macro was posted earlier as #define in one of the c++
> groups - unfortunately I don't remember who invented that
> ingenious macro)

Nor I.

--
- Alan

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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 <3624A22C.79DFDD20@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> markw65@my-dejanews.com wrote:
> >
> > In article <6vrv1u$qpu$1@nnrp1.dejanews.com>,
> >   ajenkins@javanet.com wrote:
>
> [...]
>
> > > Technically this is true; the /Za switch turns off most MS extensions.
> > > However /Za also prevents all but the most trivial programs from
compiling,
> > > since it also turns off the __cdecl, __declspec, and __stdcall keywords,
> > > which are used extensively throughout the standard headers.  There is no
> > > switch to just make for-loop scoping work correctly, at least not with
VC++
> > > 5.0, so MSC users have to live with the old-style for scoping rule.
> >
> > /Za /D__cdecl= /D__declspec= /D__stdcall=
> >
> > :-)
>
> This probably will prevent all but the most trivial programs
> from linking...

It had better not. You may not be able to get MFC apps to compile/link
properly, but then I understand that MFC relies on the microsoft extensions
anyway. But any standard C++ program should compile and link [Actually, the
__declspec define is wrong, because __declspec takes parameters. Fortunately,
the headers dont actually use it... they use things like _CRTIMP which is
written in such a way that you can predefine it to be empty]

As it turns out tho, the problems with the standard library are not ( at least
as far as I have gone) down to using these keywords. Its due to actual
violations of the final standard in the implementation of the library (missing
typenames, incorrect template syntax etc). Presumably because earlier versions
of MSVC++ wouldnt compile the correct code (or because the libraries were
written before the syntax had stabilised).

>
> However, the following switch should work:
>
> /Dfor=if(1)for
>

if (x)
 for (int i = 1; i < 100; i++) {
//...
 }
else {
// oops, we never get here...
}

Mark Williams

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 discussion has drifted away from standards
  issues to programming techniques. I've redirected followups to
  skip comp.std.c++. -sdc ]

Brent McPherson wrote in message <701qu2$697@news.dns.microsoft.com>...
[Cut stuff re scope of vars introduced in for.]

>Alternatively, you could do what I do and use the following pre-processor
>hack on compilers that aren't conformant.
>
>   #define for   if (1) for
>
>I have used this with several compilers over the years including VC++
>5.0 without any problems. (and yes, I was also surprised that VC++ 5.0
>was not standard conmforming in this respect!)

Without asserting or admitting I would write such code,
the following construct will fail with your hack in place:

if (someCondition)
    for (int i = 0; i < 2; ++i) callSub();
else
    doWhatever();

The else clause, attached to "if (1)", can never run.

--Larry Brasfield
Above opinions may be mine alone.
(Humans may reply at unundered larry_br@sea_net.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 discussion has drifted away from standards
  issues to programming techniques. I've redirected followups to
  skip comp.std.c++. -sdc ]

In article <701qu2$697@news.dns.microsoft.com>,
Brent McPherson <nospam@nospam.com> wrote:

> Alternatively, you could do what I do and use the following pre-processor
> hack on compilers that aren't conformant.

>    #define for   if (1) for

> I have used this with several compilers over the years including VC++
> 5.0 without any problems. (and yes, I was also surprised that VC++ 5.0
> was not standard conmforming in this respect!)

This technique fails for statements such as

 if (x < y) for (i=0; i<n; ++i) f(i); else g();

because it expands to

 if (x < y) if(1) for (i=0; i<n; ++i) f(i); else g();

and the else is now attached to the second if instead of the first.

I think the following variation works, though:

 #define for if (0) ; else for
--
    Andrew Koenig
    ark@research.att.com
    http://www.research.att.com/info/ark


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]



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

ajenkins@javanet.com writes:

>markw65@my-dejanews.com wrote:
>
>> ajenkins@javanet.com wrote:
>> > Technically this is true; the /Za switch turns off most MS extensions.
>> > However /Za also prevents all but the most trivial programs from compiling,
>> > since it also turns off the __cdecl, __declspec, and __stdcall keywords,
>> > which are used extensively throughout the standard headers.  There is no
>> > switch to just make for-loop scoping work correctly, at least not with VC++
>> > 5.0, so MSC users have to live with the old-style for scoping rule.
>
>> /Za /D__cdecl= /D__declspec= /D__stdcall=
>
>Nice try, but it won't work either.  It may make the code compile, but it
>won't run correctly because the calling conventions will be different in your
>code and the standard libraries you link with. Face it, with VC++, you can't
>use standard headers when the compiler is in standard-conforming mode! Aargh

Does this really apply to ISO C and C++ standard headers such as <stdlib.h>?
Or is it only Microsoft header files such as <windows.h> that cause
the problem?

If the former, then VC++ with the /Za switch is not a conforming
implementation.  I presume that VC++ _without_ the /Zs switch is
not a conforming implementation either, although if the extensions
don't change the behaviour of any strictly conforming program
and don't invade the user's namespace then it could be conforming.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ 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 <706vr9$mna$1@mulga.cs.mu.OZ.AU>,
  fjh@cs.mu.OZ.AU (Fergus Henderson) wrote:
> ajenkins@javanet.com writes:
> >> /Za /D__cdecl= /D__declspec= /D__stdcall=
> >
> >Nice try, but it won't work either.  It may make the code compile, but it
> >won't run correctly because the calling conventions will be different in your
> >code and the standard libraries you link with. Face it, with VC++, you can't
> >use standard headers when the compiler is in standard-conforming mode!
Aargh
>
> Does this really apply to ISO C and C++ standard headers such as <stdlib.h>?
> Or is it only Microsoft header files such as <windows.h> that cause
> the problem?

VC++'s standard C and C++ headers are littered with these keywords, so yes,
VC++ with /Za is not a conforming C++ compiler at all. It's almost as if /Za
were just added for show, since almost no standard, or even MS, header file
can be included with /Za.

--
Adam P. Jenkins
ajenkins@javanet.com

P.S. Here's the output of
    grep -l '\<__stdcall\|__cdecl\|__declspec\>' *
in VC++'s include directory.  (For the grep deprived, this lists all the files
which contain any of these keywords).  Many of these are either standard
headers, or included by standard headers.

ASSERT.H
BASETYPS.H
COMDEF.H
COMIP.H
COMPLEX
COMUTIL.H
CONIO.H
CRTDBG.H
CTYPE.H
D3DRMDEF.H
DIRECT.H
DOCOBJ.H
DOCOBJ.IDL
DOS.H
EH.H
ERRNO.H
EXCEPTION
EXCPT.H
FLOAT.H
FPIEEE.H
FSTREAM
FSTREAM.H
FTSIFACE.H
FUNCTIONAL
HLINK.H
HLINK.IDL
IMAGEHLP.H
IO.H
IOMANIP
IOS
IOS.H
IOSFWD
IOSTREAM.H
ISTREAM
ISTREAM.H
LIMITS
LMCONS.H
LOADPERF.H
LOCALE
LOCALE.H
MALLOC.H
MAPIDBG.H
MAPIDEFS.H
MAPINLS.H
MAPIVAL.H
MATH.H
MBCTYPE.H
MBSTRING.H
MEMORY.H
NEW
NEW.H
OAIDL.H
OAIDL.IDL
OBJBASE.H
OBJIDL.H
OBJIDL.IDL
ODBCINST.H
OSTREAM
OSTREAM.H
PDH.H
PROCESS.H
RPC.H
RPCNDR.H
RPCPROXY.H
SEARCH.H
SETJMP.H
SIGNAL.H
SQLTYPES.H
STDDEF.H
STDEXCPT.H
STDIO.H
STDIOSTR.H
STDLIB.H
STREAMB.H
STRING
STRING.H
STRSTREA.H
STRSTREAM
TCHAR.H
TIME.H
TYPEINFO
TYPEINFO.H
UNKNWN.H
UNKNWN.IDL
UTILITY
WCHAR.H
WCTYPE.H
WDBGEXTS.H
WINDEF.H
WINNT.H
WPSPI.H
XCOMPLEX
XIOSBASE
XLOCALE
XLOCINFO
XLOCINFO.H
XLOCMON
XLOCNUM
XLOCTIME
XSTDDEF
XSTRING
YMATH.H
YVALS.H

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <70ei33$m95$1@nnrp1.dejanews.com>,
  ajenkins@javanet.com wrote:

> VC++'s standard C and C++ headers are littered with these keywords, so yes,
> VC++ with /Za is not a conforming C++ compiler at all. It's almost as
if /Za
> were just added for show, since almost no standard, or even MS, header file
> can be included with /Za.
>
> --
> Adam P. Jenkins
> ajenkins@javanet.com
>
> P.S. Here's the output of
>     grep -l '\<__stdcall\|__cdecl\|__declspec\>' *
> in VC++'s include directory.  (For the grep deprived, this lists all the files
> which contain any of these keywords).  Many of these are either standard
> headers, or included by standard headers.
>
[long list of files snipped]

Very clever. But what grep doesnt tell you is that they are all guarded, so
that they do _not_ cause errors when using /Za (or indeed when using a
non-microsoft compiler).

I hate to stand up for microsoft on this one... but the only problems Ive been
able to find are to do with changes in the C++ standard, such as requiring
typename for dependant names (ie the compiler is correctly enforcing the
standard, as requested by the /Za switch). I have yet to see a single header
fail to compile because of microsoft specific keywords.

Mark Williams

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Jerry Coffin wrote in message ...
>In article <6ppsn5$q8j$1@nnrp1.dejanews.com>, jim.hyslop@leitch.com
>says...
>
>> Well, there are certain standard items that Microsoft gets wrong
(scope of a
>> variable introduced in the for-init-statement, for example), but in
general
>> I'd agree with both your statements.
>
>MS does not get this wrong -- they support older code as an
extension,
>but if you ask for conformance, you get it, at least in this respect.

Huh? Am I missing something? With VC5, I get

  for (int i = 0; i < 10; ++i) DoStuff();
  for (int i = 0; i < 10; ++i) DoMoreStuff();
  error C2374: 'i' : redefinition; multiple initialization

I haven't tried it yet, but I have read that VC6 is little or no
closer to the standard than 5 was. Please tell me what compiler switch
to use to "ask for conformance".

- Jim

--
Jim Barry, Thermoteknix Systems Ltd., Cambridge, UK.
http://www.thermoteknix.co.uk - Queen's Award for Export 1998
http://www.geocities.com/SiliconValley/2060



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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.102e4b30f7bb3090989c39@news.rmi.net>,
  jcoffin@taeus.com (Jerry Coffin) wrote:
> In article <6ppsn5$q8j$1@nnrp1.dejanews.com>, jim.hyslop@leitch.com
> says...
>
> [ ... ]
>
> > Well, there are certain standard items that Microsoft gets wrong (scope of a
> > variable introduced in the for-init-statement, for example), but in general
> > I'd agree with both your statements.
>
> MS does not get this wrong -- they support older code as an extension,
> but if you ask for conformance, you get it, at least in this respect.

Technically this is true; the /Za switch turns off most MS extensions.
However /Za also prevents all but the most trivial programs from compiling,
since it also turns off the __cdecl, __declspec, and __stdcall keywords,
which are used extensively throughout the standard headers.  There is no
switch to just make for-loop scoping work correctly, at least not with VC++
5.0, so MSC users have to live with the old-style for scoping rule.

Adam

--
Adam P. Jenkins
ajenkins@javanet.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <6vrv1u$qpu$1@nnrp1.dejanews.com>,
  ajenkins@javanet.com wrote:
> In article <MPG.102e4b30f7bb3090989c39@news.rmi.net>,
>   jcoffin@taeus.com (Jerry Coffin) wrote:
> > In article <6ppsn5$q8j$1@nnrp1.dejanews.com>, jim.hyslop@leitch.com
> > says...
> >
> > [ ... ]
> >
> > > Well, there are certain standard items that Microsoft gets wrong (scope of
a
> > > variable introduced in the for-init-statement, for example), but in
general
> > > I'd agree with both your statements.
> >
> > MS does not get this wrong -- they support older code as an extension,
> > but if you ask for conformance, you get it, at least in this respect.
>
> Technically this is true; the /Za switch turns off most MS extensions.
> However /Za also prevents all but the most trivial programs from compiling,
> since it also turns off the __cdecl, __declspec, and __stdcall keywords,
> which are used extensively throughout the standard headers.  There is no
> switch to just make for-loop scoping work correctly, at least not with VC++
> 5.0, so MSC users have to live with the old-style for scoping rule.

/Za /D__cdecl= /D__declspec= /D__stdcall=

:-)

Mark Williams

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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 <6vrv1u$qpu$1@nnrp1.dejanews.com>,
  ajenkins@javanet.com wrote:
> In article <MPG.102e4b30f7bb3090989c39@news.rmi.net>,
>   jcoffin@taeus.com (Jerry Coffin) wrote:
> > In article <6ppsn5$q8j$1@nnrp1.dejanews.com>, jim.hyslop@leitch.com
> > says...
> >
> > [ ... ]
> >
> > > Well, there are certain standard items that Microsoft gets wrong (scope
of
a
> > > variable introduced in the for-init-statement, for example), but in
general
> > > I'd agree with both your statements.
> >
> > MS does not get this wrong -- they support older code as an extension,
> > but if you ask for conformance, you get it, at least in this respect.
>
> Technically this is true; the /Za switch turns off most MS extensions.
> However /Za also prevents all but the most trivial programs from compiling,
> since it also turns off the __cdecl, __declspec, and __stdcall keywords,
> which are used extensively throughout the standard headers.  There is no
> switch to just make for-loop scoping work correctly, at least not with VC++
> 5.0, so MSC users have to live with the old-style for scoping rule.

I'm led to believe that VC5 isn't the only compiler that gets this
wrong -- note that this was the correct behavior throughout most of
the years that the spec was more correctly called "the draft spec."

Until the spec is implemented widely enough that exceptions can be
considered an oddity (perhaps not too far off), there is a simple
workaround that will compile correctly in both environments: Simply
add an additional pair of braces around every for statement.

    { for (i=0; i<10; ++i) DoSomething(); }
    { for (i=0; i<10; ++i) DoSomethingElse(); }

Works correctly wherever fine compilers are sold.

"But I don't want to convert all of my programs!"

Then you don't want to switch compilers! At least not yet. But
this isn't a minor issue; just hang on a little while, and this
will be fixed nearly everywhere.

Don't hold your breath, though, waiting for *ALL* compilers
to be 100% compliant in every nit-picky rule. I'm not talking
about interpretation issues (though that would make a long
monologue in itself); I'm talking about reality. So long as
there are customers with deadlines, there will be programmers
willing to use whatever tools they have to get the job done --
and that means that minor issues will be glossed over if they
can be identified and avoided. That's why there is no bug-free
software on the market today, not even from the
billion-dollar-plus megamonolith software vendors who could
afford to meet this criteria if it made fiscal sense. (Which,
unfortunately, it generally doesn't.)

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

markw65@my-dejanews.com wrote:
>
> In article <6vrv1u$qpu$1@nnrp1.dejanews.com>,
>   ajenkins@javanet.com wrote:

[...]

> > Technically this is true; the /Za switch turns off most MS extensions.
> > However /Za also prevents all but the most trivial programs from compiling,
> > since it also turns off the __cdecl, __declspec, and __stdcall keywords,
> > which are used extensively throughout the standard headers.  There is no
> > switch to just make for-loop scoping work correctly, at least not with VC++
> > 5.0, so MSC users have to live with the old-style for scoping rule.
>
> /Za /D__cdecl= /D__declspec= /D__stdcall=
>
> :-)

This probably will prevent all but the most trivial programs
from linking...

However, the following switch should work:

/Dfor=if(1)for

(This macro was posted earlier as #define in one of the c++
groups - unfortunately I don't remember who invented that
ingenious macro)

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

ajenkins@javanet.com wrote in message <6vrv1u$qpu$1@nnrp1.dejanews.com>...
>In article <MPG.102e4b30f7bb3090989c39@news.rmi.net>,
>  jcoffin@taeus.com (Jerry Coffin) wrote:
>> In article <6ppsn5$q8j$1@nnrp1.dejanews.com>, jim.hyslop@leitch.com
>> says...
>>
>> [ ... ]
>>
>> > Well, there are certain standard items that Microsoft gets wrong (scope
of a
>> > variable introduced in the for-init-statement, for example), but in
general
>> > I'd agree with both your statements.
>>
>> MS does not get this wrong -- they support older code as an extension,
>> but if you ask for conformance, you get it, at least in this respect.
>
>Technically this is true; the /Za switch turns off most MS extensions.
>However /Za also prevents all but the most trivial programs from compiling,
>since it also turns off the __cdecl, __declspec, and __stdcall keywords,
>which are used extensively throughout the standard headers.  There is no
>switch to just make for-loop scoping work correctly, at least not with VC++
>5.0, so MSC users have to live with the old-style for scoping rule.
>

Alternatively, you could do what I do and use the following pre-processor
hack on compilers that aren't conformant.

   #define for   if (1) for

I have used this with several compilers over the years including VC++
5.0 without any problems. (and yes, I was also surprised that VC++ 5.0
was not standard conmforming in this respect!)

Hope this helps!
--
Brent McPherson
Softimage Special Projects
email: brent . mcpherson @ softimage . com
---------------------------------------------------------
*spam-buster* - remove spaces from email address to reply
---
[ 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 <6vvhut$g33$1@nnrp1.dejanews.com>,
  markw65@my-dejanews.com wrote:

> In article <6vrv1u$qpu$1@nnrp1.dejanews.com>,
>   ajenkins@javanet.com wrote:
> > Technically this is true; the /Za switch turns off most MS extensions.
> > However /Za also prevents all but the most trivial programs from compiling,
> > since it also turns off the __cdecl, __declspec, and __stdcall keywords,
> > which are used extensively throughout the standard headers.  There is no
> > switch to just make for-loop scoping work correctly, at least not with VC++
> > 5.0, so MSC users have to live with the old-style for scoping rule.

> /Za /D__cdecl= /D__declspec= /D__stdcall=



Nice try, but it won't work either.  It may make the code compile, but it
won't run correctly because the calling conventions will be different in your
code and the standard libraries you link with. Face it, with VC++, you can't
use standard headers when the compiler is in standard-conforming mode! Aargh

--
Adam P. Jenkins
ajenkins@javanet.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 discussion has drifted away from any
  connection to the C++ Standard and is no longer suitable for
  comp.std.c++. I've redirected followups to the other
  groups in the list of newsgroups. -sdc ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:

[Forcing correct scoping of "for" in Microsoft product]

> However, the following switch should work:
>
> /Dfor=if(1)for
>
> (This macro was posted earlier as #define in one of the c++
> groups - unfortunately I don't remember who invented that
> ingenious macro)

Not good enough:

if (some condition)
   for (...) {
      ....
   }
else

will get garbled by this construct.

  {1. I don't want to bless macro hackery, but "protecting against macro side effects"
  was precisely one of the reasons why our coding standards mandate braces around all
  if/while/do bodies, even if they're only one line. 2. Thanks for using the word
  "grok"! -hps}

You'd probably better use something like
/Dfor=if(0);else for

I don't know how to make Windows grok the semicolon and space, so
you'd have to check that yourself.

--
David Kastrup                                     Phone:
+49-234-700-5570
Email: dak@neuroinformatik.ruhr-uni-bochum.de       Fax:
+49-234-709-4209
Institut f   r Neuroinformatik, Universit   tsstr. 150, 44780 Bochum,
Germany

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 wrote:
> >But this is a no-win proposition. If they use a static heap, then
they
> >probably use a different version of the C++ heap than we do. But if
> >they use a dynamic library to implement the heap, then we had better
> >use the same DLL that they do.

  Dennis Weldy <nojunkmail@ever.com> wrote:
> If a particular library uses its own heap manager, why not also define
> operator new and delete for those classes? This way, it's guaranteed
to
> use the correct allocator/deallocator, yes?

But I think this is moving backwards. Someone (not me) said that they
had a policy of using operator new for all classes in DLL's. And
someone else (also not me) suggested that this was not neccesary. And
soon intelligent and respectable people were rolling about on the
floor, screaming their opinions about Microsoft and nursing bloody
noses and black eyes...

I think the only conclusion was that *nix had it easier, because it has
the C run-time-library built into the OS.  Which is probably true, but
not very helpful for people trying to write general-purpose DLL's for
sale.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <01bdc7b1$f232db80$8a1ec2d0@porky>,
  "P.J. Plauger" <pjp@dinkumware.com> wrote:
>
[snip]
> I have no idea whether you can build satisfactory DLLs without these
> added decorations, and I don't care. The customer asked for 'em and
> paid good money to get 'em. I make a living licensing useful software,
> not proving points.

And isn't that what programming is about - give the customers what they want!
If Standard C++ allows us to provide practical solutions to our customers
(see footnote) in a timely manner, then Standard C++ is a great tool.  OTOH,
if Standard C++ (or any tool) hinders us in providing the end-product, then
we'll quickly look for better tools.

Jim

Footnote:  "Customer" does not always mean someone outside the company paying
money to your company. Your "customers" are the people who use your
software, whether those customers are paying big bucks (such as MicroSoft) to
your company, or whether you are a programmer working in the IS department
writing utilities for use by other IS staff (in the latter case, the other IS
staff are your customers).

-----== 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 wrote in article
<6qvef0$li0$1@nnrp1.dejanews.com>...

> I've never done the second method on a non-trivial project because
> there's no advantage to it. But don't tell me that keywords are
> required in order to implement .DLLs!

it's doable. it has it's advantages when porting code from an executable to
a dll, because all the changes are concentrated in one place.

i believe the real problem is not the functions in DLLs but the static
data, for which there appears to be no way to avoid the AFX_DATA macro.
ideas ?

stuart


[ 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 a particular library uses its own heap manager, why not also define
operator new and delete for those classes? This way, it's guaranteed to
use the correct allocator/deallocator, yes?

Dennis

--
Considering how to build better systems and how various languages can
serve that end is a much better use of time than fighting language wars.
Bjarne Stroustrup - http://www.research.att.com/~bs/blast.html

AllanW@my-dejanews.com wrote in message
<6qg4v6$4n1$1@nnrp1.dejanews.com>...

>But this is a no-win proposition. If they use a static heap, then they
>probably use a different version of the C++ heap than we do. But if
>they use a dynamic library to implement the heap, then we had better
>use the same DLL that they do.

[ moderator's note: Excessive quoting deleted. Please remove
  unnecessary material wehn you respond to an article. -sdc ]

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

Ron Bass wrote in message <35d4ef28.16923679@news.ti.com>...
>
>David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote:
>
>>It's a shame that the CRT DLL file doesn't have a version number
>>in it.
>
>But it does.  It's in the version resource.  The current version
>on my machine (came with VC++ 5.0) is 5.0.0.7303  Just use the
>standard API to read the resource.

But this doesn't permit the simultaneous existence of two different
versions, because the filename is the same. An app can be running
fine, only to break when some other program installs another version
of the .dll (even if it's a newer one). It's kind of hard to test your
program against versions of code that doesn't exist yet. :)

Tha's just a pitfall of the concept of dynamically shared code. I'm
not saying the advantages don't outweigh the disadvantages.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 12 Aug 1998 18:40:30 GMT, David R Tribble
<david.tribble@noSPAM.central.beasys.com> wrote:

>It's a shame that the CRT DLL file doesn't have a version number
>in it.

It's in the version resource.

>I'll bet that next year's program, which works fine with
>the VC/6 version of MSCVCRT.DLL, won't run with last year's version
>of MSCVCRT.DLL.

Could be, but that possibility bothers me a lot less than the
converse!

>I simply can't believe that the same filename can
>be used safely release after release, year after year; indeed, my
>experience with updating different "versions" of DLLs with identical
>filenames during 3rd-party software installs proves otherwise.

Maybe I've been lucky, but so far, all my apps compiled under VC5 work
fine with the VC6 msvcrt.dll and mfc42.dll, even though they also use
the VC5 C++ runtime dll, msvcp50.dll. Actually, it goes further than
that. I've been using the VC6 msvcrt.dll for months now; VC5 has been
using it just fine, as have many other programs. I have had zero
problems due to the new DLL.

The alternative to using DLLs for things like the CRT is rather
gloomy. I don't want X copies each of the CRT, MFC, and other DLLs
wasting my memory, be they linked dynamically under different
filenames or statically linked into executables. These DLLs are
fundamental to a large number of programs, and in that respect,
they're rather like OS DLLs. It's desirable for programs to share them
to the fullest extent possible.

>(See http://ourworld.compuserve.com/homepages/timp/dllrant.htm
>for other opinions about the shortcomings of DLLs.)

Another article worth reading is Brockschmidt's "How OLE and COM Solve
the Problems of Component Software Design", which appeared in the
May-96 MSJ. It's largely concerned with how COM addresses problems
inherent to DLLs in general. That's a different subject, however, than
I've been addressing in this thread, which was, in a nutshell, "MSFT's
DLL implementation is unusable because every dynamically linked
component uses a separate heap," which in general, is incorrect.

--
Doug Harrison
dHarrison@worldnet.att.net


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

David R Tribble wrote in message
<35D0E298.7BEA@noSPAM.central.beasys.com>...
>
>Paul Flinders <paul.flinders@finobj.com> wrote:
>>> There is perhaps an argument that the C and C++ built-in types are so
>>> loosely defined that one should never use them for variables.
>
>AllanW@my-dejanews.com wrote:
>> I'll assume you don't mean that we should never use integers! You mean
>> that we should never declare a variable as int, but only as some type
>> INT which has been typedef'd to be some integral type.
>>
>> It's a good rule of thumb, and coincidentally it's the rationale for
>> types such as BYTE, WORD, LONG, and LPSTR in the Windows header files.
>> But we shouldn't be to anal about it. For instance, I wouldn't use it
>> for character data.

Why is it a good rule of thumb?  Why is using INT better than using the
builtin type int?

What does using the WORD type guarantee about arithmetic on its data types?
What can I assume about adding 1 to a WORD with value 65535?

>
>It's also completely unnecessary if you're writing code that is
>ported to a set of systems that are all somewhat similar in CPU
>characteristics.  If you can live comfortably with the standard
>sizes of int, short, long, etc., then you don't need typedefs to
>insulate you from them.  Typedefs, in programming environments like
>this, are for clarity and documentation, not for insulation.

Typedefs like "Coordinate" clarify the use of an integer.  Typedefs like
"LONG" do not any clarity at all.

>
>Rarely do you find the need for complete, absolute portability
>across all conceivable systems.  Most real applications run on a
>fairly well-defined, relatively small set of platforms.

Many sets of "portability" typedefs are not really that portable either.
For example, how would you define WORD on a machine where sizeof(char)==1
and sizeof(short)==4?  Better to not write code that is broken if there is
no two-byte integer type.

>For example, we port our system (~700,000 lines of C++ code)
>across Win32 and several Unixes.  We assume, more or less, that
>'int' is at least 32 bits wide and big enough for most mundane uses
>(such as array indices, loop counters, error codes, "handles",
>generic numeric integers, etc.).  We also assume that 'char' works
>for most character data (where it doesn't, we use 'unsigned char'
>or 'wchar_t').  Same goes for 'float' and 'double'.  And pointers
>are pointers are pointers - we simply use '*' for them.

Right.  Use int unless you have reason to believe it will not work.  (It is
guaranteed to be at least 16 bits.)  Use an asterisk if you mean pointer.
Nobody will be surprised by this.  Nobody will have to learn a new type
system.

Typedefs should enhance readability.  I'm sure that those who invented the
typedefs I criticized would claim that theirs do enhance readability.

Readability is a subjective matter.  Many of the typedefs I see everyday do
not enhance my ability to read the code.  Others, such as function pointers,
I need to keep for my own sanity.

The issues here border on religion.  But heck, I'll argue religion :-)

Kevin Hopps
My views do not necessarily reflect the views of my employer.






      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <35D0E298.7BEA@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:
>
> Paul Flinders <paul.flinders@finobj.com> wrote:
> >> There is perhaps an argument that the C and C++ built-in types are so
> >> loosely defined that one should never use them for variables.
>
> AllanW@my-dejanews.com wrote:
> > I'll assume you don't mean that we should never use integers! You mean
> > that we should never declare a variable as int, but only as some type
> > INT which has been typedef'd to be some integral type.
> >
> > It's a good rule of thumb, and coincidentally it's the rationale for
> > types such as BYTE, WORD, LONG, and LPSTR in the Windows header files.
> > But we shouldn't be to anal about it. For instance, I wouldn't use it
> > for character data.
>
> It's also completely unnecessary if you're writing code that is
> ported to a set of systems that are all somewhat similar in CPU
> characteristics.  If you can live comfortably with the standard
> sizes of int, short, long, etc., then you don't need typedefs to
> insulate you from them.  Typedefs, in programming environments like
> this, are for clarity and documentation, not for insulation.
>
> Rarely do you find the need for complete, absolute portability
> across all conceivable systems.  Most real applications run on a
> fairly well-defined, relatively small set of platforms.

I've never yet worked anywhere that wanted to support every platform
that was possible to support, but I could imagine wanting to do so.
For instance, much of the GNU system is written this way, isn't it?

It's possible you're confusing cause and effect. Your program
supports lots of 32-bit platforms, and you don't use typedefs
because all of your platforms are 32-bit. But what would happen if
you wanted to port to a 16-bit platform? Presumably this would be
to make more money, buy selling to clients on 16-bit systems. But
you evaluate your code; with no typedefs, it would be a very
expensive port, costing more than you could hope to make from
sales. So you cancel the project, and the next time you are in this
newsgroup you can still say that all your platforms are 32-bits,
so you still don't need typedefs!

Using typedefs from the beginning would have cost a few extra
seconds at design time, with no compile or runtime overhead.
The port still wouldn't have been free, because there would be
places in the code where you should have used typedefs but didn't,
or you used the wrong one, etc.; since these never mattered before,
they wouldn't have been caught. But even though the port wouldn't
be free, it would be a lot cheaper than trying to modify the
entire program from scratch!

> For example, we port our system (~700,000 lines of C++ code)
> across Win32 and several Unixes.

Then you're fairly lucky so far. Also, your system is new enough to
have never run on Win16 (or else you refused to port it back when
int meant 16 bits -- you waited for Win32). Before Win32 was around,
Win16 was just called Windows. Type short int was almost the same as
type int (except for overloading), at 16 bits.  When Win32 was
announced, only 50% of the porting issues involved changes to the
Windows API. That's why they created some of the typedefs listed
above -- for instance, WORD always means unsigned 16-bits, no matter
which platform. Another 20% was the fact that int was now 32-bits,
which could affect things like output streams. But a large part of
the work was from code where (usually without realizing it) the
programmer assumed that int was the same size as short and smaller
than long.

Think you're immune to such changes? What will Win64 do for you? I
don't know when this is coming, but it is coming someday. My guess
is that short will still mean 16 bits and int will still be 32 bits,
but long will be 64 bits.  Any code that assumes that int is the
same as long will break. Any code that assumes that integr-type
variables come in only 3 sizes (char, short, long) will break.
Will your code break?

> We assume, more or less, that
> 'int' is at least 32 bits wide and big enough for most mundane uses
> (such as array indices, loop counters, error codes, "handles",
> generic numeric integers, etc.).

It's usually superior to other choices for array indices and loop
counters; it's the "natural" size for the current machine, so it's
fastest. Exceptions would include very-large arrays, but generally
for this to matter it would have to be so massive that the program
revolves around using it.

Some of these other cases, however, limit your choices in arbitrary
ways. For instance, if you were to upgrade(*) from Win32 to Win16:

For error codes, you could have a problem. This always works fine in
a 32-bit integer, and it even works on 16-bit integers if the values
are basically enumerations. But if you try to subdivide the number --
say, two bits for Fatal/Error/Warning/Info, one for "has user been
notified," two for suggested program action (Retry/Wait/Ignore/Prompt),
two for suggested user action (Retry/Wait/Ignore/Call support),
four for system number, four for subsystem number -- here you only
have one bit left for the specific error code!

"Handles" work fine with 16-bit ints. This allows 65,000 simultaneous
instances, which is generally plenty except on the most massive systems
(which probably wouldn't run on a 16-bit computer anyway).

General numeric integers? This is a problem in 16 bits. There are 36525
days in most centuries, and 86400 seconds in a day -- neither of these
fits into a 16-bit signed integer.

But you're not trying to run these on computers with 16-bit ints, you
say? Sure, that's true today. But politics change, and the world keeps
spinning. Tomorrow you may realize that there are 25,000 customers on
Win3.1 machines who would pay for your product. You do a little
arithmetic, and decide that this makes money if the port is easy, but
loses money if the port is hard. As mentioned above, someone evaluates
the code, and based on the realization that there are no typedefs,
concludes that it would cost more money that it makes. So the project
is cancelled, which means you don't have to do a port, which means
that you still don't have any reason to use typedefs!

(*) Many applications would get superior performance from this change.
    So shouldn't it be called an upgrade?

> We also assume that 'char' works
> for most character data (where it doesn't, we use 'unsigned char'
> or 'wchar_t').  Same goes for 'float' and 'double'.  And pointers
> are pointers are pointers - we simply use '*' for them.

Agreed; these types are rarely as much trouble as the integers.
(There's binary compatibility problems, but that's a whole other
topic.) Each of these types has a specific usage, except char which
is sometimes used as a tiny-int. Otherwise they are all
reasonably-sized for that specific use, and typedefs accomplish
little.

Hypothetically, you could have data which is stored as a float today,
but which you expect to change into a long int tomorrow. But
realistically that's rare enough to ignore, unless the original
design was faulty (in which case typedef's won't help anyway).

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <35D0ECF6.4B40@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:
> It's a shame that the CRT DLL file doesn't have a version number
> in it.  I'll bet that next year's program, which works fine with
> the VC/6 version of MSCVCRT.DLL, won't run with last year's version
> of MSCVCRT.DLL.  I simply can't believe that the same filename can
> be used safely release after release, year after year; indeed, my
> experience with updating different "versions" of DLLs with identical
> filenames during 3rd-party software installs proves otherwise.

Are we getting off-subject? [Yes, thank-you. --mod]

The Microsoft DLL system includes everything needed so that a
programmer can make DLL's backwards-compatible. C++ "decorated names"
make this slightly more difficult, so programmers sometimes ignore
it completely. Another problem is that sometimes two vendors have
DLL's with the same name but unrelated functionality. If they both
try to install into the Windows directory, or if one is running when
the other tries to launch, then at least one of them fails. There's
no "DLL name registry" so this problem has no complete solution.

That's a pity, of course, but it doesn't really relate to the C++
standard -- which doesn't even know what a DLL is.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <35C5E574.3F54@wizard.net>...
> >> > Then it's time to worry. They already added keywords to C, and
> >> > retained those keywords in C++.
>
> "Alberto Barbati" <albbarbZZZ@tin.it> wrote:
> >> If you include in "keywords" also the keywords beginning with a
> >> double underscore, then Microsoft has added _a_lot_ of keywords to
> >> C++. The __declspec keyword alone can be used in 9 different
> >> contexts, some of which (for example: property) have such an impact
> >> to the semantic that a compiler can't simply ignore it. Code that
> >> uses such keywords is not C++ code anymore.
>
> AllanW@my-dejanews.com wrote:
> > That last point is the most important. This doesn't violate the
> > standard because standard C++ programs don't use these keywords.

In article <35D0E97E.7E43@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:
> And since
> we use shared dynamic libraries (.so and DLLs), we absolutely must
> use '__declspec(export)' for Win32, otherwise our code won't run.
> So we write "portable" code that is not truly "conformant" (because
> it uses some nonstandard keywords via some preprocessor magic on
> some platforms).

I've already argued that prudent use of implementation-defined
keywords makes code more portable, rather than less.

> (Suggestions that we should use .DEF files instead of __declspec()
> won't work, since our customers compile and link against our
> libraries, and we can't force them to use .DEF files.)

Ignoring minor variations, there are two methods to build .DLL files
from Visual C++ for third-party use.  Moderator, this isn't as
off-topic as it may seem, because my point is that the second method
uses no vendor-supplied keywords.

The first method is what you're probably already doing, and it's what
Microsoft seems to expect. It's also the easiest. First, define a
macro somewhere, perhaps on the build settings for your .DLL. This
is set to "__declspec(export)" when you're building the DLL, and set
to "__declspec(import)" when your clients use your header files. (You
could also define this macro as an empty string for non-Windows
builds, but we'll ignore that for now.) The build produces a .LIB file
(which your customers use at build time) and a .DLL file (which they
use at run time). If your customers are building their own .DLL which
references yours, things get much more complicated -- but after the
first time (which will cause much pain and battle scars), the customer
will realize that they need their own macro, so that they can set
their own functions to "__declspec(export)" while simultaneously
declaring your functions to be "__declspec(import)".  After this step
(which has to be experienced before it's fully understood), things will
not be as tough anymore.

The second method requires no special keywords. First, create a .DEF
file for your DLL project. List *every* function you're going to
export from the DLL. (This is hard and error-prone, but it works.)
You build the same .LIB and .DLL files as the first method. When
your customers compile with your headers, the link remains unresolved
until the .LIB file is scanned -- at which point the symbol is
resolved from your .DLL after all. Everything works, even if the
customer is using macros for her own __declspec(im/ex-port) macros,
and even if she is building her own .DLL.

I've never done the second method on a non-trivial project because
there's no advantage to it. But don't tell me that keywords are
required in order to implement .DLLs!

> Just ask Plauger how he manages to write "portable" library code
> for several platforms without using implementation-specific keywords;
> he'll tell you it's not possible.  Plain vanilla "conforming" C++
> code isn't as "portable" in the real world as we'd like it to be.
> Once your code interacts with a real-world operating system (like
> making O/S system calls, or interrogating the file system, or
> residing in a shared library), you're forced away from total
> portability and total conformance (although some systems are worse
> about this than others).

Alright, I'm asking. Mr. Plauger, I note that your code uses macros
which use implementation-specific keywords. For instance, on Microsoft
platforms you define _CRTIMP as touted above -- __declspec(export)
when building the library DLL, otherwise __declspec(import). When no
DLL is involved, the definition is blank. But do you consider this an
expedient measure, meant to get the library code ported quickly and
easily while avoiding painful non-language issues such as .DEF files?
Or do you agree with Mr. Tribble, that "it's not possible" to create
such a library without doing this? Remember, we're not talking about
what's practical, just what's possible.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 wrote in article <6qvef0$li0$1@nnrp1.dejanews.com>...
> > Just ask Plauger how he manages to write "portable" library code
> > for several platforms without using implementation-specific keywords;
> > he'll tell you it's not possible.  Plain vanilla "conforming" C++
> > code isn't as "portable" in the real world as we'd like it to be.
> > Once your code interacts with a real-world operating system (like
> > making O/S system calls, or interrogating the file system, or
> > residing in a shared library), you're forced away from total
> > portability and total conformance (although some systems are worse
> > about this than others).
>
> Alright, I'm asking. Mr. Plauger, I note that your code uses macros
> which use implementation-specific keywords. For instance, on Microsoft
> platforms you define _CRTIMP as touted above -- __declspec(export)
> when building the library DLL, otherwise __declspec(import). When no
> DLL is involved, the definition is blank. But do you consider this an
> expedient measure, meant to get the library code ported quickly and
> easily while avoiding painful non-language issues such as .DEF files?
> Or do you agree with Mr. Tribble, that "it's not possible" to create
> such a library without doing this? Remember, we're not talking about
> what's practical, just what's possible.

It is definitely an expedient. Microsoft asked me to add these decorations
for the version I delivered to them. I made them macros so I could redefine
them (occasionally) or turn them off (for most other implementations).
They are but a few of the more visible concessions I have to make in the
Standard C++ library baseline code to achieve real-world portability in
any practical sense.

I have no idea whether you can build satisfactory DLLs without these
added decorations, and I don't care. The customer asked for 'em and
paid good money to get 'em. I make a living licensing useful software,
not proving points.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com/hot_news.html



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

Paul Flinders <paul.flinders@finobj.com> wrote:
>> There is perhaps an argument that the C and C++ built-in types are so
>> loosely defined that one should never use them for variables.

AllanW@my-dejanews.com wrote:
> I'll assume you don't mean that we should never use integers! You mean
> that we should never declare a variable as int, but only as some type
> INT which has been typedef'd to be some integral type.
>
> It's a good rule of thumb, and coincidentally it's the rationale for
> types such as BYTE, WORD, LONG, and LPSTR in the Windows header files.
> But we shouldn't be to anal about it. For instance, I wouldn't use it
> for character data.

It's also completely unnecessary if you're writing code that is
ported to a set of systems that are all somewhat similar in CPU
characteristics.  If you can live comfortably with the standard
sizes of int, short, long, etc., then you don't need typedefs to
insulate you from them.  Typedefs, in programming environments like
this, are for clarity and documentation, not for insulation.

Rarely do you find the need for complete, absolute portability
across all conceivable systems.  Most real applications run on a
fairly well-defined, relatively small set of platforms.

For example, we port our system (~700,000 lines of C++ code)
across Win32 and several Unixes.  We assume, more or less, that
'int' is at least 32 bits wide and big enough for most mundane uses
(such as array indices, loop counters, error codes, "handles",
generic numeric integers, etc.).  We also assume that 'char' works
for most character data (where it doesn't, we use 'unsigned char'
or 'wchar_t').  Same goes for 'float' and 'double'.  And pointers
are pointers are pointers - we simply use '*' for them.

-- David R. Tribble, dtribble@technologist.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              ]

Doug Harrison wrote:
>> In sum, if my third party libraries are using a DLL specific heap, it
>> is an error in the way that the third party built them, and I should
>> insist that they build differently.
>
> I couldn't comment specifically on that without reviewing the
> situation in detail. I've only meant to point out that the problem you
> seemed to categorically describe as inherent to Win32 operating
> systems is in fact not inherent to them, and that one certainly can
> avoid such problems. Consider the MFC DLL supplied with VC. It links
> dynamically to the CRT, and as long as my MFC program also links
> dynamically to the same CRT, I don't have the problem. If you have a
> versioning problem, you'll want to recompile so that everyone agrees
> on the CRT, but at least VC5/6 seem to have stabilized on a single,
> binary-compatible msvcrt.dll (and MFC dll).

It's a shame that the CRT DLL file doesn't have a version number
in it.  I'll bet that next year's program, which works fine with
the VC/6 version of MSCVCRT.DLL, won't run with last year's version
of MSCVCRT.DLL.  I simply can't believe that the same filename can
be used safely release after release, year after year; indeed, my
experience with updating different "versions" of DLLs with identical
filenames during 3rd-party software installs proves otherwise.

(See http://ourworld.compuserve.com/homepages/timp/dllrant.htm
for other opinions about the shortcomings of DLLs.)

-- David R. Tribble, dtribble@technologist.com --
-- Win95: Start me up... You make a grown man cry...


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

(Note: Credits may be wrong...)

Bryan Althaus wrote:
> >> Microsoft likes C++, they don't like Java.  When Microsoft starts
> >> adding new keywords to its C++, then it's time to worry, until then
> >> I don't ...

James Kuyper wrote in message <35C5E574.3F54@wizard.net>...
>> > Then it's time to worry. They already added keywords to C, and
>> > retained those keywords in C++.

"Alberto Barbati" <albbarbZZZ@tin.it> wrote:
>> If you include in "keywords" also the keywords beginning with a
>> double underscore, then Microsoft has added _a_lot_ of keywords to
>> C++. The __declspec keyword alone can be used in 9 different
>> contexts, some of which (for example: property) have such an impact
>> to the semantic that a compiler can't simply ignore it. Code that
>> uses such keywords is not C++ code anymore.

Correction: It most certainly is C++ code, it's just not "conforming"
or "portable" C++ code anymore.

AllanW@my-dejanews.com wrote:
> That last point is the most important. This doesn't violate the
> standard because standard C++ programs don't use these keywords.

AllanW@my-dejanews.com wrote:
> They wouldn't be, though, unless you took steps to force it to (you
> might get away with
>     #define __declspec(x)
> but there's no guarantees). Fortunately, this isn't a concern because
> programmers writing for portability aren't supposed to use these
> keywords anyway.

Your definition of "portable" is a little different than mine.  I
write "portable" code that ports successfully to several different
machines that our company distributes our software for.  And since
we use shared dynamic libraries (.so and DLLs), we absolutely must
use '__declspec(export)' for Win32, otherwise our code won't run.
So we write "portable" code that is not truly "conformant" (because
it uses some nonstandard keywords via some preprocessor magic on
some platforms).

Just ask Plauger how he manages to write "portable" library code
for several platforms without using implementation-specific keywords;
he'll tell you it's not possible.  Plain vanilla "conforming" C++
code isn't as "portable" in the real world as we'd like it to be.
Once your code interacts with a real-world operating system (like
making O/S system calls, or interrogating the file system, or
residing in a shared library), you're forced away from total
portability and total conformance (although some systems are worse
about this than others).

(Suggestions that we should use .DEF files instead of __declspec()
won't work, since our customers compile and link against our
libraries, and we can't force them to use .DEF files.)

-- David R. Tribble, dtribble@technologist.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              ]

David,

Not all of this is aimed specifically at your message. You can figure
out which bits are :)

David R Tribble wrote:
>
> Paul Flinders <paul.flinders@finobj.com> wrote:
> >> There is perhaps an argument that the C and C++ built-in types are so
> >> loosely defined that one should never use them for variables.
>
> AllanW@my-dejanews.com wrote:
> > I'll assume you don't mean that we should never use integers! You mean
> > that we should never declare a variable as int, but only as some type
> > INT which has been typedef'd to be some integral type.
> >
> > It's a good rule of thumb, and coincidentally it's the rationale for
> > types such as BYTE, WORD, LONG, and LPSTR in the Windows header files.
> > But we shouldn't be to anal about it. For instance, I wouldn't use it
> > for character data.
>
> It's also completely unnecessary if you're writing code that is
> ported to a set of systems that are all somewhat similar in CPU
> characteristics.  If you can live comfortably with the standard
> sizes of int, short, long, etc., then you don't need typedefs to
> insulate you from them.  Typedefs, in programming environments like
> this, are for clarity and documentation, not for insulation.
>

But the whole point of those particular types was to ease the transition
between Win16 & Win32. These two CPU modes had radically different
characteristics.

> Rarely do you find the need for complete, absolute portability
> across all conceivable systems.  Most real applications run on a
> fairly well-defined, relatively small set of platforms.
>

Once again, these typedefs were soley intended for porting from Win16 to
Win32. They may also come in handy when we go to Win64!

> For example, we port our system (~700,000 lines of C++ code)
> across Win32 and several Unixes.  We assume, more or less, that
> 'int' is at least 32 bits wide and big enough for most mundane uses
> (such as array indices, loop counters, error codes, "handles",
> generic numeric integers, etc.).

This may be a safe assumption for your target platforms. It is plainly
false when moving between 16 & 32 bit platforms.

> We also assume that 'char' works
> for most character data (where it doesn't, we use 'unsigned char'
> or 'wchar_t').

And when moving from an ASCII to Unicode (or DBCS) platform.

> Same goes for 'float' and 'double'.

I'll buy this one.

> And pointers
> are pointers are pointers - we simply use '*' for them.
>

Again, this was not true in the 16 bit world - pointers could be near or
far.

Anyway, the point of all this is that the Windows data types (LPTR etc.)
(in 32 bit mode) are *not* non-standard or language extensions - the
32-bit versions are implemented using completely standard C++ features.
Admittedly, the 16 bit versions use non-standard near & far for pointer
types but there really was no other choice. MS was not the only compiler
vendor to use these keywords. It also seems inappropriate to me to put
down MS for non-standard features that pre-date the existance of the
standard.

--
Terry Richards
Terry Richards Software

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote:

>It's a shame that the CRT DLL file doesn't have a version number
>in it.

But it does.  It's in the version resource.  The current version
on my machine (came with VC++ 5.0) is 5.0.0.7303  Just use the
standard API to read the resource.

>I'll bet that next year's program, which works fine with
>the VC/6 version of MSCVCRT.DLL, won't run with last year's version
>of MSCVCRT.DLL.  I simply can't believe that the same filename can
>be used safely release after release, year after year; indeed, my
>experience with updating different "versions" of DLLs with identical
>filenames during 3rd-party software installs proves otherwise.
>

That's why Microsoft introduced the version resource for
executables and DLL's back in the days of Win 3.0.

Of course, if some other company chooses to write an installation
procedure that doesn't check the version numbers before replacing
files, you can hardly blame MS.


 -Ron
---
  Ronald Bass Ph.D.
  Intersect Technologies, Inc    Phone:
  A Texas Instruments Company    (303) 651-5979
  2600 Trade Centre Avenue
  Longmont, CO 80501


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <ubtpymr3l.fsf@finobj.com>,
  Paul Flinders <paul.flinders@finobj.com> wrote:
>
> AllanW@my-dejanews.com writes:
> > I'll assume you don't mean that we should never use integers! You mean
> > that we should never declare a variable as int, but only as some type
> > INT which has been typedef'd to be some integral type.
>
> That's exactly what I mean

You're agreeing with me, right? (There's two ways to read your response)

> > It's a good rule of thumb, and coincidentally it's the rationale for
> > types such as BYTE, WORD, LONG, and LPSTR in the Windows header files.
> > But we shouldn't be to anal about it. For instance, I wouldn't use it
> > for character data. Also consider this example:
> >
> >     DATA total(DATA *data, int count) {
> >         DATA tot=0;
> >         while (count--) tot+=data[count];
> >         return tot;
> >     }
> >
> > The returned value is a DATA, so that it can be a plain int if possible
> > and a long int if needed. But count is a short-lived variable used as
> > an array index; such variables should always be an int unless there's
> > some good reason not to. Remember, int is the "natural" integer type for
> > the current platform. If short and/or long are different than int, they
> > might require extra machine code to increment or decrement; but I doubt
> > there are many platforms where decrementing an int requires more machine
> > code than decrementing a short or long.
>
> I'll agree that it's possible to get a bit too hung up on this.
>
> However the plain char type specifically leaves the decision as to
> whether it is signed or unsigned to the compiler implementer so even
> "char" should probably not be used directly

But you have to, in order to call C-library functions such as strcpy()!

> Also for your example count is not just "a short-lived variable used
> as an array index" - the range of values for "count" depends on the
> number of items in the data array which is global.
>
> Consider
>
> Money total_wage_bill(Money *emp_sals, int count)
> {
>     Money tot=0;
>     while (count--) tot+=emp_sals[count];
>     return tot;
> }
>
> I hope you recognise it as your example with a few names changed.

Yes. You even used almost the same line spacing, except for the first
left brace.

> For
> small organisations a 16bit int will be more than sufficient for the
> count - but suppose IBM (roughly 225,000 employees) get interested in
> your code. In that case you will have to hunt down every loop over
> your employee table and make sure the index variable is a long.

I wonder if such an application can have reasonable performance on a
16-bit system? :^) But your point is valid.

> Would
>
> Money total_wage_bill(Money *emp_sals, employee_index count)
> {
>     Money tot=0;
>     while (count--) tot+=emp_sals[count];
>     return tot;
> }
>
> not have been easier to modify (assuming employee_index had been used
> throughout the program).

Your point is valid, if there is such a thing as a 16-bit system that can
index more than 2^15 Money objects in a single array. (My experience on
Intel 16-bit platforms was that an array can't be that large without
extraordinary effort, and strange restrictions, but this might not apply
to all 16-bit platforms.)

Still, how far do you take this?
    employee_index       For arrays indexed by employee
    department_index     For arrays indexed by department
    location_index       For arrays indexed by location number
    division_index       For arrays indexed by sales division
    region_index         For arrays indexed by region
    telephone_index      For arrays indexed by telephone extension
    hash_index           For hash tables, regardless of hash algorithm?
                            (We need a separate constant for HASH_MAX,
                             but what size index variable do we use?)
    year_index           For arrays indexed by year
    month_index          For arrays indexed by month and year
    date_index           For arrays indexed by date
    hour_index           For arrays with up to 24 hourly indexes
    minute_index         For arrays with up to 1440 per-minute indexes
    second_index         For arrays with up to 86000 indexes
    page_index           For indexes which represent page numbers in a book
ad nauseum...

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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

In article <35C91E2B.13D9@nospam.aracnet.com>,
  sj_nospam@nospam.aracnet.com wrote:
> AllanW@my-dejanews.com wrote:
> [snip]
> > The returned value is a DATA, so that it can be a plain int if
> > possible and a long int if needed. But count is a short-lived variable
> > used as an array index; such variables should always be an int unless
> > there's some good reason not to. Remember, int is the "natural"
> > integer type for the current platform. If short and/or long are
> > different than int, they might require extra machine code to increment
> > or decrement; but I doubt there are many platforms where decrementing
> > an int requires more machine code than decrementing a short or long.
>
> Probably not... but there are no guarantees...

Isn't there?  CD2:

  3.9.1  Fundamental types                           [basic.fundamental]

2 There  are  four  signed  integer  types:  "signed char", "short int",
  "int", and "long int."  In this list, each type provides at  least  as
  much  storage  as those preceding it in the list.  Plain ints have the
  natural  size  suggested  by  the  architecture   of   the   execution
  environment15) ; the other signed integer types are provided  to  meet
  special needs.

"...have the natural size suggested by the architecture..." makes me
believe that even if it doesn't handle all possible arrays, it at least
handles the vast majority.

In any case, I don't need a guarantee.  By definintion, our portable
source code can't optimize for every platform we port to. But if the
code works optimally on some large percentage of compilers, and works
correctly (but slightly suboptimally) on a few, we can call it a success.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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

In article <6q9ufe$s0p@dg2.iunet.it>,
  "Alberto Barbati" <albbarbZZZ@tin.it> wrote:
> James Kuyper wrote in message <35C5E574.3F54@wizard.net>...
> >Bryan Althaus wrote:
> >> Microsoft likes C++, they don't like Java.  When Microsoft starts adding
> >> new keywords to its C++, then its time to worry, until then I don't
> >
> >Then it's time to worry. They already added keywords to C, and retained
> >those keywords in C++.
>
> If you include in "keywords" also the keywords beginning with a double
> underscore, then Microsoft has added _a_lot_ of keywords to C++. The
> __declspec keyword alone can be used in 9 different contexts, some of
> which
> (for example: property) have such an impact to the semantic that a
> compiler
> can't simply ignore it. Code that uses such keywords is not C++ code
> anymore.

That last point is the most important. This doesn't violate the standard
because standard C++ programs don't use these keywords.

Just because the Visual C++ compiler compiles programs that are not
standard-compliant, doesn't make it non-conforming. It does properly
handle all programs that are standard-compliant, with certain
exceptions caused by compiler bugs.

BTW, I haven't seen any posts from Microsoft on this subject. I wouldn't
expect a "promise" because someone might hold you liable -- but can
you give us an *indication* about weather or not you *think* this
bug is fixed in 6.0?

> The VC++ 6.0 adds two more keywords (__forceinline and __assume),
> fortunately they are only for optimization purpose and can easily be
> ignored
> by a non-MS compiler.

They wouldn't be, though, unless you took steps to force it to (you might
get away with
    #define __declspec(x)
but there's no guarantees). Fortunately, this isn't a concern because
programmers writing for portability aren't supposed to use these keywords
anyway.

> I do not think that MS likes C++. Otherwise the VC6 would have been a
> compiler improvement and not just an IDE update, as it is.

Are you saying that the underlying compiler hasn't changed at all? How do
you know this?

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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

In article <35C65F23.66F4C7E7@ix.netcom.com>,
  "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
> kanze@my-dejanews.com wrote:
> >
> > In article <35BFDA99.2FEA@atlas.otago.ac.nz>,
> >   ok@atlas.otago.ac.nz wrote:
> > > System-depdent libraries?  Yes of course, but that's not LANGUAGE
> > > extensions.  Hooks into assembler?  On rare occasions, yes, but
> > > again, it *CAN* be done entirely without LANGUAGE extensions.
> > > Access to DLLs?  Why yes of course, but no sane system has or needs
> > > any LANGUAGE extensions for that!
> >
> > About the only point I can seriously agree with is the last.
>
> I don't quite agree with the last statement. The purpose of the
> extension is to make dynamic linking more automatic and efficient,
> without the need for explicit indirect function calls, etc. The job can
> be done without extensions, but can be done better with.

You don't need extensions to make dynamic linking more automatic or
efficient.  None of the UNIX compilers need them.

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

Alberto Barbati wrote in message <6q9ufe$s0p@dg2.iunet.it>...
>Code that uses such keywords is not C++ code
>anymore.

It's C++, but it's not Standard C++. The two aren't equivalent. If
they were, there would be no C++ compilers and this newsgroup could
not exist.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 Kanze wrote:
>>First, my experience is limited to Windows NT; Windows 95 may behave
>>differently.  Under Windows NT, each DLL has its own copy of malloc/free,
>>and its own free space arena.  Freeing memory to the wrong free space
>>arena causes an immediate error if the debugging allocators are used;


Doug Harrison replied:
>In general, the above is incorrect. You can get that behavior, but it
>isn't forced down your throat. As I said in another message in this
>thread:
>
>"If you're composing a C++ program out of dynamically linked
>components, and each component links to the same C (and C++) run-time
>DLL, the entire program uses a single heap. Under those conditions,
>any component can free memory allocated by any other component,
>subject to the usual rules concerning matching allocation and
>deallocation functions. Even if you explicitly load a DLL, as long as
>the DLL is dynamically linked to the CRT you're using, I'm pretty sure
>that your app will continue to share a single heap."
>
>This is the case for Win95, Win98, WinNT, etc. I reckon you must be
>statically linking to the CRT; dynamically linking to the CRT will
>address your concerns.


Except there are more than one version of the run time library which can be
linked in even if one uses DLLs.  Using any of the standard C++ header files
(e.g., <algorithm>, <fstream>) forces a link to one standard run time
library.  Not using them defaults to a different one.  Oh, and then one must
take into account that there are single-threaded and multi-threaded versions
also.

All DLLs in your system have to use the same one, or you are not going to be
using the same heap.

Phil Weiss.

[also, better watch out if some parts are compiled with MS Fortran
Powerstation.  It forces a link to yet another version of the C runtime.]



[ 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 <35cdc263.4201734@netnews.worldnet.att.net>,
  dHarrison@worldnet.att.net (Doug Harrison) wrote:
> On 5 Aug 1998 05:57:54 -0400, jkanze@otelo.ibmmail.com wrote:
>
> >First, my experience is limited to Windows NT; Windows 95 may behave
> >differently.  Under Windows NT, each DLL has its own copy of malloc/free,
> >and its own free space arena.  Freeing memory to the wrong free space
> >arena causes an immediate error if the debugging allocators are used;
>
> In general, the above is incorrect. You can get that behavior, but it
> isn't forced down your throat. As I said in another message in this
> thread:
>
> "If you're composing a C++ program out of dynamically linked
> components, and each component links to the same C (and C++) run-time
> DLL, the entire program uses a single heap. Under those conditions,
> any component can free memory allocated by any other component,
> subject to the usual rules concerning matching allocation and
> deallocation functions. Even if you explicitly load a DLL, as long as
> the DLL is dynamically linked to the CRT you're using, I'm pretty sure
> that your app will continue to share a single heap."
>
> This is the case for Win95, Win98, WinNT, etc. I reckon you must be
> statically linking to the CRT; dynamically linking to the CRT will
> address your concerns.

In sum, if my third party libraries are using a DLL specific heap, it
is an error in the way that the third party built them, and I should
insist that they build differently.

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

I didn't say it directly; I only asked Paul Flinders if that's what
he meant. You snipped the next paragraph of my response.

> The standard types [un]signed char,
> [unsigned] short, [unsigned] int, [unsigned] long make all the same
> promises as [u]int_least8_t, [u]int_least16_t, [u]int_fast16_t, or
> [u]int_least32_t respectively.

Are these standard types? I'm not familiar with them, though I
can guess their meaning. Microsoft does something similar with
BYTE, WORD, and DWORD for unsigned types, and SHORT, INT, and
LONG for signed types. (But, since the latter three have "obvious"
definitions, I don't think they actually buy us anything...)

> Any places where those typedefs would be
> appropriate (except when one of those types is explicitly required by an
> interface), so would those standard types (though not vice-versa). Of
> course, when you want different promises, a typedef is needed.

The trouble with names like int_least16_t (which I suppose means "an
integer with at least 16 bits") is that it's still too hardware specific.
If you find that your customer load is increasing, you need to increase
the size of variables that hold customer numbers, but there's no reason
to increase the size of variables that hold vendor numbers. With names
such as this, customers and vendors are likely to be represented with
the same typedef.

> > It's a good rule of thumb, and coincidentally it's the rationale for
> > types such as BYTE, WORD, LONG, and LPSTR in the Windows header files.
>
> It's not a good reason for creating typedefs with such generic names. It
> would have been better if they'd at least prefixed them with W_.

Naming standards are a whole other ball of wax, one which Microsoft is
only marginally aquainted with.

But the new C++ standard could help. Perhaps in some future version of
Microsoft's compiler, they can move all the legacy symbols into
namespace Microsoft::Windows -- by that I mean nested namespaces, as in
    namespace Microsoft {
        namespace Windows {
            // ... definitions here ...
        }
    }
Reasons for using this parallel the std:: idiom -- the existing
<windows.h> can define all the existing symbols, and then add
    using namespace Microsoft::Windows
to avoid breaking any code; while newer code would have access to the
symbols without polluting global namespace. But something tells me
that it isn't going to happen.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----== 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 wrote:
>
> In article <6q78hu$j5g$1@nnrp1.dejanews.com>,
>   jkanze@otelo.ibmmail.com wrote:

[...]

> [snip]
> > These services were defined
> > by Microsoft at a time when there was no standard, or even a proposed
> > one, at least with regards to the library.
> [snip]
> > face it: if you had 250KLoc of code using CObject::IsKindOf because
> > there wasn't anything else, you'd be rather pissed off if it suddenly
> > wasn't there.)
>
> That's right.
>
> Try saying it the other way around. Why are you writing any programs
> for Windows, when there could very well be an ISO/ANSI C++ in the year
> 2008, and it might make all your window-handling routines obsolete?
> Why are you bothering to read and write files the hard way, when the
> next C++ might create standards for portable binary record I/O? Why are
> you bothering to create algorithms, when you could wait 10 years or so
> and maybe possibly have half of them written into the library?
>
> Jolyon Wright, if you pay for a C++ compiler then you must have had
> some practical need for one. Presumably, it's to write programs that
> you need to use. That means that the program must be finished sometime
> soon. And that means using the tools you have now, instead of waiting
> until 2008 or so. Because in 2008, you would want to wait for an even
> newer standard in 2019; after that, wait until 2031, and then 2039 --
> let's say that in 2041 the ISO committee declares the language C++ to
> be "mature," meaning no more revisions will be made except to fix
> technical errors.

No, since in 2035 there will be the invention of "human oriented
programming", and in 2040 this will be widespread enough to
consider to support it in C++ - especially as it will fit nicely
into the 2039 version of C++...
(You want to know what human-oriented programming is? Well, in
2040 we will know ;-))

[...]


[ 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:
> I'll assume you don't mean that we should never use integers! You mean
> that we should never declare a variable as int, but only as some type
> INT which has been typedef'd to be some integral type.

That's exactly what I mean

> It's a good rule of thumb, and coincidentally it's the rationale for
> types such as BYTE, WORD, LONG, and LPSTR in the Windows header files.
> But we shouldn't be to anal about it. For instance, I wouldn't use it
> for character data. Also consider this example:
>
>     DATA total(DATA *data, int count) {
>         DATA tot=0;
>         while (count--) tot+=data[count];
>         return tot;
>     }
>
> The returned value is a DATA, so that it can be a plain int if possible
> and a long int if needed. But count is a short-lived variable used as
> an array index; such variables should always be an int unless there's
> some good reason not to. Remember, int is the "natural" integer type for
> the current platform. If short and/or long are different than int, they
> might require extra machine code to increment or decrement; but I doubt
> there are many platforms where decrementing an int requires more machine
> code than decrementing a short or long.

I'll agree that it's possible to get a bit too hung up on this.

However the plain char type specifically leaves the decision as to
whether it is signed or unsigned to the compiler implementer so even
"char" should probably not be used directly

Also for your example count is not just "a short-lived variable used
as an array index" - the range of values for "count" depends on the
number of items in the data array which is global.

Consider

Money total_wage_bill(Money *emp_sals, int count)
{
    Money tot=0;
    while (count--) tot+=emp_sals[count];
    return tot;
}

I hope you recognise it as your example with a few names changed. For
small organisations a 16bit int will be more than sufficient for the
count - but suppose IBM (roughly 225,000 employees) get interested in
your code. In that case you will have to hunt down every loop over
your employee table and make sure the index variable is a long.

Would

Money total_wage_bill(Money *emp_sals, employee_index count)
{
    Money tot=0;
    while (count--) tot+=emp_sals[count];
    return tot;
}

not have been easier to modify (assuming employee_index had been used
throughout the program).



[ 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 <6q7lf7$dg0$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
says...

[ ... ]
> One C++ vendor for Microsoft Windows, I forgot which one, *did* try to
> subvert them once. They tried to create a "virtual function" mechanism
> which used specific v-table slots. I think that the syntax was something
> like this:
>     class Window {
>     public:
>         // ...
>         virtual(0x0111) long OnCommand(long,long);
>         // ...
>     };
> where 0x0111 is the Microsoft Windows "WM_COMMAND" message.

Ahh, this was Borland.  The syntax was actually like this:

class whatever {
 virtual void HandleSomeMessage(RTMessage msg) =
  [ SomeWindowsMessageNumber];
};

However, this was also long before there was a standard for C++.
Their compiler may still allow this for the sake of backward
compatibility, but I'm really not sure one way or the other about
that.

> Microsoft never did anything so pathetic. Instead, they created the
> concept of a "message map" which contains a list of message
> numbers, an enumeration for function signatures, and a member
> function pointer. This isn't exactly simple either, and I think that
> they could have done it with a bit fewer macros, but at least they
> didn't have to break any language constructs to make it work.

I think just about anybody who's used their message maps agrees that
they're pretty ugly.  However, I don't know of any superior solutions
having come along either: as of OWL 2, Borland went to a set of macros
with different names than MS uses, but the basic concepts are
essentially identical.

> Totally unfair. MFC was created before RTTI and even before they
> implemented templates. (You try creating some of this stuff without
> using that half of the language!)

If you look, you'll find that the current version of MFC actually DOES
use RTTI internally, when it can.  However, RTTI doesn't do the job
for persistent objects, and MFC does.

[ ... ]

> It would be insane for them to suddenly drop
> support for these classes just because there's now an even-more-
> portable way to do it.

AllanW@my-dejanews.com wrote:
>
> In article <upvegkdaq.fsf@finobj.com>,
>   Paul Flinders <paul.flinders@finobj.com> wrote:
> > James Kuyper <kuyper@wizard.net> writes:
> >
> > > Jerry Coffin wrote:
> > > ...
> > > > I have to agree about most typedef's like LPSTR.  They pervade almost
> > > > everything MS writes, but they're _fairly_ easy to ignore most of the
> > > > time -- being typedef's, you can use "char *" instead and the two are
> > > > perfectly compatible.
> > >
> > > Any time that a publicly documented interface involves a typedef, there
> > > exists the implication that the typedef might change. Anyone who doesn't
> > > want to have to rewrite their code when that happens should use the
> > > typedef, not the underlying type, and not make more assumptions than
> > > necessary which are based upon that underlying type.
> >
> > There is perhaps an argument that the C and C++ built-in types are so
> > loosely defined that one should never use them for variables.
>
> I'll assume you don't mean that we should never use integers! You mean
> that we should never declare a variable as int, but only as some type
> INT which has been typedef'd to be some integral type.
>
> It's a good rule of thumb, and coincidentally it's the rationale for
> types such as BYTE, WORD, LONG, and LPSTR in the Windows header files.
> But we shouldn't be to anal about it. For instance, I wouldn't use it
> for character data. Also consider this example:

At work, we have a collection of similar types.  My rule of thumb is if
I'm defining and/or exporting an interface, I use Int8 or UInt32 (which
is what we are currently calling them...though I expect C9X might have
something to say about that in the future...)

For local variables, though...I tend to use plain old ints.


[snip]


> The returned value is a DATA, so that it can be a plain int if
> possible and a long int if needed. But count is a short-lived variable > used as an array index; such variables should always be an int unless > there's some good reason not to. Remember, int is the "natural"
> integer type for the current platform. If short and/or long are
> different than int, they might require extra machine code to increment > or decrement; but I doubt there are many platforms where decrementing > an int requires more machine code than decrementing a short or long.


Probably not... but there are no guarantees...


Scott


[ 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 5 Aug 1998 05:57:54 -0400, jkanze@otelo.ibmmail.com wrote:

>First, my experience is limited to Windows NT; Windows 95 may behave
>differently.  Under Windows NT, each DLL has its own copy of malloc/free,
>and its own free space arena.  Freeing memory to the wrong free space
>arena causes an immediate error if the debugging allocators are used;

In general, the above is incorrect. You can get that behavior, but it
isn't forced down your throat. As I said in another message in this
thread:

"If you're composing a C++ program out of dynamically linked
components, and each component links to the same C (and C++) run-time
DLL, the entire program uses a single heap. Under those conditions,
any component can free memory allocated by any other component,
subject to the usual rules concerning matching allocation and
deallocation functions. Even if you explicitly load a DLL, as long as
the DLL is dynamically linked to the CRT you're using, I'm pretty sure
that your app will continue to share a single heap."

This is the case for Win95, Win98, WinNT, etc. I reckon you must be
statically linking to the CRT; dynamically linking to the CRT will
address your concerns.

--
Doug Harrison
dHarrison@worldnet.att.net

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <199808031312.JAA04346@mailfw1.ford.com>,
  Mike Tiller <mtiller@ford.com> wrote:
> kanze@my-dejanews.com writes:
>
> > In article <35BE9CE0.ECEAD19D@nonexistant.com>,
> >   "Robert O'Dowd" <nospam@nonexistant.com> wrote:
>
> > > Correct me if I'm wrong ....   but the standard does not disallow
> > > extensions like LPTR being supported by a compiler.  The standard
> > > simply specifies a minimum level of features (capability and behavi=
our)
> > > that.  The standard simply specifies what features a programmer
> > > should stick to if software is to work with any compliant compiler.
> > > If other features are used (e.g. LPTR) then, by definition, the
> > > code has undefined behaviour.  I suppose a compiler could give
> > > warnings if extended features are used.
>
> > Well, the following program should compile and run on a compliant
> > compiler:
> >
> >     #include <iostream>
> >
> >     int
> >     main()
> >     {
> >         int         LPTR =3D 1 ;
> >         std::cout << LPTR << '\n' ;
> >         return 0 ;
> >     }
> >
> > And it does, at least with VC++ 5.0.  If you include the header file
> > which defines LPTR, however, you have invoked undefined behavior from
> > the point of view of the standard, and Microsoft defined behavior in
> > this particular case.
>
> It would seem to me that the same thing could be said about this case:
>
>      #include <iostream>
>
>      int
>      main()
>      {
>          int         __hpux__ =3D 1 ;
>          std::cout << __hpux__ << '\n' ;
>          return 0 ;
>      }
>
> Which might work under windows, but not under HP-UX.

The difference is that the first program is a legal C++ program, with
defined semantics, whereas the second isn't.  Thus, the first must run
on any system claiming to be conforming (and it does compile and run
on all systems I know of), where as anything can happen with the second.

If Microsoft failed to compile and run the first, it would be proof that
they are not conformant.  The fact that HP fails to compile the second
doesn't mean anything, however.

> However, as I understand it, use of preprocessor macros with double
> underscores both prepended and appended is reserved for the compiler
> implementation.  So it seems to me that microsoft should have
> implemented LPTR as __LPTR__ allowing you to do something like:
>
> #ifdef __LPTR__
> typedef int LPTR WidgetData;
> #else
> typedef int *WidgetData;
> #endif
>
> That way your example above using LPTR is complient and yet you can
> still make use of Microsoft's extension if you choose.

Such might have been a better solution.  Not knowing what LPTR is, or why
you would want to use it, I cannot say.  What I can say is that if the
symbol LPTR is defined in a program which only includes the standard
headers, they are not conformant, and if it isn't, they are, at least
on this point.  As to defining a symbol like LPTR (or STDIN_FILENO --
Microsoft isn't alone on this) in a non-standard header,
a program which includes this header isn't conformant, and must conform
to the requirements of the extensions (MFC, Posix, etc.) that it uses.

--
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=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
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              ]

|There is perhaps an argument that the C and C++ built-in types are so
|loosely defined that one should never use them for variables.

There is, but personally I don't think it's a good one. :-)

The built-in types are not _that_ loose; plenty of useful things can
be done with them, and needlessly hiding them behind typedefs can be
confusing.  Quick, will the following loop ever terminate?

 for (WORD i = 10; i >= 0; i--);

Abstraction can be obfuscation if misused.

IMHO, `broad' typedefs like WORD or even int16 (is that _exactly_ 16
bits, or _at least_ 16 bits?) are usually more trouble than they are
worth.  If you're going to use a new type, at least name it for what
it _is_ not its representation.

(That said, I'm happy about the <inttypes.h> in the C9X draft, since
it's nice to be able to more precisely specify the requirements that
you have for the underlying type.)
--
To reply by mail, please remove "mail." from my address -- but please
send e-mail or post, not both


[ 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 wrote:
>
> In article <upvegkdaq.fsf@finobj.com>,
>   Paul Flinders <paul.flinders@finobj.com> wrote:
> > James Kuyper <kuyper@wizard.net> writes:
> >
> > > Jerry Coffin wrote:
> > > ...
> > > > I have to agree about most typedef's like LPSTR.  They pervade almost
> > > > everything MS writes, but they're _fairly_ easy to ignore most of the
> > > > time -- being typedef's, you can use "char *" instead and the two are
> > > > perfectly compatible.
> > >
> > > Any time that a publicly documented interface involves a typedef, there
> > > exists the implication that the typedef might change. Anyone who doesn't
> > > want to have to rewrite their code when that happens should use the
> > > typedef, not the underlying type, and not make more assumptions than
> > > necessary which are based upon that underlying type.
> >
> > There is perhaps an argument that the C and C++ built-in types are so
> > loosely defined that one should never use them for variables.
>
> I'll assume you don't mean that we should never use integers! You mean
> that we should never declare a variable as int, but only as some type
> INT which has been typedef'd to be some integral type.

"never" is too strong a term. The standard types [un]signed char,
[unsigned] short, [unsigned] int, [unsigned] long make all the same
promises as [u]int_least8_t, [u]int_least16_t, [u]int_fast16_t, or
[u]int_least32_t respectively. Any places where those typedefs would be
appropriate (except when one of those types is explicitly required by an
interface), so would those standard types (though not vice-versa). Of
course, when you want different promises, a typedef is needed.

> It's a good rule of thumb, and coincidentally it's the rationale for
> types such as BYTE, WORD, LONG, and LPSTR in the Windows header files.

It's not a good reason for creating typedefs with such generic names. It
would have been better if they'd at least prefixed them with W_.


[ 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:
...
> "never" is too strong a term. The standard types [un]signed char,
> [unsigned] short, [unsigned] int, [unsigned] long make all the same
> promises as [u]int_least8_t, [u]int_least16_t, [u]int_fast16_t, or
> [u]int_least32_t respectively. Any places where those typedefs would be
> appropriate (except when one of those types is explicitly required by an
> interface), so would those standard types (though not vice-versa). Of
> course, when you want different promises, a typedef is needed.

Oops! Excuse me - that's what come from monitoring both comp.std.c and
comp.std.c++. I should have mentioned that <inttypes.h> is part of the
proposed C9X standard, and not a part of the C++ standard. With that
proviso, my comments still apply.


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

But this is a no-win proposition. If they use a static heap, then they
probably use a different version of the C++ heap than we do. But if
they use a dynamic library to implement the heap, then we had better
use the same DLL that they do.

So how do we avoid new in one place and delete in another?

   * The old HANDLE idiom: call my "init" function and I'll give you
     a handle, which you then pass back to me every time you want to
     do something to the data. But the DLL's data is never visible to
     the client or vice-versa (implication: we can't write a base
     class that the client specializes).

   * The client must pass in the address of ::operator new and ::operator
     delete; the DLL will use that for every object that might get
     constructed or deleted from client code. (I don't know of any DLL
     that does this, but it should work...)
     Bonus question: Call this function, passing the address of global
           operator new and global operator delete:
               DLL_init(void*(*op_new)(size_t), void(*op_del)(void*,size_t));

   * The DLL can avoid ever calling new or delete at all, for any object
     visible from the client. Instead, insist that the client code do
     so. To facilitate this, the client may use a hybrid approach:
     supply a thin layer of code that's statically bound in the client,
     including all of the allocation; leave the rest of the
     implementation in the DLL.

Answer to bonus question (untested):
    DLL_init(::operator new(size_t), ::operator delete(void*,size_t));

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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

>In sum, if my third party libraries are using a DLL specific heap, it
>is an error in the way that the third party built them, and I should
>insist that they build differently.

I couldn't comment specifically on that without reviewing the
situation in detail. I've only meant to point out that the problem you
seemed to categorically describe as inherent to Win32 operating
systems is in fact not inherent to them, and that one certainly can
avoid such problems. Consider the MFC DLL supplied with VC. It links
dynamically to the CRT, and as long as my MFC program also links
dynamically to the same CRT, I don't have the problem. If you have a
versioning problem, you'll want to recompile so that everyone agrees
on the CRT, but at least VC5/6 seem to have stabilized on a single,
binary-compatible msvcrt.dll (and MFC dll).

--
Doug Harrison
dHarrison@worldnet.att.net


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

>Except there are more than one version of the run time library which can be
>linked in even if one uses DLLs.  Using any of the standard C++ header files
>(e.g., <algorithm>, <fstream>) forces a link to one standard run time
>library.  Not using them defaults to a different one.  Oh, and then one must
>take into account that there are single-threaded and multi-threaded versions
>also.

If we're talking about VC5 or VC6, there's only one CRT DLL, and
that's the multithreaded msvcrt.dll. Both the old and new style C++
DLL runtimes link to it. As of VC5 and the VC6 release candidate,
msvcrt.dll seems to have stabilized. Before, it was changing with each
version, and we had msvcrt20.dll and msvcrt40.dll, and I agree that's
a problem when recompiling is impossible. Hopefully, msvcrt.dll will
maintain binary compatibility for a long time to come. As for the C++
runtime DLL, VC6 supplies a new one. This is understandable, since the
DLL contains the most common instantiations of basic_string,
basic_ostream, etc., and there are probably some differences between
the old and new versions. Now that the standard has been accepted,
hopefully VC7 will stabilize on a single, final C++ runtime DLL.

>All DLLs in your system have to use the same one, or you are not going to be
>using the same heap.

Yes, if by "system" you mean "program composed from dynamically linked
components".

--
Doug Harrison
dHarrison@worldnet.att.net


[ 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 sum, if my third party libraries are using a DLL specific heap, it
> is an error in the way that the third party built them, and I should
> insist that they build differently.

Possibly.  There are two sides to this.  If they use a common heap,
the same sorts of problems arise under Windows as under UNIX: if you
upgrade your standard library, you'll most likely need to get an
updated version of their DLL to go with it.

Ultimately, this comes down to a question of ownership of the memory.
If they allocate memory on a heap where you can't manipulate it, then
you can't take ownership of the memory, and they need to take care of
deleting it when it's no longer needed.

Conversely, if they want you to take ownership of the memory and
delete it when it's no longer needed, they need to ensure that it's
allocated in such a way that you CAN take ownership and delete it when
it's no longer needed.  There are a couple of ways of handling this:
they can use the same heap you do; the shortcoming of this is
mentioned above.  If they want to avoid that, they can ask you to
create an allocator object and pass its address to their library.
Chances are this will be something truly trivial that just overloads
operator () to allocate a chunk of memory -- the important point is
that new that gets called is in YOUR standard library so it allocates
from your heap.

Ultimately, it comes out pretty simple: the situation right now is
about like they've sold you some land, and then pointed out that all
the surrounding land is owned by other people, and you'll be allowed
to occupy, or even get close to, the land you just bought.  It's
clearly an impossible and intolerable situation, but that doesn't mean
there's only one possible solution to the problem.

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

jkanze@otelo.ibmmail.com wrote:

[snip]

>You don't need extensions to make dynamic linking more automatic or
>efficient.  None of the UNIX compilers need them.

But a unix shared library is just a collection of functions and data
which acts as though it had been linked into the executable. A dll
has the capability to act in a more sophisticated way. It can act
more like a separate program, maintaining its own data which it
can protect from any of its clients. To specify these requires
more facilities than the standard provides

Norman
X-No-Acknowledgement


[ 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 <199808031312.JAA04346@mailfw1.ford.com>,
  Mike Tiller <mtiller@ford.com> wrote:
> kanze@my-dejanews.com writes:
>
> > In article <35BE9CE0.ECEAD19D@nonexistant.com>,
> >   "Robert O'Dowd" <nospam@nonexistant.com> wrote:
>
> > > Correct me if I'm wrong ....   but the standard does not disallow
> > > extensions like LPTR being supported by a compiler.  The standard
> > > simply specifies a minimum level of features (capability and behaviour)
> > > that.  The standard simply specifies what features a programmer
> > > should stick to if software is to work with any compliant compiler.
> > > If other features are used (e.g. LPTR) then, by definition, the
> > > code has undefined behaviour.  I suppose a compiler could give
> > > warnings if extended features are used.
>
> > Well, the following program should compile and run on a compliant
> > compiler:
> >
> >     #include <iostream>
> >
> >     int
> >     main()
> >     {
> >         int         LPTR = 1 ;
> >         std::cout << LPTR << '\n' ;
> >         return 0 ;
> >     }
> >
> > And it does, at least with VC++ 5.0.  If you include the header file
> > which defines LPTR, however, you have invoked undefined behavior from
> > the point of view of the standard, and Microsoft defined behavior in
> > this particular case.
>
> It would seem to me that the same thing could be said about this case:
>
>      #include <iostream>
>
>      int
>      main()
>      {
>          int         __hpux__ = 1 ;
>          std::cout << __hpux__ << '\n' ;
>          return 0 ;
>      }
>
> Which might work under windows, but not under HP-UX.

No. Using __hpux__ as a variable name makes the program ill-formed.
Doesn't matter if it works on some compiler, it's never guaranteed to.

> However, as I understand it, use of preprocessor macros with double
> underscores both prepended and appended is reserved for the compiler
> implementation.  So it seems to me that microsoft should have
> implemented LPTR as __LPTR__ allowing you to do something like:
>
> #ifdef __LPTR__
> typedef int LPTR WidgetData;
> #else
> typedef int *WidgetData;
> #endif

This won't work anywhere. LPTR is not a Microsoft language extension.
One of the WINDOWS.H headers defines LPTR as a symbolic constant, just
as SEEK_SET is defined as a constant in STDIO.H. But since LPTR isn't
included in the program unless the programmer explicitly #includes the
windows header files, there is no reason why a compliant program can't
use it -- no #ifdef is needed. The same goes for LPSTR, which is not
#defined anywhere, but there are typedefs equivalent to
    typedef char CHAR;
    typedef CHAR*LPSTR, *PSTR;

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

In article <199808031312.JAA04346@mailfw1.ford.com>, mtiller@ford.com
says...

[ ... ]

> However, as I understand it, use of preprocessor macros with double
> underscores both prepended and appended is reserved for the compiler
> implementation.  So it seems to me that microsoft should have
> implemented LPTR as __LPTR__ allowing you to do something like:
>
> #ifdef __LPTR__
> typedef int LPTR WidgetData;
> #else
> typedef int *WidgetData;
> #endif
>
> That way your example above using LPTR is complient and yet you can
> still make use of Microsoft's extension if you choose.

As has been pointed out (repeatedly) already, LPTR is NOT a compiler
extension -- it's just one of many symbols MS defines in a non-
standard header.  If you don't include windows.h, then LPTR, LPSTR,
LPTSTR, etc., aren't defined at all.  As far as the C++ standard
cares, this is no different from including, e.g., sys/types.h or
sys/io.h, which also define things that aren't in the standard.  If
you include a header that isn't in the standard, you're almost certain
to get definitions of things that aren't in the standard either.  MS
does NOT define any of these symbols in the standard headers, and none
of them is pre-defined by the compiler or anything like that.  In
short, this entire discussion is basically much adieu about nothing.

MS _does_ predefine a few things on the same general order as
__hpux__, such as __WIN32.  As far as the standard cares, there's no
real difference between the two: you don't need to have both leading
and trailing pairs of underscores to have a reserved identifier.  Any
identifier that contains two underscores in a row, regardless of
position, is reserved.  Including more than one such pair doesn't make
the identifier any more reserved.  (Well, maybe an identifier like
__Stuffy__English__Gentleman__ would be a bit more reserved than most,
but the standard wouldn't notice...<G> )

--
    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 <35c72093.3740906@netnews.worldnet.att.net>,
dHarrison@worldnet.att.net says...

[ ... ]

> >MS does not get this wrong -- they support older code as an extension,
> >but if you ask for conformance, you get it, at least in this respect.
>
> It's mostly useless conformance, though, since the standard headers
> require the extensions. See KB articles Q167748 and Q168934 for more.

Right.  Ironically enough, MS' non-standard iostream.h compiles
perfectly well with extensions turned off, but the standard iostream
requires that extensions be turned on!

--
    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 <6psfor$reo$1@news.interlog.com>,
  "Daniel Parker" <danielp@nospam.com> wrote:
> kanze@my-dejanews.com wrote in message
> <6pnp4o$7fk$1@nnrp1.dejanews.com>...
> >
> >(On the other hand, I'll have to admit that the Microsoft implementation
> >of DLL's is almost unusable.  First, as you say, you need to add things
> >to the source code.  Worse, however, memory must be freed in the same DLL
> >in which it was allocated.
>
> In Win32, a DLL is mapped into the client process's address space, it
> has the same address space as the client, so what difference would it
> make in what DLL memory was freed?  In Win16, DLLs received their own
> local heaps, but that's not the case for Win32.

First, my experience is limited to Windows NT; Windows 95 may behave
differently.  Under Windows NT, each DLL has its own copy of malloc/free,
and its own free space arena.  Freeing memory to the wrong free space
arena causes an immediate error if the debugging allocators are used;
I've not tried it, but I would imagine that even without the debugging
allocators, unloading a DLL while retaining a pointer to memory allocated
in its free space arena is an invitation to disaster.

On all of the UNIX systems I've used, there has been a single free space
arena in the root, which is shared by all of the shared libraries.  I
don't know the arguments for doing it differently, but the little experience
I have suggests that the NT solution is a frequent source of errors,
sometimes difficult to work around.  (At least one third party library
defines a class local operator new and operator delete for every class
in the library.  The goal is to ensure that all of the new's and delete's
pass through these operators, which are in the same shared library.)

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

On 4 Aug 1998 17:30:06 GMT, James Kuyper <kuyper@wizard.net> wrote:

>Jolyon Wright wrote:
>...
>> Hm - yes, but wouldnt it be wonderful if the microsoft extensions extended
>> the language/ standards, instead of subverting them.  I am thinking of:-
>>
>> 1) Microsoft's insistance on using CObject::IsKindOf() etc rather than
>> "normal" RTTI
>> 2) CObject as an "impure" abstract base, thus precluding the possibility of
>> using MI effectively
>> 3) Profoundly eccentric collection classes (CArray etc) - STL is brilliant;
>> why not use it?
>
>I hate to defend Microsoft, but I think that all of those features of
>MFC predate the corresponding developements in the C++ standard.
>Microsoft would have to provide support for them as a matter of backward
>compatibility, even in the unlikely case that they favored people
>switching over to the new methods.

But why spoil the fun of knocking nonstandard code? :-)

Seriously, this reflects a general problem we've had for several years
and will continue to have for a while.  Having worked with various
vendors C++ implementations, I'm convinced that there really isn't a
good solution.

Borland (now Inprise) has in the past been one of the best at keeping
up with the standard.  This meant that each version gave us new,
improved capabilities but also brought new problems, some caused by
bugs because Borland was rushing things (want to see my scars from
4.50?), but more simply because the language was changing.

Microsoft was stable compared to Borland, but now we face some real
difficulties in bringing code up to date.  For example, nothing good
happens if one tries to combine libraries which use the old
<iostream.h> with new code that uses <iostream>.  And we're not done.
There will be at least one more traumatic upgrade.

Which is better?  I generally have prefered Microsoft's approach, but
the upgrade to 5.0 (and subsequent service packs) has been painful.

Similarly, on Solaris I've generally preferred Sun's stability despite
the fact that they've been among the worst at tracking the standard
(Sun has made it very clear that this was a conscious decision to
avoid forcing their users to continually modify code).  Conversion to
standard C++ will be very painful.  Even if they provide backward
compatibility options (as I expect they will) we'll be faced with the
choice of upgrading our code or trying to maintain nonstandard code
for years.  I must confess that much of my code, written before the
standard string and container classes were available or RTI, will look
just as terrible as Microsoft's when it is put in a standard
conforming implementation.

--
Michael M Rubenstein


[ 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 <35C5E574.3F54@wizard.net>...
>Bryan Althaus wrote:
>...
>> As I read all this I can't help thinking I'm reading this in a Java
>> newsgroup. Why all the Microsoft bashing? The standard is a few days
>> old and now Microsoft C++ 5.0 released way before the standard isn't
compliant,
>> that's a shock!  Here's another shocker, ANSI C++ is going to mean no
>> more to platform independent code than ANSI C does.
>
>Other implementations have done a much better job of tracking the
>evolving standard than MSVC.

Sun hasn't.  Borland hasn't.  Intel, with it's drop in compiler, hasn't.
GNU hasn't.  That's all I've had first hand experience with lately.
Which implementations did you have in mind?  I know there are better ones,
like KAI, but there are also worse ones.  Microsoft hasn't done too bad.

>That's the reason for the complaints,

I doubt it :-)

>and for the expectation that Microsoft will be exceptionally slow at
>bringing its compiler into compliance.

It's not very interesting hearing complaints about version 5 now.  I'd
be more interested in hearing comments on the conformity of version 6.

Regards,
Daniel Parker, danielp@no_spam.anabasis.com


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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:
>   "Daniel Parker" <danielp@nospam.com> wrote:
> > kanze@my-dejanews.com wrote
> > >
> > >(On the other hand, I'll have to admit that the Microsoft implementation
> > >of DLL's is almost unusable.  First, as you say, you need to add things
> > >to the source code.  Worse, however, memory must be freed in the same DLL
> > >in which it was allocated.
> >
> > In Win32, a DLL is mapped into the client process's address space, it
> > has the same address space as the client, so what difference would it
> > make in what DLL memory was freed?  In Win16, DLLs received their own
> > local heaps, but that's not the case for Win32.
>
> First, my experience is limited to Windows NT; Windows 95 may behave
> differently.  Under Windows NT, each DLL has its own copy of malloc/free,
> and its own free space arena.  Freeing memory to the wrong free space
> arena causes an immediate error if the debugging allocators are used;
> I've not tried it, but I would imagine that even without the debugging
> allocators, unloading a DLL while retaining a pointer to memory allocated
> in its free space arena is an invitation to disaster.
>
> On all of the UNIX systems I've used, there has been a single free space
> arena in the root, which is shared by all of the shared libraries.  I
> don't know the arguments for doing it differently, but the little experience
> I have suggests that the NT solution is a frequent source of errors,
> sometimes difficult to work around.  (At least one third party library
> defines a class local operator new and operator delete for every class
> in the library.  The goal is to ensure that all of the new's and delete's
> pass through these operators, which are in the same shared library.)
>
> --
> James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr

The reason for the separate malloc/frees in DLL's vs. Unix's one
malloc/free
for all is cultural, rather than technological.

Under Unix, shipping the C runtime library as a dll is the
responsibility of
the OS. Every Unix ships a c runtime, and it doesn't change much. Just
ask a
linux user how much of a pain it is to upgrade the C library.

Under Windows, shipping the C runtime is the responsibility of the
compiler
vendor. Not every Windows system even has a c runtime installed. Every
compiler has its own, and this library can and does change between
vendors
and versions from a single vendor. DLL's need a C runtime to work, and
they
link against whatever library their compiler came with. It may even
statically link with the runtime rather than dynamically link with it.

Yes, it's a pain.

-Chris

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <901821972.8819.0.nnrp-11.c2dea108@news.demon.co.uk>,
  "Jolyon Wright" <bob@jolyon.demon.co.uk> wrote:
> [Mod note: some excessive quoting snipped --mod (fjh).]
>
> kanze@my-dejanews.com wrote in message <6pnqin$96u$1@nnrp1.dejanews.com>...
> >MFC cannot conform to the standard, by definition, since it offers
> >services that are not defined by the standard.
>
> MFC is C--
> ---------------
>
> Hm - yes, but wouldnt it be wonderful if the microsoft extensions extended
> the language/ standards, instead of subverting them.  I am thinking of:-
>
> 1) Microsoft's insistance on using CObject::IsKindOf() etc rather than
> "normal" RTTI
> 2) CObject as an "impure" abstract base, thus precluding the possibility of
> using MI effectively
> 3) Profoundly eccentric collection classes (CArray etc) - STL is brilliant;
> why not use it?
>
> It seems to me that MFC is an extension of the Operating Sytem: not the
> language.  These services (above) ARE defined by the standard!

These services are but a very small part of MFC, which for the most
part is concerned about managing windows.  These services were defined
by Microsoft at a time when there was no standard, or even a proposed
one, at least with regards to the library.  I don't particularly like
the way they are done; even then, Booch Components did a far better
job.  But they were certainly an extension at the time, and of course,
backwards compatibility means that they are still there, even if
Microsoft fully supports std::string and std::vector today.  (Let's
face it: if you had 250KLoc of code using CObject::IsKindOf because
there wasn't anything else, you'd be rather pissed off if it suddenly
wasn't there.)

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <kuyper@wizard.net> writes:

> Jerry Coffin wrote:
> ...
> > I have to agree about most typedef's like LPSTR.  They pervade almost
> > everything MS writes, but they're _fairly_ easy to ignore most of the
> > time -- being typedef's, you can use "char *" instead and the two are
> > perfectly compatible.
>
> Any time that a publicly documented interface involves a typedef, there
> exists the implication that the typedef might change. Anyone who doesn't
> want to have to rewrite their code when that happens should use the
> typedef, not the underlying type, and not make more assumptions than
> necessary which are based upon that underlying type.

There is perhaps an argument that the C and C++ built-in types are so
loosely defined that one should never use them for variables.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

Hmm....given that you can use
    #include "afxwin.h", where it searches te current "directory" for
the
file prior to going to the system directories, would you be well-formed?
Even if the header file actually existed in the system directory and
wasn't
in the current directory?

If not, then if you include a "local" header file, #include "foo.h"
containing your own structs, would you be well-formed?

My point is that, assuming that no implementation-specific extensions to
C++
are needed to get a given library to compile (perhaps not link, as the
underlying API calls may not be available) then it's really not any
different from a "library" that a user would write.

Corrections welcome.

Dennis


--
Considering how to build better systems and how various languages can
serve that end is a much better use of time than fighting language wars.
Bjarne Stroustrup - http://www.research.att.com/~bs/blast.html

AllanW@my-dejanews.com wrote in message
<6pop3f$iq3$1@nnrp1.dejanews.com>...
>In article <6pkmr9$q5i$1@nnrp1.dejanews.com>,
>  jhyslop@my-dejanews.com wrote:
>> In article <6phorq$jtq$1@reader1.reader.news.ozemail.net>,
>>   "Patrick Wray" <pwray@ozemail.com.au> wrote:
>> >
>> > Tony wrote in message ...
>> > >Do I hear some agreement here that ANSI/ISO C++ compilers should not
be
>> > >tainted with (bundled with) proprietary technologies?  (my humble
>> > >bandwagon).  A movement anyone? :)
>> > >
>> > >Tony
>> >
>> > That humble bandwagon big enough for two?
>>
>> I don't have a problem - *as long as* the proprietary technology adheres
to
>> the Standard (which MFC reportedtly doesn't - the question is, will MS
>revise
>> it so it does?).
>
>Since there are no "foundation classes" in the C++ standard at all,
>all that's neccesary is to leave out the header file for MFC, and
>everything is compliant.
>
>For that matter, compliant compilers are allowed to do anything they
>want to do with programs that are not well-formed. And the moment you
>    #include <afxwin.h>
>you are no longer well-formed.
>


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

One place where MFC does not adhere to the standard is that they rely on
variables declared in a for loop to exist after the for-loop.
    for(int i = 0 ; i < count ; i++)
    {
        ...
    }

    retval = (i < count) ;

The above is non-standard.

While by deiniton a library such as MFC is non-standard, as they will
typically call platform-dependent routines to do their stuff, most
libraries
DO offer services outside the standard. :-)

--
Considering how to build better systems and how various languages can
serve
that end is a much better use of time than fighting language wars.
Bjarne Stroustrup - http://www.research.att.com/~bs/blast.html

kanze@my-dejanews.com wrote in message
<6pnqin$96u$1@nnrp1.dejanews.com>...
>In article <6pkmr9$q5i$1@nnrp1.dejanews.com>,
>  jhyslop@my-dejanews.com wrote:
>> In article <6phorq$jtq$1@reader1.reader.news.ozemail.net>,
>>   "Patrick Wray" <pwray@ozemail.com.au> wrote:
>> >
>> > Tony wrote in message ...
>> > >Do I hear some agreement here that ANSI/ISO C++ compilers should not
be
>> > >tainted with (bundled with) proprietary technologies?  (my humble
>> > >bandwagon).  A movement anyone? :)
>> > >
>> > >Tony
>> >
>> > That humble bandwagon big enough for two?
>>
>> I don't have a problem - *as long as* the proprietary technology adheres
to
>> the Standard (which MFC reportedtly doesn't - the question is, will MS
>revise
>> it so it does?).
>
>MFC cannot conform to the standard, by definition, since it offers
>services that are not defined by the standard.
>

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

jkanze@otelo.ibmmail.com wrote:

> First, my experience is limited to Windows NT; Windows 95 may behave
> differently.  Under Windows NT, each DLL has its own copy of malloc/free,
> and its own free space arena.

This is only true if you tell the compiler to do so. If you tell the
compiler to use the shared version of the C/C++ runtime library, all
DLLs and the EXE share one common memory pool. This is true for Visual
C++ under Windows NT and Windows 95 (in fact, it's a compiler issue, not
an OS issue).

--
Christof Stadler

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <901821972.8819.0.nnrp-11.c2dea108@news.demon.co.uk>,
  "Jolyon Wright" <bob@jolyon.demon.co.uk> wrote:

> Hm - yes, but wouldnt it be wonderful if the microsoft extensions extended
> the language/ standards, instead of subverting them.

They don't subvert them.

One C++ vendor for Microsoft Windows, I forgot which one, *did* try to
subvert them once. They tried to create a "virtual function" mechanism
which used specific v-table slots. I think that the syntax was something
like this:
    class Window {
    public:
        // ...
        virtual(0x0111) long OnCommand(long,long);
        // ...
    };
where 0x0111 is the Microsoft Windows "WM_COMMAND" message.

Microsoft never did anything so pathetic. Instead, they created the
concept of a "message map" which contains a list of message
numbers, an enumeration for function signatures, and a member
function pointer. This isn't exactly simple either, and I think that
they could have done it with a bit fewer macros, but at least they
didn't have to break any language constructs to make it work.

> I am thinking of:-
>
> 1) Microsoft's insistance on using CObject::IsKindOf() etc rather than
> "normal" RTTI
> 2) CObject as an "impure" abstract base, thus precluding the possibility of
> using MI effectively
> 3) Profoundly eccentric collection classes (CArray etc) - STL is brilliant;
> why not use it?
[snip]
> These services (above) ARE defined by the standard!

Totally unfair. MFC was created before RTTI and even before they
implemented templates. (You try creating some of this stuff without
using that half of the language!)

Even in an MFC project, nothing prevents you from using the new
features. Now that there are other ways to accomplish the same
thing, I'll even grant that the new ways are superior. But one of
MFC's strong points is that it reduces the amount of rewrite needed
to port a Windows program to the next version of Windows or to the
next version of C++. It would be insane for them to suddenly drop
support for these classes just because there's now an even-more-
portable way to do it.

I'm against "Microsoft bashing for fun and profit." If you're going
to pick on them, look around and find something genuinely wrong.
(There are lots of them.) But please don't just wail about them just
because they're large and successful.

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 comp.lang.c++.moderated James Kuyper <kuyper@wizard.net> wrote:
: Bryan Althaus wrote:
: ...
:> As I read all this I can't help thinking I'm reading this in a Java
:> newsgroup. Why all the Microsoft bashing? The standard is a few days
:> old and now Microsoft C++ 5.0 released way before the standard isn't compliant,
:> that's a shock!  Here's another shocker, ANSI C++ is going to mean no
:> more to platform independent code than ANSI C does.

: Other implementations have done a much better job of tracking the
: evolving standard than MSVC. That's the reason for the complaints, and
: for the expectation that Microsoft will be exceptionally slow at
: bringing its compiler into compliance.
:
 Slow?  Take a look at Sun's latest C++ compiler 4.2. STL? What's that?
 STL doesn't come with Sun's C++ compilers (correct me if I'm wrong).

 You need to *buy* a special version of STL from RogueWave just to get it
to
 compile under Sun's compilers because they are so far behind the standard.

 Under v4.2 'bool','true', &  'false' are not reserved keywords.
 namespaces, RTTI, etc. missing.

 This all goes away when Sun CC v5.0 ships soon, but Sun has made no
 secret wanting to protect it v4.x customer base by moving slowly
 on ANSI features.

 So why don't I hear any Sun bashing??  (I'm PRO Solaris...)

:> Microsoft likes C++, they don't like Java.  When Microsoft starts adding
:> new keywords to its C++, then its time to worry, until then I don't

: Then it's time to worry. They already added keywords to C, and retained
: those keywords in C++.

I assume you are talking about keywords like, 'near', 'far', 'pascal' ?

And haven't they for years?  Given the amount of code out there and the
fact that they only ship one compiler which is both a C and C++ compiler,
what are they to do? (If I'm wrong about C/C++ being the same compiler,
sorry)


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <199808031258.IAA24472@mailfw2.ford.com>,
  Mike Tiller <mtiller@ford.com> wrote:
> kanze@my-dejanews.com writes:
>
> > MFC cannot conform to the standard, by definition, since it offers
> > services that are not defined by the standard.
>
> As far as I know, a compiler vendor is free to implement functionality
> above and beyond the standard so long as the compiler continues to
> compile code that is conformant and so long as the extended language
> doesn't conflict with the standard language.

No problem, but such extensions cannot be said to "conform to the
standard."  MFC is NOT all of the VC++, and MFC certainly doesn't
conform to the standard.  Nor does it claim to; it is an extension.
As soon as I use anything from MFC, my program is not standard conforming,
and it is not portable.

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

Dennis Weldy <nojunkmail@ever.com> wrote:

>One place where MFC does not adhere to the standard is that they rely on
>variables declared in a for loop to exist after the for-loop.
>    for(int i = 0 ; i < count ; i++)
>    {
>        ...
>    }
>
>    retval = (i < count) ;
>
>The above is non-standard.

The above was standard at the time it was written. You cannot blame
Microsoft if the standard changes after the event.

Norman
X-No-Acknowledgement


[ 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 <6q78hu$j5g$1@nnrp1.dejanews.com>,
  jkanze@otelo.ibmmail.com wrote:
> In article <901821972.8819.0.nnrp-11.c2dea108@news.demon.co.uk>,
>   "Jolyon Wright" <bob@jolyon.demon.co.uk> wrote:
> > [Mod note: some excessive quoting snipped --mod (fjh).]
> >
> > kanze@my-dejanews.com wrote in message <6pnqin$96u$1@nnrp1.dejanews.com>...
> > >MFC cannot conform to the standard, by definition, since it offers
> > >services that are not defined by the standard.
> >
> > MFC is C--
> > ---------------
> >
> > Hm - yes, but wouldnt it be wonderful if the microsoft extensions extended
> > the language/ standards, instead of subverting them.  I am thinking of:-
> >
> > 1) Microsoft's insistance on using CObject::IsKindOf() etc rather than
> > "normal" RTTI
> > 2) CObject as an "impure" abstract base, thus precluding the possibility of
> > using MI effectively
> > 3) Profoundly eccentric collection classes (CArray etc) - STL is brilliant;
> > why not use it?
> >
> > It seems to me that MFC is an extension of the Operating Sytem: not the
> > language.  These services (above) ARE defined by the standard!
>
[snip]
> These services were defined
> by Microsoft at a time when there was no standard, or even a proposed
> one, at least with regards to the library.
[snip]
> face it: if you had 250KLoc of code using CObject::IsKindOf because
> there wasn't anything else, you'd be rather pissed off if it suddenly
> wasn't there.)

That's right.

Try saying it the other way around. Why are you writing any programs
for Windows, when there could very well be an ISO/ANSI C++ in the year
2008, and it might make all your window-handling routines obsolete?
Why are you bothering to read and write files the hard way, when the
next C++ might create standards for portable binary record I/O? Why are
you bothering to create algorithms, when you could wait 10 years or so
and maybe possibly have half of them written into the library?

Jolyon Wright, if you pay for a C++ compiler then you must have had
some practical need for one. Presumably, it's to write programs that
you need to use. That means that the program must be finished sometime
soon. And that means using the tools you have now, instead of waiting
until 2008 or so. Because in 2008, you would want to wait for an even
newer standard in 2019; after that, wait until 2031, and then 2039 --
let's say that in 2041 the ISO committee declares the language C++ to
be "mature," meaning no more revisions will be made except to fix
technical errors.

    From: boss@whatever.retirement.uk
    To: bob@jolyon.retirement.uk
    Date: August 6, 2041 AD
    Subject: Re: Accounts Receivable system

    On August 5, 2041 AD, "Jolyon Wright" <bob@julyon.retirement.uk> wrote:

    > Hey, boss, remember that AR system you asked me to write back in
    > 1998? I told you that if we waited for the new C++ features, I
    > could do it in 85 lines of code? Well, it took 43 years for the
    > ISO committee to give me a "mature" language, but here it is --
    > and you'll be happy to know I did it in just 44 lines of code!

    Congratulations, Jolyon, on finally finishing the AR system. I've
    tested it with Testo41 and it performs flawlessly. Ironically, upper
    management refuses to implement it, saying that the interim system
    first developed in 1999 still works well enough. Even though your
    new system is much more maintainable (because it's completely written
    in standard C++), they seem to feel that having a system that works
    and is delivered on-time is even more important. Oh, well...

    BTW, I submitted your name to the Guiness Web Page of World Records
    as the slowest programmer on the face of the planet (less than one
    productive line per year!), but they rejected it because of their
    nit-picky rules. (Back in 2015, some wise-ass actually went out and
    PROVED what we already knew -- that Lines Of Code wasn't worth a
    dime. Somehow that made a difference to the Guiness people. Go
    figure...)

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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

In article <35c204d9.0@bbs.ugsolutions.com>,
  Dennis Weldy <nojunkmail@ever.com> wrote:
> One place where MFC does not adhere to the standard is that they rely on
> variables declared in a for loop to exist after the for-loop.
>     for(int i = 0 ; i < count ; i++)
>     {
>         ...
>     }
>
>     retval = (i < count) ;
>
> The above is non-standard.

Only because it used C++ before that aspect was documented in a standard.
This will affect a lot of programs, not just MFC.

(Some of us saw this coming, and avoided declaring variables in a for()
loop for just this reason. Were we diligent enough to make sure that we
*NEVER* did anything like this? I'll let you know after we get the next
version of our C++ compiler...)

> While by deiniton a library such as MFC is non-standard, as they will
> typically call platform-dependent routines to do their stuff, most
> libraries
> DO offer services outside the standard. :-)

Of course. MFC offered strings before strings were standard, they
offered container classes before templates were widespread, etc. You
could argue about whether these were the best implementations that
they could offer at the time, but you can't reasonably argue that
they weren't needed by anybody.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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

In article <upvegkdaq.fsf@finobj.com>,
  Paul Flinders <paul.flinders@finobj.com> wrote:
> James Kuyper <kuyper@wizard.net> writes:
>
> > Jerry Coffin wrote:
> > ...
> > > I have to agree about most typedef's like LPSTR.  They pervade almost
> > > everything MS writes, but they're _fairly_ easy to ignore most of the
> > > time -- being typedef's, you can use "char *" instead and the two are
> > > perfectly compatible.
> >
> > Any time that a publicly documented interface involves a typedef, there
> > exists the implication that the typedef might change. Anyone who doesn't
> > want to have to rewrite their code when that happens should use the
> > typedef, not the underlying type, and not make more assumptions than
> > necessary which are based upon that underlying type.
>
> There is perhaps an argument that the C and C++ built-in types are so
> loosely defined that one should never use them for variables.

I'll assume you don't mean that we should never use integers! You mean
that we should never declare a variable as int, but only as some type
INT which has been typedef'd to be some integral type.

It's a good rule of thumb, and coincidentally it's the rationale for
types such as BYTE, WORD, LONG, and LPSTR in the Windows header files.
But we shouldn't be to anal about it. For instance, I wouldn't use it
for character data. Also consider this example:

    DATA total(DATA *data, int count) {
        DATA tot=0;
        while (count--) tot+=data[count];
        return tot;
    }

The returned value is a DATA, so that it can be a plain int if possible
and a long int if needed. But count is a short-lived variable used as
an array index; such variables should always be an int unless there's
some good reason not to. Remember, int is the "natural" integer type for
the current platform. If short and/or long are different than int, they
might require extra machine code to increment or decrement; but I doubt
there are many platforms where decrementing an int requires more machine
code than decrementing a short or long.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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

In message <6pop3f$iq3$1@nnrp1.dejanews.com>, I wrote:
>For that matter, compliant compilers are allowed to do anything they
>want to do with programs that are not well-formed. And the moment you
>    #include <afxwin.h>
>you are no longer well-formed.

In article <35c2063b.0@bbs.ugsolutions.com>,
  Dennis Weldy <nojunkmail@ever.com> replied:
> Hmm....given that you can use
>     #include "afxwin.h", where it searches t[h]e current "directory" for
> the
> file prior to going to the system directories, would you be well-formed?

Yes, if you supplied the afxwin.h header file and everything else
required.

> Even if the header file actually existed in the system directory and
> wasn't in the current directory?

Presuming it was already there, and you didn't copy it: No. Such a
program wouldn't compile on every compliant compiler, such as any compiler
not made for Windows.

> If not, then if you include a "local" header file, #include "foo.h"
> containing your own structs, would you be well-formed?

Yes.

> My point is that, assuming that no implementation-specific extensions to
> C++
> are needed to get a given library to compile

Yes, that assumption is exactly the point. You may use MFC or not, as
you like, but don't think that a program written to use MFC is standard
C++ unless you are willing to port MFC along with the program.

> (perhaps not link, as the
> underlying API calls may not be available)

Suppose you port your program to another platform, along with the MFC
header files but not the implementation. This hypothetical platform
compiles without any diagnostics, but refuses to link. Are you satisfied?

> then it's really not any
> different from a "library" that a user would write.

Correct.

Include *ALL* of MFC with your programs. Be sure to follow *ALL* of the
rules in the C++ standard. Simple. (Not easy -- this may include a total
or complete rewrite of MFC -- but certainly simple.) Now include it with
your program.

Viola: your program is now compliant, and as promised, you can now sleep
comfortably, secure in the knowledge that your program will compile and
execute properly on *ANY* system with a conforming C++ compiler.
Congratulations.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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

In article <6q7hli$e4@news1.panix.com>,
  Bryan Althaus <bryan@panix.com> wrote:
> In comp.lang.c++.moderated James Kuyper <kuyper@wizard.net> wrote:
> : Then it's time to worry. They already added keywords to C, and retained
> : those keywords in C++.
>
> I assume you are talking about keywords like, 'near', 'far', 'pascal' ?
>
> And haven't they for years?  Given the amount of code out there and the
> fact that they only ship one compiler which is both a C and C++ compiler,
> what are they to do? (If I'm wrong about C/C++ being the same compiler,
> sorry)

It's one compiler, but with two modes. When compiling C code, this:
    int func(a,b) int a,b; { return a+b; }
works just fine. But in C++ it issues a diagnostic.

The identifiers near, far, and pascal are incorrectly recognized as obsolete
keywords, even when used in legal expressions. This is a compiler bug, and
it affects C even harder than C++. What they *should* do is issue a warning
message, but instead they get various inappropriate errors.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

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

James Kuyper wrote in message <35C5E574.3F54@wizard.net>...
>Bryan Althaus wrote:
>> Microsoft likes C++, they don't like Java.  When Microsoft starts adding
>> new keywords to its C++, then its time to worry, until then I don't
>
>Then it's time to worry. They already added keywords to C, and retained
>those keywords in C++.

If you include in "keywords" also the keywords beginning with a double
underscore, then Microsoft has added _a_lot_ of keywords to C++. The
__declspec keyword alone can be used in 9 different contexts, some of
which
(for example: property) have such an impact to the semantic that a
compiler
can't simply ignore it. Code that uses such keywords is not C++ code
anymore.
The VC++ 6.0 adds two more keywords (__forceinline and __assume),
fortunately they are only for optimization purpose and can easily be
ignored
by a non-MS compiler.
I do not think that MS likes C++. Otherwise the VC6 would have been a
compiler improvement and not just an IDE update, as it is.


--
Alberto Barbati
Please remove ZZZ from my e-ddress when replying




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

kanze@my-dejanews.com writes:

> In article <35BE9CE0.ECEAD19D@nonexistant.com>,
>   "Robert O'Dowd" <nospam@nonexistant.com> wrote:

> > Correct me if I'm wrong ....   but the standard does not disallow
> > extensions like LPTR being supported by a compiler.  The standard
> > simply specifies a minimum level of features (capability and behaviour)
> > that.  The standard simply specifies what features a programmer
> > should stick to if software is to work with any compliant compiler.
> > If other features are used (e.g. LPTR) then, by definition, the
> > code has undefined behaviour.  I suppose a compiler could give
> > warnings if extended features are used.

> Well, the following program should compile and run on a compliant
> compiler:
>
>     #include <iostream>
>
>     int
>     main()
>     {
>         int         LPTR = 1 ;
>         std::cout << LPTR << '\n' ;
>         return 0 ;
>     }
>
> And it does, at least with VC++ 5.0.  If you include the header file
> which defines LPTR, however, you have invoked undefined behavior from
> the point of view of the standard, and Microsoft defined behavior in
> this particular case.

It would seem to me that the same thing could be said about this case:

     #include <iostream>

     int
     main()
     {
         int         __hpux__ = 1 ;
         std::cout << __hpux__ << '\n' ;
         return 0 ;
     }

Which might work under windows, but not under HP-UX.

However, as I understand it, use of preprocessor macros with double
underscores both prepended and appended is reserved for the compiler
implementation.  So it seems to me that microsoft should have
implemented LPTR as __LPTR__ allowing you to do something like:

#ifdef __LPTR__
typedef int LPTR WidgetData;
#else
typedef int *WidgetData;
#endif

That way your example above using LPTR is complient and yet you can
still make use of Microsoft's extension if you choose.

> --
> James Kanze

--
Michael Tiller
Ford Motor Company


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 3 Aug 1998 08:14:46 -0400, fjh@cs.mu.OZ.AU (Fergus Henderson)
wrote:

>David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:
>
>>FWIW, I tried compiling the following conforming program on VC++ 5.0:
>>
>>    // far.cpp
>>
>>    #include <iostream>
>>
>>    int main()
>>    {
>>        int     far = 1;
>>
>>        std::cout << far << '\n';
>>        return (0);
>>    }
>>
>>Compiling under VC++ 5.0 I get:
>>    far.cpp(7) : error C4226: nonstandard extension used : 'far' is
>>        an obsolete keyword
>>    far.cpp(7) : error C2513: 'int' : decl-specifier is missing a
>>        declarator before '='
>...
>>
>>So they're better (i.e., closer to the standard) than they were
>>before, but they still have a few conformance problems.
>
>What options did you compile with?
>
>Most compilers are not conforming unless invoked with options to
>enable strict conformance.

Unfortunately, Microsoft's option for standard compilation is badly
broken and gives a large number error messages (not related to far) in
the supplied headers on this program.
--
Michael M Rubenstein

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <901821972.8819.0.nnrp-11.c2dea108@news.demon.co.uk>,
bob@jolyon.demon.co.uk says...

[ ... ]

> 1) Microsoft's insistance on using CObject::IsKindOf() etc rather than
> "normal" RTTI

If you bother to look, you'll find that the RTTI-like functionality in
MFC does things that RTTI itself doesn't; in particular, RTTI doesn't
provide much help with persistent objects, but IsKindOf does.  In
short, RTTI simply won't do the job on its own.

> 2) CObject as an "impure" abstract base, thus precluding the possibility of
> using MI effectively

"effectively" makes this a value oriented statement rather than an
objective one.  As is often the case with older, more or less
monolithic class libraries, you end up with some restrictions on MI,
but if you look through the tech-notes, you'll find specific
directions on how to use MI in conjunction with MFC.

> 3) Profoundly eccentric collection classes (CArray etc) - STL is brilliant;
> why not use it?

There are at least four reasons that appear obvious to me:

 1) the cost is high (collections, strings, etc., are used throughout
MFC, so you're looking at a major rewrite.)

2) the benefit isn't particularly high: the major savings to MS would
have been in not having to write the MFC collections, but since
they're already written, there's no savings in that area.  As far as
portability of source code goes, at least for now, code using MFC is
likely more portable than code using the standard library.

3) The MFC classes provide persistence and the standard classes don't.
In reality, CObject::IsKindOf and such _are_ more or less extensions
of RTTI; in fact, they resolve to using RTTI on instantiated objects.
However, bare RTTI simply doesn't provide all the capabilities
necessary for what MFC does, so they use a wrapper that adds the
functionality they need.

4) MS has licensed MFC to a number of other vendors, most of whose
compilers won't even come _close_ to compiling the standard library.

Given some of the flimsy excuses already being used to accuse MS of
unfair trade practices, this isn't something they can afford to even
think about.  If they licensed MFC to other vendors to get it
established, then modified it so the other vendors' compilers wouldn't
work with it anymore, they'd undoubtedly be accused of trying to
leverage its widespread use to increase sales of their compiler.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

"Jolyon Wright" <bob@jolyon.demon.co.uk> wrote:

>kanze@my-dejanews.com wrote in message <6pnqin$96u$1@nnrp1.dejanews.com>...
>>MFC cannot conform to the standard, by definition, since it offers
>>services that are not defined by the standard.
>
>MFC is C--
>---------------
>
>Hm - yes, but wouldnt it be wonderful if the microsoft extensions extended
>the language/ standards, instead of subverting them.  I am thinking of:-
>
>1) Microsoft's insistance on using CObject::IsKindOf() etc rather than
>"normal" RTTI
>2) CObject as an "impure" abstract base, thus precluding the possibility of
>using MI effectively
>3) Profoundly eccentric collection classes (CArray etc) - STL is brilliant;
>why not use it?
>
>It seems to me that MFC is an extension of the Operating Sytem: not the
>language.  These services (above) ARE defined by the standard!

>
>Maybe, if we all whinge enough they will get with the programme - but what
>else are you going to use??

MFC predates the standard by many years. It has to support an great deal
of legacy code. For many people its continued support of that legacy
code
is more important than adhering to the new standard.

The content of your post seems to be nothing more than "Let's knock
Microsoft because the code they wrote 5 years ago doesn't conform
to this month's standard". Hardly a meaningful contribution to
human knowledge.

Norman

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 3 Aug 1998 07:47:29 -0400, jcoffin@taeus.com (Jerry Coffin) wrote:

>> Well, there are certain standard items that Microsoft gets wrong (scope of
a
>> variable introduced in the for-init-statement, for example), but in general
>> I'd agree with both your statements.
>
>MS does not get this wrong -- they support older code as an extension,
>but if you ask for conformance, you get it, at least in this respect.

It's mostly useless conformance, though, since the standard headers
require the extensions. See KB articles Q167748 and Q168934 for more.

--
Doug Harrison
dHarrison@worldnet.att.net

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 wrote:
...
> I have to agree about most typedef's like LPSTR.  They pervade almost
> everything MS writes, but they're _fairly_ easy to ignore most of the
> time -- being typedef's, you can use "char *" instead and the two are
> perfectly compatible.

Any time that a publicly documented interface involves a typedef, there
exists the implication that the typedef might change. Anyone who doesn't
want to have to rewrite their code when that happens should use the
typedef, not the underlying type, and not make more assumptions than
necessary which are based upon that underlying type.
---
[ 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              ]

Bryan Althaus wrote:
...
> As I read all this I can't help thinking I'm reading this in a Java
> newsgroup. Why all the Microsoft bashing? The standard is a few days
> old and now Microsoft C++ 5.0 released way before the standard isn't compliant,
> that's a shock!  Here's another shocker, ANSI C++ is going to mean no
> more to platform independent code than ANSI C does.

Other implementations have done a much better job of tracking the
evolving standard than MSVC. That's the reason for the complaints, and
for the expectation that Microsoft will be exceptionally slow at
bringing its compiler into compliance.

> Microsoft likes C++, they don't like Java.  When Microsoft starts adding
> new keywords to its C++, then its time to worry, until then I don't

Then it's time to worry. They already added keywords to C, and retained
those keywords in C++.
---
[ 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              ]

kanze@my-dejanews.com wrote:
>
> In article <35BFDA99.2FEA@atlas.otago.ac.nz>,
>   ok@atlas.otago.ac.nz wrote:
> > System-depdent libraries?  Yes of course, but that's not LANGUAGE
> > extensions.  Hooks into assembler?  On rare occasions, yes, but
> > again, it *CAN* be done entirely without LANGUAGE extensions.
> > Access to DLLs?  Why yes of course, but no sane system has or needs
> > any LANGUAGE extensions for that!
>
> About the only point I can seriously agree with is the last.

I don't quite agree with the last statement. The purpose of the
extension is to make dynamic linking more automatic and efficient,
without the need for explicit indirect function calls, etc. The job can
be done without extensions, but can be done better with.

--

Ciao,
Paul
---
[ 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              ]

Jolyon Wright wrote:
>
> [Mod note: some excessive quoting snipped --mod (fjh).]
>
> kanze@my-dejanews.com wrote in message <6pnqin$96u$1@nnrp1.dejanews.com>...
> >MFC cannot conform to the standard, by definition, since it offers
> >services that are not defined by the standard.
>
> MFC is C--
> ---------------
>
> Hm - yes, but wouldnt it be wonderful if the microsoft extensions extended
> the language/ standards, instead of subverting them.  I am thinking of:-

In fairness to MS...

> 1) Microsoft's insistance on using CObject::IsKindOf() etc rather than
> "normal" RTTI

1)  MFC has been around longer than C++ RTTI.  When MFC was first
    developed, there WAS no dynamic_cast operator in C++.

2)  Nowadays, MS is pushing COM, which among other things, aims to be
language neutral--AND also desires to have "universal" RTTI (so COM
objects can be passed around).  To do the former, you need some RTTI
mechanism not dependant on language features--hence C++ RTTI is not
useable; it depends on how the compiler handles virtual dispatch.  To do
the latter, you need UUIDs, which C++ RTTI does not support either.

> 2) CObject as an "impure" abstract base, thus precluding the
> possibility of using MI effectively

How do you mean impure--that it has data and/or non-abstract methods?
If ya type "virtual" in front of "public" whenever you inherit from it,
that'll solve your problem.

> 3) Profoundly eccentric collection classes (CArray etc) - STL is
> brilliant; why not use it?

MFC has been around a lot longer than has STL.

> It seems to me that MFC is an extension of the Operating Sytem: not
> the language.  These services (above) ARE defined by the standard!

MFC is, in many ways, an extension to the OS.  The services you describe
are defined by the standard now, but were not six years ago, when MFC
appeared.

Scott

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

Jolyon Wright wrote:
...
> Hm - yes, but wouldnt it be wonderful if the microsoft extensions extended
> the language/ standards, instead of subverting them.  I am thinking of:-
>
> 1) Microsoft's insistance on using CObject::IsKindOf() etc rather than
> "normal" RTTI
> 2) CObject as an "impure" abstract base, thus precluding the possibility of
> using MI effectively
> 3) Profoundly eccentric collection classes (CArray etc) - STL is brilliant;
> why not use it?

I hate to defend Microsoft, but I think that all of those features of
MFC predate the corresponding developements in the C++ standard.
Microsoft would have to provide support for them as a matter of backward
compatibility, even in the unlikely case that they favored people
switching over to the new methods.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 <6pncqi$mfe$1@nnrp1.dejanews.com>,
  kanze@my-dejanews.com wrote:
[snip]
> Who cares how they do it?  The point is simple: the C++ standard does
> not define a windowing API, so any C++ program which does windowing isn't
> conforming anyway.

I don't agree that that is necessarily so (it most likely is true in
practise). Theoretically, the windowing API is provided by a library that
your program links to. Say, for example, that the library is developed under
X-Windows, and the library's API is strictly conforming - no extensions such
as "declspec". If you then write *your* program's code as strictly
conforming, then theoretically you could port the library to a different
platform (such as Windows NT) and it should be ISO-conformant. Porting the
library would, of course, be a major task.

The above premise is, of course, heavily theoretical and breaks down very
quickly in "real life".  My point was, I don't think it's fair to say that it
is impossible for a windowing program to be conforming.

> More to the point, standard conforming programs DO compile and run with
> the Microsoft compiler, and with the correct options, programs requiring
> a diagnostic get one.  Which is exactly what is required for a compiler
> to be considered conforming.

Well, there are certain standard items that Microsoft gets wrong (scope of a
variable introduced in the for-init-statement, for example), but in general
I'd agree with both your statements.

> While I personally may prefer the way X
> does it, my personal preferences don't affect the conformity of the
> compiler.  (Actually, my personal preference is to get some intelligently
> written third party library, which offers a reasonable level of abstraction
> and is available for both X and MS-Windows, and let the third party library
> vendor worry about all of these compatibility issues.)
Sounds good to me.  Actually, I had heard about such a library once - don't
remember where.  As I recall, it supported MS-Windows, MacIntosh and X-Windows
and possibly a few other platforms, and it cost $1,000 per platform per
developer.

Jim

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <6pillb$au4$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:
[snip]
> Remember that this talks about VC++5.0, not 6.0 (which is due out in
> September).  "The latest ANSI features" may suggest that it probably
> conforms to the latest C++ standard, but it certainly doesn't promise
> anything tangible.

The online documentation for VC 5.0 states that it is based on the ARM and
"the current working paper for the draft proposed language".  However, it
does not state which version of the working paper it used.  I suspect it was
not the Dec. 96 version.

[snip]

> A more interesting problem is how the vendor could demonstrate
> compliance.  Is anyone working on an independant test suite?
I asked this once, about a year ago, and no one had an answer.  It would be a
major task, but possibly worthwhile.

Jim

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

kanze@my-dejanews.com writes:

> In article <199807281217.IAA27606@mailfw1.ford.com>,
>   Mike Tiller <mtiller@ford.com> wrote:
> > kanze@my-dejanews.com writes:
> >
> > > (Of course, if you use X-Windows, you also use a lot of non-standard
> > > features.  But only to interface the windowing system itself, which
> > > is not covered by the C++ standard.)
> >
> > What non-standard features are you referring to?  X has nothing to do
> > with the compiler, it is a (heavily documented) communications
> > protocol and a library of C language bindings to the protocol.  It
> > does not require a special compiler to build windowing applications in
> > X, moreover it certainly doesn't require a C++ compiler.
>
> So.  What is the point?  Whether you use X Windows, or MS-Windows, you
> are not writing strictly compatible code, but using an "extension"
> provided by your compiler vendor and/or some third party.  My X-Windows
> code won't compile and run on my NT machine, and my MS-Windows code
> won't compile and run on my AIX or Solaris based machines.  A program
> using either is NOT a conforming program.

You X Windows code will compile on an NT machine.  You simply need a
copy of the the X libraries for that operating system and I'm pretty
confident such libraries exist.

Your definition of conforming is obviously very different from mine.
My idea of conforming is that the source code (after preprocessing)
obeys the grammatical rules of the language's standard.

Your definition of conforming is, apparently, that you are
non-conforming if you use any library that is not distributed as part
of your C++ compiler.

Taking that definition to extreme you could say that any program that
uses a third party library is non-conformant?!  I don't think tha is a
reasonable definition (just my opinion).

> > Microsoft may hack all sorts of proprietary features into their
> > compilers to support their GUI API, but that is definitely not the way
> > X does it.
>
> Who cares how they do it?  The point is simple: the C++ standard does
> not define a windowing API, so any C++ program which does windowing isn't
> conforming anyway.

Again, this depends on your definition of conformance.  By my
definition it is easily possible to write windowing code that is
conformant.

> More to the point, standard conforming programs DO compile and run with
> the Microsoft compiler, and with the correct options, programs requiring
> a diagnostic get one.  Which is exactly what is required for a compiler
> to be considered conforming.  While I personally may prefer the way X
> does it, my personal preferences don't affect the conformity of the
> compiler.

By "X" you mean the "X Window System"?  If so, what do you mean by
"the way X does it"?  X Windows is not a compiler or an operating
system it is *simply* (from a programming standpoint) a library of C
functions.  While the X Window System requires a certain amount of
operating system level support to compile, if you have that you can
build both X clients and X servers with any ANSI-C compiler.  There is
no special compiler used to build X applications.  The X Window System
is implemented strictly as a library and requires nothing from the
compiler except that it compile ANSI-C code.

> --
> James Kanze

--
Michael Tiller
Ford Motor Company


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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,

kanze@my-dejanews.com wrote:

> (On the other hand, I'll have to admit that the Microsoft implementation
> of DLL's is almost unusable.

I absolutely disagree. We use DLLs to split quite large C++ projects
without major problems.

> First, as you say, you need to add things
> to the source code.

Yes, you have to declare which classes to export in the header file.
However, if you use a macro for this (like we do), this is not a
problem.

> Worse, however, memory must be freed in the same DLL
> in which it was allocated.

Definitely not true. As long as you use the DLL version of the runtime
library, you can allocate and free memory wherever you like. As a
programmer, you do not have to know in which DLL a certain class is
implemented in or where some area of memory has been allocated.

--
Christof Stadler

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 comp.std.c++ kanze@my-dejanews.com wrote:
:   sj_nospam@nospam.aracnet.com wrote:
:> kanze@my-dejanews.com wrote:
:> >
:> > I suspect the real complaint is that it is rare to work on a Microsoft
:> > machine without doing windows, and once you do that, you typically end
:> > up having to use a lot of extra features that have nothing to do with
:> > windowing.  (Of course, if you use X-Windows, you also use a lot of
:> > non-standard features.  But only to interface the windowing system
:> > itself, which is not covered by the C++ standard.)
:>
:> I suspect folks aren't complaining about libraries which are outside the
:> scope of the standard libraries.  There are LOTS of things which are not
:> covered at all by either standard, but many useful programs have to
:> do--windowing, networking, multithreading, multimedia, graphics, etc.
:>
:> What folks are complaining about is the pervasiveness of Microsoft
:> extensions to the language itself.  It seems in order to write ANY
:> useful code on Windoze, you need to embrace one or more of the
:> following:

As I read all this I can't help thinking I'm reading this in a Java
newsgroup. Why all the Microsoft bashing? The standard is a few days
old and now Microsoft C++ 5.0 released way before the standard isn't compliant,
that's a shock!  Here's another shocker, ANSI C++ is going to mean no
more to platform independent code than ANSI C does.

Want 100% platform independence?  Use Java.

Microsoft likes C++, they don't like Java.  When Microsoft starts adding
new keywords to its C++, then its time to worry, until then I don't
see the problem.

:> *  thread-local storage (two ways of doing this--"dynamic" and "static";
:> dynamic thread local storage is implemented using libraries; like
:> POSIX thread keys, static thread local storage is implemented using a
:> declspec, and I assume, thread-specific data segments.

: Again, threads are an extension.  If you are using Posix threads, you'll
: also have to use some non-standard library functions.  As with the windowing
: stuff, your best bet is a third party library available on both platforms
: (RogueWave has one).

This is where ANSI C++ is going to help the most, 3rd party libraries!  Lack
of Standard C++ has been killing the language for years.

:> Try compiling MFC with an ANSI-compliant compiler, and see how far
:> you get.

: Try compiling the sources to most of your UNIX libraries with a strictly
: compliant compiler (no non-standard libraries like unistd.h:-) and see
: how far you get.  MFC is part of the Microsoft run-time; as such, they
: have the right to use any special features they want.

Exactly, but people like to bash Microsoft (I'm a Solaris person..).

:> Some of the above features might be useful additions to the language;
:> I'd love an "export" keyword to hint to the implementation that
:> a symbol might be referenced dynamically, for instance.  But none of
:> them are currently standard.  (At least MS behaves themselved these days
:> with regard to their non standard extensions, and prefixes them all with
:> double-underscores.  Used to be they didn't do that...)

: I know.  I once used a variable called far:-).  They're improving.  They
: still have a long way to go, but nobody is really perfect here.

  Which is why I'm confused how this thread went from announcing Standard
  C++ to bashing Microsoft over MSVC++ 5.0!?


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

kanze@my-dejanews.com writes:

> and of course, g++ doesn't even document the standard library, but
> presents g++ specials like String or ObStack as if they were standard.

This era is over.  Since version 2.8.0, they do not support their
library
libg++ anymore, but provide a new one called libstdc++ which is close to
the
standard.  Their goal is to get rid of any non-standard feature, and to
develop
as fast as they can a compiler fully compliant with the standard.  You
can
nevertheless download the old libg++ for backward compatibility if you
need it.
But they advise us to avoid it if it is possible.

Best regards,


pit

--

Michel Pitermann, Department of Psychology, Queen's University,
Kingston, Ontario, Canada K7L 3N6
email : mpiter@portia.psyc.queensu.ca
Tel: +1 - 613 - 545 6000 ext 5754      Fax: +1 - 613 - 545 2499

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <35BFDA99.2FEA@atlas.otago.ac.nz>,
  ok@atlas.otago.ac.nz wrote:
> Tim Ottinger wrote:
> > No, such a movement would not be good for me. I don't write
> > Windoze stuff, and I avoid proprietary stuff in Unixes (Uni?),
> > but sometimes you have to write the stuff that maps your cool
> > classes onto the platform, and you need some proprietary stuff
> > for that. Any features that the standard doesn't address
> > (finding the free space on a drive/partition, for example)
> > _should_ be added in with the ANSI/ISO standard compilers.
>
> I've been watching this thread with some interest, and just can't
> remain silent any longer.  *VENDOR-PROVIDED LIBRARIES* are a very
> different thing from *proprietaty **LANGUAGE EXTENSIONS***.

Really?

> Note that UNIX programmers don't have to use *any* vendor-specific
> language features in C or Fortran or Ada95 to access a huge range
> of operating system features:  in addition to their language
> standards, there are standard POSIX bindings which do not require
> *any* LANGUAGE extensions whatsoever to use.

You've chosen a bad example; the Posix standard contradicts the C
standard,
so you cannot have a compiler that is simultaneously a conforming C
compiler
and a Posix compliant.

Many people, myself included, would have prefered that Posix be a simple
extension, rather than a modification, but this is not the case.

> (What they require
> to _implement_ is none of our business.)  If I want to use X, I
> can program with my C standard at my left hand and a stack of
> X references all of which are absolutely compiler-independent at
> my right hand.  I don't have to use _any_ special keywords, I
> don't have to use _any_ special pragmas, I don't have to go
> outside the standard *language* one iota.

The moment you include a header file that isn't part of your
application,
or the moment you declare a function that isn't implemented within your
code, you have left the C standard.  In practice, I see little
difference in being required to write:
    #include <X.h>
and being required to write:
    #pragma X
In both cases, my program has ceased to be conforming, and in both
cases,
it has ceased to be portable.

If you wish to argue that X is widespread, and supported by many
different
compilers on many different platforms, whereas MFC isn't, then I would
agree, and I would also agree that this is an important argument in
favor of X.  But this has nothing to do with the standard.

(Actually, I happen to know people who use MFC on HP-UX and Sun Sparc
machines.  So it is more portable that some people here seem to be
claiming.)

    [...]
> There are so many benefits of NOT having LANGUAGE extensions that
> it's hard to know where to start.

There are definite benefits to writing portable code whenever you can,
and
to isolating the non-portable parts in separate modules when you can't.
There is, however, no portable way to implement a DLL today, and there
is
no portable way to do anything with a window today.

> The fact that one can run code
> intended for machine X through a static checker on machine Y (where
> for example X is a microcontroller and Y is a big workstation) is
> such a win that I can't imagine anyone _not_ wanting to be able to
> do it.  The fact that _one_ editor package will handle _all_ the
> C compilers I normally use is again something I would be reluctant
> to give up.

So don't.  I use emacs and the C++ mode for writing code for VC++; it
works great.

[Warning--topic drift.  --hlh]

On 30 Jul 1998 11:05:06 -0400, kanze@my-dejanews.com wrote:

>(On the other hand, I'll have to admit that the Microsoft implementation
>of DLL's is almost unusable.  First, as you say, you need to add things
>to the source code.

Not necessarily. You can use a .DEF file. __declspec(dllexport),
however, is a lot more convenient. Also, __declspec(dllimport) allows
more efficient code generation than relying solely on .DEF files.
Usually one defines a macro, say, LIBNAME_EXPORT, that expands into
one or the other __declspecs, depending on whether you're compiling
the DLL or just using it. Then you use the macro in header files to
modify class, function, and data declarations as necessary. This is
indeed intrusive, but it does give you a lot of control and can save
space in image files.

>Worse, however, memory must be freed in the same DLL
>in which it was allocated.  And you thought that memory management under
>normal C++ was a problem:-).)

If you're composing a C++ program out of dynamically linked
components, and each component links to the same C (and C++) run-time
DLL, the entire program uses a single heap. Under those conditions,
any component can free memory allocated by any other component,
subject to the usual rules concerning matching allocation and
deallocation functions. Even if you explicitly load a DLL, as long as
the DLL is dynamically linked to the CRT you're using, I'm pretty sure
that your app will continue to share a single heap.

Also, Win32 DLLs properly handle namespace scope data initialization
in DLLs. Consider an app composed as follows, where all the DLLs are
implicitly linked together:

 1. CRT DLL
 2. DLL A (linked to 1)
 3. DLL B (linked to 1 and 2)
 4. EXE C (linked to 1, 2, and 3)

The order of static data initialization is 1, 2, 3, 4, and the
initializations are guaranteed to be performed at program start-up,
before execution of main. I believe I've heard DLL implementations
under other operating systems don't necessarily guarantee these
things.

So, I have to disagree. I think the MSFT DLL implementation is
eminently usable.

--
Doug Harrison
dHarrison@worldnet.att.net

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

"Robert O'Dowd" <nospam@nonexistant.com> wrote:
>> ...
>> Correct me if I'm wrong ....   but the standard does not disallow
>> extensions like LPTR being supported by a compiler.  The standard
>> simply specifies a minimum level of features (capability and
>> behaviour)
>> that.  The standard simply specifies what features a programmer
>> should stick to if software is to work with any compliant compiler.
>> If other features are used (e.g. LPTR) then, by definition, the
>> code has undefined behaviour.  I suppose a compiler could give
>> warnings if extended features are used.

kanze@my-dejanews.com wrote:
> Well, the following program should compile and run on a compliant
> compiler:
>
>     #include <iostream>
>
>     int main()
>     {
>         int     LPTR = 1 ;
>         std::cout << LPTR << '\n' ;
>         return 0 ;
>     }
>
> And it does, at least with VC++ 5.0.  If you include the header file
> which defines LPTR, however, you have invoked undefined behavior from
> the point of view of the standard, and Microsoft defined behavior in
> this particular case.

FWIW, I tried compiling the following conforming program on VC++
5.0:

    // far.cpp

    #include <iostream>

    int main()
    {
        int     far = 1;

        std::cout << far << '\n';
        return (0);
    }

Compiling under VC++ 5.0 I get:
    far.cpp(7) : error C4226: nonstandard extension used : 'far' is
        an obsolete keyword
    far.cpp(7) : error C2513: 'int' : decl-specifier is missing a
        declarator before '='
    far.cpp(9) : error C4226: nonstandard extension used : 'far' is
        an obsolete keyword
    far.cpp(9) : error C2059: syntax error : '<<'

So they're better (i.e., closer to the standard) than they were
before, but they still have a few conformance problems.

-- David R. Tribble, dtribble@technologist.com --

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <35BFDA99.2FEA@atlas.otago.ac.nz>,
  ok@atlas.otago.ac.nz wrote:

> Access to DLLs?  Why yes of course, but no sane system has or needs
> any LANGUAGE extensions for that!

Many of us would call Microsoft Windows useful.  But only a very few
of us would describe it as "sane."

FWIW, most of the language extensions are put there automatically
by the code generator (which obviously is not covered by the C++
standard.)  If I want to, I can generate executables from
system-independant code without resorting to any language extensions
at all.  This is not the Microsoft way, but it can be done with
Microsoft tools.

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 30 Jul 1998 11:05:07 -0400, kanze@my-dejanews.com wrote:

>In article <35BE9CE0.ECEAD19D@nonexistant.com>,
>  "Robert O'Dowd" <nospam@nonexistant.com> wrote:
>> kanze@my-dejanews.com wrote:
>> >
>> That subset will typically be features that a fair
>> majority of programmers will use frequently.  I'm even more likely
>> to be confident if the vendor is also willing to include
>> documentation that;
>>
>>    -  acknowledges which features are implemented on a provisional
>>         basis so should be used with care.
>>    -  a list of known bugs or things in the standard that
>>         are not supported. Possibly with work-arounds.  And a way
>>         of getting an updated version of that list (e.g. via a web
>>         page, regular mailing, etc).
>>    -  provides some mechanism for receipt, processing, acknowledgement,
>>         etc of bug reports (even if that mechanism sometimes says
>>         "we do not plan to support that feature because ....  Sorry!")
>>    -  clearly points out which features it provides that are non
>>         standard.  GUI libraries, extensions, etc etc.
>
>Most compiler vendors will require that you buy a maintenance contract
>to get all of this.  From what I've been told, if you have a maintenance
>contract, Microsoft will meet all of the above criteria except the last.
>Regretfully, most compilers fail on the last: HP is probably the best,
>with a specific section in their man pages for standards compliance, which
>state which standards, if any, the function conforms to.  AIX usually does
>this as well, but not always.  It is one thing I miss on Sun CC, however,
>and of course, g++ doesn't even document the standard library, but
>presents g++ specials like String or ObStack as if they were standard.
>(In this case, I think it is mainly a case of the documentation not keeping
>up with the rest.  The C++ people at Cygnus seem very concerned about
>standards conformance, but this attitude isn't shared by all of the
>people involved.)

Actually, Microsoft does moderately well on the list even without a
maintenance contract.  Most of it is available on their web site.

Microsoft's documentation is generally very good at identifying
functions that are nonstandard, but they often fall down in
identifying functions that behave in extended ways (for example, the
entry for fflush() doesn't mention that it's action on input streams
is nonportable).  It is, however, rather poor at identifying
nonstandard and missing language features.
--
Michael M Rubenstein

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <6pnqe8$8uo$1@nnrp1.dejanews.com>, kanze@my-dejanews.com
says...

[ ... ]

> Well, the following program should compile and run on a compliant
> compiler:
>
>     #include <iostream>
>
>     int
>     main()
>     {
>         int         LPTR = 1 ;
>         std::cout << LPTR << '\n' ;
>         return 0 ;
>     }
>
> And it does, at least with VC++ 5.0.  If you include the header file
> which defines LPTR, however, you have invoked undefined behavior from
> the point of view of the standard, and Microsoft defined behavior in
> this particular case.

Hmm...and what header does MS have that defines anything named LPTR?
Perhaps the intention was to refer to "LPSTR" instead?

> My only real complaint with LPTR is that it is horribly ugly.

I have to agree about most typedef's like LPSTR.  They pervade almost
everything MS writes, but they're _fairly_ easy to ignore most of the
time -- being typedef's, you can use "char *" instead and the two are
perfectly compatible.

> Of course not.  I think the complaint isn't so much that they add
> extra features, but that unless you know what you are doing, you
> end up using these features unintentionally.  Part of this may be
> intentional on the part of Microsoft, but a large part is certainly
> due to the naivety of Microsoft users.

I suspect the vast majority of people who use MS' compilers are better
informed and intelligent than most people would like to believe.  The
problem (if there is one) is that from their viewpoint, writing
portable code simply doesn't matter.  When/if they really care about
porting their totally non-portable, MFC code using hundreds of MS-
specific features, etc., they're far more likely to pay some money to
Bristol or MainSoft so their code will run unchanged on UNIX than they
are to rewrite the code.

[ ... ]

> > That subset will typically be features that a fair
> > majority of programmers will use frequently.  I'm even more likely
> > to be confident if the vendor is also willing to include
> > documentation that;
> >
> >    -  acknowledges which features are implemented on a provisional
> >         basis so should be used with care.
> >    -  a list of known bugs or things in the standard that
> >         are not supported. Possibly with work-arounds.  And a way
> >         of getting an updated version of that list (e.g. via a web
> >         page, regular mailing, etc).
> >    -  provides some mechanism for receipt, processing, acknowledgement,
> >         etc of bug reports (even if that mechanism sometimes says
> >         "we do not plan to support that feature because ....  Sorry!")
> >    -  clearly points out which features it provides that are non
> >         standard.  GUI libraries, extensions, etc etc.
>
> Most compiler vendors will require that you buy a maintenance contract
> to get all of this.  From what I've been told, if you have a maintenance
> contract, Microsoft will meet all of the above criteria except the last.

I don't think you need any sort of maintenance contract with MS to get
nearly if not absolutely all of these.  MS provides the first two on
their web site -- you have to sign up for "MSDN on-line", but that's
free.  At that point, you have full access to their "KnowledgeBase"
which is a regularly updated list of bugs, problems, documentation
errors, etc.  If you send bugs reports, you get an automatic
acknowledgement.  I haven't sent in a lot of bug reports, but I've yet
to send one in that didn't get acknowledged in the form of an article
in the KnowledgeBase within a short time.

As far as documenting which functions are standard and which aren't,
it seems to me that MS' documentation is _quite_ adequate and clear in
this respect.  Each function in the standard library documents whether
it's in the standard or not:

Function Required Header   Compatibility

exit   <process.h> or <stdlib.h>  ANSI, Win 95, Win NT
_exit  <process.h> or <stdlib.h>  Win 95, Win NT

It seems to me that this makes it pretty clear that exit is in the
standard, but _exit is not.  I guess they don't include the same in
the MFC functions and such, but there doesn't seem to be much point
there: NONE of them is in the standard, so there's not a lot of
question about which are and which aren't.  The introduction to the
MFC reference says: "Visual C++ Programmer's Guide explains how to use
the class library to program for Microsoft Windows NT   , Microsoft
Windows    95, and other Win32    platforms."

That seems a _fairly_ clear statement that if you use this, you're
restricting your programs to Win32 platforms, though I'll admit it's
not absolutely explicit that, for example, if you use MFC, your
program won't run on UNIX.  Then again, given that you can get ports
of MFC to UNIX from either Bristol or MainSoft, such a statement would
be false anyway...

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 29 Jul 98 11:25:06 GMT, Mike Tiller <mtiller@ford.com> wrote:

>kanze@my-dejanews.com writes:
>> (Of course, if you use X-Windows, you also use a lot of non-standard
>> features.  But only to interface the windowing system itself, which
>> is not covered by the C++ standard.)

>What non-standard features are you referring to?  X has nothing to do
>with the compiler, it is a (heavily documented) communications
>protocol and a library of C language bindings to the protocol.  It
>does not require a special compiler to build windowing applications in
>X, moreover it certainly doesn't require a C++ compiler.
>Microsoft may hack all sorts of proprietary features into their
>compilers to support their GUI API, but that is definitely not the way
>X does it.

No. This isn't the case. Windows is quite programmable using C (or
assembler if you wish). If you're referring to MFC, then, to be
honest, in my wildest dreams i would not expect an MFC app to be
portable to anything but a machine running MS Windows (although i
understand that Macs are supported, but who cares). Stuff like
catching button clicks is clearly outside the standard (it's funky
IO!) but it still needs to be done in a portable manner. Windows lets
me run on a variety of machines, most of which do not run Unix. I'm
not disappointed with this..

phil.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

Dr Richard A. O'Keefe wrote:
>
> Tim Ottinger wrote:
> > No, such a movement would not be good for me. I don't write
> > Windoze stuff, and I avoid proprietary stuff in Unixes (Uni?),
> > but sometimes you have to write the stuff that maps your cool
> > classes onto the platform, and you need some proprietary stuff
> > for that. Any features that the standard doesn't address
> > (finding the free space on a drive/partition, for example)
> > _should_ be added in with the ANSI/ISO standard compilers.
>
> I've been watching this thread with some interest, and just can't
> remain silent any longer.  *VENDOR-PROVIDED LIBRARIES* are a very
> different thing from *proprietaty **LANGUAGE EXTENSIONS***.

Hey, not so loud, you could wake up Bill ;-)

[...]

> Come to that, on the UNIX system I normally use, I don't have to
> use any language extensions to plug in assembly code either.  I
> can write any assembly code I want, put it in a separate file,
> write a C header to describe it, and either have the compiler
> call this code using normal calling conventions or have the
> compiler inline the code and let the optimiser eliminate the
> argument passing/return bits.  There's an existence proof that
> you don't need any special _language_ extensions to support
> assembly inserts.  Typically when one does this one writes two
> versions of the function:  one in portable C, and one that takes
> advantage of machine features, so the program as a whole just
> needs recompiling on a different system.

While it is certainly possible to write assembler into different
files and compile them into separate assembler files (however I'm
wondering how you can let your compiler _inline_ that code without
using extensions). However, inline assembly gives you some
advantages which separate assembly modules cannot give you:
- Compiler generated access code to certain variables (including
  local ones), even if there's no symbol associated with them
  (as is the case exactly for local functions)
- The compiler can adjust its own register usage depending on
  the registers you use in assembly
- With the proper extensions (see e.g. gcc), the compiler can even
  adjust the registers used by *your* assembly, so that they fit
  best with the code it generates itself (optimized register usage).

So, yes, inline assembly by the compiler *does* have an advantage
over separate assembly modules.

>
> There are so many benefits of NOT having LANGUAGE extensions that
> it's hard to know where to start.  The fact that one can run code
> intended for machine X through a static checker on machine Y (where
> for example X is a microcontroller and Y is a big workstation) is
> such a win that I can't imagine anyone _not_ wanting to be able to
> do it.  The fact that _one_ editor package will handle _all_ the
> C compilers I normally use is again something I would be reluctant
> to give up.

This obviously doesn't hold for assembler code. Note that you still
can provide a pure-C solution besides the assembler solution, even if
you program the assembler part using inline assembly.
The same holds true for any language extension: If the extension
allows you to write code that's in some way better (faster, shorter
when compiler, better optimizable by the compiler) *and* you can
in addition write that in portable code as well, then it might be a
good idea to use the extension on the special compiler.

>
> System-depdent libraries?  Yes of course, but that's not LANGUAGE
> extensions.  Hooks into assembler?  On rare occasions, yes, but
> again, it *CAN* be done entirely without LANGUAGE extensions.
> Access to DLLs?  Why yes of course, but no sane system has or needs
> any LANGUAGE extensions for that!

Well, AFAIK you don't *need* a language extension in Windows either;
just write a .DEF file, and you're done with it (extra files are
no problem; makefiles are separate files too, and without the
appropriate compiler/linker options, you'll never be able to build
an Unix shared library correctly, too...).

BTW, C++ started out as "C with Classes" - wouldn't that qualify
as compiler extension as well? So one could say, without compiler
extensions, there would never have been C++ ;-)

(BTW, strictly speaking, allowing #include <unistd.h> in C is a
language extension as well - unlike #include "unistd.h", which is
well defined...)

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

kanze@my-dejanews.com wrote in message
<6pnp4o$7fk$1@nnrp1.dejanews.com>...
>
>(On the other hand, I'll have to admit that the Microsoft implementation
>of DLL's is almost unusable.  First, as you say, you need to add things
>to the source code.  Worse, however, memory must be freed in the same DLL
>in which it was allocated.

In Win32, a DLL is mapped into the client process's address space, it
has the same address space as the client, so what difference would it
make in what DLL memory was freed?  In Win16, DLLs received their own
local heaps, but that's not the case for Win32.

--
Regards,
Daniel Parker danielp@no_spam.anabasis.com.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <6ppsn5$q8j$1@nnrp1.dejanews.com>, jim.hyslop@leitch.com
says...

[ ... ]

> Well, there are certain standard items that Microsoft gets wrong (scope of a
> variable introduced in the for-init-statement, for example), but in general
> I'd agree with both your statements.

MS does not get this wrong -- they support older code as an extension,
but if you ask for conformance, you get it, at least in this respect.

> Sounds good to me.  Actually, I had heard about such a library once - don't
> remember where.  As I recall, it supported MS-Windows, MacIntosh and X-Windows
> and possibly a few other platforms, and it cost $1,000 per platform per
> developer.

There are several such things: XVT, Zinc, zApp and WxWindows being a
few that happen to occur to me right off.  Well, technically,
WxWindows doesn't fit your description since it's free, but it's
still portable... In any case, they have little to do with the
standard as such.

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

[Mod note: some excessive quoting snipped --mod (fjh).]

kanze@my-dejanews.com wrote in message <6pnqin$96u$1@nnrp1.dejanews.com>...
>MFC cannot conform to the standard, by definition, since it offers
>services that are not defined by the standard.

MFC is C--
---------------

Hm - yes, but wouldnt it be wonderful if the microsoft extensions extended
the language/ standards, instead of subverting them.  I am thinking of:-

1) Microsoft's insistance on using CObject::IsKindOf() etc rather than
"normal" RTTI
2) CObject as an "impure" abstract base, thus precluding the possibility of
using MI effectively
3) Profoundly eccentric collection classes (CArray etc) - STL is brilliant;
why not use it?

It seems to me that MFC is an extension of the Operating Sytem: not the
language.  These services (above) ARE defined by the standard!

Maybe, if we all whinge enough they will get with the programme - but what
else are you going to use??


jolyon

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

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:

>FWIW, I tried compiling the following conforming program on VC++ 5.0:
>
>    // far.cpp
>
>    #include <iostream>
>
>    int main()
>    {
>        int     far = 1;
>
>        std::cout << far << '\n';
>        return (0);
>    }
>
>Compiling under VC++ 5.0 I get:
>    far.cpp(7) : error C4226: nonstandard extension used : 'far' is
>        an obsolete keyword
>    far.cpp(7) : error C2513: 'int' : decl-specifier is missing a
>        declarator before '='
...
>
>So they're better (i.e., closer to the standard) than they were
>before, but they still have a few conformance problems.

What options did you compile with?

Most compilers are not conforming unless invoked with options to
enable strict conformance.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ 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              ]

[posted and emailed]

jim.hyslop@leitch.com (jim.hyslop@leitch.com) wrote:
>Well, there are certain standard items that Microsoft gets wrong (scope of a
>variable introduced in the for-init-statement, for example)

I'm not so sure Microsoft did get this wrong, at least not if you use the
-Za switch, which disables non-ANSI extensions.

True, the MSVC++ 5.0 documentation says:
==========================(begin extract)========================
#include <iostream.h>

void main()
{
    for( int i = 0; i < 100; ++i )
        cout << i << "\n";

    // The loop index, i, cannot be declared in the
    //  for-init-statement here because it is still in scope.
    for( i = 100; i >= 0; --i )
        cout << i << "\n";
}
========================(end extract)=============================

However, the actual compiler seems to get it right. The following program
compiled (with only a warning about unused argc and argv):

int main(int argc, char** argv) {
    int retval = 0;
    for (int i=1; i<100; ++ i)
        retval += i;
    for (int i=1; i<100; ++ i)
        retval -= i;
    return retval;
}

and the following program does *not* compile, getting the error message
"yy.cpp(5) : error C2065: 'i' : undeclared identifier"

int main(int argc, char** argv) {
    int retval = 0;
    for (int i=1; i<100; ++ i)
        retval += i;
    for (i=1; i<100; ++ i)
        retval -= i;
    return retval;
}

Since Stroustrup says, on page 137, "the variable ... it introduces is in
scope until the end of the for statement.", it seems that the MSVC
promises to do the wrong thing but actually does the right thing.

Without the -Za switch, the results are opposite: the first program gets
an "'i' redefinition" error and the second is accepted.

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                      http://www.concentric.net/%7eBrownsta/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
---
[ 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 <6pqeaa$hsm$1@nnrp1.dejanews.com>,
 kanze@my-dejanews.com writes:
> You've chosen a bad example; the Posix standard contradicts the C
>standard, so you cannot have a compiler that is simultaneously a
>conforming C compiler and a Posix compliant.

Pardon my ignorance, but how do they vary?  I.e. what does POSIX
violate in C standard and as C++ programmers wishing to write
programs as portably as possible which areas should concern us?

Thanks

Peter


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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:
>
> kanze@my-dejanews.com wrote in message
> <6pnp4o$7fk$1@nnrp1.dejanews.com>...
> >
> >(On the other hand, I'll have to admit that the Microsoft implementation
> >of DLL's is almost unusable.  First, as you say, you need to add things
> >to the source code.  Worse, however, memory must be freed in the same DLL
> >in which it was allocated.
>
> In Win32, a DLL is mapped into the client process's address space, it
> has the same address space as the client, so what difference would it
> make in what DLL memory was freed?  In Win16, DLLs received their own
> local heaps, but that's not the case for Win32.

Not so when you are mixing different versions of the C++ runtime.  The
C++ runtime static library cannot mix its heap storage with the C++ DLL
runtime, and there are also differences between the debugging and
non-debugging versions.  So the previous poster is write that you must
be careful that you free memory in the same DLL it was allocated in, if
those DLLs each have their own copy of the C++ runtime.

Pretty stupid thing to do, if you ask me, but I'll bet there is actually
a good historical reason why VC++ does this.

{Please move further discussion of DLL dependent stuff to a more
appropriate forum. -mod}
--
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <35C10567.6E74@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:

> FWIW, I tried compiling the following conforming program on VC++
> 5.0:
>
>     // far.cpp
>
>     #include <iostream>
>
>     int main()
>     {
>         int     far = 1;
>
>         std::cout << far << '\n';
>         return (0);
>     }
>
> Compiling under VC++ 5.0 I get:
>     far.cpp(7) : error C4226: nonstandard extension used : 'far' is
>         an obsolete keyword
>     far.cpp(7) : error C2513: 'int' : decl-specifier is missing a
>         declarator before '='
>     far.cpp(9) : error C4226: nonstandard extension used : 'far' is
>         an obsolete keyword
>     far.cpp(9) : error C2059: syntax error : '<<'
>
> So they're better (i.e., closer to the standard) than they were
> before, but they still have a few conformance problems.

I was disappointed to see that you are quite right. And it gets worse.

Looking at the VC++ documentation for C4226:
  * It is only supposed to apply to the keyword __export, not
    to the keyword far
  * It is supposed to be a Warning (level 1), not an error

The problem is "obviously" a case of wrong compiler switches. (A
conforming compiler is allowed to be conforming only when compile
switches are set in a certain manner.) In this case, there is a
setting; on the command line it's "/Za" and in the IDE it's called
"Disable Language Extensions." The help text says:
    Set this option if you want the compiler to use ANSI C rules.
    Clear this option if you want to use Microsoft C language
    extensions.
The phrase "ANSI C rules" is somewhat troubling, since this
compiler can handle both C and C++, but we'll hope that this also
applies to ANSI C++ rules vs. Microsoft C++ language extensions.
So we set the option and try again.

*POW!* We get 101 errors before the compiler quits trying. The first few
are [formatted to make slightly less incomprehensible]:

    C:\Ms\VC\INCLUDE\iosfwd(132) : error C2906: C++ language change:
        to explicitly specialize class template 'char_traits' use the
        following syntax -
            template<> struct char_traits<unsigned short> ...
    C:\Ms\VC\INCLUDE\iosfwd(171) : error C2906: C++ language change:
        to explicitly specialize class template 'char_traits' use the
        following syntax -
            template<> struct char_traits<char> ...
    C:\Ms\VC\INCLUDE\utility(74) : error C2838:
        illegal qualified name in member declaration
    C:\Ms\VC\INCLUDE\utility(74) : error C2146: syntax error :
        missing ';' before identifier 'iterator_category'

Note the one thing in common for all 101 error messages: these are
errors in the standard library files! The bottom line is that you
can't compile any C++ programs with "Disable Language Extensions" set.

...But a conforming compiler is allowed to be conforming only when
compile switches are set in a certain manner, right? So I did manage
to come up with a compile switch that let me compile far.cpp without
any errors.  The command-line version is
    /Dfar=___far
and the IDE version is
    far=___far
in the "Preprocessor Definitions" section.

Cheating? It depends on what you mean by cheating. Agreed that this
type of balogna *shouldn't* be needed. Like trail mix in the desert,
it may keep you going, but it isn't very satisfying. But given that
it *is* needed, it also does work correctly, no?

Further, the solution I've just given is also practical, to the extent
that it always works on VC++ (unless the program also defined a symbol
___far, which it isn't supposed to). That is, if I inherited a body of
code which I was trying to port to VC++5, and that body of code tended
to use "far" as a variable name more than rarely, I would add this
setting to the project. If I saw other symbols with similar problems,
I would expand the setting string; it seems likely I would end up
with at least:
    /Dfar=___far /Dnear=___near /Dhuge=___huge
etc.

[For those who don't know, "near" and "huge" are also legacy keywords
with similar usage to the "far" keyword.  None of them have ever been
valid in the 32-bit Windows environment, which is the only one that
VC++5 targets, but all of them were valid for older versions of
Microsoft C or Microsoft C++ that allowed 16-bit Windows targets. In
later years, Microsoft changed the spelling of these keywords to _far,
_near, and _huge, and then later changed them to __far, __near, and
__huge. In each case various compiler switches allowed the old names
to be recognized, and in each case the stated purpose was ANSI
compliance. Thus, it's rather ironic that their current compiler won't
allow the name to be used in any form outside of the original context!]

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

kanze@my-dejanews.com writes:

> MFC cannot conform to the standard, by definition, since it offers
> services that are not defined by the standard.

As far as I know, a compiler vendor is free to implement functionality
above and beyond the standard so long as the compiler continues to
compile code that is conformant and so long as the extended language
doesn't conflict with the standard language.

Can anybody produce a quote from the standard that says otherwise?

> --
> James Kanze

--
Michael Tiller
Ford Motor Company
---
[ 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 <35BEA0AA.4DA5@nospam.aracnet.com>,
  sj_nospam@nospam.aracnet.com wrote:
> kanze@my-dejanews.com wrote:
> >
> > I suspect the real complaint is that it is rare to work on a Microsoft
> > machine without doing windows, and once you do that, you typically end
> > up having to use a lot of extra features that have nothing to do with
> > windowing.  (Of course, if you use X-Windows, you also use a lot of
> > non-standard features.  But only to interface the windowing system
> > itself, which is not covered by the C++ standard.)
>
> I suspect folks aren't complaining about libraries which are outside the
> scope of the standard libraries.  There are LOTS of things which are not
> covered at all by either standard, but many useful programs have to
> do--windowing, networking, multithreading, multimedia, graphics, etc.
>
> What folks are complaining about is the pervasiveness of Microsoft
> extensions to the language itself.  It seems in order to write ANY
> useful code on Windoze, you need to embrace one or more of the
> following:

What your are saying is partially true.  There is very little software
written for Windows 95 which doesn't actually use windows, and using
windows immediately puts you into the Microsoft world.  Under UNIX, of
course, using X-Windows immediately locks you into UNIX, but there are
still an enormous number of UNIX programs which don't use X-Windows.

Now that Microsoft is targetting the NT as a server platform, this will
probably change some.  FWIW, we've recently developed part of a significantly
large application on Windows NT, and are porting to AIX.  There have been
practically no problems due to Microsoft extensions.  (Of course, we
planned it this way from the start, and insisted that people use a string
class available on both platforms, rather than CString, etc.)

> *  declaration specifiers (for declaring entry points to DLLs, among
> other things)

If you're writing DLL's yourself, then you are using an extension.  If
you're just using third party DLL's, on the other hand, they may have the
extra declaration specifiers, but you don't have to know about it.

(On the other hand, I'll have to admit that the Microsoft implementation
of DLL's is almost unusable.  First, as you say, you need to add things
to the source code.  Worse, however, memory must be freed in the same DLL
in which it was allocated.  And you thought that memory management under
normal C++ was a problem:-).)

> *  thread-local storage (two ways of doing this--"dynamic" and "static";
> dynamic thread local storage is implemented using libraries; like
> POSIX thread keys, static thread local storage is implemented using a
> declspec, and I assume, thread-specific data segments.

Again, threads are an extension.  If you are using Posix threads, you'll
also have to use some non-standard library functions.  As with the windowing
stuff, your best bet is a third party library available on both platforms
(RogueWave has one).

> *  structured exception handling.  Rather than software interrupts
> resulting in signals; you get an exception, similar to a C++ exception.
> There is some stack unwinding support (__finally blocks, which do the
> same thing as in Java).  While this is useful; it certainly is a
> pervasive extension to the language.  (I once heard that MS has a patent
> on structured exception handling; though given lotsa prior art, and the
> fact that Java supports asynchronous exceptions, I kinda find this one
> hard to believe.  Anyone care to comment?)

No experience here, so I can't comment.  We moved to the AIX before we
got far enough to worry about signal handling.

> Try compiling MFC with an ANSI-compliant compiler, and see how far
> you get.

Try compiling the sources to most of your UNIX libraries with a strictly
compliant compiler (no non-standard libraries like unistd.h:-) and see
how far you get.  MFC is part of the Microsoft run-time; as such, they
have the right to use any special features they want.

> Some of the above features might be useful additions to the language;
> I'd love an "export" keyword to hint to the implementation that
> a symbol might be referenced dynamically, for instance.  But none of
> them are currently standard.  (At least MS behaves themselved these days
> with regard to their non standard extensions, and prefixes them all with
> double-underscores.  Used to be they didn't do that...)

I know.  I once used a variable called far:-).  They're improving.  They
still have a long way to go, but nobody is really perfect here.  I still
prefer UNIX and the UNIX compilers.  I use emacs, GNU make and the bash
shell when developing for VC++, which probably says a lot.  But I refuse
to let my personal preferences blind me to the rest of the world.

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

In article <35BE9CE0.ECEAD19D@nonexistant.com>,
  "Robert O'Dowd" <nospam@nonexistant.com> wrote:
> kanze@my-dejanews.com wrote:
> >
> > In article <6pfkke$4i8$1@usenet40.supernews.com>,
> >   "Mark Wilden" <mwilden@sierratel.com> wrote:
> > > Thaddeus L. Olczyk wrote in message
> > > <35ba433b.1405020@nntp.interaccess.com>...
> > > >
> > > >Not only will they not make [VC++] any closer
> > >
> > > It seems to me quite unlikely that they won't add a single
> > > ANSI-conforming feature.
> > >
> > > >but they will add a lot of
> > > >new featurs which will make managers happy but force us to write
> > > >code which is written in an even poorer style of C++.
> > >
> > > Could you give an example in VC++ 5.0?
> >
> > Start with LPTR and go from there.  Of course, you don't have to use
> > them.
> >
>
> Correct me if I'm wrong ....   but the standard does not disallow
> extensions like LPTR being supported by a compiler.  The standard
> simply specifies a minimum level of features (capability and behaviour)
> that.  The standard simply specifies what features a programmer
> should stick to if software is to work with any compliant compiler.
> If other features are used (e.g. LPTR) then, by definition, the
> code has undefined behaviour.  I suppose a compiler could give
> warnings if extended features are used.

Well, the following program should compile and run on a compliant
compiler:

    #include <iostream>

    int
    main()
    {
        int         LPTR = 1 ;
        std::cout << LPTR << '\n' ;
        return 0 ;
    }

And it does, at least with VC++ 5.0.  If you include the header file
which defines LPTR, however, you have invoked undefined behavior from
the point of view of the standard, and Microsoft defined behavior in
this particular case.

My only real complaint with LPTR is that it is horribly ugly.

> If a hypothetical compiler fully supports the standard, and
> adds one extra feature that is not specified in the standard,
> I would have trouble claiming that compiler is not ANSI compliant.

Of course not.  I think the complaint isn't so much that they add
extra features, but that unless you know what you are doing, you
end up using these features unintentionally.  Part of this may be
intentional on the part of Microsoft, but a large part is certainly
due to the naivety of Microsoft users.

> > > >I don't
> > > >understand how they get away with writing  "ANSI C++ " on
> > > >their box and in their advertisements.
> > >
> > > I don't believe they do in fact claim complete ANSI compliance.
> >
> > It's hard to be compliant with something that doesn't exist.
> >
> > In practice, of course, to be 100% compiant means to have no bugs.
> > So most vendors lie a little, and we accept it, because the lie is
> > often more informative than the truth (that there are no compliant
> > compilers, even for C) is.
> >
>
> If a vendor claims a compiler is ANSI compliant, that is a fairly
> good indication that the compiler complies with a useful subset of
> the standard.

I would take such a statement as a stated goal of the compiler vendor.
In general, if a compiler vendor claims ISO compliance, and I find something
that doesn't work as it should according to the standard, I would expect
the vendor to recognize it as an error.

> That subset will typically be features that a fair
> majority of programmers will use frequently.  I'm even more likely
> to be confident if the vendor is also willing to include
> documentation that;
>
>    -  acknowledges which features are implemented on a provisional
>         basis so should be used with care.
>    -  a list of known bugs or things in the standard that
>         are not supported. Possibly with work-arounds.  And a way
>         of getting an updated version of that list (e.g. via a web
>         page, regular mailing, etc).
>    -  provides some mechanism for receipt, processing, acknowledgement,
>         etc of bug reports (even if that mechanism sometimes says
>         "we do not plan to support that feature because ....  Sorry!")
>    -  clearly points out which features it provides that are non
>         standard.  GUI libraries, extensions, etc etc.

Most compiler vendors will require that you buy a maintenance contract
to get all of this.  From what I've been told, if you have a maintenance
contract, Microsoft will meet all of the above criteria except the last.
Regretfully, most compilers fail on the last: HP is probably the best,
with a specific section in their man pages for standards compliance, which
state which standards, if any, the function conforms to.  AIX usually does
this as well, but not always.  It is one thing I miss on Sun CC, however,
and of course, g++ doesn't even document the standard library, but
presents g++ specials like String or ObStack as if they were standard.
(In this case, I think it is mainly a case of the documentation not keeping
up with the rest.  The C++ people at Cygnus seem very concerned about
standards conformance, but this attitude isn't shared by all of the
people involved.)

--
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 orientie 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  <AllanW@my-dejanews.com> writes:

> A more interesting problem is how the vendor could demonstrate
> compliance.  Is anyone working on an independant test suite?

There are several commercial testsuites available, from Plum-Hall,
Perennial and Modena, probably among others.  Their customers are
compiler
vendors, and they come with a fairly hefty price tag, due to the limited
market.  Nobody has yet produced a freely available testsuite that tries
to be comprehensive.

Jason

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

Tim Ottinger wrote:
> No, such a movement would not be good for me. I don't write
> Windoze stuff, and I avoid proprietary stuff in Unixes (Uni?),
> but sometimes you have to write the stuff that maps your cool
> classes onto the platform, and you need some proprietary stuff
> for that. Any features that the standard doesn't address
> (finding the free space on a drive/partition, for example)
> _should_ be added in with the ANSI/ISO standard compilers.

I've been watching this thread with some interest, and just can't
remain silent any longer.  *VENDOR-PROVIDED LIBRARIES* are a very
different thing from *proprietaty **LANGUAGE EXTENSIONS***.

Note that UNIX programmers don't have to use *any* vendor-specific
language features in C or Fortran or Ada95 to access a huge range
of operating system features:  in addition to their language
standards, there are standard POSIX bindings which do not require
*any* LANGUAGE extensions whatsoever to use.  (What they require
to _implement_ is none of our business.)  If I want to use X, I
can program with my C standard at my left hand and a stack of
X references all of which are absolutely compiler-independent at
my right hand.  I don't have to use _any_ special keywords, I
don't have to use _any_ special pragmas, I don't have to go
outside the standard *language* one iota.  (This also applies if
I want to use X/Motif from Ada, once again _no_ non-standard
language _features_ are required whatsoever in order to use the
X/Motif binding available to me.  What was required to _implement_
it is not of interest to me.)  Nor do UNIX systems require special
*syntax* or pragmas to generate or use DLLs.

Come to that, on the UNIX system I normally use, I don't have to
use any language extensions to plug in assembly code either.  I
can write any assembly code I want, put it in a separate file,
write a C header to describe it, and either have the compiler
call this code using normal calling conventions or have the
compiler inline the code and let the optimiser eliminate the
argument passing/return bits.  There's an existence proof that
you don't need any special _language_ extensions to support
assembly inserts.  Typically when one does this one writes two
versions of the function:  one in portable C, and one that takes
advantage of machine features, so the program as a whole just
needs recompiling on a different system.

There are so many benefits of NOT having LANGUAGE extensions that
it's hard to know where to start.  The fact that one can run code
intended for machine X through a static checker on machine Y (where
for example X is a microcontroller and Y is a big workstation) is
such a win that I can't imagine anyone _not_ wanting to be able to
do it.  The fact that _one_ editor package will handle _all_ the
C compilers I normally use is again something I would be reluctant
to give up.

System-depdent libraries?  Yes of course, but that's not LANGUAGE
extensions.  Hooks into assembler?  On rare occasions, yes, but
again, it *CAN* be done entirely without LANGUAGE extensions.
Access to DLLs?  Why yes of course, but no sane system has or needs
any LANGUAGE extensions for that!
---
[ 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              ]

Thaddeus L. Olczyk wrote in message
  <35ba433b.1405020@nntp.interaccess.com>...
> > > >but they will add a lot of
> > > >new featurs which will make managers happy but force us to write
> > > >code which is written in an even poorer style of C++.

In article <6pfkke$4i8$1@usenet40.supernews.com>,
  "Mark Wilden" <mwilden@sierratel.com> wrote:
> > > Could you give an example in VC++ 5.0?

kanze@my-dejanews.com wrote:
> > Start with LPTR and go from there.  Of course, you don't have to use
> > them.

Assuming that you don't use them, do they get in the way? For what it's
worth, LPTR is not a compiler feature. It's part of the Windows API.
Non-windows programs don't get this symbol defined, unless they do it
themselves.

After all, the program that says
    #include <windows.h>
is already not a well-formed C++ program, right? If the symbol is defined
in a header file you don't include, then it doesn't get in the way, and it
doesn't make VC5 non-compliant.

If you port a strictly-C++ program (that doesn't include any third-
party library) to Microsoft, it should compile correctly, unless the
program uses some of the very newest C++ features that VC5 doesn't
implement.

But you're right -- I showed LPTR to my manager, and he smiled. :-p

In article <35BE9CE0.ECEAD19D@nonexistant.com>,
  "Robert O'Dowd" <nospam@nonexistant.com> wrote:
> Correct me if I'm wrong ....   but the standard does not disallow
> extensions like LPTR being supported by a compiler.  The standard
> simply specifies a minimum level of features (capability and behaviour)
> that.  The standard simply specifies what features a programmer
> should stick to if software is to work with any compliant compiler.
> If other features are used (e.g. LPTR) then, by definition, the
> code has undefined behaviour.  I suppose a compiler could give
> warnings if extended features are used.

If it was really a compiler feature, (it isn't), it would have to start
with two underscores to ensure that it didn't get in the way of
well-formed programs that might want to use that same symbol. Or else
there would have to be a way to turn it off -- conforming compilers are
allowed to be conforming only when certain compiler switches are
applied, and nothing says that all these compile switches have to be
the defaults.

BTW, Microsoft has four warning levels, from NONE to Level 4; the highest
level, according to the help file:
    Displays informational warnings which in most cases can be
    safely ignored. [[ Such as non-ANSI compliance -- AllanW ]]
    /W4 should be used occasionally to provide "lint" level
    warnings and is not recommended as your usual warning level
    setting.
For instance, warning C4207 warns about a specific case of
initialization that breaks ANSI rules:
    char c[] = { 'a', 'b', "cdefg" };
The code works as the programmer probably intended. It does not
even issue a warning at the default warning level (3), but if
the programmer switches to warning level 4, this and other ANSI
violations are reported.

...interesting. I've been browsing the level 4 warnings to write
this message, and it appears that most of them are things that I
would want to know about. In fact, the only reason I can't turn
it on is because Microsoft source code flagrantly disregards most
of these rules. Understandable, I suppose, since there is no
reason for the Visual C++ library source code to be portable to
other compilers...

I suppose it's possible that the way they chose level-4 candidates
was by compiling their own code, assuming it to be perfect, and
changing all the warnings that they saw to level 4. But to believe
that would make me as a bigger cynic than I want to be (at least
bigger than I want to be know as.-)

> If a hypothetical compiler fully supports the standard, and
> adds one extra feature that is not specified in the standard,
> I would have trouble claiming that compiler is not ANSI compliant.

It's ANSI compliant if it always compiles well-formed programs.  A
program that uses the symbol LPTR for it's own purposes certainly can
be well-formed. I would say that Microsoft wasn't compliant if it
couldn't compile such a program; fortunately, it can, simply by not
including the windows header files.

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

In article <35BE7BA0.7A17@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:
> On the other hand, extensions like Microsoft's 'near' and 'far'
> keywords, which blatantly invade the user namespace, are an
> abomination.  And Microsoft *requires* the use of things like
> '__declspec(export)' and '__cdecl' in your source code if you're
> trying to make shared libraries and language-independent code;
> but at least they use reserved keywords for these things.

Well, the C++ standard doesn't say that you can create shared libraries
and language-independent code at all, so this is already a vendor
extension.  Furthermore, I am under the impression that you could type
the names of all your export functions into a .DEF file instead of
marking them __declspec(export) in your code; if so, then declaring
them __declspec(export) instead of putting them into the .DEF file is
a convenience issue, and doesn't force you to do anything incompatible.

However, I wish that they had chosen to implement this feature with
    extern "EXPORT"
instead. There's a very explicit hook, which seems like it was designed
specifically for the type of thing Microsoft is accomplsihing with
__declspec(export). The hook allows the vendors to give non-standard
constant strings any meaning they wish to. It's also ver intuitive and
very explicit, as opposed to the word "declspec" which means nothing to
me.

> I hope that vendors will begin to put their extensions (at least
> library variables, functions, and types) into separate namespaces
> (such as "sys::" or "posix::"), and thus become more "conforming"
> in the long run.

I hope so too.

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

In article <35BF2C35.2781@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> kanze@my-dejanews.com wrote:
> >
> > In article <6pfkke$4i8$1@usenet40.supernews.com>,
> >   "Mark Wilden" <mwilden@sierratel.com> wrote:
> ...
> > > I don't believe they do in fact claim complete ANSI compliance.
> >
> > It's hard to be compliant with something that doesn't exist.
>
> But it does exist, and has existed since shortly before this thread
> started (see subject line).

Formally, it won't exist until ISO finishes the paper work.  But that
wasn't my point.  The originator was talking about ad's claiming
conformance.  For him to have seen them, they must have been created
before the last vote, and so before there was any standard.

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

>In article <35BE9CE0.ECEAD19D@nonexistant.com>,
>  "Robert O'Dowd" <nospam@nonexistant.com> wrote:
>>
>> Correct me if I'm wrong ....   but the standard does not disallow
>> extensions like LPTR being supported by a compiler.

LPTR is not an extension and it's not "supported" by the VC++
compiler. It's merely a define in a Windows SDK header.

kanze@my-dejanews.com wrote in message
<6pnqe8$8uo$1@nnrp1.dejanews.com>...
>    #include <iostream>
>
>    int
>    main()
>    {
>        int         LPTR = 1 ;
>        std::cout << LPTR << '\n' ;
>        return 0 ;
>    }
>
>And it does, at least with VC++ 5.0.  If you include the header file
>which defines LPTR, however, you have invoked undefined behavior from
>the point of view of the standard, and Microsoft defined behavior in
>this particular case.

LPTR is defined like this in Winbase.h

#define LMEM_FIXED          0x0000
#define LMEM_ZEROINIT       0x0040
#define LPTR (LMEM_FIXED | LMEM_ZEROINIT)

In your example, this does not produce undefined behavior--it produces
a syntax error.

>My only real complaint with LPTR is that it is horribly ugly.

How so? Certainly this style is old-fashioned, though.
---
[ 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              ]

kanze@my-dejanews.com wrote:
>
> In article <6pfkke$4i8$1@usenet40.supernews.com>,
>   "Mark Wilden" <mwilden@sierratel.com> wrote:
...
> > I don't believe they do in fact claim complete ANSI compliance.
>
> It's hard to be compliant with something that doesn't exist.

But it does exist, and has existed since shortly before this thread
started (see subject line). It's even remotely possible that someone
gambled on the standard being approved, and has already release a fully
conformant version. I haven't seen any ads for one yet, however.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <6pkmr9$q5i$1@nnrp1.dejanews.com>,
  jhyslop@my-dejanews.com wrote:
> In article <6phorq$jtq$1@reader1.reader.news.ozemail.net>,
>   "Patrick Wray" <pwray@ozemail.com.au> wrote:
> >
> > Tony wrote in message ...
> > >Do I hear some agreement here that ANSI/ISO C++ compilers should not be
> > >tainted with (bundled with) proprietary technologies?  (my humble
> > >bandwagon).  A movement anyone? :)
> > >
> > >Tony
> >
> > That humble bandwagon big enough for two?
>
> I don't have a problem - *as long as* the proprietary technology adheres to
> the Standard (which MFC reportedtly doesn't - the question is, will MS
revise
> it so it does?).

MFC cannot conform to the standard, by definition, since it offers
services that are not defined by the standard.

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <199807281217.IAA27606@mailfw1.ford.com>,
  Mike Tiller <mtiller@ford.com> wrote:
> kanze@my-dejanews.com writes:
>
> > (Of course, if you use X-Windows, you also use a lot of non-standard
> > features.  But only to interface the windowing system itself, which
> > is not covered by the C++ standard.)
>
> What non-standard features are you referring to?  X has nothing to do
> with the compiler, it is a (heavily documented) communications
> protocol and a library of C language bindings to the protocol.  It
> does not require a special compiler to build windowing applications in
> X, moreover it certainly doesn't require a C++ compiler.

So.  What is the point?  Whether you use X Windows, or MS-Windows, you
are not writing strictly compatible code, but using an "extension"
provided by your compiler vendor and/or some third party.  My X-Windows
code won't compile and run on my NT machine, and my MS-Windows code
won't compile and run on my AIX or Solaris based machines.  A program
using either is NOT a conforming program.

> Microsoft may hack all sorts of proprietary features into their
> compilers to support their GUI API, but that is definitely not the way
> X does it.

Who cares how they do it?  The point is simple: the C++ standard does
not define a windowing API, so any C++ program which does windowing isn't
conforming anyway.

More to the point, standard conforming programs DO compile and run with
the Microsoft compiler, and with the correct options, programs requiring
a diagnostic get one.  Which is exactly what is required for a compiler
to be considered conforming.  While I personally may prefer the way X
does it, my personal preferences don't affect the conformity of the
compiler.  (Actually, my personal preference is to get some intelligently
written third party library, which offers a reasonable level of abstraction
and is available for both X and MS-Windows, and let the third party library
vendor worry about all of these compatibility issues.)

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

In article <6pkmr9$q5i$1@nnrp1.dejanews.com>,
  jhyslop@my-dejanews.com wrote:
> In article <6phorq$jtq$1@reader1.reader.news.ozemail.net>,
>   "Patrick Wray" <pwray@ozemail.com.au> wrote:
> >
> > Tony wrote in message ...
> > >Do I hear some agreement here that ANSI/ISO C++ compilers should not be
> > >tainted with (bundled with) proprietary technologies?  (my humble
> > >bandwagon).  A movement anyone? :)
> > >
> > >Tony
> >
> > That humble bandwagon big enough for two?
>
> I don't have a problem - *as long as* the proprietary technology adheres to
> the Standard (which MFC reportedtly doesn't - the question is, will MS
revise
> it so it does?).

Since there are no "foundation classes" in the C++ standard at all,
all that's neccesary is to leave out the header file for MFC, and
everything is compliant.

For that matter, compliant compilers are allowed to do anything they
want to do with programs that are not well-formed. And the moment you
    #include <afxwin.h>
you are no longer well-formed.

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

>kanze@my-dejanews.com wrote:
>>
>> > Could you give an example in VC++ 5.0?
>>
>> Start with LPTR and go from there.  Of course, you don't have to
use
>> them.

LPTR is a define found in Winbase.h. It has absolutely nothing to do
with the VC++ compiler and its implementation of the C++ language. I
certainly hope the standard doesn't forbid distributing libraries and
their associated headers!




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

>Anyone care to name some names and an estimate of
>the implementation's level of conformance?


This would be a really useful thing to know - the language features
supported by the various major compilers.  I'm fed up with wasting time
trying to work out why my code doesn't work only to find that the
compiler's
idea of C++ isn't the same as mine.

Does anyone know if the next version of VC++ will be any closer to the
standard?

Jon



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

kanze@my-dejanews.com writes:

> How about an estimate of the number of bugs the first conformant
version
> will contain:-)?

None.  Or it would not be conformant.  Which means that you should not
expect it any time soon (or at all?).


--
David Kastrup                                     Phone:
+49-234-700-5570
Email: dak@neuroinformatik.ruhr-uni-bochum.de       Fax:
+49-234-709-4209
Institut f   r Neuroinformatik, Universit   tsstr. 150, 44780 Bochum,
Germany

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 25 Jul 1998 00:29:34 GMT, "Jon Pearson" <pearson@ccdc.cam.ac.uk>
wrote:

>
>Does anyone know if the next version of VC++ will be any closer to the
>standard?
>

Not only will they not make it any closer, but they will add a lot of
new featurs which will make managers happy but force us to write
code which is written in an even poorer style of C++.  I don't
understand how they get away with writing  "ANSI C++ " on
their box and in their advertisements.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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

Thaddeus L. Olczyk wrote in message
<35ba433b.1405020@nntp.interaccess.com>...
>
>Not only will they not make [VC++] any closer

It seems to me quite unlikely that they won't add a single
ANSI-conforming feature.

>but they will add a lot of
>new featurs which will make managers happy but force us to write
>code which is written in an even poorer style of C++.

Could you give an example in VC++ 5.0?

>I don't
>understand how they get away with writing  "ANSI C++ " on
>their box and in their advertisements.

I don't believe they do in fact claim complete ANSI compliance.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

In article <35ba433b.1405020@nntp.interaccess.com>,
olczyk@interaccess.com says...
> On 25 Jul 1998 00:29:34 GMT, "Jon Pearson" <pearson@ccdc.cam.ac.uk>
> wrote:
> >Does anyone know if the next version of VC++ will be any closer to the
> >standard?
> Not only will they not make it any closer, but they will add a lot of
> new featurs which will make managers happy but force us to write
> code which is written in an even poorer style of C++.  I don't
> understand how they get away with writing  "ANSI C++ " on
> their box and in their advertisements.

Do I hear some agreement here that ANSI/ISO C++ compilers should not be
tainted with (bundled with) proprietary technologies?  (my humble
bandwagon).  A movement anyone? :)

Tony

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

anthonNO-SPAMp9@idt.net (Tony) wrote:
>> Do I hear some agreement here that ANSI/ISO C++ compilers should not
>> be tainted with (bundled with) proprietary technologies?  (my humble
>> bandwagon).  A movement anyone? :)

AllanW@my-dejanews.com wrote:
> Unrealistic. These "proprietary technologies" exist to satisfy the
> general public, not to annoy them.
> ...
> This is ideal for application programmers, because it gives us the
> best of both worlds. If the local feature set is more important to
> me than portability, I can use them at will. If portability is more
> important, it's easy to code that way too.

Agreed.  The POSIX library, after all, is an "extension" beyond
pure ANSI.  Indeed, enabling "strict ANSI" mode for many compilers
disables common extensions like POSIX, X/Open, OSF, and vendor-
specific O/S functions, making the result essentially useless for
anything except toy programs.

On the other hand, extensions like Microsoft's 'near' and 'far'
keywords, which blatantly invade the user namespace, are an
abomination.  And Microsoft *requires* the use of things like
'__declspec(export)' and '__cdecl' in your source code if you're
trying to make shared libraries and language-independent code;
but at least they use reserved keywords for these things.

I hope that vendors will begin to put their extensions (at least
library variables, functions, and types) into separate namespaces
(such as "sys::" or "posix::"), and thus become more "conforming"
in the long run.

We'll see.

-- David R. Tribble, dtribble@technologist.com --

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

kanze@my-dejanews.com wrote:
>
> In article <6pfkke$4i8$1@usenet40.supernews.com>,
>   "Mark Wilden" <mwilden@sierratel.com> wrote:
> > Thaddeus L. Olczyk wrote in message
> > <35ba433b.1405020@nntp.interaccess.com>...
> > >
> > >Not only will they not make [VC++] any closer
> >
> > It seems to me quite unlikely that they won't add a single
> > ANSI-conforming feature.
> >
> > >but they will add a lot of
> > >new featurs which will make managers happy but force us to write
> > >code which is written in an even poorer style of C++.
> >
> > Could you give an example in VC++ 5.0?
>
> Start with LPTR and go from there.  Of course, you don't have to use
> them.
>

Correct me if I'm wrong ....   but the standard does not disallow
extensions like LPTR being supported by a compiler.  The standard
simply specifies a minimum level of features (capability and behaviour)
that.  The standard simply specifies what features a programmer
should stick to if software is to work with any compliant compiler.
If other features are used (e.g. LPTR) then, by definition, the
code has undefined behaviour.  I suppose a compiler could give
warnings if extended features are used.

If a hypothetical compiler fully supports the standard, and
adds one extra feature that is not specified in the standard,
I would have trouble claiming that compiler is not ANSI compliant.

> > >I don't
> > >understand how they get away with writing  "ANSI C++ " on
> > >their box and in their advertisements.
> >
> > I don't believe they do in fact claim complete ANSI compliance.
>
> It's hard to be compliant with something that doesn't exist.
>
> In practice, of course, to be 100% compiant means to have no bugs.
> So most vendors lie a little, and we accept it, because the lie is
> often more informative than the truth (that there are no compliant
> compilers, even for C) is.
>

If a vendor claims a compiler is ANSI compliant, that is a fairly
good indication that the compiler complies with a useful subset of
the standard. That subset will typically be features that a fair
majority of programmers will use frequently.  I'm even more likely
to be confident if the vendor is also willing to include
documentation that;

   -  acknowledges which features are implemented on a provisional
        basis so should be used with care.
   -  a list of known bugs or things in the standard that
        are not supported. Possibly with work-arounds.  And a way
        of getting an updated version of that list (e.g. via a web
        page, regular mailing, etc).
   -  provides some mechanism for receipt, processing, acknowledgement,
        etc of bug reports (even if that mechanism sometimes says
        "we do not plan to support that feature because ....  Sorry!")
   -  clearly points out which features it provides that are non
        standard.  GUI libraries, extensions, etc etc.

-<Automagically included trailer>
Robert O'Dowd                       Ph    +61 (8) 9553 3618
DSTO Bldg A51                     Fax    +61 (8) 9553 3577
HMAS Stirling                       Email:
robert.odowd@dsto.defence.gov.au
Rockingham, Western Australia, 6958

Disclaimer: Opinions above are mine and may be worth what you paid for
them

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

kanze@my-dejanews.com wrote:
>
> In article <MPG.1025ec4f6fd9c075989850@news.idt.net>,
>   anthonNO-SPAMp9@idt.net (Tony) wrote:
> > In article <35ba433b.1405020@nntp.interaccess.com>,
> > olczyk@interaccess.com says...
> > > On 25 Jul 1998 00:29:34 GMT, "Jon Pearson" <pearson@ccdc.cam.ac.uk>
> > > wrote:
> > > >Does anyone know if the next version of VC++ will be any closer to the
> > > >standard?
> > > Not only will they not make it any closer, but they will add a lot of
> > > new featurs which will make managers happy but force us to write
> > > code which is written in an even poorer style of C++.  I don't
> > > understand how they get away with writing  "ANSI C++ " on
> > > their box and in their advertisements.
> >
> > Do I hear some agreement here that ANSI/ISO C++ compilers should not be
> > tainted with (bundled with) proprietary technologies?  (my humble
> > bandwagon).  A movement anyone? :)
>
> It would make them pretty much unusable, wouldn't it?  After all, Microsoft
> isn't the only one -- Posix defines a mess of additional features as well.
>
> I suspect the real complaint is that it is rare to work on a Microsoft
> machine without doing windows, and once you do that, you typically end
> up having to use a lot of extra features that have nothing to do with
> windowing.  (Of course, if you use X-Windows, you also use a lot of
> non-standard features.  But only to interface the windowing system
> itself, which is not covered by the C++ standard.)

I suspect folks aren't complaining about libraries which are outside the
scope of the standard libraries.  There are LOTS of things which are not
covered at all by either standard, but many useful programs have to
do--windowing, networking, multithreading, multimedia, graphics, etc.

What folks are complaining about is the pervasiveness of Microsoft
extensions to the language itself.  It seems in order to write ANY
useful code on Windoze, you need to embrace one or more of the
following:

*  declaration specifiers (for declaring entry points to DLLs, among
other things)

*  thread-local storage (two ways of doing this--"dynamic" and "static";
dynamic thread local storage is implemented using libraries; like
POSIX thread keys, static thread local storage is implemented using a
declspec, and I assume, thread-specific data segments.

*  structured exception handling.  Rather than software interrupts
resulting in signals; you get an exception, similar to a C++ exception.
There is some stack unwinding support (__finally blocks, which do the
same thing as in Java).  While this is useful; it certainly is a
pervasive extension to the language.  (I once heard that MS has a patent
on structured exception handling; though given lotsa prior art, and the
fact that Java supports asynchronous exceptions, I kinda find this one
hard to believe.  Anyone care to comment?)

Try compiling MFC with an ANSI-compliant compiler, and see how far
you get.

Some of the above features might be useful additions to the language;
I'd love an "export" keyword to hint to the implementation that
a symbol might be referenced dynamically, for instance.  But none of
them are currently standard.  (At least MS behaves themselved these days
with regard to their non standard extensions, and prefixes them all with
double-underscores.  Used to be they didn't do that...)

Scott

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <6phorq$jtq$1@reader1.reader.news.ozemail.net>,
  "Patrick Wray" <pwray@ozemail.com.au> wrote:
>
> Tony wrote in message ...
> >Do I hear some agreement here that ANSI/ISO C++ compilers should not be
> >tainted with (bundled with) proprietary technologies?  (my humble
> >bandwagon).  A movement anyone? :)
> >
> >Tony
>
> That humble bandwagon big enough for two?

I don't have a problem - *as long as* the proprietary technology adheres to
the Standard (which MFC reportedtly doesn't - the question is, will MS revise
it so it does?).

Jim

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

Tony wrote:
> Do I hear some agreement here that ANSI/ISO C++ compilers
> should not be tainted with (bundled with) proprietary
> technologies?  (my humble bandwagon).  A movement anyone? :)

I recognize the smiley, but...

No, such a movement would not be good for me. I don't write
Windoze stuff, and I avoid proprietary stuff in Unixes (Uni?),
but sometimes you have to write the stuff that maps your cool
classes onto the platform, and you need some proprietary stuff
for that. Any features that the standard doesn't address
(finding the free space on a drive/partition, for example)
_should_ be added in with the ANSI/ISO standard compilers.

Also remember that there is no GUI with C++, nor an IDE. While
I'd rather work in vim and I prefer and trust makefiles better
than IDEs, I don't think I'd want to pay extra for them.

On the other hand, there are those who think that MSVC++ *is*
the C++ standard, and that MFC is the standard API, and that
the IDE is part of the language. That's because of marketing
not bundling, and we can't do much about that either.

Tim
---
[ 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 wrote:

> Graphical User Interface systems differ from text-only
> interactive systems, which are still different than batch systems.
> (C++ for Microsoft Windows must have the ability to create a window,
> which will never be Standard C++.)

I agree that platform-specific language extensions can be necessary, but
this
is not a valid example. Creating a window (or any other user
interface-related functionality, for that matter) is not built into
Visual
C++, it is part of the Win32 API, which can, in theory, be called from
any
language that allows you to call DLLs and supports the calling
convention
used. The latter *is* a language extension, by the way. You can also
create a
window using MFC, but this is just an extra C++ (well, sort of) layer on
top
of Win32. If this would be considered a language extension, any class
library
would be, too.

Gerhard Menzl


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

Tony wrote in message ...
>Do I hear some agreement here that ANSI/ISO C++ compilers should not be
>tainted with (bundled with) proprietary technologies?  (my humble
>bandwagon).  A movement anyone? :)
>
>Tony


That humble bandwagon big enough for two?



[ 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 26 Jul 1998 01:11:51 GMT, olczyk@interaccess.com (Thaddeus L.
Olczyk) wrote:

>Not only will they not make it any closer, but they will add a lot of
>new featurs which will make managers happy but force us to write
>code which is written in an even poorer style of C++.  I don't
>understand how they get away with writing  "ANSI C++ " on
>their box and in their advertisements.

What particular proprietary features?

Francis.

Home: francis@pobox.co.uk  Web: www.meta.demon.co.uk
---
[ 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.1025ec4f6fd9c075989850@news.idt.net>,
  anthonNO-SPAMp9@idt.net (Tony) wrote:
> In article <35ba433b.1405020@nntp.interaccess.com>,
> olczyk@interaccess.com says...
> > On 25 Jul 1998 00:29:34 GMT, "Jon Pearson" <pearson@ccdc.cam.ac.uk>
> > wrote:
> > >Does anyone know if the next version of VC++ will be any closer to the
> > >standard?
> > Not only will they not make it any closer, but they will add a lot of
> > new featurs which will make managers happy but force us to write
> > code which is written in an even poorer style of C++.  I don't
> > understand how they get away with writing  "ANSI C++ " on
> > their box and in their advertisements.
>
> Do I hear some agreement here that ANSI/ISO C++ compilers should not be
> tainted with (bundled with) proprietary technologies?  (my humble
> bandwagon).  A movement anyone? :)

It would make them pretty much unusable, wouldn't it?  After all, Microsoft
isn't the only one -- Posix defines a mess of additional features as well.

I suspect the real complaint is that it is rare to work on a Microsoft
machine without doing windows, and once you do that, you typically end
up having to use a lot of extra features that have nothing to do with
windowing.  (Of course, if you use X-Windows, you also use a lot of
non-standard features.  But only to interface the windowing system
itself, which is not covered by the C++ standard.)

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

Thaddeus L. Olczyk wrote:
>
> On 25 Jul 1998 00:29:34 GMT, "Jon Pearson" <pearson@ccdc.cam.ac.uk>
> wrote:
>
> >
> >Does anyone know if the next version of VC++ will be any closer to the
> >standard?
> >
>
> Not only will they not make it any closer, but they will add a lot of
> new featurs which will make managers happy but force us to write
> code which is written in an even poorer style of C++.  I don't
> understand how they get away with writing  "ANSI C++ " on
> their box and in their advertisements.

Are you sure they claim full compliance with the C++ standard? The very
first C++ standard has only just been approved (note the subject line),
after a vote that ended a month ago. I thought that advertising
campaigns usually require longer than that to set up.
---
[ 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              ]

"Patrick Wray" <pwray@ozemail.com.au> wrote:
>Tony wrote in message ...
>>Do I hear some agreement here that ANSI/ISO C++ compilers should not be
>>tainted with (bundled with) proprietary technologies?  (my humble
>>bandwagon).  A movement anyone? :)
>
>That humble bandwagon big enough for two?

I'm smiling because I can appreciate the sentiment here -- but extensions
aren't necessarily evil, and some are necessary to cope with platform
dependencies.

Don't forget that every compiler ever produced has had extensions, and
that certainly includes compilers for languages other than C++. For
example, ISO/ANSI C has the atoi() function but no itoa(), and many
compilers provide the latter as an extension; similarly, it has toupper()
and tolower() for chars but no strupr() or strlwr() for strings, and
that's another common extension.

Now, granted, it's a little different when some environments add basic
language features /and/ essentially require their use (e.g., C++ Builder),
but even in that case extensions aren't necessarily evil.

Herb


---
Herb Sutter (mailto:herbs@cntc.com)

Current Network Technologies Corp  2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com    Mississauga Ontario Canada L5K 2N6
---
[ 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 <35ba433b.1405020@nntp.interaccess.com>,
  olczyk@interaccess.com (Thaddeus L. Olczyk) wrote:
> On 25 Jul 1998 00:29:34 GMT, "Jon Pearson" <pearson@ccdc.cam.ac.uk>
> wrote:
>
> >Does anyone know if the next version of VC++ will be any closer to the
> >standard?
>
> Not only will they not make it any closer, but they will add a lot of
> new featurs which will make managers happy but force us to write
> code which is written in an even poorer style of C++.

Details, please?

> I don't
> understand how they get away with writing  "ANSI C++ " on
> their box and in their advertisements.

Just now, I picked up four of the recent magazines for programmers
that were on my desk, and scanned all the ads from Microsoft.  None
of them used "Ansi" anywhere on the ad.

Peeking at their web site, I did find one mention of ANSI on page
http://www.microsoft.com/visualc/prodinfo/datasheet/ (please forgive
the sales hype; remember that this comes from a page for prospective
buyers):

    The latest C++ compiler technology in Visual C++ is finely tuned
    for performance, producing significantly faster and smaller
    32-bit applications for the Windows.95 and Windows NT.Workstation
    operating systems. With new industry-leading optimizations and the
    latest ANSI features, your Visual C++ based applications run better
    than ever.

Remember that this talks about VC++5.0, not 6.0 (which is due out in
September).  "The latest ANSI features" may suggest that it probably
conforms to the latest C++ standard, but it certainly doesn't promise
anything tangible.

Indeed, 5.0 is pretty close in many of the important measures of
compliance. I'm sure that there are lots of compilers out there that
are much more compliant, on any particular weighted scoresheet, but
there are probably lots of them that are much less compliant, too.

I've done my share of Microsoft bashing in the past, but let's be
fair about it.

My personal guess is that early next year will be the first time a
compiler claims to be fully compliant, and perhaps another 6-10 months
before one actually *is* compliant.

A more interesting problem is how the vendor could demonstrate
compliance.  Is anyone working on an independant test suite?

If some vendor released a usable test suite to the public domain soon
enough, then even though it wasn't independant, many buyers would
probably use it to test a wide variety of platforms.  If that happened,
then other vendors might begin advertising compliance on that basis --
and thus it would become the de-facto industry test suite.

The vendor who pulled this off would be in a position comparable to
Hewlett Packard -- although they gave out the original version of the
Standard Template Library for free, they now have a copyright notice
in almost every implementation of the C++ library. This enhances their
already excellent reputation and credibility.

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

[comp.std.c++ removed from followups]

Tony <anthonNO-SPAMp9@idt.net> wrote:
>Do I hear some agreement here that ANSI/ISO C++ compilers should not be
>tainted with (bundled with) proprietary technologies?  (my humble
>bandwagon).  A movement anyone? :)

Unfortunately, those "proprietary technologies" often make it easier
to get a job done.

For example, from time to time I delve into the nitty gritty internals
of my system (peeking at the stack, messing with a value here or
there, etc.).  I could -- painfully -- do this in assembly, or use
compiler calling-convention extensions (__cdecl, __pascal, __stdcall,
etc.) to get the same effect in half a line of code.

By far and large, I try to avoid compiler-specific extensions.  That
only makes sense.  But I would go nuts if my compiler didn't support
these extensions and I had to implement this code.
---
[ 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.1025ec4f6fd9c075989850@news.idt.net>,
  anthonNO-SPAMp9@idt.net (Tony) wrote:
> Do I hear some agreement here that ANSI/ISO C++ compilers should not be
> tainted with (bundled with) proprietary technologies?  (my humble
> bandwagon).  A movement anyone? :)

Unrealistic. These "proprietary technologies" exist to satisfy the
general public, not to annoy them. Systems with large physical
memory differ from those with large virtual memory implemented with
swapping, which are different still from systems with small virtual
memory.  (C++ for 16-bit Intel processors need the optimizations
provided by differing memory models, which will never be Standard
C++.)  Graphical User Interface systems differ from text-only
interactive systems, which are still different than batch systems.
(C++ for Microsoft Windows must have the ability to create a window,
which will never be Standard C++.)  Game systems programs differ
from mission-critical systems in which a single crash could cost
lives or lots of money.  In each case, the programmers may come to
expect certain features in their compilers which are not universal.

The use of these features is safe and efficient, and generally
provides few problems other than portability (if portability is
defined to include other compilers on the same platform).

Backwards compatibility is also important; C++ for platform A must
be compatible with already-written C++ programs written for platform
A, so it must (as a bare minimum) support all previously-existing
technology.  In any case, non-standard extensions are going to be
around for a long, long time.

However, the C++ standard does place limits on these incompatible
extensions.  By defining rigid boundaries of compliance, we can
state categorically that programs which do *not* use any of the
vendor-supplied extensions *will* work correctly on any other
platform that has earned the right to call themselves compliant.
During the design phase, it's usually easy enough to specify a
limited number of modules that will use these extensions directly;
these modules will have to be translated when moving to a new
platform, but most of the others will require few or no changes.

This is ideal for application programmers, because it gives us the
best of both worlds. If the local feature set is more important to
me than portability, I can use them at will. If portability is more
important, it's easy to code that way too.

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

In article <6pfkke$4i8$1@usenet40.supernews.com>,
  "Mark Wilden" <mwilden@sierratel.com> wrote:
> Thaddeus L. Olczyk wrote in message
> <35ba433b.1405020@nntp.interaccess.com>...
> >
> >Not only will they not make [VC++] any closer
>
> It seems to me quite unlikely that they won't add a single
> ANSI-conforming feature.
>
> >but they will add a lot of
> >new featurs which will make managers happy but force us to write
> >code which is written in an even poorer style of C++.
>
> Could you give an example in VC++ 5.0?

Start with LPTR and go from there.  Of course, you don't have to use
them.

> >I don't
> >understand how they get away with writing  "ANSI C++ " on
> >their box and in their advertisements.
>
> I don't believe they do in fact claim complete ANSI compliance.

It's hard to be compliant with something that doesn't exist.

In practice, of course, to be 100% compiant means to have no bugs.
So most vendors lie a little, and we accept it, because the lie is
often more informative than the truth (that there are no compliant
compilers, even for C) is.

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

Tony wrote in message ...
>Do I hear some agreement here that ANSI/ISO C++ compilers should not be
>tainted with (bundled with) proprietary technologies?  (my humble
>bandwagon).  A movement anyone? :)

You probably hear SOME agreement, but I would offer a dissenting view.
Assuming that ANSI C++ reflects the ideas of a living language and is
not just a dead standard, enhancements must be proposed, allowed to
circulate within the public, and be evaluated.  The role of a standard
is to tell you how far you can go and (it is hoped) still be compilable
on any compiler; it is not to freeze the language and mark its
permanent boundaries beyond which it must not pass.

Now, one may argue that features that are implementable on only one OS
or hardware platform are a BAD THING (TM) - I think so - or that they
should not be used unless the programmer is aware that they may be
limiting the portability of their program; but that is up to the
programmer to decide.  One can also try to ensure that these
mono-systemic features are not ensconced in future standards, as well -
they probably shouldn't be (and more to the point, suggesting that they
would be is probably an insult to most working on the standards
process, as most of the people who participate would be aware of their
true nature and would not let them pass).  One may also bemoan the
current poor state of knowledge of C++ programmers who may not be aware
that their favorite programming constructs are specific to a single
compiler or system, but by this time, they have little but their own
ignorance to blame for this.  Finally, remember that most language
features (including ones that require system support) start out as
mono-systemic features; only after they are tried and promoted do they
become wide-spread enough to be accepted through the community and the
associated support systems to become commonplace - even if they require
OS support (Remember that VM was once handled inside programs. It is
now commonplace enough that most language systems depend on it).

The bottom line is that the people who work on standards are too smart
to let this happen and you need a test-bed for new features in the
language (even those that may require system support).  Standards set
outer boundaries within which one stays if one wants to be safe.  They
do not (and should not) preclude people from trying new techniques,
even if one cannot see a way to implement them efficiently on one's
current software or hardware system.  Doing otherwise leads a language
down the path of the dodos.

Frank A. Adrian
franka@europa.com

P.S.  Although I have little regard for a certain large Washington
state software company, many of these complaints seem to focus
exclusively on this company.  I guess I see it as the nature of our
industry.  All of the players try to lock their users into proprietary
systems.  I don't trust Scott McNealy or Larry Ellison to do any
different than Bill Gates and Andy Grove.  The only difference between
them is in size and ability to make their "standards" stick.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

kanze@my-dejanews.com writes:

> (Of course, if you use X-Windows, you also use a lot of non-standard
> features.  But only to interface the windowing system itself, which
> is not covered by the C++ standard.)

What non-standard features are you referring to?  X has nothing to do
with the compiler, it is a (heavily documented) communications
protocol and a library of C language bindings to the protocol.  It
does not require a special compiler to build windowing applications in
X, moreover it certainly doesn't require a C++ compiler.

Microsoft may hack all sorts of proprietary features into their
compilers to support their GUI API, but that is definitely not the way
X does it.

> --
> James Kanze

--
Michael Tiller
Ford Motor Company


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

Steve Clamage wrote:

> Now that we do have a standard, we should see successive
> releases of C++ implementations moving closer to full
> conformance. Some are quite close now.
>
> --
> Steve Clamage, stephen.clamage@sun.com

Anyone care to name some names and an estimate of
the implementation's level of conformance?

Eric.



[ 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 <35B65982.541235F@lmco.com>,
  Eric Lemings <eric.b.lemings@lmco.com> wrote:
> Steve Clamage wrote:
>
> > Now that we do have a standard, we should see successive
> > releases of C++ implementations moving closer to full
> > conformance. Some are quite close now.
> >
> > --
> > Steve Clamage, stephen.clamage@sun.com
>
> Anyone care to name some names and an estimate of
> the implementation's level of conformance?

How about an estimate of the number of bugs the first conformant version
will contain:-)?  Always beware of version numbers ending in a .0:-)!

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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 writes:

>In article <EwEx05.BAt@research.att.com>,
>  ark@research.att.com (Andrew Koenig) wrote:
>> I learned today that the C++ standard was officially approved,
>> by a vote of 20 to 0.

>Do you mean, that the vote on the FDIS passed, or that the ISO
>administration has put the last stamp on the document, and that
>there is now an official ISO 14882 standard.  (My impression was
>that it could take ISO up to 6 months after the vote passed, but
>I would just love to hear that I'm wrong.)

The vote by ISO national member bodies passed. The administrative
wheels still need to turn (hear the squeaking in the distance?)
before an actual standard is published. OTOH, the text of the
FDIS is the text of the standard, so there are no more
uncertainties about the contents of the International Standard.

When I hear anything official about availability of the actual
standard, I'll post it in the C++ newsgroups and in the FAQ for
newsgroup comp.std.c++.

--
Steve Clamage, stephen.clamage@sun.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              ]

olczyk@interaccess.com (Thaddeus L. Olczyk) writes:

>On 21 Jul 98 06:03:43 GMT, ark@research.att.com (Andrew Koenig) wrote:

>>I learned today that the C++ standard was officially approved,
>>by a vote of 20 to 0.
>>
>>Time to break out the bubbly...
>>--

>So what is the new name of MSVC++, since they can no longer use C++ in
>their name.

I didn't see a smiley, so I'll answer. The name "C++" is not
protected in any way. Selling something as a "C++ compiler" does
not by itself guarantee anything about conformance to the
standard. Probably a good thing, since no implementation fully
conforms as yet.

As chair of J16, the ANSI C++ Committee, I had promised to
announce the result of the vote as soon as I heard about it.
Andy Koenig beat me to it, due to time zone differences. :-)

A lot of people worked for many years to make the standard
a reality. I'm particularly pleased that the Committee was
able to satisfy the conflicting demands of the range of
individuals and national bodies involved. I consider the
unanimous vote of J16 and of the ISO member nations a
real validation of all our work.

Regular participants in these newsgroups can also take a
measure of pride in the achievement. More than a few
problems and errors in drafts of the standard were
discovered and discussed by people who are not Committee
members, but who use these communication channels as a
less-direct means of participation.

Now that we do have a standard, we should see successive
releases of C++ implementations moving closer to full
conformance. Some are quite close now.

We can all then concentrate on learning how to use the features
of Standard C++ (it feels good to be able to write that phrase)
to best advantage.

--
Steve Clamage, stephen.clamage@sun.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              ]

On 21 Jul 98 06:03:43 GMT, ark@research.att.com (Andrew Koenig) wrote:

>I learned today that the C++ standard was officially approved,
>by a vote of 20 to 0.
>
>Time to break out the bubbly...
>--

So what is the new name of MSVC++, since they can no longer use C++ in
their name.
---
[ 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 <EwEx05.BAt@research.att.com>,
  ark@research.att.com (Andrew Koenig) wrote:
> I learned today that the C++ standard was officially approved,
> by a vote of 20 to 0.
>
> Time to break out the bubbly...

Does anyone have an estimate of when the C++ Standard...whoo whoo,
we can actually say, "Standard"...will be available to the public
for purchase?

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

In article <EwEx05.BAt@research.att.com>,
  ark@research.att.com (Andrew Koenig) wrote:
> I learned today that the C++ standard was officially approved,
> by a vote of 20 to 0.

Do you mean, that the vote on the FDIS passed, or that the ISO
administration has put the last stamp on the document, and that
there is now an official ISO 14882 standard.  (My impression was
that it could take ISO up to 6 months after the vote passed, but
I would just love to hear that I'm wrong.)

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