Topic: Serious ARM-noncompliance in CFRONT


Author: jamshid@ses.com (Jamshid Afshar)
Date: Sat, 23 Apr 1994 02:54:26 GMT
Raw View
In article <lincmadCoJvAv.5DH@netcom.com>,
Linc Madison <lincmad@netcom.com> wrote:
>In regards to my recent query about overload resolution, I received
>replies from a number of people who tested my sample code on their
>machines.  Three of the respondents were using compilers based on
>CFRONT, all of which exhibited the following behavior in violation of
>ARM, not related to my question about overload resolution:
>
>long double ld;
>cout << ld; // CFRONT incorrectly flags as ambiguous because it
>  // fails to define operator<<(long double)

First of all, the ARM doesn't even mention streams or cout, so I don't
see how this can be called an ARM non-conformance.  Cfront doesn't
even support the `long double' type in your own code unless the +a1
option is used to indicate that the C compiler backend supports ANSI C
constructs.  What I wouldn't give for this to qualify as a serious
problem with Cfront.  Unfortunately, there's lots, more important
things that Cfront says is "Sorry, not implemented" or that Cfront
crashes on.  Btw, `signed' is also not supported.

>[...]
>If your architecture doesn't define long double as a representation
>distinct from double, you can just define op<<(ld) to cast the argument
>to double and call the double instance.

Yes, what I've done in my `hacks' include file directory is add a
simple inline to iostream.h to define:

 istream& operator>>(long double& ld)
   { double d; if((*this)>>d) ld=d; return *this;
   }

I could do the same with ostream.  It's silly of USL not to fix
iostream.h so that it defines these operators when +a1 is used.

Jamshid Afshar
jamshid@ses.com




Author: lincmad@netcom.com (Linc Madison)
Date: Wed, 20 Apr 1994 08:52:07 GMT
Raw View
In regards to my recent query about overload resolution, I received
replies from a number of people who tested my sample code on their
machines.  Three of the respondents were using compilers based on
CFRONT, all of which exhibited the following behavior in violation of
ARM, not related to my question about overload resolution:

long double ld;
cout << ld; // CFRONT incorrectly flags as ambiguous because it
  // fails to define operator<<(long double)

The compilers in question were:
Glockenspiel 2.0C (based on AT&T release 2.0C)
SPARCompiler 2.0.1 (based on CFRONT 3.0.1)
HP C++ 3.0.5 (based on CFRONT, unspecified version)
  and other versions of HP's C++

If your architecture doesn't define long double as a representation
distinct from double, you can just define op<<(ld) to cast the argument
to double and call the double instance.  However, failing to define any
behavior at all for op<<(ld) is noncompliant; see section 10.2.1 of the
gray book.  (Although Bjarne doesn't mention long double in this
section, it states "The class ostream is defined with << to handle
output of the built-in types," and long double is a built-in type.)

-- Linc Madison   *   Oakland, California   *   LincMad@Netcom.com
"Crusading for long-double equality!"