We have a standard!
Steve Clamage
>On 21 Jul 98 06:03:43 GMT, a...@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...@sun.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Thomas A. Horsley
>of Standard C++ (it feels good to be able to write that phrase)
>to best advantage.
No!, No!, No! Now we have to start on the *next* C++ standard :-).
We need persistent object support! (or at least compiler support to
simplify
"marshalling" and "unmarshalling").
We need garbage collection!
We need compiler support for threads!
See, your work is never done :-).
--
>>==>> The *Best* political site <URL:http://www.vote-smart.org/> >>==+
email: Tom.H...@worldnet.att.net icbm: Delray Beach, FL |
<URL:http://home.att.net/~Tom.Horsley> Free Software and Politics <<==+
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Eric Lemings
> 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...@sun.com
Anyone care to name some names and an estimate of
the implementation's level of conformance?
Eric.
ka...@my-dejanews.com
Tom.H...@worldnet.att.net (Thomas A. Horsley) wrote:
> >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.
>
> No!, No!, No! Now we have to start on the *next* C++ standard :-).
>
> We need persistent object support! (or at least compiler support to
> simplify
> "marshalling" and "unmarshalling").
>
> We need garbage collection!
>
> We need compiler support for threads!
We need Java! :-)
(Seriously, I'm sure that one could create the same sort of list for
Java. For some strange reason, a language is always too big, but always
lacks some feature we need.)
--
James Kanze +33 (0)1 39 23 84 71 mailto: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@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
ka...@my-dejanews.com
Eric Lemings <eric.b....@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...@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: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@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++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Jon Pearson
>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
David Kastrup
> 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: d...@neuroinformatik.ruhr-uni-bochum.de Fax:
+49-234-709-4209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum,
Germany
Thaddeus L. Olczyk
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.
Ashley Fryer
olc...@interaccess.com says...
>
> 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.
>
Could you be more specific about the problems you see in VC++?
I use VC5 ( not MFC ) and have followed the standard for years. My
experience has been that although not fully conformant, VC is at least as
close as any alternative. What are you seeing that I don't?
Regards,
ashley
---
Mark Wilden
<35ba433b...@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.
Tony
> wrote:
> >Does anyone know if the next version of VC++ will be any closer to the
> >standard?
> new featurs which will make managers happy but force us to write
> 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
Patrick Wray
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?
Francis Irving
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: fra...@pobox.co.uk Web: www.meta.demon.co.uk
---
ka...@my-dejanews.com
anthonN...@idt.net (Tony) wrote:
> In article <35ba433b...@nntp.interaccess.com>,
> olc...@interaccess.com says...
> > On 25 Jul 1998 00:29:34 GMT, "Jon Pearson" <pea...@ccdc.cam.ac.uk>
> > wrote:
> > >Does anyone know if the next version of VC++ will be any closer to the
> > >standard?
> > 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.
>
> 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: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@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
James Kuyper
>
> On 25 Jul 1998 00:29:34 GMT, "Jon Pearson" <pea...@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.
Mark Wilden
>
be
>tainted with (bundled with) proprietary technologies?
I'd never complain about any technology, proprietary or not, that
makes me more productive. If it doesn't, I simply won't use it. C++ is
just one tool of many.
Herb Sutter
>Tony wrote in message ...
>>Do I hear some agreement here that ANSI/ISO C++ compilers should not be
>>bandwagon). A movement anyone? :)
>
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:he...@cntc.com)
Current Network Technologies Corp 2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com Mississauga Ontario Canada L5K 2N6
All...@my-dejanews.com
olc...@interaccess.com (Thaddeus L. Olczyk) wrote:
> On 25 Jul 1998 00:29:34 GMT, "Jon Pearson" <pea...@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
David A. Cuthbert
Tony <anthonN...@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.
All...@my-dejanews.com
anthonN...@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
ni...@my-dejanews.com
>On 26 Jul 1998 01:11:51 GMT, olc...@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.
How about __declspec(property) for one (added in VC5.0 I guess, but it
illustrated the point ?)
Nick
-----== 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++-...@netlab.cs.rpi.edu for info ]
Christopher Eltschka
>
> In article <6p5m7g$p...@bgtnsc02.worldnet.att.net>,
> Tom.H...@worldnet.att.net (Thomas A. Horsley) wrote:
> > >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.
> >
> > No!, No!, No! Now we have to start on the *next* C++ standard :-).
> >
> > We need persistent object support! (or at least compiler support to
> > simplify
> > "marshalling" and "unmarshalling").
> >
> > We need garbage collection!
> >
> > We need compiler support for threads!
>
> We need Java! :-)
>
> (Seriously, I'm sure that one could create the same sort of list for
> Java. For some strange reason, a language is always too big, but always
> lacks some feature we need.)
Well, the ideal language would have just four or five keywords,
a simple syntax, a simple but exhaustive type system, but every
feature you can think of.
Of course it would allow procedural, functional, OO, ADT, and
spaghetti code programming; OTOH it would enforce the style you've
chosen, while at the same time allow mixing of styles if you
want to.
Probably it would include a system independant assembler, as well.
:-) ;-) 8-] !-} [:-)
ka...@my-dejanews.com
"Mark Wilden" <mwi...@sierratel.com> wrote:
> Thaddeus L. Olczyk wrote in message
> <35ba433b...@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.
>
> >new featurs which will make managers happy but force us to write
> >code which is written in an even poorer style of C++.
>
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: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@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
Tim Ottinger
> Francis:
> >What particular proprietary features?
>
> How about __declspec(property) for one (added in VC5.0 I guess, but it
> illustrated the point ?)
Ah, non-standard language features is different from nonstandard tech.
When the talk was about nonstandard technology, I thought that meant
libraries. I'm a little more prone toward saying "no language
extensions",
but still worry that it's too radical. As long as you are not required
to use nonstandard tech, it's okay. If you're required to use it, then
there's something not quite kosher.
Likewise, nobody should omit standard technology from a language
version.
For instance, choosing not to include the "platform" bits of Java...
;-)
tim
Stan Brown
ni...@my-dejanews.com (ni...@my-dejanews.com) wrote:
>
>>On 26 Jul 1998 01:11:51 GMT, olc...@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?
>
>How about __declspec(property) for one (added in VC5.0 I guess, but it
>illustrated the point ?)
Well, what about it? The Dec. 1996 draft standard said (section 2.10
paragraph 2), "... identifiers containing a double underscore ... are
reserved for use by C++ implementations and shall not be used otherwise;
no diagnostic is required."
Sounds to me like a C++ compiler vendor is free to define anything it
likes using "__" (not necessarily at the start of the identifier). Or am
I misreading the draft standard?
--
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.
John Burton
ni...@my-dejanews.com wrote in message
<6pjg2v$e97$1...@nnrp1.dejanews.com>...
>
>>On 26 Jul 1998 01:11:51 GMT, olc...@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?
>
>How about __declspec(property) for one (added in VC5.0 I guess, but it
>illustrated the point ?)
Well if you don't like it nobody if forcing you to use it so what's your
problem?
Frank A. Adrian
>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
fra...@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++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Mike Tiller
> (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
ka...@my-dejanews.com
> >
> > 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.
> >
>
>
> I use VC5 ( not MFC ) and have followed the standard for years. My
> experience has been that although not fully conformant, VC is at least as
> close as any alternative. What are you seeing that I don't?
I suspect the fact that Microsoft does add a lot of additional
"features"
to the standard, and that it is difficult to avoid them if you are
programming in a Windows environment.
Like you, I've found VC++ to be a pretty good compiler, and fairly
close to the standard, BUT... we've only been using it temporarily
to prototype the server, which doesn't use any windowing (other than
through CORBA), and we've been very careful to pay attention to
portability issues, since the final target is an AIX. Not everyone
is so lucky.
--
James Kanze +33 (0)1 39 23 84 71 mailto: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@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++-...@netlab.cs.rpi.edu for info ]
fv...@biotrack.com
phul...@DIESPAMDIEbmarket.com (Ashley Fryer) wrote:
>
>
> Could you be more specific about the problems you see in VC++?
>
> I use VC5 ( not MFC ) and have followed the standard for years. My
> experience has been that although not fully conformant, VC is at least as
> close as any alternative. What are you seeing that I don't?
>
> ashley
>
Amongst some of the non-conformant issues I have encountered, here is an
example, right from the CD2 draft, regarding partial specialization:
template<class T1, class T2, int I> class A { }; // #1
template<class T, int I> class A<T, T*, I> { }; // #2
template<class T1, class T2, int I> class A<T1*, T2, I> { }; // #3
template<class T> class A<int, T*, 5> { }; // #4
template<class T1, class T2, int I> class A<T1, T2*, I> { }; // #5
This does not compile, and produces the following errors:
...DllMain.cpp(224) : error C2989:
'A<`template-parameter-1',`template-parameter-1', ?? >' : template class
has
already been defined as a non-template class ...DllMain.cpp(225) : error
C2989: 'A<`template-parameter-1',`template-parameter-2', ?? >' :
template
class has already been defined as a non-template class
...DllMain.cpp(226) :
error C2989: 'A<int,`template-parameter-1',5>' : template class has
already
been defined as a non-template class ...DllMain.cpp(227) : error C2989:
'A<`template-parameter-1',`template-parameter-2', ?? >' : template class
has
already been defined as a non-template class
Is there some switch that needs to be turned on in VC5++ to get this to
compile properly? -fais
David R Tribble
>> 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? :)
All...@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, dtri...@technologist.com --
Robert O'Dowd
>
> In article <6pfkke$4i8$1...@usenet40.supernews.com>,
> "Mark Wilden" <mwi...@sierratel.com> wrote:
> > Thaddeus L. Olczyk wrote in message
> > <35ba433b...@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.
> >
> > >new featurs which will make managers happy but force us to write
> > >code which is written in an even poorer style of C++.
> >
>
> 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...@dsto.defence.gov.au
Rockingham, Western Australia, 6958
Disclaimer: Opinions above are mine and may be worth what you paid for
them
Scott Johnson
> > In article <35ba433b...@nntp.interaccess.com>,
> > olc...@interaccess.com says...
> > > wrote:
> > > >Does anyone know if the next version of VC++ will be any closer to the
> > > >standard?
> > > new featurs which will make managers happy but force us to write
> > > understand how they get away with writing "ANSI C++ " on
> > > their box and in their advertisements.
> >
> > tainted with (bundled with) proprietary technologies? (my humble
> > bandwagon). A movement anyone? :)
>
> 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
> 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
jhy...@my-dejanews.com
> >tainted with (bundled with) proprietary technologies? (my humble
> >bandwagon). A movement anyone? :)
> >
>
> 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
Tim Ottinger
> 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
Jon Pearson
>example, right from the CD2 draft, regarding partial specialization:
VC++ doesn't support partial specialization at all. There are other
deviations from the standard with templates - e.g. template conversion
operators don't work, or see the problem I posted recently about pointers to
template functions.
Gerhard Menzl
> 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++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Mike Tiller
> [posted and emailed]
>
> ni...@my-dejanews.com (ni...@my-dejanews.com) wrote:
> >
> >>On 26 Jul 1998 01:11:51 GMT, olc...@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?
> >
> >How about __declspec(property) for one (added in VC5.0 I guess, but
it
> >illustrated the point ?)
>
> Well, what about it? The Dec. 1996 draft standard said (section 2.10
> paragraph 2), "... identifiers containing a double underscore ... are
> reserved for use by C++ implementations and shall not be used
otherwise;
> no diagnostic is required."
>
> Sounds to me like a C++ compiler vendor is free to define anything it
> likes using "__" (not necessarily at the start of the identifier). Or
am
> I misreading the draft standard?
I think that quote is meant to prohibit the use of identifiers that
have double underscores because (for example) the compiler might use
double underscores in it namemangling. The "shall not be used
otherwise" I read as "source code is not allowed to contain them in
identifiers". In other words, they may appear (in the symbol table of
an object file) so don't use them (at all )to avoid conflict.
The "__declspec(property)" example (whatever it does) would seem to me
to violate the "shall not be used otherwise" clause because they
aren't being used in the C++ implementation (compiler internals) but
in the program source code.
That would be my reading of it.
> --
> Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
> http://www.concentric.net/%7eBrownsta/
--
Michael Tiller
Ford Motor Company
James Kuyper
>
> In article <6pfkke$4i8$1...@usenet40.supernews.com>,
> "Mark Wilden" <mwi...@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++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
ka...@my-dejanews.com
jhy...@my-dejanews.com wrote:
> In article <6phorq$jtq$1...@reader1.reader.news.ozemail.net>,
> "Patrick Wray" <pw...@ozemail.com.au> wrote:
> >
> > Tony wrote in message ...
> > >tainted with (bundled with) proprietary technologies? (my humble
> > >bandwagon). A movement anyone? :)
> > >
> >
> > 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: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@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++-...@netlab.cs.rpi.edu for info ]
ka...@my-dejanews.com
Mike Tiller <mti...@ford.com> wrote:
> ka...@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.)
>
> 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: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@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
All...@my-dejanews.com
jhy...@my-dejanews.com wrote:
> In article <6phorq$jtq$1...@reader1.reader.news.ozemail.net>,
> "Patrick Wray" <pw...@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++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Mark Wilden
>>
>> > 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!
ka...@my-dejanews.com
sj_n...@nospam.aracnet.com wrote:
> ka...@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
> > non-standard features. But only to interface the windowing system
> > itself, which is not covered by the C++ standard.)
>
> 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: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@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
ka...@my-dejanews.com
"Robert O'Dowd" <nos...@nonexistant.com> wrote:
> ka...@my-dejanews.com wrote:
> >
> > In article <6pfkke$4i8$1...@usenet40.supernews.com>,
> > "Mark Wilden" <mwi...@sierratel.com> wrote:
> > > <35ba433b...@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.
> > >
> > > >new featurs which will make managers happy but force us to write
> > > >code which is written in an even poorer style of C++.
> > >
> >
> > 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.)
Jason Merrill
> 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++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Dr Richard A. O'Keefe
> 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!
All...@my-dejanews.com
> > > >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" <mwi...@sierratel.com> wrote:
> > > Could you give an example in VC++ 5.0?
ka...@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...@nonexistant.com>,
"Robert O'Dowd" <nos...@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
All...@my-dejanews.com
dtri...@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.
Mike Ost & Martha Wade
>Could you be more specific about the problems you see in VC++?
Something that perhaps is more in the realm of an error came up in my
explorations of the cryptic stream classes. I was using an 'istream' and was
trying to copy a range of bytes from that to an 'ostream.' There is a method
called 'get' which can read bytes from a stream buffer. The docs say the
param is a basic_streambuf* but the implementation uses a reference. So I
had to throw a '*' in:
istream input;
ostream output;
...
// Copy over the client data. WHOA! Apparent MS STL implementation
// error. Docs refer to this param as a basic_streambuf*, but in
// "istream" it is defined as as reference. Other implementations
// may have to use input.get(output.rdbuf(), size), instead.
input.get(*output.rdbuf(), size);
This took me forever to figure out, trying to wade through all that cryptic
mish-mosh of the new C++ header files (templates are cool, but they make my
head ache and my eyes spin to try to figure out).
Alberto Barbati
<6pi7se$nmp$1...@nnrp1.dejanews.com>...
>example, right from the CD2 draft, regarding partial specialization:
>
>
>Is there some switch that needs to be turned on in VC5++ to get this to
>compile properly? -fais
Nope, VC5++ does not support partial specialization at all.
--
Alberto Barbati
Please remove ZZZ from my e-ddress when replying
ka...@my-dejanews.com
Mike Tiller <mti...@ford.com> wrote:
> brow...@concentric.net (Stan Brown) writes:
>
> > [posted and emailed]
> >
> > ni...@my-dejanews.com (ni...@my-dejanews.com) wrote:
> > >
> > >>On 26 Jul 1998 01:11:51 GMT, olc...@interaccess.com (Thaddeus L.
> > >>Olczyk) wrote:
> > >
> of
> > >>>new featurs which will make managers happy but force us to write
> > >>>understand how they get away with writing "ANSI C++ " on
> > >>>their box and in their advertisements.
> > >
> > >
> > >How about __declspec(property) for one (added in VC5.0 I guess, but
> it
> > >illustrated the point ?)
> >
> > Well, what about it? The Dec. 1996 draft standard said (section 2.10
> > paragraph 2), "... identifiers containing a double underscore ... are
> > reserved for use by C++ implementations and shall not be used
> otherwise;
> > no diagnostic is required."
> >
> > Sounds to me like a C++ compiler vendor is free to define anything it
> > likes using "__" (not necessarily at the start of the identifier). Or
> am
> > I misreading the draft standard?
>
> I think that quote is meant to prohibit the use of identifiers that
> have double underscores because (for example) the compiler might use
> double underscores in it namemangling. The "shall not be used
> otherwise" I read as "source code is not allowed to contain them in
> identifiers". In other words, they may appear (in the symbol table of
> an object file) so don't use them (at all )to avoid conflict.
>
> The "__declspec(property)" example (whatever it does) would seem to me
> to violate the "shall not be used otherwise" clause because they
> aren't being used in the C++ implementation (compiler internals) but
> in the program source code.
Read the standard, as quoted. It says clearly that symbols containing
a __ are reserved for the implementation. The implementation can do
whatever it wants with them.
The shall not be used otherwise obviously refers to "by the user", since
the clause immediately before it says that the implementation can use them.
If your code contains "__declspec(property)", then it is not conforming
C++ code; technically, it invokes undefined behavior. But precisely because
the behavior is undefined, an implementation is free to define it; your
use then becomes a means of invoking an implementation specific extension.
Of course, its use in the implementation headers is perfectly legal, since
they are part of the implementation.
--
James Kanze +33 (0)1 39 23 84 71 mailto: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@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++-...@netlab.cs.rpi.edu for info ]
jim.h...@leitch.com
Mike Tiller <mti...@ford.com> wrote:
> brow...@concentric.net (Stan Brown) writes:
> > Well, what about it? The Dec. 1996 draft standard said (section 2.10
> > paragraph 2), "... identifiers containing a double underscore ... are
> > reserved for use by C++ implementations and shall not be used
> otherwise;
> > no diagnostic is required."
> >
> > Sounds to me like a C++ compiler vendor is free to define anything it
> > likes using "__" (not necessarily at the start of the identifier). Or
> am
> > I misreading the draft standard?
>
> I think that quote is meant to prohibit the use of identifiers that
> have double underscores because (for example) the compiler might use
> double underscores in it namemangling. The "shall not be used
> otherwise" I read as "source code is not allowed to contain them in
> identifiers". In other words, they may appear (in the symbol table of
> an object file) so don't use them (at all )to avoid conflict.
>
> The "__declspec(property)" example (whatever it does) would seem to me
> to violate the "shall not be used otherwise" clause because they
> aren't being used in the C++ implementation (compiler internals) but
> in the program source code.
implementations and standard libraries..."
^^^^^^^^^^^^^^^^^^^^^^
meaning the STL can use double underscores, meaning source code can use double
underscores, meaning __declspec is a legal extension to the language.
It seems to me limiting the double underscore to internal use only is
unsatisfactory - compilers are required to implement certain features, with
only a general guide being provided by the Standard. In order to implement
some of those features, the compilers are going to *have* to use identifiers
*in the source code* (implementation details on the STL, for example). The
compiler vendors need a way to guarantee that their identifiers will not
conflict with your identifiers - specifying that identifiers containing
double underscores are reserved for compiler implementations is a reasonable
way to do this. It also gives you and me guidelines on how we can avoid
problems with identifiers, both now *and* with future releases of the
compiler.
Jim
ka...@my-dejanews.com
James Kuyper <kuy...@wizard.net> wrote:
> ka...@my-dejanews.com wrote:
> >
> > In article <6pfkke$4i8$1...@usenet40.supernews.com>,
> > "Mark Wilden" <mwi...@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.
>
> 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: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@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
Mark Wilden
> "Robert O'Dowd" <nos...@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.
ka...@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.
NF Stevens
>
>>On 26 Jul 1998 01:11:51 GMT, olc...@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.
>
>How about __declspec(property) for one (added in VC5.0 I guess, but it
>illustrated the point ?)
declspec is used in the gcc c compiler to specify the packing of
structures. It is hardly new and certainly not Microsoft specific.
Besides which it begins with two leading underscores which signifies
a compiler specific extension.
Norman
David Thornley
>> Tom.H...@worldnet.att.net (Thomas A. Horsley) wrote:
>> > >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.
>> >
As soon as our compiler vendors do. Metrowerks promised that their
compiler would be compliant with any approved standard, but I think
they meant that they needed to have it out by November or so.
Currently, you have to do some nonstandard stuff to use the STL
features properly, and they have a number of other compatibility
problems.
>> (Seriously, I'm sure that one could create the same sort of list for
>> Java. For some strange reason, a language is always too big, but always
>> lacks some feature we need.)
>
One solution is to try to make the language friendly to libraries.
For example, one can deal with various different sorts of numeric-
like things in C++ by defining an appropriate cast with appropriate
overloaded operators and such. There are limits, e.g. you can't have
more than three operators with multiplication precedence, but you
can still do a lot.
Stroustrup said that library design is language design, and the C++
language is very friendly towards integrating library features
into the language. (Almost all languages are somewhere between
COBOL and C++ on this.)
So, if you want persistent objects, garbage collection, or whatever
in the language, try to figure out how it would work, come up
with an interface, and implement it. Go for it! Try to make it
effective and generally useful, even if it has to be implemented
in different ways on different platforms, and give the committee
some prior art for the next go-around.
>Well, the ideal language would have just four or five keywords,
>a simple syntax, a simple but exhaustive type system, but every
>feature you can think of.
>Of course it would allow procedural, functional, OO, ADT, and
>spaghetti code programming; OTOH it would enforce the style you've
>chosen, while at the same time allow mixing of styles if you
>want to.
The surprising thing is that Common Lisp comes very close to this,
if you'll allow me to define "keyword" as something that is implemented
as a special form, rather than a macro or function.
Now, if you'd mentioned efficiency and usual footprint, you'd
tilt the balance a lot in favor of C++.
I think a good indication of Common Lisp vs. C++ thinking is
multi-methods - virtual functions that specialize on any
parameters, sort of an overload on the actual type of
parameters rather than the declared type. Stroustrup thought that
a really neat idea, but never came up with an efficient implementation.
The Lisp folks couldn't come up with an efficient implementation
either. It's in Common Lisp and not in C++.
>Probably it would include a system independant assembler, as well.
>:-) ;-) 8-] !-} [:-)
>
Those of us who were on comp.lang.c at a certain time want Scott
Nudds to come back as soon as he writes his Portable Assembler
- but not before!
--
David H. Thornley | These opinions are mine. I
da...@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly. O-
Christopher Eltschka
> >
> > ni...@my-dejanews.com (ni...@my-dejanews.com) wrote:
> > >
> > >>On 26 Jul 1998 01:11:51 GMT, olc...@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?
> > >
> it
> > >illustrated the point ?)
> >
> > paragraph 2), "... identifiers containing a double underscore ... are
> > reserved for use by C++ implementations and shall not be used
> otherwise;
> > no diagnostic is required."
> >
> > Sounds to me like a C++ compiler vendor is free to define anything it
> > likes using "__" (not necessarily at the start of the identifier). Or
> am
> > I misreading the draft standard?
>
> I think that quote is meant to prohibit the use of identifiers that
> have double underscores because (for example) the compiler might use
> double underscores in it namemangling. The "shall not be used
> otherwise" I read as "source code is not allowed to contain them in
> identifiers". In other words, they may appear (in the symbol table of
> an object file) so don't use them (at all )to avoid conflict.
So would you say that source code is not allowed to contain
__cplusplus, and therefore the following would be ill-formed?
#ifdef __cplusplus
extern "C"
{
#endif
void f(int);
#ifdef __cplusplus
}
#endif
This would make __cplusplus pretty useless...
ScottG...@my-dejanews.com
In article <6pncqi$mfe$1...@nnrp1.dejanews.com>,
ka...@my-dejanews.com wrote:
> In article <1998072812...@mailfw1.ford.com>,
> Mike Tiller <mti...@ford.com> wrote:
> > ka...@my-dejanews.com writes:
> >
> > 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.
I think that 'we' as a community should care how they do it. While the C++
standard does not define a window API, there are mechanisims for libraries and
including source. There are mechanisms that many compiler vendors have built
for shared objects/libs that do not require language extension, etc.
The statement "any C++ program which does windowing isn't
> conforming anyway" seems a little strange. That would imply that because
there was nothing in the standard for printing the Hello World to somewhere
then it must be a non-conforming program?
AFAIK I can write ANSI C X-Windows code, and can probably therefore write
conforming C++ code as well. (I can also compile it on NT if I want to.)
So can I have a 'standard' program that uses libraries only available on one
machine? I would think yes.
Can I have a 'standard' program that uses non-standard language extentions? I
would think no. (Then again one could argue that as long as the preprocessor
can strip out the offending bits, then it might well be a conforming program.)
So what is a 'conforming' program?
sdg
-----== 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++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
jim.h...@leitch.com
> 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
jim.h...@leitch.com
All...@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.
Mike Tiller
> In article <1998072812...@mailfw1.ford.com>,
> Mike Tiller <mti...@ford.com> wrote:
> > ka...@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
Christof Stadler
ka...@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++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Bryan Althaus
: sj_n...@nospam.aracnet.com wrote:
:> ka...@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++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Michel Pitermann
> 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 : mpi...@portia.psyc.queensu.ca
Tel: +1 - 613 - 545 6000 ext 5754 Fax: +1 - 613 - 545 2499
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
ka...@my-dejanews.com
o...@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.
From my experience with VC++, it is a conforming compiler, at least as
much as such can exist without a standard. It offers a number of
extensions, but you are not required to use them, unless, of course
you want to do something that is not supported by the langauge (like
open a window). And in such cases, you will have to use some sort
of an extension no matter what compiler you use.
> 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.
--
James Kanze +33 (0)1 39 23 84 71 mailto: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@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++-...@netlab.cs.rpi.edu for info ]
Doug Harrison
On 30 Jul 1998 11:05:06 -0400, ka...@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
dHar...@worldnet.att.net
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
David R Tribble
>> 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.
ka...@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, dtri...@technologist.com --
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
All...@my-dejanews.com
> 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++-...@netlab.cs.rpi.edu for info ]
Michael Rubenstein
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++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Jerry Coffin
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.
phil
>ka...@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.
Christopher Eltschka
>
> 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...)
Andrew Bell
wrote:
>Nope, VC5++ does not support partial specialization at all.
Actually, it's slightly worse than that, in that Visual will often
compile *but ignore* partial specialization. It also doesn't complain
about certain things in uninstantiated templates that other compilers
will complain about (in my case, Metrowerks), but I can't say for
certain whether that's a problem with VC or with Metrowerks.
Andrew Bell
Jerry Coffin
[ ... ]
> Something that perhaps is more in the realm of an error came up in my
> explorations of the cryptic stream classes. I was using an 'istream' and was
> trying to copy a range of bytes from that to an 'ostream.' There is a method
> called 'get' which can read bytes from a stream buffer. The docs say the
> param is a basic_streambuf*
The error here is in the documentation, not the code -- istream::get
is supposed to take a reference rather than a pointer.
> but the implementation uses a reference. So I had to throw a '*' in:
>
> istream input;
> ostream output;
> ...
> // Copy over the client data. WHOA! Apparent MS STL implementation
> // error. Docs refer to this param as a basic_streambuf*, but in
> // "istream" it is defined as as reference. Other implementations
> // may have to use input.get(output.rdbuf(), size), instead.
> input.get(*output.rdbuf(), size);
Other implementations should use the same code as VC++: rdbuf is
supposed to return a pointer, and get is supposed to take a reference
as a parameter. (at least according to CD2, 27.6.1.3 paragraph 12 or
thereabouts...)
--
Later,
Jerry.
The Universe is a figment of its own imagination.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Daniel Parker
<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
>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.
Jerry Coffin
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.
Thaddeus L. Olczyk
<celt...@physik.tu-muenchen.de> wrote:
>So would you say that source code is not allowed to contain
>__cplusplus, and therefore the following would be ill-formed?
>
>#ifdef __cplusplus
>extern "C"
>{
>#endif
> void f(int);
>#ifdef __cplusplus
>}
>#endif
>
Ahem.
__cplusplus is part of the standard.
Jolyon Wright
ka...@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
Fergus Henderson
>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 <f...@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 f...@128.250.37.3 | -- the last words of T. S. Garp.
Stan Brown
jim.h...@leitch.com (jim.h...@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.
Jason Merrill
> It also doesn't complain about certain things in uninstantiated templates
> that other compilers will complain about (in my case, Metrowerks), but I
> can't say for certain whether that's a problem with VC or with
> Metrowerks.
Well, that depends. The standard says that the compiler can choose to
diagnose syntax errors when the template definition is seen or wait until
instantiation time.
Jason
Crazy Pete
ka...@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
Jonathan Biggar
>
> ka...@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
j...@floorboard.com
j...@biggar.org
All...@my-dejanews.com
dtri...@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
Mike Tiller
> 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
Mike Tiller
> In article <1998072914...@mailfw1.ford.com>,
> Mike Tiller <mti...@ford.com> wrote:
> > brow...@concentric.net (Stan Brown) writes:
> [snip]
> > > Well, what about it? The Dec. 1996 draft standard said (section
> > > 2.10 paragraph 2), "... identifiers containing a double
> > > underscore ... are reserved for use by C++ implementations and
> > > shall not be used otherwise; no diagnostic is required."
> > The "__declspec(property)" example (whatever it does) would seem to me
> > to violate the "shall not be used otherwise" clause because they
> > aren't being used in the C++ implementation (compiler internals) but
> > in the program source code.
> The above quote is incomplete - the quote reads "reserved for use by C++
> implementations and standard libraries..."
> ^^^^^^^^^^^^^^^^^^^^^^
> meaning the STL can use double underscores, meaning source code can
> use double underscores, meaning __declspec is a legal extension to
> the language.
I think a reasonable interpretation, which others have stated, is that
implementators of compilers are allowed, in their implementations, to
use double underscores in identifiers. However, what Microsoft does,
apparently, with "__declspec(property)" is to force programmers to add
this to their source code. That would seem to be a violation.
I think about it in these terms. If I include a header file like
<map> and <map> happens to use double underscores on a Microsoft
platform, fine. If I move my source to another compiler and include
<map> no harm is done. However, if I write source code for a
Microsoft platform and I'm forced to put a "__declspec(property)" in
my source (I'm not saying I am forced, I'm just saying imagine it is
the case) then when I move to another platform it won't be portable
because its use is not (necessarily) part of the implementation of a
non-Microsoft compiler.
> It seems to me limiting the double underscore to internal use only is
> unsatisfactory - compilers are required to implement certain features, with
> only a general guide being provided by the Standard. In order to implement
> some of those features, the compilers are going to *have* to use identifiers
> *in the source code* (implementation details on the STL, for example).
Yes but so long as their use is limited to that implementation of the
STL then it is fine. The use of double underscores need not enter the
domain of the programmer.
> The compiler vendors need a way to guarantee that their identifiers
> will not conflict with your identifiers - specifying that
> identifiers containing double underscores are reserved for compiler
> implementations is a reasonable way to do this. It also gives you
> and me guidelines on how we can avoid problems with identifiers,
> both now *and* with future releases of the compiler.
I obviously wasn't clear enough about my interpretation of the quote
above. People seem to think that I'm against the use of double
underscores altogether. I'm not saying that. I'm saying it isn't for
the programmer to use in their source code.
> 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++-...@netlab.cs.rpi.edu for info ]
> [ about comp.lang.c++.moderated. First time posters: do this! ]
--
Michael Tiller
Ford Motor Company
Mike Tiller
> On 1 Aug 1998 13:00:18 -0400, Christopher Eltschka
> <celt...@physik.tu-muenchen.de> wrote:
>
> >So would you say that source code is not allowed to contain
> >__cplusplus, and therefore the following would be ill-formed?
> >
> >#ifdef __cplusplus
> >extern "C"
> >{
> >#endif
> > void f(int);
> >#ifdef __cplusplus
> >}
> >#endif
> >
> Ahem.
> __cplusplus is part of the standard.
Not only that, it isn't being used as an identifier in C++. Its being
used in the name of a preprocessor macro. That name will not appear
in the resulting post-processed C++ code.
Jerry Coffin
says...
> I think a reasonable interpretation, which others have stated, is that
> implementators of compilers are allowed, in their implementations, to
> use double underscores in identifiers.
This is absolutely true; there's really no question about that much.
> However, what Microsoft does, apparently, with "__declspec(property)"
> is to force programmers to add this to their source code.
This is NOT true. There is _no_ circumstance under which you _need_
to add this to your source code.
> That would seem to be a violation.
If it was true, (i.e. the their compiler would not compile source code
lacking this non-standard identifier) this would render the
implementation non-conforming.
The rules are fairly simple: a conforming compiler must accept any
strictly conforming code. Strictly conforming code must NOT contain
any identifiers with double underscores. Therefore the compiler must
accept code that does not contain double underscores.
However, there's nothing in the standard about being able to produce
DLLs or anything similar at all. If you choose to do something that's
not portable in the first place, the source code you use to do it may
not be strictly conforming anymore, so other implementations are no
longer obliged to accept it.
In the case of DLLs with MS's compiler, you're NOT required to use
anything non-standard in the source code at all. Doing so can provide
(usually minor) improvements in efficiency, so some people do so.
However, MS has basically done things correctly: they've provided an
extension, but put all the identifiers involved in their own
namespace, where they're allowed to introduce almost any identifier
they wish. The name of the identifier gives you a warning that if you
use this identifier in your code, your code is no longer strictly
conforming.
> The use of double underscores need not enter the domain of the programmer.
Yes and no -- when you use double-underscores in your program, you've
written something that has undefined behavior. A compiler is
completely within its rights to provide some meaningful implementation
of undefined behavior.
> I obviously wasn't clear enough about my interpretation of the quote
> above. People seem to think that I'm against the use of double
> underscores altogether. I'm not saying that. I'm saying it isn't for
> the programmer to use in their source code.
I think you've got this wrong. If we were talking about, e.g. Java, I
think your idea would be right. However, one of the basic ideas of C
and C++ almost since the beginning has been that you can write either
1) portable code, or 2) non-portable code.
Now, if you want to write portable code, you shouldn't use any
identifiers containing double-underscores (except the couple like
__cplusplus that are specifically defined in the standard.)
However, if you decide you WANT to use some compiler-specific
extension, you are allowed to do so. IMO, this is as things should
be. Not all code is, or should be, portable. If/when you say that
all code in a language should be portable, you're really saying "code
that embodies non-portable concepts shall not be written in this
language." That's reasonable for some languages, but not for all:
there is still a reason to write code that isn't portable, and some
language has to provide for that.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David Harmon
>I think a reasonable interpretation, which others have stated, is that
>implementators of compilers are allowed, in their implementations, to
>use double underscores in identifiers. However, what Microsoft does,
>apparently, with "__declspec(property)" is to force programmers to add
>this to their source code. That would seem to be a violation.
No, because you only have to do that when using Microsoft extensions.
A conforming compiler is required to compile strictly conforming
programs. You can write conforming programs without using
__declspec(whatever). MSVC will compile them for you.
What the standard promises is that if you do not write any __x
symbols in your program then you will not conflict with a conforming
implementation (in that regard.)
If you do use __x symbols, you must do so in accordance with the
extensions provided by your particular vendor. If you do that, you
are no longer writing conforming C++ code. What the compiler does
with such code is (partly) outside the scope of the C++ standard.
Mike Tiller
> In article <35BE9CE0...@nonexistant.com>,
> "Robert O'Dowd" <nos...@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++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Michael Rubenstein
wrote:
>David R Tribble <david....@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
Jerry Coffin
b...@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++-...@netlab.cs.rpi.edu for info ]
NF Stevens
>ka...@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
Doug Harrison
>> 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
dHar...@worldnet.att.net
Thomas Holaday
> > olc...@interaccess.com says...
> >
> > Could you be more specific about the problems you see in VC++?
> >
My current favorite is the implementation of set_new_handler. If a
program calls set_new_handler with (of all things) a non-null
new_handler, an assertion failure occurs. The debugger brings up a
source file which suggests one use _set_new_handler instead.
Paul D. DeRocco
>
> The statement "any C++ program which does windowing isn't
> conforming anyway" seems a little strange. That would imply that
> because there was nothing in the standard for printing the Hello World
> to somewhere then it must be a non-conforming program?
>
> AFAIK I can write ANSI C X-Windows code, and can probably therefore
> write conforming C++ code as well. (I can also compile it on NT if I
> want to.)
Fully conforming C++ code has a main() function. Windows uses something
else.
But anyway, the only purpose of having a standard is to allow
portability. If you're writing for Windows, you only need to be portable
across the various flavors of Windows, so there's no intrinsic problem
with extensions added by Microsoft, as long as they're supported in all
those flavors.
--
Ciao,
Paul
James Kuyper
...
> The statement "any C++ program which does windowing isn't
> > conforming anyway" seems a little strange. That would imply that because
>
> there was nothing in the standard for printing the Hello World to somewhere
> then it must be a non-conforming program?
The facilities needed to print Hello World are part of the standard
library. That is not true of the X functions, nor of the Windows
functions. A strictly conforming program can't call those functions,
because a conforming implementation needn't provide them.
James Kuyper
...
> 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.
James Kuyper
...
> 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++.