"Shao Wu" <swu00@earthlink.net> wrote in message news:3D7D6AC0.9329AFE7@earthlink.net...

> Ken has pointed out some problems with str*() function.
> In addition, str*() functions are too ASCII centric and not
> work well with other  [human] languages and locales.
> Win32 is using Unicode as its "native" character set, and
> str*() is not native in W2k and XP.

What the hell is ``ASCII centric'' about a nul-terminated sequence of
bytes? You can use these functions to manipulate UTF-8, JIS, Shift JIS,
and EUC -- among many multibyte encodings of languages used around the
world. Of course you shouldn't use the str* functions to manipulate a
sequence of wchar_t, but you shouldn't use them to manipulate a sequence
of float either.

Whether you should use wchar_t for all your text instead of char is an
issue orthogonal to the utility, safety, and portability of the str*
functions, which are a part of the C90, C++98, and C99 Standards.

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



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

swu00@earthlink.net (Shao Wu) wrote:
> > > Why bother with standard compliant when you are developing
> > > in the Microsoft world? So that you can port your code from
> > > Windows NT to Windows XP without source code modifcation
> > > using the Microsoft compiler?

> Frode.Nilsen@mison.no wrote:
> > Both MetroWerks and Borland have good compilers for Windows.

swu00@earthlink.net (Shao Wu) wrote:
> I know my arguments sound crazy.

You admit you're not a Windows developer. Have you considered the
possibility that you're simply mistaken?

> If you were developing comerical
> applications on the Windows platform, whether VC++ is standard
> compliant or not is least of your problem. VC++ is mostly like your
> only reasonable choice if you care for the life cycle of your project.
[...]
> It's extremely important to have an industry standard. But if
> you were on Windows, you are already confined by Microsoft.
> their non-compliant VC++ is least of your problem.  In addition,
> because VC++ is dominating Windows C++ development market,
> whether VC++ is ISO compliant or not is not important because
> cross-compiler portability is next to none existen.

Even if I accepted your arguments -- and I do not -- there would still
be the issue of code developed for multiple platforms.

> Wow! How would you do that?  Use only subset of C++, never
> make any operating system calls, use only C/C++ standard
> library calls, never use printf() or str*() functions, and is character
> base?  Or did you write them in C without any Win32 calls?

The same way as any other multiple-platform system. Isolate your system-
dependent sections. Put all your Windows-specific code in one module;
use the same interface for another module with all your Mac-specific
code, and yet another for all your X-Window specific code. The same
thing would apply for different databases, by the way. The rest of the
code -- the parts that actually have the application logic -- can be
shared.

> > > If you were developing in Unix platforms,  I would agree that
> > > you need standard compliant compilers. With Microsoft, you
> > > have only one source for your operating system, namely
> > > Microsoft, and only one source for compilers (again, Microsoft).

Read the FAQ. There are quite a few sources for C++ compilers. Some of
them are free -- Microsoft compilers are definately NOT free.

> > > My point is, your Windows applicaton cannot be compiled
> > > outside of Windows,

> > false, I have several applications usable in both Windows and Unix. (Same
> > code, different build scripts ).

> Are they character based, use only C/C++ standard library
> calls (excluding str*(), printf*()) and never make any
> operating system calls?  Or do you use 3rd party libraries,
> such as RogueWave, heavily?  Did you spend a lot of time
> to learn and figure out how to use those libraries, too?

C++ doesn't define a standard window system anywhere, so no matter
what your GUI platform is, this is going to be your tradeoff: either
use the lowest-common denominator (some sort of text window), or
use a 3rd-party library, or write your own library using OS-specific
modules.

Are you suggesting that this does not apply on other GUIs? That
somehow when you're on Unix, the C++ standard gets extended in
ways that Microsoft developers don't know about?

> > > As a result, whether MSVC++ is
> > > standard compliant or not is complete not important. Besides,
> > > because VC++ is not compliant, anyone who wants to sell
> > > a C++ compiler to the Windows platform has to implement
> > > some sort of VC++ compatibility any way.
> >
> > Could you please elaborate on last statement ? Makes complete nonsense
> > (linkage has nothing to do with C++).
>
> I mean the MS specific extensions to the C++ language. To the
> extend that some Unix C++ compilers start supporting some of
> those MS extensions.  it's not a completely bad thing in my opinion.

The MS-specific extensions are extensions, and not every program needs
them. You can use them to good advantage, or not.

For example, the C++ standard cannot talk about such things as Dynamic
Load Libraries. If you choose not to write DLL's for your application,
you don't need the MS-specific extensions that apply to them. If you
decide that you DO want to use user-written DLL's, you can either let
your code be locked into Microsoft technology and then whine about how
none of the other compilers are compatible(*), or you can find a way
to isolate this dependency in the MS-specific module. (In extreme
cases you might need to use the preprocessor -- but this too is part
of standard C++).

(*) AFAIK, all of the C++ compilers for Windows DO support creating
DLLs.

Just because Microsoft gives you a way to do something nonstandard,
doesn't automatically mean you can't do it the standard way.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Shao Wu wrote:
>
> "James Russell Kuyper Jr." wrote:
>
> > Shao Wu wrote:
....
> > > Wow! How would you do that?  Use only subset of C++, never
> > > make any operating system calls, use only C/C++ standard
> > > library calls, never use printf() or str*() functions, and is character
> > > base? Or did you write them in C without any Win32 calls?
> >
> > That sounds like most of the code I write. Well, not quite; I make
> > extensive use of a few third party libraries. However, the combination
> > of my code plus the source code for those libraries fits all of those
> > restrictions, except the ones about str*() - why do you consider those a
> > problem? The result is portable anywhere those libraries can be
> > installed, which includes all three of those operating systems.
> >
>
> Ken has pointed out some problems with str*() function.
> In addition, str*() functions are too ASCII centric and not
> work well with other  [human] languages and locales.
> Win32 is using Unicode as its "native" character set, and
> str*() is not native in W2k and XP.

Most of the text strings I work with are read and written from files,
and those files are supposed to store those strings as 8-bit bytes using
an ASCII encoding. My code would therefore be incorrect if it used
specifically Unicode-oriented functions.

It might seem, therefore, that it would also be incorrect to port my
code to a platform where 'char' was not represented by an 8-bit bytes
with an ASCII encoding. However, one of the third party libraries I
mentioned is responsible for converting native data types to and from
the fixed platform-independent representation used in the files
themselves. If that library can be ported to a given platform, then my
code can be ported there as well. If my code passes it a char array,
that third-party library is responsible for translating that array into
8-bit bytes encoded in ASCII before writing it to the file, regardless
of what the native representation of 'char' is on that platform; it does
the reverse translation on reading from the file.

If I actually needed to store Unicode (which is not likely to happen),
I'd use arrays of  'int16' or 'int32', depending upon which version of
Unicode I was storing. 'int16' and 'int32' are typedefs established by
that library to identify native types which are big enough to store the
contents that, in the files, are represented as 16 bit and 32 bit
(littleendian?) 2's complement signed integers, respectively.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ken Hagan wrote:

> "Shao Wu" <swu00@earthlink.net> wrote ...
> >
> > My point is, your Windows applicaton cannot be compiled
> > outside of Windows, and you don't have any more choices
> > for compilers either.
>
> Not true, but I shall refrain from giving an incomplete list.
>

Like Borland, gcc, Intel? Borland is more likely happy
to sell a compiler in the $49 - $99 market, and hope to be
able to sell the same compiler for a lot more to enterprises.
I'm not sure how long would it take for Intel to realize
that there is no market (too small?) for its compiler.

>
> > Perhaps, people
> > should wake up and accept Microsoft is the standard in the
> > Windows World.  If you want to get out of that, try Linux + gcc.
>
> So you've heard of gcc? Have you tried the Windows version?
>

Can you compile and link with VC++ generated libraries?
It must be fun to debug Win32 GUI app with gdb. Do you
hand craft those resources files, too?  If you
were to develop something for real in Windows, you would
be much better off to cut back on you lunch money and save
enough money for a VC++.   The non-compliant VC++ is
least of your problem.

Shao

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Frode.Nilsen@mison.no wrote:

> In article <3D73D047.E732BB9C@earthlink.net>, swu00@earthlink.net (Shao
> Wu) wrote:
>
> This post might seem offensive, but I think this has gone to far. A
> compliance violation is a violation, no excuses exist.
> You can not claim 100% compliance, and be 99.9%. You can claim compliance
> with specified exceptions, and handle the rest as bugs.
> If these principles don't stand, why should we bother with a standard ?

I know my arguments sound crazy. If you were developing comerical
applications on the Windows platform, whether VC++ is standard
compliant or not is least of your problem. VC++ is mostly like your
only reasonable choice if you care for the life cycle of your project.

It is true that there are a handful other compilers out there for Windows.
If I were to choose a compiler for my projects (I'm not a Windows
developer, by the way), I would worry very much how long those
"3rd party" compilers would last: small shops could shut their doors,
and compilers from big name companys could get dumped.

It's extremely important to have an industry standard. But if
you were on Windows, you are already confined by Microsoft.
their non-compliant VC++ is least of your problem.  In addition,
because VC++ is dominating Windows C++ development market,
whether VC++ is ISO compliant or not is not important because
cross-compiler portability is next to none existen.

>
>
> >
> > Why bother with standard compliant when you are developing
> > in the Microsoft world? So that you can port your code from
> > Windows NT to Windows XP without source code modifcation
> > using the Microsoft compiler?
> >
>
> ??? You bother because you want to use your functions on both Windows, Mac
> and Unix. Because as a developer you don't want to look in on any
> particular platform, but have code that just continue to work.

Wow! How would you do that?  Use only subset of C++, never
make any operating system calls, use only C/C++ standard
library calls, never use printf() or str*() functions, and is character
base?  Or did you write them in C without any Win32 calls?

>
>
> > If you were developing in Unix platforms,  I would agree that
> > you need standard compliant compilers. With Microsoft, you
> > have only one source for your operating system, namely
> > Microsoft, and only one source for compilers (again, Microsoft).
>
> Both MetroWerks and Borland have good compilers for Windows.

And Intel, too.  Only time would help Intel to realize that
they can't sell anything to compete with M$.

>
> > It is true that there is a tiny shop called Borland (still in
> > business?) still selling a C++ compiler.  How many companies
> > still use Borland compilers?
> >
>
> Several. Where you one of those consultants that used months producing
> applications with VC++ when you could have used days with C++ builder ?
> (This is fact, not marketing. BTW IBM's VisualAge for C++ was even better,
> but for some unknown reason they killed it.).

No kidding!  Because IBM is such a big fish not happy to be  the
5th or 6th biggest compiler vendor competing in the remaining
1% of Windows development tools market where everyone is only
welling to spend $49 to $99 for a compiler?

> > My point is, your Windows applicaton cannot be compiled
> > outside of Windows,
>
> false, I have several applications usable in both Windows and Unix. (Same
> code, different build scripts ).

Are they character based, use only C/C++ standard library
calls (excluding str*(), printf*()) and never make any
operating system calls?  Or do you use 3rd party libraries,
such as RogueWave, heavily?  Did you spend a lot of time
to learn and figure out how to use those libraries, too?

>
> > and you don't have any more choices
> > for compilers either.
>
> false, there are several other C++ compiler vendors in the Windows world.

Therefore, Microsoft is not a monopoly? ;-)

>
> > As a result, whether MSVC++ is
> > standard compliant or not is complete not important. Besides,
> > because VC++ is not compliant, anyone who wants to sell
> > a C++ compiler to the Windows platform has to implement
> > some sort of VC++ compatibility any way.
>
> Could you please elaborate on last statement ? Makes complete nonsense
> (linkage has nothing to do with C++).
>

I mean the MS specific extensions to the C++ language. To the
extend that some Unix C++ compilers start supporting some of
those MS extensions.  it's not a completely bad thing in my opinion.

Regards,
Shao

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Shao Wu wrote:
>
> Frode.Nilsen@mison.no wrote:
....
> > ??? You bother because you want to use your functions on both Windows, Mac
> > and Unix. Because as a developer you don't want to look in on any
> > particular platform, but have code that just continue to work.
>
> Wow! How would you do that?  Use only subset of C++, never
> make any operating system calls, use only C/C++ standard
> library calls, never use printf() or str*() functions, and is character
> base? Or did you write them in C without any Win32 calls?

That sounds like most of the code I write. Well, not quite; I make
extensive use of a few third party libraries. However, the combination
of my code plus the source code for those libraries fits all of those
restrictions, except the ones about str*() - why do you consider those a
problem? The result is portable anywhere those libraries can be
installed, which includes all three of those operating systems.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

""James Russell Kuyper Jr."" <kuyper@wizard.net> wrote in message
news:3D7A99D0.60FB9A8E@wizard.net...
>
> That sounds like most of the code I write. Well, not quite; I make
> extensive use of a few third party libraries. However, the combination
> of my code plus the source code for those libraries fits all of those
> restrictions, except the ones about str*() - why do you consider those
a
> problem? The result is portable anywhere those libraries can be
> installed, which includes all three of those operating systems.

str*() are a problem because it is far too easy to (a) not check the
buffer length, (b) when using the checked versions, accidentially use
the wrong buffer length, and (c) when using the checked versions and the
correct buffer length, forget that the edge case leaves you with a
non-null-terminated C-string.

Ken


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ken Alverson wrote:
>
> ""James Russell Kuyper Jr."" <kuyper@wizard.net> wrote in message
> news:3D7A99D0.60FB9A8E@wizard.net...
> >
> > That sounds like most of the code I write. Well, not quite; I make
> > extensive use of a few third party libraries. However, the combination
> > of my code plus the source code for those libraries fits all of those
> > restrictions, except the ones about str*() - why do you consider those
> a
> > problem? The result is portable anywhere those libraries can be
> > installed, which includes all three of those operating systems.
>
> str*() are a problem because it is far too easy to (a) not check the
> buffer length, (b) when using the checked versions, accidentially use
> the wrong buffer length, and (c) when using the checked versions and the
> correct buffer length, forget that the edge case leaves you with a
> non-null-terminated C-string.

Well, misuse of the str*() functions can cause problems on any platform.
In itself it's not a portability issue. There's no incorrectly used
str*() functions in my code. Some of the third-party library code isn't
as clean as it should be, but mine's clean.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Russell Kuyper Jr." wrote:

> Shao Wu wrote:
> >
> > Frode.Nilsen@mison.no wrote:
> ....
> > > ??? You bother because you want to use your functions on both Windows, Mac
> > > and Unix. Because as a developer you don't want to look in on any
> > > particular platform, but have code that just continue to work.
> >
> > Wow! How would you do that?  Use only subset of C++, never
> > make any operating system calls, use only C/C++ standard
> > library calls, never use printf() or str*() functions, and is character
> > base? Or did you write them in C without any Win32 calls?
>
> That sounds like most of the code I write. Well, not quite; I make
> extensive use of a few third party libraries. However, the combination
> of my code plus the source code for those libraries fits all of those
> restrictions, except the ones about str*() - why do you consider those a
> problem? The result is portable anywhere those libraries can be
> installed, which includes all three of those operating systems.
>

Ken has pointed out some problems with str*() function.
In addition, str*() functions are too ASCII centric and not
work well with other  [human] languages and locales.
Win32 is using Unicode as its "native" character set, and
str*() is not native in W2k and XP.

Shao

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Shao Wu <swu00@earthlink.net> wrote:

> Why bother with standard compliant when you are developing
> in the Microsoft world? So that you can port your code from
> Windows NT to Windows XP without source code modifcation
> using the Microsoft compiler?

When I'm writing code to run on a specific platform, I can work around
the deficiencies of the available compiler, not without some grumbling
along the way.  But I want to compile more than just the code I write
myself.  I also want to compile and use code written by other people,
not necessarily for that compiler or that platform: things like the
Boost libraries, for example, or code licensed from a third party.
That's when a compiler that doesn't support the current standard becomes
a problem.

--
Jim Janney

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

clamage@eng.sun.com (Steve Clamage) wrote in message
news:<Pine.SOL.4.33.0209041419070.20777-100000@taumet>...
> James Kanze wrote:

> > And Sun had a Web page claiming 100% compliance at an epoch when
> > they didn't even support member templates.

> Unfortunately, the marketing departments at many companies, including Sun,
> tend to make public statements without clearing them with engineering
> for accuracy.

I know.  That was exactly the point I was trying to make.  I didn't mean
to criticize Sun in particular, only to point out that the criticisms
levied against a certain other company were perhaps somewhat exagerated,
in the sense that that's the way things are, they aren't likely to
change, and if you count on a compiler being 100% compilant and without
any bugs, just because some marketing dude put a statement to that
effect in a Web page, you're not doing your homework.

> When I found out about incorrect claims on Sun's web pages, I took
> steps to get them corrected. But the same incorrect claims get
> propagated to many places and have to be cleaned up one by one. :-(

I know, and it is to Sun's honour that they did listen to you.  (It's a
shame that they don't do the same with Java, or that no one in their
Java group is as conscientious as you about it.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

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

Francis Glassborow wrote:

> In article <3D73D047.E732BB9C@earthlink.net>, Shao Wu
> <swu00@earthlink.net> writes
> >My point is, your Windows applicaton cannot be compiled
> >outside of Windows, and you don't have any more choices
> >for compilers either.  As a result, whether MSVC++ is
> >standard compliant or not is complete not important. Besides,
> >because VC++ is not compliant, anyone who wants to sell
> >a C++ compiler to the Windows platform has to implement
> >some sort of VC++ compatibility any way. Perhaps, people
> >should wake up and accept Microsoft is the standard in the
> >Windows World.  If you want to get out of that, try Linux + gcc.
>
> But there are many people who want to develop software that can be
> compiled to execute on both Windows platforms and other ones.

Like Windows 95, Windows 98, Windows ME, Windows NT,
Windows 2000, Windows XP, and their Pro Editions, Home Editions,
Enterprise Editions?  I understand.  It's very important to be able
to develop code that is portable.  Have you heard of VC++? ;-)

If you want to develop code that is portable to Unix/Linux,
you have much bigger problems than the non-compliant
C++ compiler.


> If I just wanted to develop software for Windows, I might just as well us
> VB
> (which, of course is incompatible with itself :) or C# (though that
> might well be available on other platforms as it has an ECMA standard)
>

That is my point; sort of. If you were developing in Windows,
your code is not portable without major efforts. VC++ is least
of your problems than other parts.

Regards,
Shao

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:

> And Sun had a Web page claiming 100% compliance at an epoch when they
> didn't even support member templates.

Do you mean a template member class inside a class
does not work with the Sun compiler? What version of the
compiler are you using?  It works fine for me with
Forte 6 Update 1 and Update 2 versions of the
compilers.

Shao

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:

> Gennaro Prota <gennaro_prota@yahoo.com> wrote
> > On Tue, 27 Aug 2002 12:14:55 CST, kanze@gabi-soft.de (James Kanze)
> > wrote:
> > >If we want compilers to be standard compliant, the only way is to make
> > >the suppliers aware that we consider standard compliance an important
> > >factor when choosing a compiler.
> >
> > But this would happen in an ideal world where "we" would be the people
> > that use compilers and have a good knowledge of the language.
> > Unfortunately, many of us work in environments where Visual C++ is
> > chosen because it's Microsoft and because "it's a C++ compiler". So,
> > it's understandable that one wants to be a little harsh when
> > commenting about it. Personally I could do an infinite list of things
> > that are not "fair" in the MS compiler, not least that /Za switch that
> > claims ANSI compliance. And in a not ideal world, as this one is, we
> > could also be in the embarrassing situation of being considered idiots
> > because the code that we correctly consider well-formed is rejected by
> > MSVC++ with the /Za switch or viceversa :-)
>
> I think that if most C++ compilers were standards-compliant, and Microsoft
> was not (in some important way), that there would be even more pressure
> than there is today to GET compliant.

Why bother with standard compliant when you are developing
in the Microsoft world? So that you can port your code from
Windows NT to Windows XP without source code modifcation
using the Microsoft compiler?

If you were developing in Unix platforms,  I would agree that
you need standard compliant compilers. With Microsoft, you
have only one source for your operating system, namely
Microsoft, and only one source for compilers (again, Microsoft).
It is true that there is a tiny shop called Borland (still in
business?) still selling a C++ compiler.  How many companies
still use Borland compilers?

My point is, your Windows applicaton cannot be compiled
outside of Windows, and you don't have any more choices
for compilers either.  As a result, whether MSVC++ is
standard compliant or not is complete not important. Besides,
because VC++ is not compliant, anyone who wants to sell
a C++ compiler to the Windows platform has to implement
some sort of VC++ compatibility any way. Perhaps, people
should wake up and accept Microsoft is the standard in the
Windows World.  If you want to get out of that, try Linux + gcc.

Shao

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3D73D047.E732BB9C@earthlink.net>, swu00@earthlink.net (Shao
Wu) wrote:

This post might seem offensive, but I think this has gone to far. A
compliance violation is a violation, no excuses exist.
You can not claim 100% compliance, and be 99.9%. You can claim compliance
with specified exceptions, and handle the rest as bugs.
If these principles don't stand, why should we bother with a standard ?

> Allan W wrote:
>
> > Gennaro Prota <gennaro_prota@yahoo.com> wrote
> > > On Tue, 27 Aug 2002 12:14:55 CST, kanze@gabi-soft.de (James Kanze)
> > > wrote:
> > > >If we want compilers to be standard compliant, the only way is to make
> > > >the suppliers aware that we consider standard compliance an important
> > > >factor when choosing a compiler.
> > >
> > > But this would happen in an ideal world where "we" would be the people
> > > that use compilers and have a good knowledge of the language.
> > > Unfortunately, many of us work in environments where Visual C++ is
> > > chosen because it's Microsoft and because "it's a C++ compiler". So,
> > > it's understandable that one wants to be a little harsh when
> > > commenting about it. Personally I could do an infinite list of things
> > > that are not "fair" in the MS compiler, not least that /Za switch that
> > > claims ANSI compliance. And in a not ideal world, as this one is, we
> > > could also be in the embarrassing situation of being considered idiots
> > > because the code that we correctly consider well-formed is rejected by
> > > MSVC++ with the /Za switch or viceversa :-)
> >
> > I think that if most C++ compilers were standards-compliant, and Microsoft
> > was not (in some important way), that there would be even more pressure
> > than there is today to GET compliant.
>
> Why bother with standard compliant when you are developing
> in the Microsoft world? So that you can port your code from
> Windows NT to Windows XP without source code modifcation
> using the Microsoft compiler?
>

??? You bother because you want to use your functions on both Windows, Mac
and Unix. Because as a developer you don't want to look in on any
particular platform, but have code that just continue to work.

> If you were developing in Unix platforms,  I would agree that
> you need standard compliant compilers. With Microsoft, you
> have only one source for your operating system, namely
> Microsoft, and only one source for compilers (again, Microsoft).

Both MetroWerks and Borland have good compilers for Windows.

> It is true that there is a tiny shop called Borland (still in
> business?) still selling a C++ compiler.  How many companies
> still use Borland compilers?
>

Several. Where you one of those consultants that used months producing
applications with VC++ when you could have used days with C++ builder ?
(This is fact, not marketing. BTW IBM's VisualAge for C++ was even better,
but for some unknown reason they killed it.).

> My point is, your Windows applicaton cannot be compiled
> outside of Windows,

false, I have several applications usable in both Windows and Unix. (Same
code, different build scripts ).

> and you don't have any more choices
> for compilers either.

false, there are several other C++ compiler vendors in the Windows world.

> As a result, whether MSVC++ is
> standard compliant or not is complete not important. Besides,
> because VC++ is not compliant, anyone who wants to sell
> a C++ compiler to the Windows platform has to implement
> some sort of VC++ compatibility any way.

Could you please elaborate on last statement ? Makes complete nonsense
(linkage has nothing to do with C++).

> Perhaps, people
> should wake up and accept Microsoft is the standard in the
> Windows World.  If you want to get out of that, try Linux + gcc.
>

Micro$oft defines the API in the Windows world, they are not the C++
*standard* in the Windows World.  ISO is the C++ standard in the (whole)
world. If a company sells a product claiming compliance that is not
compliant, the standardization authorty in that contry is responsible for
stopping/punishing that.


> Shao
>

frode

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Shao Wu" <swu00@earthlink.net> wrote ...
>
> My point is, your Windows applicaton cannot be compiled
> outside of Windows, and you don't have any more choices
> for compilers either.

Not true, but I shall refrain from giving an incomplete list.

> As a result, whether MSVC++ is
> standard compliant or not is complete not important.

MS apparently disagree with you. Perhaps they were worried
that the increased use and knowledge of high quality libraries
like boost was giving their customers a real incentive to drop a
compiler that couldn't use all of them.

> Besides, because VC++ is not compliant, anyone who wants
> to sell a C++ compiler to the Windows platform has to implement
> some sort of VC++ compatibility any way.

True, but one flick of the compiler option and they all disappear.

> Perhaps, people
> should wake up and accept Microsoft is the standard in the
> Windows World.  If you want to get out of that, try Linux + gcc.

So you've heard of gcc? Have you tried the Windows version?


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Shao Wu" <swu00@earthlink.net> wrote in message
news:3D73D047.E732BB9C@earthlink.net...
> Allan W wrote:
> Why bother with standard compliant when you are developing
> in the Microsoft world? So that you can port your code from
> Windows NT to Windows XP without source code modifcation
> using the Microsoft compiler?

Ease of porting is but a small factor in the importance of standards
compliance.

We use a complex language called C++ - NOT C++ for Windows or C++ for
Linux. The complexity is such that all programmers using this language
are able to benefit from the efforst and experience of others - STL,
Boost, Loki et al, plus the serious dicussion, characterisation and just
plain exploration which is conducted here and in c.l.c++.mod.

In short without a standard we are not using the same language; if we
are not using the same language how can we learn from each other?

Julian


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Shao Wu" <swu00@earthlink.net> skrev i meddelandet
news:3D73D047.E732BB9C@earthlink.net...
> Allan W wrote:
>
> > Gennaro Prota <gennaro_prota@yahoo.com> wrote
> > > On Tue, 27 Aug 2002 12:14:55 CST, kanze@gabi-soft.de (James Kanze)
> > > wrote:
> > > >If we want compilers to be standard compliant, the only way is to
make
> > > >the suppliers aware that we consider standard compliance an important
> > > >factor when choosing a compiler.
> > >
> > > But this would happen in an ideal world where "we" would be the people
> > > that use compilers and have a good knowledge of the language.
> > > Unfortunately, many of us work in environments where Visual C++ is
> > > chosen because it's Microsoft and because "it's a C++ compiler". So,
> > > it's understandable that one wants to be a little harsh when
> > > commenting about it. Personally I could do an infinite list of things
> > > that are not "fair" in the MS compiler, not least that /Za switch that
> > > claims ANSI compliance. And in a not ideal world, as this one is, we
> > > could also be in the embarrassing situation of being considered idiots
> > > because the code that we correctly consider well-formed is rejected by
> > > MSVC++ with the /Za switch or viceversa :-)
> >
> > I think that if most C++ compilers were standards-compliant, and
Microsoft
> > was not (in some important way), that there would be even more pressure
> > than there is today to GET compliant.
>
> Why bother with standard compliant when you are developing
> in the Microsoft world? So that you can port your code from
> Windows NT to Windows XP without source code modifcation
> using the Microsoft compiler?
>
> If you were developing in Unix platforms,  I would agree that
> you need standard compliant compilers. With Microsoft, you
> have only one source for your operating system, namely
> Microsoft, and only one source for compilers (again, Microsoft).

Yes, but what if you would like to move your amazing Linux application to
Windows?

Sorry, the compiler has some nifty .NET extensions, but it doesn't compile
your standard compliant code!

:-)


Bo Persson
bop2@telia.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3D73D047.E732BB9C@earthlink.net>, Shao Wu
<swu00@earthlink.net> writes
>My point is, your Windows applicaton cannot be compiled
>outside of Windows, and you don't have any more choices
>for compilers either.  As a result, whether MSVC++ is
>standard compliant or not is complete not important. Besides,
>because VC++ is not compliant, anyone who wants to sell
>a C++ compiler to the Windows platform has to implement
>some sort of VC++ compatibility any way. Perhaps, people
>should wake up and accept Microsoft is the standard in the
>Windows World.  If you want to get out of that, try Linux + gcc.

But there are many people who want to develop software that can be
compiled to execute on both Windows platforms and other ones. If I just
wanted to develop software for Windows, I might just as well us VB
(which, of course is incompatible with itself :) or C# (though that
might well be available on other platforms as it has an ECMA standard)

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

swu00@earthlink.net (Shao Wu) wrote in message
news:<3D73C543.BC14CA14@earthlink.net>...
> James Kanze wrote:

> > And Sun had a Web page claiming 100% compliance at an epoch when
> > they didn't even support member templates.

> Do you mean a template member class inside a class does not work with
> the Sun compiler? What version of the compiler are you using?  It
> works fine for me with Forte 6 Update 1 and Update 2 versions of the
> compilers.

I said had, not has.  Member templates work with current releases of Sun
CC.  If you tried them with Sun CC 5.0, however, you got a message:
"Sorry, not implemented".  And when Sun CC 5.0 appeared, the marketing
people put up a Web page claiming compliance.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

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

On 28 Aug 2002 17:50:28 GMT, kanze@gabi-soft.de (James Kanze) wrote:

>Gennaro Prota <gennaro_prota@yahoo.com> wrote in message
>news:<igdnmukqin4fheledfc94preuj8svuntsk@4ax.com>...

>> >If we want compilers to be standard compliant, the only way is to
>> >make the suppliers aware that we consider standard compliance an
>> >important factor when choosing a compiler.
>
>> But this would happen in an ideal world where "we" would be the people
>> that use compilers and have a good knowledge of the language.
>> Unfortunately, many of us work in environments where Visual C++ is
>> chosen because it's Microsoft and because "it's a C++ compiler".
>
>I'm quite aware that there are companies where "if it's Microsoft, we
>use it."  There are also companies where the reverse rules ; avoid
>Microsoft if at all possible.  Both attitudes are IMHO stupid.

And I agree.

>Judging from the job interviews I've had, such companies are a minority.
>Most companies have a complex selection process for compilers, which
>takes a number of factors into consideration.

That's how it should be.

[...]
>> And in a not ideal world, as this one is, we could also be in the
>> embarrassing situation of being considered idiots because the code
>> that we correctly consider well-formed is rejected by MSVC++ with the
>> /Za switch or viceversa :-)
>
>I'd say that if for whatever reason, you have to use compiler X, and you
>intentionally write code which doesn't work with it, just because the
>standard says you can, you're not very intelligent.  Or at least not
>very pratical.

Now it's you who are a bit harsh :-) Normally I'm not in this category
of people. Anyhow I can say that I write C++. If I read that the
compiler doesn't support, say, partial template specialization I will
not use it. Anyhow if I read that a feature is supported I expect it
to be really supported. In the case of MSVC++ there's a knowledge base
article (Q243451) that lists the main non-compliance issues (BTW when
a feature is not supported, it calls it a "bug", and maybe it's better
that I do not comment on this). What remains are the supported
features. But how are they supported?

For instance: default template arguments are "supported". If you
write:

template <class T = char, class U = std::char_traits<T> >
class X;

template <class T, class U>
class X {

  // ....
};

int main() {

    X <> x;

}

you have: "error C2984: 'X' : template parameters '' and '' do not
match"

BTW, I haven't found nothing in the MSDN that documents that bug (but
maybe I should have simply searched better) and the only solution was
to do some "do it yourself" and discover that it simply wants you to
repeat the default arguments on the definition. The time that I've
spent to find this is a cost for my employer. And we were lucky,
because judging from the error message we could have spent days to
find it out.

Another example, off the top of my head:

// with the /Za switch
//
typedef int x;

void f(double x)
{
}

warning C4224: nonstandard extension used : formal parameter 'x' was
previously defined as a type


- To compile this you need the /Ze switch (!) and then still get an
error:


#include <vector>

int main() {

    using std::vector;

    vector<int>::allocator_type alloc;
}


It wants std::vector<int>::allocator_type.
But weren't namespaces supported??


In practice MSVC++ is a weird dialect of C++. And the problem is that,
even if you want to learn it, you can only do that by experimentation.
It has often its own rules (like the "rule" about name hiding above)
and often I think we can't either talk of "rules" because they are too
intermixed with bugs. So it's not a problem of compliance, but of
quality.

Believe me. If you write something that goes just beyond a toy example
you'll spend more time to workaround compiler bugs than to write the
first version of the code. This gives me the impression of a really
low-quality compiler. Put this together with the fact that well-known
bugs remain uncorrected for years and you will have the strong feeling
that Microsoft claims you use the compiler as is, and that you have
nothing to complain. I want to emphasize that I'm not in the habit of
doing discussions like this, and that I'm commenting on a purely
technical ground. I wanted to explain why I commented on that "being
fair" that F. Glassborow brought up. I think Microsoft has already
proved its guilt. Now it has to demonstrate its innocence. Yes, we
should encourage it on its current track but also make clear that,
like st. Thomas, we won't just take its word.


Genny.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Gennaro Prota" <gennaro_prota@yahoo.com> wrote in message
news:nq6vmuclqrhskd5sbbae6vokkh1rm1e35l@4ax.com...

> In practice MSVC++ is a weird dialect of C++. And the problem is that,
> even if you want to learn it, you can only do that by experimentation.
> It has often its own rules (like the "rule" about name hiding above)
> and often I think we can't either talk of "rules" because they are too
> intermixed with bugs. So it's not a problem of compliance, but of
> quality.

As someone who regularly uses a number of C++ compilers to package
nontrivial code, I have to say that you can substitute damn near
any product name for MSVC++ above and get a true statement. (The
one notable exception is the EDG front end, which is extraordinarily
bug free and compliant.) IME, the qualitative *sense* that different
people get about the quality of different compilers is based on some
nonlinear function of how much they use each compiler and how kindly
disposed they are to the supplier.

> Believe me. If you write something that goes just beyond a toy example
> you'll spend more time to workaround compiler bugs than to write the
> first version of the code. This gives me the impression of a really
> low-quality compiler. Put this together with the fact that well-known
> bugs remain uncorrected for years and you will have the strong feeling
> that Microsoft claims you use the compiler as is, and that you have
> nothing to complain. I want to emphasize that I'm not in the habit of
> doing discussions like this, and that I'm commenting on a purely
> technical ground. I wanted to explain why I commented on that "being
> fair" that F. Glassborow brought up. I think Microsoft has already
> proved its guilt. Now it has to demonstrate its innocence. Yes, we
> should encourage it on its current track but also make clear that,
> like st. Thomas, we won't just take its word.

Now substitute <supplier name> for Microsoft and see previous statement.

Or you can be more tolerant of all players and notice that:

1) The draft C++ Standard changed steadily and rapidly for most of a
decade, making a moving target that kept everybody off balance.

2) Every supplier of C++ compilers suffers many pressures; standards
conformance is not always the greatest or most important one.

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



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

"alex" <alex_jin@smics.com> wrote in message
news:9fca20c0.0208250748.f13b4a1@posting.google.com...
> Most C++ compiler refer to ISO/IEC 14882:1998. But VC 6.0 and ISO/IEC
> 14882:1998 were all pubnished in 1998. So I wonder which ANSI/ISO C++
> standard VC 6.0 refer to?

None.

-cd


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Carl Daniel" <cpdaniel@pacbell.net> skrev i meddelandet
news:Ibva9.6153$sg1.619789609@newssvr13.news.prodigy.com...
> "alex" <alex_jin@smics.com> wrote in message
> news:9fca20c0.0208250748.f13b4a1@posting.google.com...
> > Most C++ compiler refer to ISO/IEC 14882:1998. But VC 6.0 and ISO/IEC
> > 14882:1998 were all pubnished in 1998. So I wonder which ANSI/ISO C++
> > standard VC 6.0 refer to?
>
> None.
>

:-)


Well, there is only one Standard, so there is not much choice.

The draft standard was available a year in advance, because it had to be
formally accepted by all parties involved, so the content was known a year
in advance.

>From another news group I also know that Microsofts Program Manager for C++
states that he was attending to at least some of the meetings of the
committee, so he had all info necessary to be compliant. Too bad they
decided to put their mayor efforts on C# instead.


Bo Persson
bop2@telia.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <cKva9.4287$e5.623567@newsb.telia.net>, Bo Persson
<bop2@telia.com> writes
>>From another news group I also know that Microsofts Program Manager for C++
>states that he was attending to at least some of the meetings of the
>committee, so he had all info necessary to be compliant. Too bad they
>decided to put their mayor efforts on C# instead.

Well let us be fair all round. MS were not present at enough meetings in
the mid 1990s to lose their voting rights. However that had nothing to
do with C# which was not under consideration at that time. Their efforts
at developing C# almost exactly coincide with their greatly increased
efforts to bring VC++ up to standard. We should also remember that
commercial pressures have affects on efforts to correct the errors of
the past.

I think it is much better to encourage MS on its current track than to
repeatedly condemn them for the past. As long as they keep going towards
standard conformance and eschew the concepts of activation that seem so
popular in other parts of the company I think we should be positive.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

alex_jin@smics.com (alex) wrote
> Most C++ compiler refer to ISO/IEC 14882:1998. But VC 6.0 and ISO/IEC
> 14882:1998 were all pubnished in 1998. So I wonder which ANSI/ISO C++
> standard VC 6.0 refer to?

Not 100% sure I understand your question, but...

So far, there's only been one ANSI or ISO standard C++. As far as I
know, Microsoft never claimed that Visual C++ version 6.0 was 100%
compliant with it. It does implement many of the features that were
relatively new in 1998.

(Is it fair to say that VC6 was pretty close to 100% compliant with
everything except the way it handled templates? I don't think so,
but I can't think of anything else off-hand.)

I believe that Microsoft claims that their newest C++ compiler,
Visual C++ .Net version 2002, is much CLOSER to compliant, and their
next one will be closer still. AFAIK, they're not claiming that even
that next one will achieve 100% compliance.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
news:<qecfT5A4sqa9Ew4o@robinton.demon.co.uk>...

>                                       We should also remember that
> commercial pressures have affects on efforts to correct the errors of
> the past.

I think that Francis has hit on a key point, and not just for Microsoft.
The primary goal of all of the compiler suppliers is not to standard
compliant, it is to sell compilers, or to get people to use their
compiler.  Standard compliance is a means to help achieve that goal.  It
isn't a sufficient means, and in some cases, it may not even be a
necessary means -- if implementing export means that the compiler will
run 100 times more slowly, then I think most people would prefer the
compiler without export.  (I don't think that this is the case.  I just
made up an example.)

If we want compilers to be standard compliant, the only way is to make
the suppliers aware that we consider standard compliance an important
factor when choosing a compiler.  Insist that the compiler support UCN,
for example, or has a wide range of locales.

Personally, I would also insist that it respected other standards as
well: wchar_t should use ISO 10646, the compiler should support Posix
(threads, sockets, etc.) and so on.

> I think it is much better to encourage MS on its current track than to
> repeatedly condemn them for the past. As long as they keep going
> towards standard conformance and eschew the concepts of activation
> that seem so popular in other parts of the company I think we should
> be positive.

Quite.  We should also be understanding when they (or anyone else)
chooses to have other goals (like not breaking existing code) as well.
The world is full of compromises.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

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

On Tue, 27 Aug 2002 12:14:55 CST, kanze@gabi-soft.de (James Kanze)
wrote:

>Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
>news:<qecfT5A4sqa9Ew4o@robinton.demon.co.uk>...
>
>>                                       We should also remember that
>> commercial pressures have affects on efforts to correct the errors of
>> the past.
>
>I think that Francis has hit on a key point, and not just for Microsoft.
>The primary goal of all of the compiler suppliers is not to standard
>compliant, it is to sell compilers, or to get people to use their
>compiler.  Standard compliance is a means to help achieve that goal.  It
>isn't a sufficient means, and in some cases, it may not even be a
>necessary means -- if implementing export means that the compiler will
>run 100 times more slowly, then I think most people would prefer the
>compiler without export.  (I don't think that this is the case.  I just
>made up an example.)
>
>If we want compilers to be standard compliant, the only way is to make
>the suppliers aware that we consider standard compliance an important
>factor when choosing a compiler.


But this would happen in an ideal world where "we" would be the people
that use compilers and have a good knowledge of the language.
Unfortunately, many of us work in environments where Visual C++ is
chosen because it's Microsoft and because "it's a C++ compiler". So,
it's understandable that one wants to be a little harsh when
commenting about it. Personally I could do an infinite list of things
that are not "fair" in the MS compiler, not least that /Za switch that
claims ANSI compliance. And in a not ideal world, as this one is, we
could also be in the embarrassing situation of being considered idiots
because the code that we correctly consider well-formed is rejected by
MSVC++ with the /Za switch or viceversa :-)


Genny.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gennaro Prota <gennaro_prota@yahoo.com> wrote in message
news:<igdnmukqin4fheledfc94preuj8svuntsk@4ax.com>...
> On Tue, 27 Aug 2002 12:14:55 CST, kanze@gabi-soft.de (James Kanze)
> wrote:
> >Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
> >news:<qecfT5A4sqa9Ew4o@robinton.demon.co.uk>...

> >>                                       We should also remember that
> >> commercial pressures have affects on efforts to correct the errors of
> >> the past.

> >I think that Francis has hit on a key point, and not just for
> >Microsoft.  The primary goal of all of the compiler suppliers is not
> >to standard compliant, it is to sell compilers, or to get people to
> >use their compiler.  Standard compliance is a means to help achieve
> >that goal.  It isn't a sufficient means, and in some cases, it may
> >not even be a necessary means -- if implementing export means that
> >the compiler will run 100 times more slowly, then I think most people
> >would prefer the compiler without export.  (I don't think that this
> >is the case.  I just made up an example.)

> >If we want compilers to be standard compliant, the only way is to
> >make the suppliers aware that we consider standard compliance an
> >important factor when choosing a compiler.

> But this would happen in an ideal world where "we" would be the people
> that use compilers and have a good knowledge of the language.
> Unfortunately, many of us work in environments where Visual C++ is
> chosen because it's Microsoft and because "it's a C++ compiler".

I'm quite aware that there are companies where "if it's Microsoft, we
use it."  There are also companies where the reverse rules ; avoid
Microsoft if at all possible.  Both attitudes are IMHO stupid.

Judging from the job interviews I've had, such companies are a minority.
Most companies have a complex selection process for compilers, which
takes a number of factors into consideration.  In such cases, it is
usually possible to push for standards conformance to be one of those
factors.  It is impossible, of course, for it to be the only factor,
which is as it should be.

On the whole, VC++ has had an acceptable level of compliance, at least
when compared with other compilers in other environments.  VC++ 6.0, or
even 5.0, for example, was far more compliant than g++ 2.95.2.  (I've
not had a chance to try VC++ 7.0, so I can't compare with g++ 3.1 or
later.)  If I add features like support for threads that, while not
covered by the standard, are necessary for many applicatons, VC++ shows
up even better.  So that while I think that until recently, standards
compliance wasn't of major importance at Microsoft, at least at the
official level, they weren't too far off anyway.  (More likely it was
simply a case of the others being so much worse, than anything positive
Microsoft was doing:-).)

> So, it's understandable that one wants to be a little harsh when
> commenting about it. Personally I could do an infinite list of things
> that are not "fair" in the MS compiler, not least that /Za switch that
> claims ANSI compliance.

And Sun had a Web page claiming 100% compliance at an epoch when they
didn't even support member templates.

The only C++ compiler available today which is anywhere near compliance
is Comeau.  If you aren't aware of this, then you really aren't too much
aware of what is going on in the C++ world.

If you do have the occasion to actively participate in the choice of a
compiler, you should not fail to obtain one (or more) of the commercial
test suites, and use it.  Eliminating, of course, the tests for features
you don't need (trigraphs, anyone).  And adding a number of tests of
your own for non-standard features that you do need.

You then treat the results of this test as ONE critera in the
evaluation.  You will also want to consider things like optimization,
ease of use, support, availability of people familiar with the
compiler...  Management will probably also insist on your considering
price, although from what I've seen, the price differences aren't large
enough to be worth considering.

> And in a not ideal world, as this one is, we could also be in the
> embarrassing situation of being considered idiots because the code
> that we correctly consider well-formed is rejected by MSVC++ with the
> /Za switch or viceversa :-)

I'd say that if for whatever reason, you have to use compiler X, and you
intentionally write code which doesn't work with it, just because the
standard says you can, you're not very intelligent.  Or at least not
very pratical.

Again, lobby for compliance, but do be aware that it isn't the only
factor which must be considered.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

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

Gennaro Prota <gennaro_prota@yahoo.com> wrote
> On Tue, 27 Aug 2002 12:14:55 CST, kanze@gabi-soft.de (James Kanze)
> wrote:
> >If we want compilers to be standard compliant, the only way is to make
> >the suppliers aware that we consider standard compliance an important
> >factor when choosing a compiler.
>
> But this would happen in an ideal world where "we" would be the people
> that use compilers and have a good knowledge of the language.
> Unfortunately, many of us work in environments where Visual C++ is
> chosen because it's Microsoft and because "it's a C++ compiler". So,
> it's understandable that one wants to be a little harsh when
> commenting about it. Personally I could do an infinite list of things
> that are not "fair" in the MS compiler, not least that /Za switch that
> claims ANSI compliance. And in a not ideal world, as this one is, we
> could also be in the embarrassing situation of being considered idiots
> because the code that we correctly consider well-formed is rejected by
> MSVC++ with the /Za switch or viceversa :-)

I think that if most C++ compilers were standards-compliant, and Microsoft
was not (in some important way), that there would be even more pressure
than there is today to GET compliant.

The people that make the buying decisions might not always understand
what it is that they're buying. But if the programmers say, "all of these
other compilers are okay, but not Microsoft," this is something that
buyers will understand. And Microsoft knows this.

On the other hand, if the only problems with Microsoft all have trivial
workarounds (no variables named "far" or "near"), then the pressure
would be significantly less.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Most C++ compiler refer to ISO/IEC 14882:1998. But VC 6.0 and ISO/IEC
14882:1998 were all pubnished in 1998. So I wonder which ANSI/ISO C++
standard VC 6.0 refer to?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]