Topic: Compliance (or lack thereof) Information
Author: comeau@panix.com (Greg Comeau)
Date: 1999/06/01 Raw View
In article <374D3E6A.24E7C2FC@wizard.net> James Kuyper <kuyper@wizard.net> writes:
>Greg Comeau wrote:
>> In article <MPG.11accba4b8a28014989ad6@news.mindspring.com> jcoffin@taeus.com (Jerry Coffin) writes:
>> >In article <374246F3.8B35F5FF@pixar.com>, king@pixar.com says...
>> >> It is amazing that so many people have some much to say about this topic.
>> >> However, unless I missed it, nobody has suggested any way to go about
>> >> collecting information regarding what compilers support what standard
>> >> features.
>>
>> Maybe I'm missing a context from earlier in the thread, but what's
>> wrong with asking the vendor for a list?
>
>The context of this thread was the idea of forming a comprehesive list
>of available implementations and how well they support various language
>features, along with user feedback, so they can be compared. It should
>be possible to collect the vendor's information for each implementation
>only once per product release. Ideally, it shouldn't be necessary for
>each compiler purchaser to seperatly request, collect, and analyse the
>data.
Sounds reasonable to me. Somebody go for it!
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Ross Smith <ross.s@ihug.co.nz>
Date: 1999/06/02 Raw View
Greg Comeau wrote:
>
> In article <374D3E6A.24E7C2FC@wizard.net> James Kuyper <kuyper@wizard.net> writes:
> >
> >The context of this thread was the idea of forming a comprehesive list
> >of available implementations and how well they support various language
> >features, along with user feedback, so they can be compared. It should
> >be possible to collect the vendor's information for each implementation
> >only once per product release. Ideally, it shouldn't be necessary for
> >each compiler purchaser to seperatly request, collect, and analyse the
> >data.
>
> Sounds reasonable to me. Somebody go for it!
What the heck, I'll give it a try. I've put together a rough checklist
style comparison chart for the handful of compilers I'm familiar with;
readers with detailed knowledge of other compilers are invited to
contribute. This is intentionally a fairly broad-brushed comparison
rather than a detailed list of bugs, features, itsnotabugitsafeatures,
and marketing hype.
http://animal.ihug.co.nz/c++/compilers.html
--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
I know you're desperate, I really sympathise
I see the morbid horror flicker in your eyes
But rest assured I'm gonna help to ease your pain
I'm gonna put a thousand tiny implants in your brain [Motorhead]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <Bonnard.V@wanadoo.fr>
Date: 1999/06/02 Raw View
Ross Smith wrote:
> What the heck, I'll give it a try. I've put together a rough checklist
> style comparison chart for the handful of compilers I'm familiar with;
> readers with detailed knowledge of other compilers are invited to
> contribute. This is intentionally a fairly broad-brushed comparison
> rather than a detailed list of bugs, features, itsnotabugitsafeatures,
> and marketing hype.
>
> http://animal.ihug.co.nz/c++/compilers.html
[Moderator note:
I should have inserted a comment here: could you please
discuss issues (if you have any) about this web page with
the maintainer of this page, that is, Ross Smith ?
Of course if you have a disagreement about the conformance
of doing xxx in the implementation of feature yyy then you
can post a question in this group.
Posts about compiler conformance have generally been
accepted in this group, but discussions of the claims
of a particular web page should generally be done by
private mail.
This is _not_ an a priori rejection of any followups
to Ross Smith's post.
--vb]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1999/05/28 Raw View
In article <7ii6e1$i6d$1@panix.com>, comeau@panix.com says...
>
> In article <MPG.11accba4b8a28014989ad6@news.mindspring.com> jcoffin@taeus.com (Jerry Coffin) writes:
> >In article <374246F3.8B35F5FF@pixar.com>, king@pixar.com says...
> >> It is amazing that so many people have some much to say about this topic.
> >> However, unless I missed it, nobody has suggested any way to go about
> >> collecting information regarding what compilers support what standard
> >> features.
>
> Maybe I'm missing a context from earlier in the thread, but what's
> wrong with asking the vendor for a list?
If a vendor happens to be controlled primarily by marketing rather
than technical people, they might present somewhat inflated claims of
compliance and features.
Just FWIW, I was recently browsing through the documentation for
Intel's new version of their compiler, and found precisely the
opposite. The following is a quote from their documentation:
Conformance to C++ Standards
The Intel C/C++ compiler conforms to the Microsoft
implementation of the C++ language. For more
information on the Microsoft implementation of the
C++ language, see the Microsoft Visual C++
documentation.
I suspect most of us are more likely to trust technical people than
marketing people; I'd certainly be more inclined to believe (for
example) your statements about what your compiler does or doesn't
support than similar statements from Inprise or Microsoft.
The other obvious situation would be one about like that encountered
with Blitz -- if you're releasing some source code, and want to know
what the compiler supports, it's handy to be able to figure out more
or less automatically when installing, configuring or building the
library.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: comeau@panix.com (Greg Comeau)
Date: 1999/05/30 Raw View
In article <MPG.11b72cf63645b0fb989abb@news.mindspring.com> brahms@mindspring.com (Stan Brown) writes:
>
>Dixitque comeau@panix.com (Greg Comeau) in comp.std.c++:
>>In article <MPG.11accba4b8a28014989ad6@news.mindspring.com> jcoffin@taeus.com (Jerry Coffin) writes:
>>>In article <374246F3.8B35F5FF@pixar.com>, king@pixar.com says...
>>>> It is amazing that so many people have some much to say about this topic.
>>>> However, unless I missed it, nobody has suggested any way to go about
>>>> collecting information regarding what compilers support what standard
>>>> features.
>>
>>Maybe I'm missing a context from earlier in the thread, but what's
>>wrong with asking the vendor for a list?
>
>How likely is it that the response would bear any great resemblance to
>the truth?
I did this about 6 years ago and didn't have a problem. That the
same people may not be involved, or that C++ has more features
should not necessarily change this much.
FWIW, the Comeau site lists what we support (twice in fact),
and even includes what we don't support.
>Any product comparison must be independent of the manufacturers, or it is
>likely to be tainted by wishful thinking or marketing hype.
"If it's not one thing, it's another"
- Roseanne Roseannadanna
Any such list will meet a compromise. In any case, the issue will be
how one hurdles it.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1999/05/31 Raw View
Greg Comeau wrote:
>
> In article <MPG.11accba4b8a28014989ad6@news.mindspring.com> jcoffin@taeus.com (Jerry Coffin) writes:
> >In article <374246F3.8B35F5FF@pixar.com>, king@pixar.com says...
> >> It is amazing that so many people have some much to say about this topic.
> >> However, unless I missed it, nobody has suggested any way to go about
> >> collecting information regarding what compilers support what standard
> >> features.
>
> Maybe I'm missing a context from earlier in the thread, but what's
> wrong with asking the vendor for a list?
The context of this thread was the idea of forming a comprehesive list
of available implementations and how well they support various language
features, along with user feedback, so they can be compared. It should
be possible to collect the vendor's information for each implementation
only once per product release. Ideally, it shouldn't be necessary for
each compiler purchaser to seperatly request, collect, and analyse the
data.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: comeau@panix.com (Greg Comeau)
Date: 1999/05/27 Raw View
In article <MPG.11accba4b8a28014989ad6@news.mindspring.com> jcoffin@taeus.com (Jerry Coffin) writes:
>In article <374246F3.8B35F5FF@pixar.com>, king@pixar.com says...
>> It is amazing that so many people have some much to say about this topic.
>> However, unless I missed it, nobody has suggested any way to go about
>> collecting information regarding what compilers support what standard
>> features.
Maybe I'm missing a context from earlier in the thread, but what's
wrong with asking the vendor for a list?
>One thing you might find helpful is to get a copy of Blitz++.....
>You may not care about Blitz++ itself, but it includes a compiler test
>suite that has quite good coverage of most of the template-oriented
>features a compiler might or might not support. This produces output
>in two forms: a log file showing the compiler invocations on the files
>used to test various features, and the any error messages the compiler
>might produce. The other form of output is a header with various
>constants either #define'd or #undef'd, depending on whether specific
>features are supported.
>sets of math functions some compilers include.
Blitz is clever on this matter, indeed. However, -- and this is not to
say there is a problem with the results per se -- I have on more than
one occassion seen _programmers_ make conclusions which are invalid
based upon such programaticly computed assumptions while completely
ignoring things such as the command line switches being used with the
compiler.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: brahms@mindspring.com (Stan Brown)
Date: 1999/05/27 Raw View
Dixitque comeau@panix.com (Greg Comeau) in comp.std.c++:
>In article <MPG.11accba4b8a28014989ad6@news.mindspring.com> jcoffin@taeus.com (Jerry Coffin) writes:
>>In article <374246F3.8B35F5FF@pixar.com>, king@pixar.com says...
>>> It is amazing that so many people have some much to say about this topic.
>>> However, unless I missed it, nobody has suggested any way to go about
>>> collecting information regarding what compilers support what standard
>>> features.
>
>Maybe I'm missing a context from earlier in the thread, but what's
>wrong with asking the vendor for a list?
How likely is it that the response would bear any great resemblance to
the truth?
Any product comparison must be independent of the manufacturers, or it is
likely to be tainted by wishful thinking or marketing hype.
--
There's no need to e-mail me a copy of a follow-up; but if you do,
please identify it as such.
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1999/05/22 Raw View
In article <374246F3.8B35F5FF@pixar.com>, king@pixar.com says...
>
>
> It is amazing that so many people have some much to say about this topic.
> However, unless I missed it, nobody has suggested any way to go about
> collecting information regarding what compilers support what standard
> features.
One thing you might find helpful is to get a copy of Blitz++. Blitz++
itself is a mathematics library that makes heavy use of templates, and
quite a few of the more esoteric template-related features.
You may not care about Blitz++ itself, but it includes a compiler test
suite that has quite good coverage of most of the template-oriented
features a compiler might or might not support. This produces output
in two forms: a log file showing the compiler invocations on the files
used to test various features, and the any error messages the compiler
might produce. The other form of output is a header with various
constants either #define'd or #undef'd, depending on whether specific
features are supported.
I obviously can't guarantee anything, but you might find either or
both of these useful -- for example, you can create a header of your
own with various macros and such to improve portability. Just for one
obvious example, you might have:
#include "config.h"
#ifdef BZ_OLD_FOR_SCOPING
#define for if(0) else for
#endif
The Blitz++ test suite has tests for around 40 individual features of
a compiler, ranging from now-common (e.g. namespaces, new casts) to
features that are still only rarely supported (e.g templates as
template arguments). It also tests for a few features that are NOT
required by the C++ standard such as the ``restrict'' keyword, and
sets of math functions some compilers include.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1999/05/24 Raw View
Jerry Coffin wrote:
>
> In article <37377FE2.19E18AAC@wizard.net>, kuyper@wizard.net says...
>
> [ ... compliance of different versions of MS VC++ ]
....
> Ah, now 1.x certainly wasn't even vaguely close to compliant, lacking
> even a hint of support for templates, exception handling, namespaces,
> etc. While VC++ 6.0 isn't exactly state of the art, it's at least a
> lot closer. With 1.x, you actually DO get slightly closer conformity
> with the standard by using /Za than not, though most of the difference
> in this case is enforcing the fact that things like `near' and `far'
> aren't keywords. By contrast, the current version changes things that
> were (apparently) intentionally made non-compliant in the default
> mode, such as the well-known situation with the scope of variables
> declared in the header of a for-statement.
I want to emphasize that my comments about MSVC++ 6.0 were entirely
based upon what others have posted about it in this newsgroup. They were
only slightly influenced by my own bad memories of working with 1.51.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW <allan_w@my-dejanews.com>
Date: 1999/05/26 Raw View
In article <3741EC2A.DE1E5772@technologist.com>,
David R Tribble <dtribble@technologist.com> wrote:
>
> AllanW wrote:
> >
> >> Ed Brey wrote:
> >>> It gets worse. With Microsoft "extensions" enabled, dozens of new
> >>> C++ functions in the math library are *disabled*.
> >>>...
> >
> > In article <373B6E99.76DF8254@technologist.com>,
> > David R Tribble <dtribble@technologist.com> wrote:
> >> One of those "extensions" is for compiling code for DLLs.
...
> >> Therefore most useful Windows
> >> code requires at least one "extension", and conformance goes
> >> out the window.
> > That's not really fair. (If we're going to Microsoft-bash, at
> > least we should be fair.) Most of what makes code into an .EXE
> > or a .DLL is in the linker, not the compiler, and almost none
> > of it is required to be in the language.
> I was referring, of course, to the need for '__declspec(dllexport)'
> and '__declspec(dllimport)' keywords to properly declare symbols
> within DLLs that are used by EXEs or other DLLs.
So was I; this is NOT required. There is an extra-lingual way
of accomplishing this.
> > 2. I had to change the compiler settings to /Gz, which means
> > to assume that all functions use the __stdcall protocol.
> > It *IS* possible to put __cdecl (the default) functions
> > in a DLL, but this is rarely done. Rather than have
> > someone accuse me of a "loophole," I changed the default.
> This probably means that the standard library functions, which all
> seem to be declared as '__cdecl', will not be callable from your
> DLL code. I'm guessing, for instance, that the functions in your
> DLL can't call std::printf() or std::cout::operator<<, and maybe not
> even ::new. Try writing mySqrt() to call std::sqrt(), for instance.
Okay, I changed myDll.cpp to
#include <math.h>
double mySqrt(double arg) { return sqrt(arg); }
I recompiled the DLL and re-ran the client with no problems.
Except for ::new, a program must include the appropriate header
files before calling any of the library functions you mention.
The presence of "__cdecl" in the header files is an
implementation detail that I need not concern myself with, and
yet it allows my code to call the library functions properly.
(Ask yourself: why use header files for standard library
functions? This is why.)
> > 3. Function main() is required to be __cdecl so that the
> > runtime system will communicate with it properly. Since
> > the default was changed to __stdcall, I had to use the
> > __cdecl keyword to change this *ONE* function back to its
> > normal default.
>
> So you still had to use one nonstandard keyword. That's very close,
> but not completely zero. (Sorry, but I couldn't resist pointing
> this out! :-)
Let's call it iota -- close enough to not matter.
We're talking about compiler compliance here (right, moderator?).
Can compliant programs be compiled and used on Microsoft?
Certainly not if they're crafted to prove otherwise; name a
variable "far" and watch a Microsoft bug crash and burn. No,
Microsoft is certainly not compliant yet. However, they're much
closer than some people usually give them credit for.
If I were to port some "compliant" code to Microsoft, and the
biggest headache I had was adding *ONE* non-standard keyword to
*ONE* function, then I personally would be willing to call
Microsoft "practically conforming."
> > 4. I couldn't use Microsoft-specific keywords to export
> > functions from the DLL easily. Instead, I had to turn on
> > the map, link the DLL, read the map to find the "mangled"
> > names, and then copy these into a .DEF file.
>
> This is what I was referring to. Yes, you can go through all the
> hassle of using DEF files (which define the exported symbols for
> a DLL) instead of using explicit '__declspec(dllexport)' modifiers.
Surely you cannot fault Microsoft for giving you an entirely
OPTIONAL feature which completely eliminates a "HASSLE"? Note that
the keyword "__declspec" is entirely within the "reserved to
implementation" namespace, so it cannot be used accidentally or
otherwise adversely affect compliant programs. And yet when it
is used a major HASSLE is avoided. This is NOT a bad thing!
> But be aware that Microsoft has stated (I think) that DEF files are
> deprecated practice,
Can you tell me where you saw this? I would like to confirm.
> and that the '__declspec' approach is the
> better way to do this.
If "Better" means "Easier" then there is no contest. Furthermore, it
is in Microsoft's best interest for us to embed this in our code
because it makes porting to non-Microsoft compilers harder. But at
least for the present, .DEF files are fully supported.
If "Better" means "More portable" then this is clearly wrong.
> (I'm under the impression that DEF files
> are a holdover from the days of migrating from 16-bit to 32-bit
> Windows applications, but I'm not sure; DEF files certainly predate
> the '__declspec' gibberish.)
And also the now-defunct __export keyword. It comes from long
before that. In fact, I believe that it was present in
Windows version 1. I know that it was around for Windows/286
version 2, and not just for DLL exports but also for imports
from other DLLs. Long before .LIB files were capable of
supporting import records, .DEF files were mandatory in any
project involving a .DLL in any way (which was all of them).
> It's possible MS might drop support
> for them in a future release.
> Even if they don't, they add pain
> to the process by requiring mangled symbol names.
Which is still an extra-lingual issue. The C++ standard can
influence such issues (i.e. the double-underscore in most of
the local keywords) but it cannot dictate the solutions.
I view "mangled names" as a stopgap measure to be used until the
linker support is ready. In the past 6 years the only linker
change I'm aware of is to un-mangle the names for error messages
(but leave them mangled for most other purposes). But I daresay
that many programming shops have at least a couple of six-year-old
"stopgap" or "temporary" programs in house.
> > 5. At first I tried turning off Microsoft-specific warning
> > messages, and I got lots of messages. So I turned them
> > back on and thought, "Que sera sera." Later, when I was
> > writing this message, I turned it back on so that I could
> > state the type of errors I got -- and I didn't get any
> > errors, not even warnings! I'm not sure what it is that
> > I did right (I really wish I knew...)
>
> You seem to have stumbled upon the magic combination of options
> to keep the compiler from complaining about its own header files.
> Every one else that's posted doesn't seem to have been as lucky.
> The question is, do the functions in those header file get declared
> correctly (as __cdecl, for instance)?
Oh yes, absolutely. Changing the default calling sequence and even
turning off Microsoft extensions does *NOT* disable explicit
keywords that start with two underscores (nor should it).
> > In any case, after all that, the result was:
> >
> > The square root of 16 is 4
>
> That's a good first test. Now try something more complicated.
> I'm still betting it can't be done for general cases.
Alas, I am a member of the middle class. I really would be
interested in pursuing this type of project, but I'm even more
motivated to earn a paycheck. Therefore I'm open to many
specific tests, but "try something more complicated" is beyond
my means.
--
Allan_W@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in newsgroups only, sorry.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1999/05/21 Raw View
Stan Brown wrote:
...
> I have a CD-ROM from Microsoft. It has 4.1 and 1.52. I don't believe
> there ever was a 2.something.
There certainly was. Version 1.51 for Windows 3.1 was shipped along with
version 2.0 for Windows NT. I know this because I still have those
disks.
I apologize for starting this. I made one small typo in a version number
while disclaiming any experience with a recent version of MSVC++. That
typo triggered a chain of messages arguing discussing what the precise
version numbers were. Let's give it a rest.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David Binderman <dcb@pncl.co.uk>
Date: 1999/05/21 Raw View
Chris King wrote:
> As it is in a group like mine, the only way we can get this information is to
> laboriously try each feature on each compiler we use. This is way to time
> consuming to be practical. Therefore, our only choice is to limit our code to
> a subset of the language features that we know work.
I have seen that library vendors like Rogue Wave and libraries
like Blitz++ use a standard script to figure out what works on
a compiler and what doesn't.
Results from such a standard script run form easy pickings to
bash compiler vendors with.
You could do worse than invest in such libraries, just to
find out what your compilers of interest can & cannot do.
Of course, the immense complexity of C++ means that such a
script might be quite long !
Regards
dcb
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@eng.sun.com (Steve Clamage)
Date: 1999/05/22 Raw View
James Kuyper <kuyper@wizard.net> writes:
>If I understood [James Kanze] correctly, he was saying that 99% of all C++
>compilers in their conforming modes would would not accept very many
>useful programs. I've heard that this was true of MSVC++, but is it
>really true of most C++ compilers?
Let me give you an example from the Unix world. XOpen and POSIX
(which I'll characterise as "Unix") require declarations to be present
in nearly all the standard C headers that are forbidden by the C
and C++ standards. That is, the additional identifiers are in the
programmer's namespace.
To pass C or C++ conformance tests, the compiler might have a
"conformance" or "pedantic" flag that predefines a macro that is
tested in the headers. For example, Unix requires the functions
FILE* fdopen(int, const char *);
char* ctermid(char *);
int * fileno(FILE *);
in <stdio.h>, but a conforming non-Unix C program can use those
names as external identifiers. A C conformance test might contain
#include <stdio.h>
int fdopen(int) { return 0; }
void ctermid(int) { }
void fileno(void) { }
int main() { return 0; }
It should compile and run on a conforming C or C++ implementation
but would fail unless those functions were removed from <stdio.h>:
#if ! defined(_CONFORMANCE_MODE)
FILE* fdopen(int, const char *);
char* ctermid(char *);
int * fileno(FILE *);
#endif
If you are writing a program for a Unix platform, you expect to
find Unix functions in the standard C headers. If you put the
compiler in conforming mode, the declarations are not there, and
you are limited to the pure C/C++ subset of functionality.
--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Chris King <king@pixar.com>
Date: 1999/05/19 Raw View
It is amazing that so many people have some much to say about this topic.
However, unless I missed it, nobody has suggested any way to go about
collecting information regarding what compilers support what standard
features.
As it is in a group like mine, the only way we can get this information is to
laboriously try each feature on each compiler we use. This is way to time
consuming to be practical. Therefore, our only choice is to limit our code to
a subset of the language features that we know work.
If somebody would compile a list of compilers along with what features they
support, it would be immensely useful to the whole C++ community. It may even
shame some vendors into doing a better job.
Chris King
king@pixar.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: petebecker@acm.org
Date: 1999/05/20 Raw View
>I'm still betting it can't be done for general cases.
The main thing that can't be done without magic is importing data from a
DLL. Imported data and functions both go through two levels of
indirection. With functions that's just an indirect jump, something that
can be generated by outside tools (implib or the linker itself does this).
With data the compiler has to do it, so the compiler has to know that the
data is being imported.
-- Pete
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: petebecker@acm.org
Date: 1999/05/20 Raw View
>Even if [DEF files] don't [go away], they add pain
>to the process by requiring mangled symbol names.
They add pain only if your tools don't give you any help. Borland for many
years has shipped a tool called 'impdef' that generates the EXPORTS
section for a .DEF file directly from a DLL. I've seen a mention of
something similar in the MS tools, but wasn't able to find it when I
looked for it recently.
-- Pete
[ moderator's note: We have gone rather far from the subject of
conforming compilers. Let's try to get back on track. -sdc ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW <allan_w@my-dejanews.com>
Date: 1999/05/17 Raw View
In article <MPG.11a1188f2ff43575989a9e@news.mindspring.com>,
jcoffin@taeus.com (Jerry Coffin) spewed forth:
>
> In article <37374B3C.FA876BEB@wizard.net>, kuyper@wizard.net says...
> > The most recent version of MSVC++ that I've used is 2.5, but if
>
> Not that it really matters, but there never was a version 2.5 -- the
> version number skipped directly from 2.2 to 4.0.
Microsoft 4.0 was a 32-bit compiler producing 32-bit code. For
compatibility purposes they also came out with another version
in the 2.x series -- it was probably 2.3 -- and shipped it along
with 4.0. After that there were a few more versions of the 16-bit
product before that got ignored to death. I wouldn't be surprised
to learn that there was indeed a version 2.5, and that it was the
final 16-bit version ever produced.
Not that it really matters.
----
Allan_W@my-dejanews.com is a "Spam Magnet" -- never read.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <dtribble@technologist.com>
Date: 1999/05/18 Raw View
AllanW wrote:
>
>> Ed Brey wrote:
>>> It gets worse. With Microsoft "extensions" enabled, dozens of new
>>> C++ functions in the math library are *disabled*.
>>>...
>
> In article <373B6E99.76DF8254@technologist.com>,
> David R Tribble <dtribble@technologist.com> wrote:
>> One of those "extensions" is for compiling code for DLLs. I would
>> wager that a fair majority of code compiled under VC++ is destined
>> for use in DLLs; it's getting more and more impossible to write
>> Windows code that isn't DLL-able. Therefore most useful Windows
>> code requires at least one "extension", and conformance goes out the
>> window.
>
> That's not really fair. (If we're going to Microsoft-bash, at
> least we should be fair.) Most of what makes code into an .EXE
> or a .DLL is in the linker, not the compiler, and almost none
> of it is required to be in the language.
I was referring, of course, to the need for '__declspec(dllexport)'
and '__declspec(dllimport)' keywords to properly declare symbols
within DLLs that are used by EXEs or other DLLs.
> You want me to prove it?
>
> Alright, I proved it! I just wrote a DLL that doesn't use ANY
> Microsoft keywords in the language. Then I wrote a client that
> uses the keywords. Here I did have to use one Microsoft keyword.
> ONE.
>
> Here's the DLL:
[code snipped]
>
> Here are the things that I did differently from the "Usual"
> way to build a DLL and a client in Microsoft VC++:
>
> 1. I couldn't let the "Wizard" write the skeleton for me.
> (Actually, I did let it write it for me, but then I had
> to manually translate the non-standard macros back to
> their normal language form. It would have been easier to
> start over.)
>
> 2. I had to change the compiler settings to /Gz, which means
> to assume that all functions use the __stdcall protocol.
> It *IS* possible to put __cdecl (the default) functions
> in a DLL, but this is rarely done. Rather than have
> someone accuse me of a "loophole," I changed the default.
This probably means that the standard library functions, which all
seem to be declared as '__cdecl', will not be callable from your
DLL code. I'm guessing, for instance, that the functions in your
DLL can't call std::printf() or std::cout::operator<<, and maybe not
even ::new. Try writing mySqrt() to call std::sqrt(), for instance.
> 3. Function main() is required to be __cdecl so that the
> runtime system will communicate with it properly. Since
> the default was changed to __stdcall, I had to use the
> __cdecl keyword to change this *ONE* function back to its
> normal default.
So you still had to use one nonstandard keyword. That's very close,
but not completely zero. (Sorry, but I couldn't resist pointing
this out! :-)
> 4. I couldn't use Microsoft-specific keywords to export
> functions from the DLL easily. Instead, I had to turn on
> the map, link the DLL, read the map to find the "mangled"
> names, and then copy these into a .DEF file.
This is what I was referring to. Yes, you can go through all the
hassle of using DEF files (which define the exported symbols for
a DLL) instead of using explicit '__declspec(dllexport)' modifiers.
But be aware that Microsoft has stated (I think) that DEF files are
deprecated practice, and that the '__declspec' approach is the
better way to do this. (I'm under the impression that DEF files
are a holdover from the days of migrating from 16-bit to 32-bit
Windows applications, but I'm not sure; DEF files certainly predate
the '__declspec' gibberish.) It's possible MS might drop support
for them in a future release. Even if they don't, they add pain
to the process by requiring mangled symbol names.
> 5. At first I tried turning off Microsoft-specific warning
> messages, and I got lots of messages. So I turned them
> back on and thought, "Que sera sera." Later, when I was
> writing this message, I turned it back on so that I could
> state the type of errors I got -- and I didn't get any
> errors, not even warnings! I'm not sure what it is that
> I did right (I really wish I knew...)
You seem to have stumbled upon the magic combination of options
to keep the compiler from complaining about its own header files.
Every one else that's posted doesn't seem to have been as lucky.
The question is, do the functions in those header file get declared
correctly (as __cdecl, for instance)?
> In any case, after all that, the result was:
>
> The square root of 16 is 4
That's a good first test. Now try something more complicated.
I'm still betting it can't be done for general cases.
-- David R. Tribble, dtribble@technologist.com --
A little government and a little luck are necessary in life,
but only a fool trusts either of them.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Matt Seitz <mseitz@meridian-data.com>
Date: 1999/05/18 Raw View
The last 16-bit version of MSVC was 1.52c. That was the version that was
shipped along with 32-bit MSVC 4.0.
For a history of the MSVC version numbering, see Article ID: Q145669 in the
Microsoft Knowledgebase.
AllanW <allan_w@my-dejanews.com> wrote in message
news:7hq6qa$6e5$1@nnrp1.deja.com...
>
> In article <MPG.11a1188f2ff43575989a9e@news.mindspring.com>,
> jcoffin@taeus.com (Jerry Coffin) spewed forth:
> >
> > In article <37374B3C.FA876BEB@wizard.net>, kuyper@wizard.net says...
> > > The most recent version of MSVC++ that I've used is 2.5, but if
> >
> > Not that it really matters, but there never was a version 2.5 -- the
> > version number skipped directly from 2.2 to 4.0.
>
> Microsoft 4.0 was a 32-bit compiler producing 32-bit code. For
> compatibility purposes they also came out with another version
> in the 2.x series -- it was probably 2.3 -- and shipped it along
> with 4.0. After that there were a few more versions of the 16-bit
> product before that got ignored to death. I wouldn't be surprised
> to learn that there was indeed a version 2.5, and that it was the
> final 16-bit version ever produced.
>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: brahms@mindspring.com (Stan Brown)
Date: 1999/05/18 Raw View
Dixitque allan_w@my-dejanews.com (AllanW) in comp.std.c++:
>Microsoft 4.0 was a 32-bit compiler producing 32-bit code. For
>compatibility purposes they also came out with another version
>in the 2.x series -- it was probably 2.3 -- and shipped it along
>with 4.0.
I have a CD-ROM from Microsoft. It has 4.1 and 1.52. I don't believe
there ever was a 2.something.
I'm in the U.S.; if you're not, perhaps Microsoft used different version
numbers outside the U.S. Or perhaps your memory is playing you false.
MODS: Isn't this discussion a bit vendor-specific for this newsgroup? But
I offer the correction since you approved the quoted statement.
--
There's no need to e-mail me a copy of a follow-up; but if you do,
please identify it as such.
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW <allan_w@my-dejanews.com>
Date: 1999/05/18 Raw View
> Ed Brey wrote:
> > It gets worse. With Microsoft "extensions" enabled, dozens of new
> > C++ functions in the math library are *disabled*.
> >...
In article <373B6E99.76DF8254@technologist.com>,
David R Tribble <dtribble@technologist.com> wrote:
> One of those "extensions" is for compiling code for DLLs. I would
> wager that a fair majority of code compiled under VC++ is destined
> for use in DLLs; it's getting more and more impossible to write
> Windows code that isn't DLL-able. Therefore most useful Windows
> code requires at least one "extension", and conformance goes out the
> window.
That's not really fair. (If we're going to Microsoft-bash, at
least we should be fair.) Most of what makes code into an .EXE
or a .DLL is in the linker, not the compiler, and almost none
of it is required to be in the language.
You want me to prove it?
Alright, I proved it! I just wrote a DLL that doesn't use ANY
Microsoft keywords in the language. Then I wrote a client that
uses the keywords. Here I did have to use one Microsoft keyword.
ONE.
Here's the DLL:
#if 0
// This sample doesn't nead DllMain.
// If I did need it but didn't want Microsoft extensions
// I would use this:
int DllMain(void*hModule, unsigned long reason_for_call, void*) {
return 1;
}
#endif
// Here's the actual function I want to export
double mySqrt(double arg)
{
double guess = 0.0;
if (arg>0.0) {
double lo=1.0, hi=arg;
if (arg < 1.0) lo=0.0, hi=1.0;
do {
guess = (lo+hi)/2.0;
if (guess==lo || guess==hi) break;
double square = guess * guess;
if (square == arg) break;
if ((square < arg) == (arg < 1.0)) hi = guess;
else lo = guess;
} while (lo<hi);
}
return guess;
}
And here's the client:
#include <iostream>
// Declare function in DLL
// Should use another header file, but would complicate example
double mySqrt(double);
int __cdecl main(int argc, char* argv[])
{
double arg = atof(argv[1] ? argv[1] : "16");
std::cout << "The square root of " << arg << " is "
<< mySqrt(arg) << std::endl;
return 0;
}
Here are the things that I did differently from the "Usual"
way to build a DLL and a client in Microsoft VC++:
1. I couldn't let the "Wizard" write the skeleton for me.
(Actually, I did let it write it for me, but then I had
to manually translate the non-standard macros back to
their normal language form. It would have been easier to
start over.)
2. I had to change the compiler settings to /Gz, which means
to assume that all functions use the __stdcall protocol.
It *IS* possible to put __cdecl (the default) functions
in a DLL, but this is rarely done. Rather than have
someone accuse me of a "loophole," I changed the default.
3. Function main() is required to be __cdecl so that the
runtime system will communicate with it properly. Since
the default was changed to __stdcall, I had to use the
__cdecl keyword to change this *ONE* function back to it's
normal default.
4. I couldn't use Microsoft-specific keywords to export
functions from the DLL easily. Instead, I had to turn on
the map, link the DLL, read the map to find the "mangled"
names, and then copy these into a .DEF file.
5. At first I tried turning off Microsoft-specific warning
messages, and I got lots of messages. So I turned them
back on and thought, "Que sera sera." Later, when I was
writing this message, I turned it back on so that I could
state the type of errors I got -- and I didn't get any
errors, not even warnings! I'm not sure what it is that
I did right (I really wish I knew...)
In any case, after all that, the result was:
The square root of 16 is 4
--
Allan_W@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in newsgroups only, sorry.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Ed Brey" <brey@afd.mke.etn.com>
Date: 1999/05/10 Raw View
Stan Brown <brahms@mindspring.com> wrote in message
news:MPG.119d6a36a02b80829899a1@news.mindspring.com...
>
> Dixitque nicka@my-dejanews.com (nicka@my-dejanews.com) in comp.std.c++:
> >For example, the VC compiler was claimed at
> >somewhere over 90% compliance with Plum Hall by Microsoft I believe. Not
only
> >couldn't other people reproduce these numbers, the switches required
probably
> >prevent you from compiling pretty much any useful program.
>
> You could remove the "probably" from that. With the /Za switch (disable
> extensions), you can't compile many of the standard headers that
> Microsoft supplies.
>
> It's bad enough that this was true in 5.0. If, as I've been told, it's
> also true in 6.0, the word that comes to mind is "criminal".
It gets worse. With Microsoft "extensions" enabled, dozens of new C++
functions in the math library are *disabled*. For example:
long abs(long);
One can of course, turn off the extensions, and then these functions show
up, but as was pointed out earlier, VC will compiler little useful code
without extensions.
Clearly, this is a case of Microsoft choosing not to spend the time to get
its header files right. This is the price the customers pay for Microsoft
not writing type-safe headers in the first place.
Any web site that lists nonconformaties of compilers should judge the
compilers when their switches are set to "practial for real programs" mode,
since this is what potential customers will need to know when evaluating a
compiler.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1999/05/10 Raw View
Ed Brey wrote:
>
> Stan Brown <brahms@mindspring.com> wrote in message
> news:MPG.119d6a36a02b80829899a1@news.mindspring.com...
...
> > You could remove the "probably" from that. With the /Za switch (disable
> > extensions), you can't compile many of the standard headers that
> > Microsoft supplies.
> >
> > It's bad enough that this was true in 5.0. If, as I've been told, it's
> > also true in 6.0, the word that comes to mind is "criminal".
>
> It gets worse. With Microsoft "extensions" enabled, dozens of new C++
> functions in the math library are *disabled*. For example:
>
> long abs(long);
>
> One can of course, turn off the extensions, and then these functions show
> up, but as was pointed out earlier, VC will compiler little useful code
> without extensions.
>
> Clearly, this is a case of Microsoft choosing not to spend the time to get
> its header files right. This is the price the customers pay for Microsoft
> not writing type-safe headers in the first place.
>
> Any web site that lists nonconformaties of compilers should judge the
> compilers when their switches are set to "practial for real programs" mode,
> since this is what potential customers will need to know when evaluating a
> compiler.
If the compiler claims that is has any nearly-conforming modes, the mode
chosen should be one of those. It wouldn't be fair to judge the
compliance of a mode that was never intended to be conforming.
That's suffcient to cover this case. If Microsoft's
closest-to-conforming mode won't allow code that #includes standard
headers to compile, it's nowhere near conforming. The most recent
version of MSVC++ that I've used is 2.5, but if half of what I've heard
on this newsgroup about 6.0 is true, there's no point in even thinking
about MSVC++ as being anything more than a distant reletive of Standard
C++.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1999/05/11 Raw View
In article <37374B3C.FA876BEB@wizard.net>, kuyper@wizard.net says...
[ ... ]
> If the compiler claims that is has any nearly-conforming modes, the mode
> chosen should be one of those. It wouldn't be fair to judge the
> compliance of a mode that was never intended to be conforming.
>
> That's suffcient to cover this case. If Microsoft's
> closest-to-conforming mode won't allow code that #includes standard
> headers to compile, it's nowhere near conforming.
IMO, using MS VC++, the closest-to-conforming mode is when you turn
extensions one. With extensions turned on, it doesn't attempt to
diagnose use of extended keywords and such, but at least it'll accept
quite a bit of useful code that follows the description in the
standard.
By contrast, if you turn its extensions off, there's virtually no
useful code that it'll accept at all.
> The most recent version of MSVC++ that I've used is 2.5, but if half
Not that it really matters, but there never was a version 2.5 -- the
version number skipped directly from 2.2 to 4.0.
> of what I've heard on this newsgroup about 6.0 is true, there's no
> point in even thinking about MSVC++ as being anything more than a
> distant reletive of Standard C++.
With extensions turned on, it's toward the back of the pack, but not
substantially behind quite a few others. In its mode that attempts to
conform, the compiler itself is somewhat closer to conforming, but the
implementation overall is MUCH further away, since at that point you
essentially no longer have a standard library at all.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1999/05/11 Raw View
Jerry Coffin wrote:
>
> In article <37374B3C.FA876BEB@wizard.net>, kuyper@wizard.net says...
....
> > The most recent version of MSVC++ that I've used is 2.5, but if half
>
> Not that it really matters, but there never was a version 2.5 -- the
> version number skipped directly from 2.2 to 4.0.
My mistake; it was 1.51, not 2.5.1. I got mixed up because the same
disks had version 2.0 for Windows NT on them (and 1.51 came out
immediately after 1.5, which led me to remember it as 1.5.1). It feels
like a long time ago, but I just counted it out, and it was only about 5
years back.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/05/11 Raw View
In article <3733485E.C8E@wanadoo.fr>,
Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
>
> James.Kanze@dresdner-bank.com wrote:
> >
> > In article <372D7641.203B@wanadoo.fr>,
> > Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
>
> > > It's certainly not fully compliant, by design. VisualAge puts
> > > absolutely everything in a repository, and forget the concepts of
> > > files, translation units, and order. It's wonderful, make
> > > programming simplier (you don't have to include header files
> > > for example), but definitely non conforming.
> >
> > Except for not requiring header files, what is not conforming?
There's
> > nothing in the standard which requires that sources be in files.
>
> I have never said that VisualAge C++ doesn't require TU to be in
> files. I have said that VisualAge C++ doesn't have real TUs.
OK. I'll buy the fact that this renders the compiler non conformant.
> > The
> > standard certainly doesn't require a separate command to compile
each
> > unit separately; it doesn't say anything about how you tell the
system
> > to go from source to executable.
>
> Of course not.
>
> > On the other hand, I've heard (but not been able to personally
confirm)
> > that it doesn't support the keyword export.
>
> ???
>
> AFAIK, everything is always automagically exported everywhere
> with VisualAge C++.
Which isn't the same as supporting the keyword export. (But, except for
variables declared static and unnamed namespaces, exporting everything
everywhere is the normal case for C/C++.)
> VisualAge C++ makes lot of efforts to not understand scope.
But only at what C called the "file scope" level, I hope. Or have I
misunderstood, and it also makes e.g. class variables visible at global
scope?
--
James Kanze mailto:
James.Kanze@dresdner-bank.com
Conseils en informatique orientie objet/
Beratung in objekt orientierter
Datenverarbeitung
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86
27
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/05/11 Raw View
In article <3732FE2F.A9B41A6C@sensor.com>,
Ron Natalie <ron@sensor.com> wrote:
> James.Kanze@dresdner-bank.com wrote:
> > There's
> > nothing in the standard which requires that sources be in files.
> You better read the spec again:
>
> The first section of Chapter 2:
>
> The text of the program is kept in units called source files
> in this internactional standard.
Correct. The text of the program is kept in units [which are undefined
in this international standard] *called* source files in this
international standard.
What the text is actually kept in is not specified by the standard; for
convenience, the standard will *call* whatever it is a source file.
(In addition, the standard doesn't really define the concept of a file.
Is a deck of punched cards a file? A record in a data base?)
> The concept of files, file order, and the ability to use
> include files if the programmer so wishes are required
> concepts for the compiler to support to be conforming.
Yes and no. The "concept" of a file is necessary. Whether this
"concept" corresponds to what is traditionally called a file or not is
up to the implementation to decide. I do not have the slightest doubt
that an implementation can accept (or even require) "sources" to be on
punched cards, and still be fully conforming. I do not have the
slightest doubt, either, that an implementation can accept (or even
require) "sources" to be records in a data base, and still be fully
conforming. (I also do not have the slightest doubt that an
implementation that requires sources to be records in a data base, and
does not provide any means of importing or exporting to classical files,
will not be a big seller.)
Note that I have not actually done more than compile "Hello, world" with
the new Visual Age compiler, and so cannot comment on whether it is
conform or not. (Comments from others would seem to indicate that it
isn't.) However, the fact that it reads its sources from a data base
rather than a traditional file does not in itself make it not conform.
--
James Kanze mailto:
James.Kanze@dresdner-bank.com
Conseils en informatique orient e objet/
Beratung in objekt orientierter
Datenverarbeitung
Ziegelh ttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86
27
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/05/11 Raw View
In article <37337A15.3A1C720B@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
> Jerry Coffin wrote:
> >
> > In article <372F9198.3ADC5584@wizard.net>, kuyper@wizard.net says...
> >
> > [ ... ]
> > > Why is that so? I've more experience with C than C++; most C
> > > compilers I've used will compile a wide range of useful code in
> > > their strictly conforming mode. Why is C++ different in this
> > > regard? (aside from the fact that there's no fully conforming
> > > implementations yet)
> > I've yet to see or hear of a compiler for either C or C++ that
> > rejected any more than a small fraction of code that was not
> > strictly conforming. Just for example, strictly conforming code
> > cannot write to a file, yet I've never heard any compiler having any
> > mode in which writing to a file was rejected.
> I agree - I've never seen a compiler with an option for accepting only
> strictly conforming code. Such a compiler would of course be
> non-conforming.
> There may be a bit of confusion, due to the fact that I echoed Kanze's
> reference to "strictly conforming mode". What he and I should both
have
> said was simply "conforming mode". "strictly conforming" is a term for
> describing code, not implementations.
> If I understood him correctly, he was saying that 99% of all C++
> compilers in their conforming modes would would not accept very many
> useful programs. I've heard that this was true of MSVC++, but is it
> really true of most C++ compilers?
Correct. Several precisions are in order. The most important one is
that I'm talking about complete applications. I would expect (hope)
that in most applications, at least 90% of the modules could be compiled
in conforming mode. And it wasn't my intent to go quite as far as Jerry
Coffin, either, in saying that all IO is unportable (and thus not
strictly conforming). It's just that most programs today will use some
system services somewhere: threading, sockets and a GUI are the most
promenent, but there are so many others as well, that a complete
application of any reasonable size will almost certainly use some of
them. To use them, the code will include the appropriate header. And
at least with most of the compilers I've used, files like unistd.h or
windows.h contain things which don't compile correctly in the conforming
mode of the compiler (or else the conforming mode of the compiler
isn't).
I might add that I haven't truthfully ever tried to compile anything in
conforming mode, other than small test programs. I do note, however,
that all of these files, at least on Solaris, are full of #ifdef's on
POSIX and whatnot -- if you are compiling POSIX compatible, then you are
not in conforming mode.
Anyway, the resulting discussion has been more interesting than my
initial comment, which was made rather lightly.
--
James Kanze mailto:
James.Kanze@dresdner-bank.com
Conseils en informatique orient e objet/
Beratung in objekt orientierter
Datenverarbeitung
Ziegelh ttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86
27
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/05/11 Raw View
In article <9905071341.AA30052@opus.torolab.ibm.com>,
<mendell@VNET.IBM.COM> (Mark Mendell) wrote:
> IBM VAC++ doesn't support export (except in the sense that it allows
> the keyword in the correct places). It does support the rest of
> ANSI/ISO C++.
> The area of non-conformance is in the 'unordered' aspect of the
> system. The compiler will accept code that ANSI/C++ would not, and
> there are a few programs (involving function overloading) that will
> give different behaviour.
> There are plans to fix the 'orderless' non-conformance.
First, I'd like to thank you for the answer. It's nice to get an honest
response from someone who is really in a position to know.
With regards to ordering: the most important aspect of ordering in real
code is probably the order of initialization, which is guaranteed to be
the order of declaration within the translation unit. How do you stand
on this?
Another aspect which would interest me is exporting code as files, so
that I could develop on your system and then port to other systems.
--
James Kanze mailto:
James.Kanze@dresdner-bank.com
Conseils en informatique orient e objet/
Beratung in objekt orientierter
Datenverarbeitung
Ziegelh ttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86
27
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Martin von Loewis <loewis@informatik.hu-berlin.de>
Date: 1999/05/11 Raw View
David Hunter <djhunter@my-dejanews.com> writes:
> On thing I would find useful would be for compiler producers to publish
> more information concerning what external compliance test suites they
> use, eg, Plum-Hall, what the measure of compliance was and in what areas
> most of the non-compliant feature reside.
My understanding is that they can't publish results. When you license
such a test suite, you sign an NDA which forbids you to publish the
conformance results you obtain. Please note that this is hearsay; I
have not actually licensed a C++ test suite (and if I did, I could not
tell you :-).
Regards,
Martin
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1999/05/12 Raw View
In article <37377FE2.19E18AAC@wizard.net>, kuyper@wizard.net says...
[ ... compliance of different versions of MS VC++ ]
> My mistake; it was 1.51, not 2.5.1. I got mixed up because the same
> disks had version 2.0 for Windows NT on them (and 1.51 came out
> immediately after 1.5, which led me to remember it as 1.5.1). It feels
> like a long time ago, but I just counted it out, and it was only about 5
> years back.
Ah, now 1.x certainly wasn't even vaguely close to compliant, lacking
even a hint of support for templates, exception handling, namespaces,
etc. While VC++ 6.0 isn't exactly state of the art, it's at least a
lot closer. With 1.x, you actually DO get slightly closer conformity
with the standard by using /Za than not, though most of the difference
in this case is enforcing the fact that things like `near' and `far'
aren't keywords. By contrast, the current version changes things that
were (apparently) intentionally made non-compliant in the default
mode, such as the well-known situation with the scope of variables
declared in the header of a for-statement.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Jerry Leichter <leichter@smarts.com>
Date: 1999/05/12 Raw View
| With regards to ordering [in Visual Age C++]: the most important
| aspect of ordering in real code is probably the order of
| initialization, which is guaranteed to be the order of declaration
| within the translation unit. How do you stand on this?
As far as I can determine, order of initialization is exactly as in the
Standard.
| Another aspect which would interest me is exporting code as files, so
| that I could develop on your system and then port to other systems.
This question is based on a misunderstanding.
Visual Age C++ - at least in Version 4, but I think this was always the
case - is perfectly capable of *reading* source files. You *can* use
its IDE - just as you can use Microsoft's IDE - and never really think
about files; but you don't have to. Even if you do, there's still a
textual representation of what you typed there somewhere, and I'm pretty
sure you can export it to actual files. VAC builds a compilation
database from all the input files; other compilers do the same kind of
thing in more limited ways (template instantiation databases; the
"object files" that really contain compiler intermediate representations
at the higher, global-optimization levels of HP's aCC; various pre-
compiled header solutions). VAC just goes quite a bit further in
*using* its database - not only to do minimal recompilation, but to
change the semantics of the language ("orderless programming").
We maintain a large collection of C++ code across multiple systems,
including AIX. We recently looked into replacing our old xlC compiler
with VAC. What killed this was not orderless programming or anything of
that sort; it was that the compiler has *no* command line interface:
You can't use a Makefile to invoke it. Rather, you have to use VAC's
own configuration description language. VAC comes with a utility to
convert existing Makefiles into its descriptions, but the results
usually need some hand tuning. Since we generate our Makefiles from our
own description language, this would have been impossible for us to deal
with. (Actually, in theory, you could produce a description language
file for each individual source file. But that gets very messy, and
probably would produce terrible performance.) If I remember right, VAC
will also produce a Makefile for you from its database (the theory being
that you can use VAC as your primary development system, then export to
other "more primitive" systems).
Getting this information out of IBM required going through several
support layers - the general line is that "the compiler" *does* support
Makefiles. (If you read closely, "it" supports them either (a) by
conversion; (b) through the use of *another* compiler that ships on the
same kit, a newer (non-Standard) version of the older xlC compiler.
I'm told that true support for Makefile's is going to be part of VAC
5.0; but there are no estimates on when that will be available.
Clearly, with 5.0 the VAC developers are admitting that they are not
going to convince the whole rest of the world to do things *their* way.
(Not that there's anything wrong with their way, on principle. If I
could afford use it, I'd love to work with a compiler that, when I
changed a comment in an include file, knew enough not to recompile
everything. And when I changed just one typedef, knew enough only to
recompile code that actually uses the typedef. All the sorts of things
that VAC says it can do. Then again, I'd also love to pre-compile some
of my standard headers and probably cut my compilation times on HPUX by
quite a bit. Unfortunately, none of these are practical in the multi-
platform development world I live in.)
-- Jerry
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: mfinney@lynchburg.net (Michael Lee Finney)
Date: 1999/05/13 Raw View
In article <3739D322.7EA@smarts.com>, leichter@smarts.com says...
> What killed this was not orderless programming or anything of
> that sort; it was that the compiler has *no* command line interface:
I use VAC 4.0 and I do not use the IDE. I use source files, I create a text
file which describes the source file to the VAC compiler, and I use vacbld
to run the compiler. I generate separate .obj and .lib files for some
projects and .exe files for others. I can kick off vacbld from a makefile
just fine, although I would have to have a separate description file for
each source file. But I could do it. I have source files which have global
macros and those which do not. It is even possible to start vacbld so that
it uses a "fresh" repository for each compile. Which eliminates much of the
retained information between source files -- not that I have found a reason
to do so.
I also maintain source across several platforms (NT, HPUX, AIX and Solaris)
and have not found any problem with my code compiling under all platforms,
including MSVC 5.0 for NT and VAC 4.0 for NT (and OS/2 -- which I did for an
experiment, but we are not supporting that platform).
I have even tried modes of using the VAC compiler where I keep all of the
header files intact. VAC works just fine under those circumstances. I was
skeptical originally about the lack of directly building from a makefile,
but so far everything has worked just fine. Especially when I consider that
I have to port the makefile to every platform anyway. I have yet to have a
make file that runs unchanged between platforms.
The one place that I do consider slightly more serious is that there is no
way to run the preprocessor on a source file to obtain the preprocessed
source. I have occasionally done that and fed the result back into another
compilation pass for some complex setups. No way with VAC. There was some
experimental code that I had for a persistence library that used that
capability. I could not port that to VAC 4.0 (3.5 was just fine, however).
Nevertheless, so far as I know, that is not a requirement of the C++
standard, so the fact that VAC doesn't allow it is no reason to complain.
--
Michael Lee Finney
michael.finney@acm.org
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <dtribble@technologist.com>
Date: 1999/05/14 Raw View
Jerry Coffin wrote:
> IMO, the notion of strictly conforming code, is useful -- quite a bit
> of code isn't concerned with directly producing output, and _can_ be
> written to be entirely portable to any conforming implementation of C
> or C++, even though a complete program that makes use of the code will
> undoubtedly make use of (at least) implementation-defined behavior
> before all is said and done.
As I've posted elsewhere (news:comp.std.c) recently, a good case can
be made that most of the standard library (sans I/O functions and a
few other sundries) can be written in strictly conforming C++.
-- David R. Tribble, dtribble@technologist.com --
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1999/05/14 Raw View
In article <373B6DDB.26A69A1D@technologist.com>,
dtribble@technologist.com says...
[ ... ]
> As I've posted elsewhere (news:comp.std.c) recently, a good case can
> be made that most of the standard library (sans I/O functions and a
> few other sundries) can be written in strictly conforming C++.
Indeed true -- in fact, even a lot of what people think of as I/O
functions can be written in strictly conforming code as well. Just
for example, _most_ of the iostreams libraries (as well as printf,
scanf, etc.) are really devoted to buffer management, formatting and
such. All of this can be done in strictly conforming code.
E.g. if you're writing an ostream, about the only thing that isn't
strictly conforming code is handling buffer overflow. The vast
majority of code is devoted to filling the buffer, which can all be
strictly conforming. If a library vendor is interested primarily or
exclusively in one platform, they might use extensions for the sake of
efficiency, but they're certainly not needed; from what I've seen,
with a good compiler, extensions aren't really needed very badly, as
standard code can be quite efficient.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <dtribble@technologist.com>
Date: 1999/05/14 Raw View
Dixitque nicka@my-dejanews.com (nicka@my-dejanews.com) wrote
>| For example, the VC compiler was claimed at
>| somewhere over 90% compliance with Plum Hall by Microsoft I believe.
>| Not only couldn't other people reproduce these numbers, the switches
>| required probably prevent you from compiling pretty much any useful
>| program.
Stan Brown <brahms@mindspring.com> wrote
>> You could remove the "probably" from that. With the /Za switch
>> (disable extensions), you can't compile many of the standard headers
>> that Microsoft supplies.
Ed Brey wrote:
> It gets worse. With Microsoft "extensions" enabled, dozens of new
> C++ functions in the math library are *disabled*.
>...
One of those "extensions" is for compiling code for DLLs. I would
wager that a fair majority of code compiled under VC++ is destined
for use in DLLs; it's getting more and more impossible to write
Windows code that isn't DLL-able. Therefore most useful Windows
code requires at least one "extension", and conformance goes out the
window.
> Clearly, this is a case of Microsoft choosing not to spend the time to
> get its header files right. This is the price the customers pay for
> Microsoft not writing type-safe headers in the first place.
It would be safe to say (and many others have indeed said this) that
Micrsoft kicks and screams its way towards standards compliance,
and it seems apparent that they have very little interest in letting
users compile "conforming", let alone "portable", code (i.e., code
targeted at anything other than Microsoft systems).
>> It's bad enough that this was true in 5.0. If, as I've been told,
>> it's also true in 6.0, the word that comes to mind is "criminal".
In this case, "criminal" = "profitable".
-- David R. Tribble, dtribble@technologist.com --
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Ron Natalie <ron@sensor.com>
Date: 1999/05/09 Raw View
Jerry Coffin wrote:
> I've yet to see or hear of a compiler for either C or C++ that
> rejected any more than a small fraction of code that was not strictly
> conforming. Just for example, strictly conforming code cannot write
> to a file, yet I've never heard any compiler having any mode in which
> writing to a file was rejected.
Eh? What do you have against fstreams?
You can write conforming code that does anything you want. Just
because it calls subroutines not addressed by the standard doesn't
make it non conforming (as long as they don't do something stupid
and pollute one of the standard namespaces).
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1999/05/09 Raw View
Jerry Coffin wrote:
>
> In article <372F9198.3ADC5584@wizard.net>, kuyper@wizard.net says...
>
> [ ... ]
>
> > Why is that so? I've more experience with C than C++; most C compilers
> > I've used will compile a wide range of useful code in their strictly
> > conforming mode. Why is C++ different in this regard? (aside from the
> > fact that there's no fully conforming implementations yet)
>
> I've yet to see or hear of a compiler for either C or C++ that
> rejected any more than a small fraction of code that was not strictly
> conforming. Just for example, strictly conforming code cannot write
> to a file, yet I've never heard any compiler having any mode in which
> writing to a file was rejected.
I agree - I've never seen a compiler with an option for accepting only
strictly conforming code. Such a compiler would of course be
non-conforming.
There may be a bit of confusion, due to the fact that I echoed Kanze's
reference to "strictly conforming mode". What he and I should both have
said was simply "conforming mode". "strictly conforming" is a term for
describing code, not implementations.
If I understood him correctly, he was saying that 99% of all C++
compilers in their conforming modes would would not accept very many
useful programs. I've heard that this was true of MSVC++, but is it
really true of most C++ compilers?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: comeau@panix.com (Greg Comeau)
Date: 1999/05/09 Raw View
In article <372c55ae@news1.us.ibm.net> idanan@ibm.net writes:
>In <7g38ai$o56$1@engnews1.eng.sun.com>, clamage@eng.sun.com (Steve Clamage) writes:
>>"Scott Robert Ladd" <srladd@frontier.net> writes:
>[CUT]
>>>It ain't easy. I've encountered many different "interpretations" of Standard
>>>C++...
>>
>>I don't think you are finding different interpretations of Standard
>>C++. I think you are seeing that some features have not yet been
>>implemented according to the standard (which in some cases the
>>vendor will document). No compiler yet claims to be fully compliant
>>with the standard. It takes time to get all the features fully
>>implemented.
>
>Actually, that is not correct. IBM VisualAge C++ 4.0 Professional is
>fully ISO Standard C++ compliant. It works extremely well and from
>personal experience, its compliance appears complete.
I've been following the correspondence on this thread and the claim that
what Valentin is saying is not true. Clearly, it is true.
IBM marketing is just being manipulative, and since January their tactics
seems to be working in spreading this kind of information. Please don't
tow the company line. Let's cut the chase. Various IBM literature and
such has subtle and explicit claims about complete support of
"all of the new ANSI language features and class libraries."
But when you read/ask/look deeper, you'll find that they really mean that
they have full support Standard C++
"except for the effect of orderless programming"
And also they'll state:
"strictly speaking, VisualAge C++ 4.0 does not enforce all of the
language rules."
Uh, yeah, duh, definitely we should discuss support strictly speaking
and not marketing games speaking.
So, let's not double talk it, because the above is clear, from them,
that it's not complete or full or Standard or compliant.
Let's not confuse this with that IBM C++ is an excellent product,
may be close to compliant, orderless programming has merits, etc.
Those are good points but completely seperate issues.
There are a lot of words vendors use, and full does not yet mean full.
Actually, I would love to hear there is a full implementation (and with
some reasonable information to back it up (since IMO at some level proving
you are really fully conformant is not obvious)) but we are not there yet.
>Borland C++ Builder 4 (from Inprise) claims to be fully compliant too.
>I have not used it, so I can't say if its true or not.
I don't see how they claim this either. Point us to where you have
seem them say this in such exact words.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/05/09 Raw View
In article <MPG.119cd8ac33c59dd5989a7d@news.mindspring.com>, Jerry
Coffin <jcoffin@taeus.com> writes
>I've yet to see or hear of a compiler for either C or C++ that
>rejected any more than a small fraction of code that was not strictly
>conforming. Just for example, strictly conforming code cannot write
>to a file, yet I've never heard any compiler having any mode in which
>writing to a file was rejected.
Hmm... Have you ever tried to write useful strictly conforming code?
Just for starters, how do you get any output from strictly conforming
code? Conforming code is fine, but strictly conforming places extra
burdens (it is a technical term in C and AFAIK has no equivalent in C++)
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Ron Natalie <ron@sensor.com>
Date: 1999/05/09 Raw View
David Binderman wrote:
>
> I think Meyers indicates that these can be simulated in about
> three lines of code.
Unfortunately, it's not true. While you can make "bool" like
things, you still have to head stand to get things to work
right in all instances whether you make a bool UDT or you
just typedef it to int.
>
> >It's library isn't even close to STL or the standard.
>
> True. My customers mostly haven't heard of the STL, so they don't care
> about it.
>
> Some have heard about the standard, even if they have not seen it.
My customers wouldn't know C++ if it jumped up and snatched them
bald headed. However, what I am trying to do is develop applications
for multiple platforms without driving myself crazy (or bankrupt).
Standard containers greatly assist that. We end up lugging around
the SGI STL implementation just to deal with the least common
denominator of C++ implementations we are forced to put up with
(and SparcWerks 4.2 is at the bottom of the pile right now)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: comeau@panix.com (Greg Comeau)
Date: 1999/05/09 Raw View
In article <925349314.958.32@news.remarQ.com> "Scott Robert Ladd" <srladd@frontier.net> writes:
>....
>It all depends on the complexity of the code being ported, and the level of
>C++ being used. I can write a million line program that does nothing more
>than simple assignments and functions calls; clearly, such a program will
>port across multiple platforms, yet it provides no insight into how well
>various compilers support Standard language features.
>
>In my case, the applications use templates, multiple inheritance, and some
>pretty complex class trees. Nothing in the code is designed for Wintel, nor
>do I use any of Microsoft's unique keywords.
>
>As has often been pointed out: There is no such thing as a 100% compliant
>C++ compiler. Therefore, it seems to me that documenting and understanding
>the different implementations is important.
Understanding the differences is definitely important to many.
I wonder how biased/incomplete/outdated such a document would be though.
As a complementary issue (not a solution) finding multi-platform compilers
and/or compilers compatible with other compilers on things like templates
can go a long way too.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1999/05/10 Raw View
In article <37337A15.3A1C720B@wizard.net>, kuyper@wizard.net says...
[ ... ]
> If I understood him correctly, he was saying that 99% of all C++
> compilers in their conforming modes would would not accept very many
> useful programs. I've heard that this was true of MSVC++, but is it
> really true of most C++ compilers?
I'm not sure about most C++ compilers, but I know of at least some
others that seem to come much closer to conforming with the standard,
while accepting at least a reasonable percentage of programs that (I
believe to be) written in accordance with the standard.
Speaking from personal experience, Intel's C++ compiler is certainly a
great deal closer to the standard. Using /Za (which it also accepts
as asking it to comply as closely as it can with the standard) it
still accepts at least the standard headers I've used. I've made no
particular attempt at using every standard header and there are quite
a few I'm pretty sure I've never used (E.g. those in appendix D.7), so
I can't say it works with every one, but so far it hasn't had a
problem with the ones I've tried.
This is particularly interesting because Intel's compiler is normally
installed as an adjunct to VC++, replacing MS's compiler, but using
its standard headers and libraries (with only a few additions of its
own).
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1999/05/10 Raw View
In article <zTRpYXA2vAN3EwrP@robinton.demon.co.uk>,
francis@robinton.demon.co.uk says...
> In article <MPG.119cd8ac33c59dd5989a7d@news.mindspring.com>, Jerry
> Coffin <jcoffin@taeus.com> writes
> >I've yet to see or hear of a compiler for either C or C++ that
> >rejected any more than a small fraction of code that was not strictly
> >conforming. Just for example, strictly conforming code cannot write
> >to a file, yet I've never heard any compiler having any mode in which
> >writing to a file was rejected.
>
> Hmm... Have you ever tried to write useful strictly conforming code?
No -- in fact, I'm reasonably certain there is no such thing, at least
as the term "strictly conforming" is defined in the C standard.
> Just for starters, how do you get any output from strictly conforming
> code?
As I said (or at least implied) above, I'm reasonably certain a
strictly conforming cannot produce any output.
> Conforming code is fine, but strictly conforming places extra
> burdens (it is a technical term in C and AFAIK has no equivalent in C++)
Conforming code is fine, but so broad a term as to be essentially
meaningless.
I was NOT trying to say that I thought compilers should provide such a
mode, or even that I thought it would be particularly useful to do so,
only that I was reasonably certain no such thing existed. I believe
it was James Kanze who made the statement to which I was replying. At
least as I understand it, English is not his native language, which
may or may not have been a factor -- I rather suspect it was, but I'm
not sure.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David Binderman <dcb@pncl.co.uk>
Date: 1999/05/10 Raw View
nicka@my-dejanews.com wrote:
> On thing I would find useful would be for compiler producers to publish
> more information concerning what external compliance test suites they use,
> eg, Plum-Hall, what the measure of compliance was and in what areas most of
> the non-compliant feature reside. Also good would be some indication of when
> or in what future version these areas of compliance will be addressed.
Good idea in theory, but I think most marketing departments would stop
this.
I've been buying for 5+ years C++ compilers, all of which claim
ANSI (never ISO) C++ conformance.
It would be a bit odd for them now start to be honest, and declare
that some fraction of some test suite doesn't work correctly.
However useful such information would be to users.
Similar things can be said for the bugs reported & fixed on
a previous release of a compiler.
Such information is very commercially sensitive.
> Of course, what you *really* want also is a list of the compiler switches
> required to get the conformance For example, the VC compiler was claimed at
> somewhere over 90% compliance with Plum Hall by Microsoft I believe. Not only
> couldn't other people reproduce these numbers, the switches required probably
> prevent you from compiling pretty much any useful program.
Exactly. I've given up asking about conformance. I now ask about
things like
a) warnings for shallow copy/deep copy problems.
b) warnings for variables declared without initialisation.
and others which are nothing to do with the standard, but do help much
more
to write code that works.
Regards
dcb
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1999/05/10 Raw View
In article <7gvka9$356$1@engnews1.eng.sun.com>,
stephen.clamage@sun.com says...
>
> jcoffin@taeus.com (Jerry Coffin) writes:
>
> >In article <372F9198.3ADC5584@wizard.net>, kuyper@wizard.net says...
>
> >> Why is that so? I've more experience with C than C++; most C compilers
> >> I've used will compile a wide range of useful code in their strictly
> >> conforming mode. Why is C++ different in this regard? (aside from the
> >> fact that there's no fully conforming implementations yet)
>
> >I've yet to see or hear of a compiler for either C or C++ that
> >rejected any more than a small fraction of code that was not strictly
> >conforming. Just for example, strictly conforming code cannot write
> >to a file, yet I've never heard any compiler having any mode in which
> >writing to a file was rejected.
>
> We have to be careful with terminology like "conforming" and
> "strictly conforming".
I am, and I use them advisedly.
> In the C standard, a "conforming" hosted implementation accepts
> any strictly-conforming program. An implementation is allowed to
> have extensions. (A "hosted" implementation supports the full
> language and library, meaning it has I/O, among other things.)
Yes, it has I/O functions. Unfortunately, USING the output functions
gives implementation-defined results. If the stream is opened in
translated mode "there need not be a one-to-one correspondence between
the characters in a stream and the external representation" (C std.,
7.9.2). If it's opened in binary mode it "may, however have an
implementation defined number of null characters appended to the end
of the stream." (also section 7.9.2) I.e. all output to files is
implementation-defined to at least some extent in C. I haven't
checked in as much detail in the C++ standard, but I believe its I/O
is defined in a similar enough manner that the same problems arise.
As such, a strictly conforming program can depend upon the existence
of the I/O functions. It could, for example, take the address of
printf if it chose to do so. What it can't do is actually CALL one of
them, which renders just about everything else it can do pretty well
useless.
> A merely "conforming" C program can depend on unportable behavior
> of the implementation for which it is intended.
Unfortunately, the wording in the C standard simply says that it's
"acceptable to a conforming implementation." It's been argued that
since some versions of gcc accept FORTRAN and Objective-C in addition
that to C and C++, that this makes all FORTRAN, Objective-C and C++
programs conforming C programs, even though FORTRAN programs (for
example) bear virtually no resemblance to C programs at all.
> If you want to talk about conforming or strictly-conforming C++
> programs, you'd have to define the terms, because the C++ standard
> does not. I think the C definitions would be useful.
I disagree -- since a strictly conforming program can't write to a
file, and writing to a file is just about the only way of producing
output that's even close to portable, strictly conforming programs are
basically prevented from doing anything useful at all.
At the opposite extreme, conforming programs include those that make
use of any extension available in any conforming implementation,
including extensions that directly violate the basic syntax, grammar,
etc., of the language. As such, it's so broad as to be essentially
meaningless.
IMO, the notion of strictly conforming code, is useful -- quite a bit
of code isn't concerned with directly producing output, and _can_ be
written to be entirely portable to any conforming implementation of C
or C++, even though a complete program that makes use of the code will
undoubtedly make use of (at least) implementation-defined behavior
before all is said and done.
The notion of conforming is, IMO, utterly useless as defined. Knowing
that some code is conforming tells you nothing about it whatsoever,
and (particularly) gives you not even a vague notion of whether it
will compile and work on any particular conforming implementation.
IMO, what's needed is a word or phrase to describe programs that do
not use undefined behavior at all, do not violate any rule or
constraint in the standard, and for which the output does not depend
upon unspecified behavior.
Even though the output could depend upon implementation-defined
behavior, the author would, for example, be assured that it would be
accepted and would do something on any conforming implementation.
A program that falls into this (presently nameless) category is
probably something like 99% portable -- it'll do pretty much what you
expect on any conforming implementation anybody's likely to care
about, even though somebody with malice aforethought could create an
implementation that's technically conforming, but would produce
useless output for nearly any program you fed it.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David Binderman <dcb@pncl.co.uk>
Date: 1999/05/07 Raw View
Ron Natalie wrote:
> David Binderman wrote:
>
> > For what nearly all of my customers want me to do, Sun C++ 4.2 works
> > extremely well and appears to be compliant.
>
> Is this sarcasm?
Sadly, no. The operative word is appears.
Compliance only matters if you write C++ code that is acceptable
to a mere fraction of the compilers you are interested in.
I, and lots of other C++ coders, write in subset-C++, which
is
a) that part of C++ that all C++ compilers accept.
b) that part of C++ Joe Ordinary Programmer can understand.
At the moment, subset-C++ is approx cfront 3.0 + exceptions.
>4.2 doesn't even have bool types.
I think Meyers indicates that these can be simulated in about
three lines of code.
>It's library isn't even close to STL or the standard.
True. My customers mostly haven't heard of the STL, so they don't care
about it.
Some have heard about the standard, even if they have not seen it.
>Hopefully, 5.0 is better.
I think you are on safe ground there.
Regards
dcb
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1999/05/07 Raw View
In article <372F9198.3ADC5584@wizard.net>, kuyper@wizard.net says...
[ ... ]
> Why is that so? I've more experience with C than C++; most C compilers
> I've used will compile a wide range of useful code in their strictly
> conforming mode. Why is C++ different in this regard? (aside from the
> fact that there's no fully conforming implementations yet)
I've yet to see or hear of a compiler for either C or C++ that
rejected any more than a small fraction of code that was not strictly
conforming. Just for example, strictly conforming code cannot write
to a file, yet I've never heard any compiler having any mode in which
writing to a file was rejected.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Biju Thomas <b_thomas@ibm.net>
Date: 1999/05/07 Raw View
Ron Natalie wrote:
>
> James.Kanze@dresdner-bank.com wrote:
> >
> > There's
> > nothing in the standard which requires that sources be in files.
>
> The first section of Chapter 2:
>
> The text of the program is kept in units called source files
> in this internactional standard.
>
But, does it say that 'source files' should be the ordinary operating
system files? Why can't the data in a repository be considered 'source
file'?
--
Biju Thomas
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: nicka@my-dejanews.com
Date: 1999/05/07 Raw View
David Hunter wrote:
In article <925349314.958.32@news.remarQ.com>,
"Scott Robert Ladd" <srladd@frontier.net> wrote:
>
> As has often been pointed out: There is no such thing as a 100% compliant
> C++ compiler. Therefore, it seems to me that documenting and understanding
> the different implementations is important.
>
>
On thing I would find useful would be for compiler producers to publish
more information concerning what external compliance test suites they use,
eg, Plum-Hall, what the measure of compliance was and in what areas most of
the non-compliant feature reside. Also good would be some indication of when
or in what future version these areas of compliance will be addressed.
David Hunter
Of course, what you *really* want also is a list of the compiler switches
required to get the conformance For example, the VC compiler was claimed at
somewhere over 90% compliance with Plum Hall by Microsoft I believe. Not only
couldn't other people reproduce these numbers, the switches required probably
prevent you from compiling pretty much any useful program.
Nick
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1999/05/07 Raw View
In article <37338FAE.6AAE@pncl.co.uk>, dcb@pncl.co.uk says...
[ ... ]
> >4.2 doesn't even have bool types.
>
> I think Meyers indicates that these can be simulated in about
> three lines of code.
Yes and no. You can do what can be done in a relatively small amount
of code, but bool was added to the language largely because no matter
how much code or work you put into it, you can't simulate it
completely.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: gbush@my-dejanews.com
Date: 1999/05/07 Raw View
In article <372DC4D6.7B12142F@sensor.com>,
Ron Natalie <ron@sensor.com> wrote:
>
> David Binderman wrote:
>
> > For what nearly all of my customers want me to do, Sun C++ 4.2 works
> > extremely well and appears to be compliant.
>
> Is this sarcasm? 4.2 doesn't even have bool types. It's library
> isn't even close to STL or the standard. Hopefully, 5.0 is better.
You are right, SC 4.2 is archaic. It doesn't support even what other
compilers supported 3 years ago. SC 5.0 is somewhat better, reducing that gap
to 2 years. Gene.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1999/05/07 Raw View
jcoffin@taeus.com (Jerry Coffin) writes:
>In article <372F9198.3ADC5584@wizard.net>, kuyper@wizard.net says...
>> Why is that so? I've more experience with C than C++; most C compilers
>> I've used will compile a wide range of useful code in their strictly
>> conforming mode. Why is C++ different in this regard? (aside from the
>> fact that there's no fully conforming implementations yet)
>I've yet to see or hear of a compiler for either C or C++ that
>rejected any more than a small fraction of code that was not strictly
>conforming. Just for example, strictly conforming code cannot write
>to a file, yet I've never heard any compiler having any mode in which
>writing to a file was rejected.
We have to be careful with terminology like "conforming" and
"strictly conforming".
In the C standard, "strictly conforming" applies only to a program,
not to an implementation, and means a program whose output does not
depend on any undefined, implementation-defined, or unspecified
behavior, and that does not exceed any translation limit. It will
run on any conforming implementation. It is maximally portable.
In the C standard, a "conforming" hosted implementation accepts
any strictly-conforming program. An implementation is allowed to
have extensions. (A "hosted" implementation supports the full
language and library, meaning it has I/O, among other things.)
A conforming C compiler is not obligated to diagnose departures
from strictly-conforming code, unless some rule or constraint
is also violated.
A merely "conforming" C program can depend on unportable behavior
of the implementation for which it is intended.
The C++ standard does not have the notion of a conforming or
strictly-conforming program. (An early project editor insisted on
not talking about programs. I never did and still do not
understand why.) It has only the notion of a "conforming
implementation." It has some language to explain that when
it appears to talk about programs, it is really talking about how
the implemenation responds to such programs.
If you want to talk about conforming or strictly-conforming C++
programs, you'd have to define the terms, because the C++ standard
does not. I think the C definitions would be useful.
--
Steve Clamage, stephen.clamage@sun.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <Bonnard.V@wanadoo.fr>
Date: 1999/05/07 Raw View
James.Kanze@dresdner-bank.com wrote:
>
> In article <372D7641.203B@wanadoo.fr>,
> Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> > It's certainly not fully compliant, by design. VisualAge puts
> > absolutely everything in a repository, and forget the concepts of
> > files, translation units, and order. It's wonderful, make
> > programming simplier (you don't have to include header files
> > for example), but definitely non conforming.
>
> Except for not requiring header files, what is not conforming? There's
> nothing in the standard which requires that sources be in files.
I have never said that VisualAge C++ doesn't require TU to be in
files. I have said that VisualAge C++ doesn't have real TUs.
> The
> standard certainly doesn't require a separate command to compile each
> unit separately; it doesn't say anything about how you tell the system
> to go from source to executable.
Of course not.
> On the other hand, I've heard (but not been able to personally confirm)
> that it doesn't support the keyword export.
???
AFAIK, everything is always automagically exported everywhere
with VisualAge C++.
VisualAge C++ makes lot of efforts to not understand scope.
--
Valentin Bonnard
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <Bonnard.V@wanadoo.fr>
Date: 1999/05/07 Raw View
Ron Natalie wrote:
>
> James.Kanze@dresdner-bank.com wrote:
> >
> > There's
> > nothing in the standard which requires that sources be in files.
>
> You better read the spec again:
>
> The first section of Chapter 2:
>
> The text of the program is kept in units called source files
> in this internactional standard.
You better read the sentences you quote. It defines a term,
so it cannot at the same time require something.
--
Valentin Bonnard
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: brahms@mindspring.com (Stan Brown)
Date: 1999/05/08 Raw View
Dixitque nicka@my-dejanews.com (nicka@my-dejanews.com) in comp.std.c++:
>For example, the VC compiler was claimed at
>somewhere over 90% compliance with Plum Hall by Microsoft I believe. Not only
>couldn't other people reproduce these numbers, the switches required probably
>prevent you from compiling pretty much any useful program.
You could remove the "probably" from that. With the /Za switch (disable
extensions), you can't compile many of the standard headers that
Microsoft supplies.
It's bad enough that this was true in 5.0. If, as I've been told, it's
also true in 6.0, the word that comes to mind is "criminal".
--
There's no need to e-mail me a copy of a follow-up; but if you do,
please identify it as such.
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Ron Natalie <ron@sensor.com>
Date: 1999/05/09 Raw View
Biju Thomas wrote:
>
> >
> > The text of the program is kept in units called source files
> > in this internactional standard.
> >
>
> But, does it say that 'source files' should be the ordinary operating
> system files? Why can't the data in a repository be considered 'source
> file'?
>
If it has the same behavior as a source file as defined by
the standard it could be. But the repository doesn't provide
that concept. The repository doesn't do this. I only posted
the first sentence of Chapter 2 because someone said that the
standard didn't even have the concept. If you continue to
read Chapter 2 and the Chapters 16 and 17 and so forth.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/05/06 Raw View
In article <372f2100.13313396@nr1.toronto.istar.net>,
hsutter@peerdirect.com (Herb Sutter) wrote:
> On 04 May 99 08:32:22 GMT, Jim Hyslop <jim.hyslop@leitch.com> wrote:
> >Ah, that's what I've been looking for - is there any formal, independent
> >validation process in the works?
> Not that I know of, unless there's a FIPS number or something.
> >Around the time the Standard was being voted out of Committee, I
> >posted a question in this newsgroup asking if there would be any
> >standard test suite so that you could measure and clearly define (as
> >far as possible) a compiler's conformance. There were absolutely no
> >responses ;-)
> It was left as an opening for entrepreneurs. :) Several companies
> (Perennial comes to mind) create and sell conformance test suites for
> C++. Their customers are typically large organizations that have
> mandated conformance on RFPs (so that they have something to check
> against), and the compiler vendors themselves (as an extra QA tool,
> and/or to make sure that they're conforming).
Not just for mandated conformance. Such validation suites are
invaluable tools for compiler evaluation. (Most serious vendors will
provide you with a demo license which lasts long enough to do the
evaluation.)
--
James Kanze mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orientie objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86 27
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/05/07 Raw View
In article <372DC4D6.7B12142F@sensor.com>,
Ron Natalie <ron@sensor.com> wrote:
>
> David Binderman wrote:
>
> > For what nearly all of my customers want me to do, Sun C++ 4.2 works
> > extremely well and appears to be compliant.
>
> Is this sarcasm?
Probably more like realism. Maybe David has a real job, where he has to
produce working programs, rather than experiment with new features.
> 4.2 doesn't even have bool types. It's library
> isn't even close to STL or the standard. Hopefully, 5.0 is better.
Better is relative. If I have to by a new version of third party
software, because the old version was compiled with 4.2, and doesn't
link with the new version, then the new compiler is definitly not better
(unless it is link compatible). Bool is nice. STL can be useful. But
I managed to write significant applications without them.
Sun C++ 4.2 has was enormously useful feature that all newer compilers
lack (by definition): it's been around awhile. So it is a known factor.
--
James Kanze mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orientie objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86 27
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Ron Natalie <ron@sensor.com>
Date: 1999/05/07 Raw View
James.Kanze@dresdner-bank.com wrote:
>
> There's
> nothing in the standard which requires that sources be in files.
You better read the spec again:
The first section of Chapter 2:
The text of the program is kept in units called source files
in this internactional standard.
The concept of files, file order, and the ability to use
include files if the programmer so wishes are required
concepts for the compiler to support to be conforming.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1999/05/07 Raw View
James.Kanze@dresdner-bank.com wrote:
....
> > > Standard C++ is a _subset_ of the IBM compiler.
> >
> > That is to say: VisualAgeC++ will accept incorrect programs
> > w/o any diagnostic.
>
> So will just about any compiler I know of. Many will have a strictly
> conforming mode which will not accept any incorrect programs. 99% of
> the time, the strictly conforming mode will not accept very many useful
> programs either.
Why is that so? I've more experience with C than C++; most C compilers
I've used will compile a wide range of useful code in their strictly
conforming mode. Why is C++ different in this regard? (aside from the
fact that there's no fully conforming implementations yet)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1999/05/07 Raw View
James.Kanze@dresdner-bank.com wrote:
>
> In article <372DC4D6.7B12142F@sensor.com>,
> Ron Natalie <ron@sensor.com> wrote:
> >
> > David Binderman wrote:
> >
> > > For what nearly all of my customers want me to do, Sun C++ 4.2 works
> > > extremely well and appears to be compliant.
> >
> > Is this sarcasm?
>
> Probably more like realism. Maybe David has a real job, where he has to
> produce working programs, rather than experiment with new features.
If what he meant to say was that the compiler is useful, why didn't he
say so?
'compliant' is a fairly well defined term that has nothing to do with
'useful'.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: <mendell@VNET.IBM.COM> (Mark Mendell)
Date: 1999/05/07 Raw View
IBM VAC++ doesn't support export (except in the sense that it allows the
keyword in the correct places). It does support the rest of ANSI/ISO C++.
The area of non-conformance is in the 'unordered' aspect of the system.
The compiler will accept code that ANSI/C++ would not, and there are
a few programs (involving function overloading) that will give different
behaviour.
There are plans to fix the 'orderless' non-conformance.
Mark Mendell
Visual Age C++ Development
IBM Toronto Lab
mendell@ca.ibm.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Scott Robert Ladd" <srladd@frontier.net>
Date: 1999/04/29 Raw View
>I think this depends strongly on how many WinTel specifics are
>in the code.
It would if I used any Wintel specifics, which I don't. The primary
compatability problems involve the differing levels of support for templates
by various compilers.
>I've had good results porting code to/from Sun C++, Dec C++, H-P C++
>and Linux C++, mostly on much bigger projects than you describe.
It all depends on the complexity of the code being ported, and the level of
C++ being used. I can write a million line program that does nothing more
than simple assignments and functions calls; clearly, such a program will
port across multiple platforms, yet it provides no insight into how well
various compilers support Standard language features.
In my case, the applications use templates, multiple inheritance, and some
pretty complex class trees. Nothing in the code is designed for Wintel, nor
do I use any of Microsoft's unique keywords.
As has often been pointed out: There is no such thing as a 100% compliant
C++ compiler. Therefore, it seems to me that documenting and understanding
the different implementations is important.
>>It ain't easy. I've encountered many different "interpretations" of
Standard
>>C++... I'm almost considering going back to Java! ;>
>If you want a simpler programming language, C++ is a bad
>place to start :->
Java is in no way "simpler" than C++; it is just different. Java is nice in
some ways, but I've found it to be a significant disappointment both in
terms of performance and flexibility.
>I think the useful time for such information has passed.
Perhaps; I, however, am dealing with code in the here and now, as are most
working programmers. I can't write code for what might be available in a
year or more in the future.
== Scott Robert Ladd
srladd@frontier.net
http://www.frontier.net/~srladd
public PGP key: http://www.frontier.net/~srladd/srlpgp.html
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Oleg Zabluda <zabluda@math.psu.edu>
Date: 1999/05/02 Raw View
James.Kanze@dresdner-bank.com wrote:
: But egcs still contains enough
: serious bugs (calling destructors twice on the same variable) to mean
: that it cannot be used for production code,
Funny. SunPro 4.2 definitely contains bugs of similar and greater
severity, yet you've been using it for production code for years.
Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: idanan@ibm.net
Date: 1999/05/03 Raw View
In <7g38ai$o56$1@engnews1.eng.sun.com>, clamage@eng.sun.com (Steve Clamage) writes:
>"Scott Robert Ladd" <srladd@frontier.net> writes:
[CUT]
>>It ain't easy. I've encountered many different "interpretations" of Standard
>>C++...
>
>I don't think you are finding different interpretations of Standard
>C++. I think you are seeing that some features have not yet been
>implemented according to the standard (which in some cases the
>vendor will document). No compiler yet claims to be fully compliant
>with the standard. It takes time to get all the features fully
>implemented.
Actually, that is not correct. IBM VisualAge C++ 4.0 Professional is
fully ISO Standard C++ compliant. It works extremely well and from
personal experience, its compliance appears complete.
Borland C++ Builder 4 (from Inprise) claims to be fully compliant too.
I have not used it, so I can't say if its true or not.
- Itai
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David Binderman <dcb@pncl.co.uk>
Date: 1999/05/03 Raw View
idanan@ibm.net wrote:
> Actually, that is not correct. IBM VisualAge C++ 4.0 Professional is
> fully ISO Standard C++ compliant. It works extremely well and from
> personal experience, its compliance appears complete.
This compliance issue can be overstated.
For what nearly all of my customers want me to do, Sun C++ 4.2 works
extremely well and appears to be compliant.
Of course, it is nowhere near the final standard, but it gets the job
done.
Every single one of the dozen or so C++ Coding Standards I've seen
attempt to limit the complexity of C++. What does that tell you about
a) the complexity of C++
b) the usefulness to Joe Ordinary Programmer of that complexity ?
Lots of folks are shipping useful code, based on a five year
old version of C++.
Regards
dcb
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <Bonnard.V@wanadoo.fr>
Date: 1999/05/03 Raw View
idanan@ibm.net wrote:
> Actually, that is not correct. IBM VisualAge C++ 4.0 Professional is
> fully ISO Standard C++ compliant.
It's certainly not fully compliant, by design. VisualAge puts
absolutely everything in a repository, and forget the concepts of
files, translation units, and order. It's wonderful, make
programming simplier (you don't have to include header files
for example), but definitely non conforming.
--
Valentin Bonnard
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Niclas Granqvist <niclas.granqvist@guestlink.net>
Date: 1999/05/03 Raw View
The repository, file conecpt and translation units are implementation details
of the compiler. You do not have to use orderlessness,
although it is very convenient to have
You can organize you sources/projects exactly as before.
Standard C++ is a _subset_ of the IBM compiler. To say that the compiler is
not ISO/ANSI compliant
is not true. IBM extends ISO/ANSI C++ with orderlessness.
Sources compiled with IBM might not go through other compilers, because
of the orderlessness, so you have to be carefull with this feature.
I do not have access to the C++ standard(so I can not check what the standard
says about this order and organization of projects. I doubt that the standard
is concerned with theese). IMHO IBM does not break anything
in Stroustrup. If somebody could clarify theese matters I would be very
happy.
Niclas Granqvist
Valentin Bonnard wrote:
> idanan@ibm.net wrote:
>
> > Actually, that is not correct. IBM VisualAge C++ 4.0 Professional is
> > fully ISO Standard C++ compliant.
>
> It's certainly not fully compliant, by design. VisualAge puts
> absolutely everything in a repository, and forget the concepts of
> files, translation units, and order. It's wonderful, make
> programming simplier (you don't have to include header files
> for example), but definitely non conforming.
>
> --
>
> Valentin Bonnard
> ---
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <Bonnard.V@wanadoo.fr>
Date: 1999/05/03 Raw View
Niclas Granqvist wrote:
>
> The repository, file conecpt and translation units are implementation details
> of the compiler.
Complete nonsens. Translation units is the basic structure of
a C++ program. They are the top-level grammatical element.
> You do not have to use orderlessness,
> although it is very convenient to have
> You can organize you sources/projects exactly as before.
No you can't. You almost can. That's very different.
> Standard C++ is a _subset_ of the IBM compiler.
That is to say: VisualAgeC++ will accept incorrect programs
w/o any diagnostic.
VisualAge C++ has no option to disable this extention
(but they have that on their TODO list, in order to
make portabillity easier (and perhaps in order to get
official validation)).
> To say that the compiler is
> not ISO/ANSI compliant
> is not true.
VisualAge C++ certainly isn't conforming.
> I doubt that the standard
> is concerned with theese).
Of course it is. Order is the base of C, and C++.
You can use a name if it's in scope, it's in
scope if it appears _before_ the point of use
(well, I know there are exceptions, but you see
my point).
> IMHO IBM does not break anything
> in Stroustrup.
It break correct scoping:
#include <iostream>
void f(int) { std::cout << "int"; }
int main ()
{
f (0.);
}
void f(double) { std::cout << "double"; }
will print int on a normal compiler, and double
on VisualAge C++.
[BTW, that's the first time I see a consumer saying
<< you product is ok >> when the producer says << my
product is (strictly speaking) not correct, even if
it isn't far from conformance >>.]
--
Valentin Bonnard
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Ron Natalie <ron@sensor.com>
Date: 1999/05/03 Raw View
David Binderman wrote:
> For what nearly all of my customers want me to do, Sun C++ 4.2 works
> extremely well and appears to be compliant.
Is this sarcasm? 4.2 doesn't even have bool types. It's library
isn't even close to STL or the standard. Hopefully, 5.0 is better.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/05/03 Raw View
In article <372D7641.203B@wanadoo.fr>,
Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> idanan@ibm.net wrote:
>
> > Actually, that is not correct. IBM VisualAge C++ 4.0 Professional is
> > fully ISO Standard C++ compliant.
>
> It's certainly not fully compliant, by design. VisualAge puts
> absolutely everything in a repository, and forget the concepts of
> files, translation units, and order. It's wonderful, make
> programming simplier (you don't have to include header files
> for example), but definitely non conforming.
Except for not requiring header files, what is not conforming? There's
nothing in the standard which requires that sources be in files. And
although I only glanced at it, it seemed to understand translation
units, and their effects on scope, order of initialization, etc. The
standard certainly doesn't require a separate command to compile each
unit separately; it doesn't say anything about how you tell the system
to go from source to executable.
On the other hand, I've heard (but not been able to personally confirm)
that it doesn't support the keyword export. Which would definitly make
it non-conforming. I've also heard (but only from one source) that it
doesn't support function block exception clauses, which would also
render it non-conforming.
--
James Kanze mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient e objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelh ttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86 27
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David Hunter <djhunter@my-dejanews.com>
Date: 1999/05/03 Raw View
In article <925349314.958.32@news.remarQ.com>,
"Scott Robert Ladd" <srladd@frontier.net> wrote:
>
> As has often been pointed out: There is no such thing as a 100% compliant
> C++ compiler. Therefore, it seems to me that documenting and understanding
> the different implementations is important.
>
>
On thing I would find useful would be for compiler producers to publish
more information concerning what external compliance test suites they
use, eg, Plum-Hall, what the measure of compliance was and in what areas
most of the non-compliant feature reside. Also good would be some indication
of when or in what future version these areas of compliance will be addressed.
David Hunter
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Jim Hyslop <jim.hyslop@leitch.com>
Date: 1999/05/04 Raw View
In article <372DA4D3.322E@wanadoo.fr>,
Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
[snip]
> VisualAge C++ has no option to disable this extention
> (but they have that on their TODO list, in order to
> make portabillity easier (and perhaps in order to get
> official validation)).
Ah, that's what I've been looking for - is there any formal, independent
validation process in the works?
Around the time the Standard was being voted out of Committee, I posted a
question in this newsgroup asking if there would be any standard test suite so
that you could measure and clearly define (as far as possible) a compiler's
conformance. There were absolutely no responses ;-)
--
Jim
I ignore all email from recruitment agencies.
Please do not send me email with questions - post here.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Ron Natalie <ron@sensor.com>
Date: 1999/05/04 Raw View
Niclas Granqvist wrote:
>
> Standard C++ is a _subset_ of the IBM compiler. To say that the compiler is
> not ISO/ANSI compliant
> is not true. IBM extends ISO/ANSI C++ with orderlessness.
> Sources compiled with IBM might not go through other compilers, because
> of the orderlessness,
Compilers that do not issue a diagnostic when accepting programs
that are ill-formed (i.e., will not go through other standard
compilers) are not in comformance with the standard.
It's a two way street (one of my biggest complaints about
EGCS). You need a way to disable these "enhancements' to
be a useful tool for portability.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/05/04 Raw View
In article <372DA4D3.322E@wanadoo.fr>,
Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> Niclas Granqvist wrote:
> > The repository, file conecpt and translation units are implementation
> > details of the compiler.
> Complete nonsens. Translation units is the basic structure of
> a C++ program. They are the top-level grammatical element.
A C++ translation unit, however, does not necessarily have anything to
do with translation. It is only a grammatical unit. From a
programmer's point of view, it's most important aspect is the imposition
of order of initialization of the static variables in the translation
unit. If this is not respected, fully legal, working programs will
break. Reasonable ones, too, not just made up cases.
> > You do not have to use orderlessness,
> > although it is very convenient to have
> > You can organize you sources/projects exactly as before.
>
> No you can't. You almost can. That's very different.
>
> > Standard C++ is a _subset_ of the IBM compiler.
>
> That is to say: VisualAgeC++ will accept incorrect programs
> w/o any diagnostic.
So will just about any compiler I know of. Many will have a strictly
conforming mode which will not accept any incorrect programs. 99% of
the time, the strictly conforming mode will not accept very many useful
programs either.
> VisualAge C++ has no option to disable this extention
> (but they have that on their TODO list, in order to
> make portabillity easier (and perhaps in order to get
> official validation)).
>
> > To say that the compiler is
> > not ISO/ANSI compliant
> > is not true.
>
> VisualAge C++ certainly isn't conforming.
>
> > I doubt that the standard
> > is concerned with theese).
>
> Of course it is. Order is the base of C, and C++.
> You can use a name if it's in scope, it's in
> scope if it appears _before_ the point of use
> (well, I know there are exceptions, but you see
> my point).
Lexical ordering within a translation unit is important. Normally,
however, it will only affect legality; not getting an error when one is
expected is tolerable. If the compiler doesn't respect the order of
initialization within a translation unit, however, then I'd consider
this serious a serious problem.
Of course, since the compiler doesn't use files, they could beg the
question by stating that every top level declaration is a separate
translation unit. Viewed like this, the compiler is fully conformant.
And totally useless, since there would be no way to access a static
variable.
> > IMHO IBM does not break anything
> > in Stroustrup.
>
> It break correct scoping:
>
> #include <iostream>
>
> void f(int) { std::cout << "int"; }
>
> int main ()
> {
> f (0.);
> }
>
> void f(double) { std::cout << "double"; }
>
> will print int on a normal compiler, and double
> on VisualAge C++.
Perhaps, but this is what I'd call a useless side-effect of the standard
rules. I seriously doubt that Stroustrup writes code like this.
On the other hand, what happens if the second declaration of f is in
another "translation unit"?
--
James Kanze mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient e objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelh ttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86 27
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: hsutter@peerdirect.com (Herb Sutter)
Date: 1999/05/05 Raw View
On 04 May 99 08:32:22 GMT, Jim Hyslop <jim.hyslop@leitch.com> wrote:
>Ah, that's what I've been looking for - is there any formal, independent
>validation process in the works?
Not that I know of, unless there's a FIPS number or something.
>Around the time the Standard was being voted out of Committee, I posted a
>question in this newsgroup asking if there would be any standard test suite so
>that you could measure and clearly define (as far as possible) a compiler's
>conformance. There were absolutely no responses ;-)
It was left as an opening for entrepreneurs. :) Several companies
(Perennial comes to mind) create and sell conformance test suites for
C++. Their customers are typically large organizations that have
mandated conformance on RFPs (so that they have something to check
against), and the compiler vendors themselves (as an extra QA tool,
and/or to make sure that they're conforming).
Herb
---
Herb Sutter (mailto:hsutter@peerdirect.com)
PeerDirect Inc. 2695 North Sheridan Way, Suite 150
www.peerdirect.com Mississauga Ontario Canada L5K 2N6
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/04/28 Raw View
In article <7g52pp$j86$3@fir.prod.itd.earthlink.net>,
endh1b@right.now (Marcus Vinicius) wrote:
> I had considered doing exactly what you are suggesting but rejected it
> on the grounds of a lack of time. One of the problems is that there
> are such wide variations among compilers. Some vendors have made a
> concerted effort to keep up with the standards (eg Borland), others
> half hearted (e.g. _________ ______ C++), and some not at all (eg IBM
> for AIX).
I thought IBM was the first to bring out a compiler which "claimed" full
compliance. And as far as I know, the IBM Visual Age compiler is one of
the closest to the standard.
Note too that conformance isn't everything. Egcs is certainly closer to
being fully compliant than was g++ 2.8. But egcs still contains enough
serious bugs (calling destructors twice on the same variable) to mean
that it cannot be used for production code, and still has problems with
binary compatibility between releases, whereas g++ 2.8.2 is relatively
stable. Conclusion: for a serious project spread over a lot of
platforms, g++ 2.8.2 is a serious contender, whereas egcs simply won't
be considered.
--
James Kanze mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orientie objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86 27
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/04/28 Raw View
In article <7g38ai$o56$1@engnews1.eng.sun.com>,
clamage@eng.sun.com (Steve Clamage) wrote:
> "Scott Robert Ladd" <srladd@frontier.net> writes:
>
> >I've been porting some 100,000 lines of C++ from Wintel MS VC++ to Linux
> >egcs-1.1.2 and (in the end) HP C++, trying to keep the code 100% compatible
> >between compiler and without resorting to copious #ifdef disease.
>
> >It ain't easy. I've encountered many different "interpretations" of Standard
> >C++...
>
> I don't think you are finding different interpretations of Standard
> C++. I think you are seeing that some features have not yet been
> implemented according to the standard (which in some cases the
> vendor will document). No compiler yet claims to be fully compliant
> with the standard. It takes time to get all the features fully
> implemented.
No compiler implementor claims that his compiler is fully compliant.
Some marketing people, on the other hand... (I've seen ads for
"ANSI/ISO C++ compilers" for some years now. Long before there was a
standard, in fact.)
> Vendors have various priorities due to various kinds of clients
> to satisfy. Full standards compliance is not the first priority in
> many cases.
With regards to portable code, there are two distinct problems:
- New features. If you don't use them, you don't have a problem.
Code that doesn't use member templates, for example, will still
compile correctly with a compiler that supports them.
- Changes. These are more difficult, and must be handled on a case by
case basis. Often, there is a simple way out. (Don't declare a
variable in the for statement, and it doesn't matter whether the
compiler implements the old scope or the new.) Sometimes, a single,
centrally placed macro will do the trick: -Dexplicit, for example,
or even -D'if(0);else if', although some people think that this is
going too far. And in many cases, although the code actually
executed may be different, in a well written program, it won't
matter -- this is typically the case where overloading is involved.
(The type of a==b may be bool or int, which definitly affects
overloading. But if two functions have the same name, and only
differ because of the argument type, in a well written program, they
will have the same functional effect.)
At any rate, I've done quite a bit of portable C++, and I don't think I
ever needed a conditional compilation in the body of the file, for any
reason whatsoever. (There are cases where I've used entirely different
.cc files to implement a class. Things like reading a directory, for
example. But these have nothing to do with the language.)
(As to switching to Java: my experience is that portability in Java is
even less than in C++. But then, I'm not necessarily doing the same
things in Java that I did in C++.)
--
James Kanze mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orientie objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86 27
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David Binderman <dcb@pncl.co.uk>
Date: 1999/04/28 Raw View
Marcus Vinicius wrote:
> In article <925147317.421.97@news.remarQ.com>, "Scott Robert Ladd" <srladd@frontier.net> wrote:
> >I've been porting some 100,000 lines of C++ from Wintel MS VC++ to Linux
> >egcs-1.1.2 and (in the end) HP C++, trying to keep the code 100% compatible
> >between compiler and without resorting to copious #ifdef disease.
I think this depends strongly on how many WinTel specifics are
in the code.
I've had bad results porting code between Wintel & Unix.
I've had good results porting code to/from Sun C++, Dec C++, H-P C++
and Linux C++, mostly on much bigger projects than you describe.
> >It ain't easy. I've encountered many different "interpretations" of Standard
> >C++... I'm almost considering going back to Java! ;>
If you want a simpler programming language, C++ is a bad
place to start :->
> >Has anyone created a web site to catalog various ways in which compilers
> >fail to meet the Standard?
This is commercially sensitive enough to frighten me off.
> >If there isn't such a site, do people here think such a site is something we
> >need?
C++ standard has been evolving for seven years,
with compiler vendors playing catch-up.
Hopefully, in a year or two, their catchup will be finished.
I think the useful time for such information has passed.
Regards
dcb
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Scott Robert Ladd" <srladd@frontier.net>
Date: 1999/04/28 Raw View
Steve Clamage wrote:
>I don't think you are finding different interpretations of Standard
>C++. I think you are seeing that some features have not yet been
>implemented according to the standard (which in some cases the
>vendor will document). No compiler yet claims to be fully compliant
>with the standard. It takes time to get all the features fully
>implemented.
>
>Vendors have various priorities due to various kinds of clients
>to satisfy. Full standards compliance is not the first priority in
>many cases.
I probably should have said "implementations" instead of "interpretations."
And I'm more than aware that no one implements the actual standard, nor do I
expect anyone to do so in the near future. That is precisely the reason we
need to understand how various compilers differ in both implementation *and*
interpretation of the standard.
The point of a Standard is to allow the creation of portable code; I see no
problem with keeping a knowledge base about the compliance and mutual
compatability of various compilers.
== Scott Robert Ladd
srladd@frontier.net
http://www.frontier.net/~srladd
public PGP key: http://www.frontier.net/~srladd/srlpgp.html
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Joerg Schaible" <Joerg.Schaible.A@T.gft.de>
Date: 1999/04/28 Raw View
Hi Steve
>>It ain't easy. I've encountered many different "interpretations" of
Standard
>>C++...
>
>I don't think you are finding different interpretations of Standard
>C++.
You missed the quotation ;-)
>Vendors have various priorities due to various kinds of clients
>to satisfy. Full standards compliance is not the first priority in
>many cases.
If your job is porting C++ code to different plattforms and compilers,
*your* priority is to find the subset and C++ constructs you're able to
compile with all of them!
In this sense I would welcome a portability home page documentating compiler
bugs and workarounds.
Greetings, Jvrg
--
BTW: It is normally better to answer to the group! For direct mail reply
exchange the ".A@T." by "@"
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/04/28 Raw View
In article <7g38ai$o56$1@engnews1.eng.sun.com>, Steve Clamage
<clamage@eng.sun.com> writes
>I don't think you are finding different interpretations of Standard
>C++. I think you are seeing that some features have not yet been
>implemented according to the standard (which in some cases the
>vendor will document). No compiler yet claims to be fully compliant
>with the standard. It takes time to get all the features fully
>implemented.
Unfortunately at least one major compiler implementor has a very
substantial library used by a very large number of people. The design
of that library makes converting it to compile with a fully conforming
C++ compiler extremely costly (if it is even doable). When using that
company's development tools you have a choice between using there best
attempt at a conforming compiler and standard library (actually not bad)
but not their other libraries, or using their libraries with the
compiler switched to a far from conforming mode.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Scott Robert Ladd" <srladd@frontier.net>
Date: 1999/04/26 Raw View
I've been porting some 100,000 lines of C++ from Wintel MS VC++ to Linux
egcs-1.1.2 and (in the end) HP C++, trying to keep the code 100% compatible
between compiler and without resorting to copious #ifdef disease.
It ain't easy. I've encountered many different "interpretations" of Standard
C++... I'm almost considering going back to Java! ;>
Has anyone created a web site to catalog various ways in which compilers
fail to meet the Standard? I'm thinking of a non-commercial site, possibly
user-maintained (i.e., people post their experiences), where we could
centralize information about how compiler such-and-such fails to handle
this-and-that piece of code.
If there isn't such a site, do people here think such a site is something we
need?
== Scott Robert Ladd
srladd@frontier.net
http://www.frontier.net/~srladd
public PGP key: http://www.frontier.net/~srladd/srlpgp.html
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@eng.sun.com (Steve Clamage)
Date: 1999/04/27 Raw View
"Scott Robert Ladd" <srladd@frontier.net> writes:
>I've been porting some 100,000 lines of C++ from Wintel MS VC++ to Linux
>egcs-1.1.2 and (in the end) HP C++, trying to keep the code 100% compatible
>between compiler and without resorting to copious #ifdef disease.
>It ain't easy. I've encountered many different "interpretations" of Standard
>C++...
I don't think you are finding different interpretations of Standard
C++. I think you are seeing that some features have not yet been
implemented according to the standard (which in some cases the
vendor will document). No compiler yet claims to be fully compliant
with the standard. It takes time to get all the features fully
implemented.
Vendors have various priorities due to various kinds of clients
to satisfy. Full standards compliance is not the first priority in
many cases.
--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: endh1b@right.now (Marcus Vinicius)
Date: 1999/04/27 Raw View
In article <925147317.421.97@news.remarQ.com>, "Scott Robert Ladd" <srladd@frontier.net> wrote:
>I've been porting some 100,000 lines of C++ from Wintel MS VC++ to Linux
>egcs-1.1.2 and (in the end) HP C++, trying to keep the code 100% compatible
>between compiler and without resorting to copious #ifdef disease.
>
>It ain't easy. I've encountered many different "interpretations" of Standard
>C++... I'm almost considering going back to Java! ;>
>
>Has anyone created a web site to catalog various ways in which compilers
>fail to meet the Standard? I'm thinking of a non-commercial site, possibly
>user-maintained (i.e., people post their experiences), where we could
>centralize information about how compiler such-and-such fails to handle
>this-and-that piece of code.
>
>If there isn't such a site, do people here think such a site is something we
>need?
I had considered doing exactly what you are suggesting but rejected it on the
grounds of a lack of time. One of the problems is that there are such wide
variations among compilers. Some vendors have made a concerted effort to keep
up with the standards (eg Borland), others half hearted (e.g. _________ ______
C++), and some not at all (eg IBM for AIX).
John - N8086N
Big brother is watching. Disable cookies in your web browser.
-------------------------------------------
Wise man says "Never use a bank with the initials F. U."
-------------------------------------------
Are you interested in a professional society or
guild for programmers? Want to fight section 1706?
See www.programmersguild.org
Newsgroup: us.issues.occupations.computer-programmers
EMail Address:
_m-i-a-n-o_@_c_o_l_o_s_s_e_u_m_b_u_i_l_d_e_r_s._c_o_m_
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]