HDTenEightyP/NetNews huggingface dataset:
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Expanding enumerators in inheriting classes
Date: 13 Aug 92 09:49:56 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

hildum@ntmtv.UUCP (Eric Hildum) writes:
: In article <1992Aug11.190816.8623@inmet.camb.inmet.com>, stt@spock.camb.inmet.com (Tucker Taft) writes:
: 
: |> 
: |> One reason we lost interest was the observation that record 
: |> extension/derivation tends to make enumeration types less necessary.  
: |> Rather than having a variant record/union type with a value of an enumeration
: |> type distinguishing the variants, one would simply define distinct
: |> derivations.  A virtual function could return a string name
: |> for each distinct derivation, corresponding to the enumeration literal.
: |> A separate virtual function could return an integer code, if needed.
: |> 
: 
: That is run time type information via string compares, or via integer compares.
: The problem with this is that now the programmer has to be concerned with the
: exact values returned from each different class to prevent conflicts within
: inheritance trees (and across such trees), [...]

A better approach is to have each class return a reference to a unique
object, one for each class, like this:

virtual const Type& someClass :: myType();
{
	static Type theType;	// unique type object
	return theType;
}

Since objects are guaranteed to have distinct addresses,
conflicts between class type identifiers are avoided.  Also,
the Type class can be extended with additional operations and
data.  You would probably want easy equality tests:

int operator == ( const Type& a, const Type& b )
{ return &a == &b; }
-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| jbn@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490              |
--------------------------------------------------------------------------
Newsgroups: comp.std.c++
From: dag@control.lth.se (Dag Bruck)
Subject: Re: Expanding enumerators in inheriting classes
Keywords: inheritance, enumerator
Organization: Department of Automatic Control, Lund, Sweden
Date: Fri, 14 Aug 1992 19:30:46 GMT

In <comp.std.c++> hildum@ntmtv.UUCP (Eric Hildum) writes:
>
>... C++ already allows duplicate codes

Yes, but the definitions are at least in one place, which makes the
code easier to maintain.  Never mind, I'm sure you are aware of the
potential problems.

I have implemented extensible enumerations with templates.  I think
the template sollution offers much of what you would like:

	- extensible set of enumerators
	- named enumerator symbols
	- type-safe, in the sense that an enumeration variable
	  may only be assigned enumerators of the corresponding
	  (possibly extended) enumeration

However, there are problems:

	- the template version is MUCH less efficient, at least
	  with current template implementations
	- these enumerators are not compile-time constants, so
	  they cannot be used as case labels, for example
	- compiler must allocate storage for enumerators
	- the scope of the enumerator may not match the scope
	  of the enumerated type, so garbage values may float
	  around in the system

It is possible to add additional logic to handle the last problem
listed above, but it does cost a little in run-time performance.

I did this excercise as part of the analysis of operator overloading
of enumerations (a C++ standardization issue).  I can post the actual
code if there is enough interest; it's just two pages of code.


		-- Dag
Newsgroups: comp.std.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: this == 0 for nonvirtual functions
Date: Wed, 19 Aug 1992 04:22:14 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
|	IMHO, the ability to *depend upon* the (desired) fact that
|	*calling* a non-virtual member-function with a nil pointer is
|	*guaranteed* to be harmless seems worthwhile (and its addition
|	to the language wouldn't break anything as far as I can tell).

If this change to the language were made, it might be appropriate
not to include the case of calling a member function with a nil
pointer to a class virtually derived from the class where the
function is defined:

   class Base { void f(); };
   class Derived : public virtual Base {};
   ...
   Derived* p;
   p->f();

If I understand correctly, in most implementations the conversion
of p to a Base* will require examining the contents of *p.
If p may be 0, then the compiler must insert extra code to
treat this case correctly.

Of course, this extra code is currently necessary for all conversions
of a Derived* to a Base* where the compiler can't be sure that
the pointer is non-nil.  So perhaps the extra overhead for the
function calls wouldn't be seen as significant.

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: this == 0 for nonvirtual functions
Keywords: this virtual function undefined
Date: 21 Aug 92 14:30:01 GMT
Article-I.D.: alice.23512
Reply-To: ark@alice.UUCP ()
Distribution: usa
Organization: AT&T Bell Laboratories, Murray Hill NJ

Perhaps someone might like to try to construct an example of why
it might actually be useful to allow this==0 in a member function.
I've been away, so I've missed some messages, but so far the only
justification I've seen is statement like `it seems like a good idea.'

I find it hard to imagine why it would be useful.  A member function
that never looks at `this' could just as well be made static;
one that actually uses `this' had better not be called with this==0.
Thus it appears that the only useful cases are:

	1. a function that actually checks if this==0 and does different
	   things depending on the result, or

	2. a function that looks at this only if one of its arguments has
	   a particular value.

Both of these cases seem contrived to me, to the extent that I would
expect to be able to accomplish an equivalent thing more elegantly by
other means.

Can someone actually come with a useful example?
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.std.c
From: mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn)
Subject: Handling ISO 10646 UCS in C
Organization: CSD., University of Erlangen, Germany
Date: Sat, 15 Aug 1992 15:34:13 GMT

Are there any proposals about future extensions to Standard C that will
allow the programmer to use ISO 10646/Unicode strings as easily as
char []?

Will wchar_t be fixed to UCS-2 or will the standard commitees introduce two 
new char types e.g.

   ucs2_t     for the 16-bit ISO 10646 BMP (also known as Unicode)
   ucs4_t     for the full 32-bit ISO 10646 code

together with new string constant notations for both of them and a lot
of new library functions for arrays of these new types? (I'd prefer 
introducing two new types a lot!)

Will C programs be allowed to be UCS-2 files in addition to ASCII files
which would make entering Unicode characters in string constants and
comments as easy as ASCII characters today?

What will be the new equivalent of \0? \x0000 or \ffff or another special
character?

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
-A distributed system is one in which the failure of a computer you didn't-
-even know existed can render your own computer unusable. (Leslie Lamport)-
From: hendrik@vedge.UUCP (Hendrik Boom)
Newsgroups: comp.std.c
Subject: Re: mixing prototyping and non-prototyping
Date: 21 Aug 92 13:56:37 GMT
Organization: Visual Edge Software, St. Laurent, Quebec

davisonj@bnr.ca (John Davison) writes:
: 
: In article <28616@vedge.UUCP> hendrik@vedge.UUCP (Hendrik Boom) writes:

: >To make this work at least some of the time,
: >a function defined using old-style syntax,
: >will expect its parameters to have been converted
: >using the standard argument promotion rules.
: >
: >A function with a single real argument, such as
: >	f(r)real r;{    }
: 
:         You did not define "real".
: 
My mistake. I've spent ten years coding in C, ten years making
this mistake, and ten years being reminded by a compiler
what a nitwit I am!  Of course I mean float.

: >(a)	Include parameters in function declarations
: >	conditional on the absence of _NO_PROTO.
: ...
: >Its use is not dictated or mentioned by the ANSI standard.
: 
:     To determine if a compiler is Standard C, the existence and value (should
: be 1 in standard C) of __STDC__ should be checked.
: 

Right, __STDC__ tells me whether the compiler is standard C, in which case
it would be expected to accept prototypes.  But I use _NO_PROTO to tell
the include files whether to provide prototypes -- which is a different
issue:
	- it enables me to test the software in a mode in which an
	  end-user with a nonprototyping compiler might use it).
	- Nonstandard compilers sometimes do accept prototypes
	  without defining __STDC__
	- Compilers defining __STDC__ to 1 occasionally have bugs
	  and fail to do prototypes correctly (this is rare)

The specific word _NO_PROTO was chosen because it is used for this purpose
in a lot of manufacturers' include files on UNIX.  So many, in fact,
that I wonter whether there is some standard other tnat ANSI C that
mandates this.  Is there some edict from OSF? X/OPEN? POSIX? Anyone know?
 
: 
: -- 
: NOTE: I CAN'T SEND/RECEIVE E-MAIL HERE!!!  Use --> davisonj@ecn.purdue.edu <--
:       During (roughly) August 20-25, I will be in transit.  Please be patient.
:       The opinions and other information contained herein are not necessarily
:       representative of Northern Telecom or any of its subsidiaries. 
-- 
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work:	hendrik@vedge.com,  iros1!vedge!hendrik
at home:	uunet!altitude!ozrout!topoi!hendrik
Newsgroups: comp.std.c
From: enag@ifi.uio.no (Erik Naggum)
Newsgroups: comp.std.c
Subject: Re: preprocessing subterfuge
Date: 12 Aug 92 15:13:56 GMT
Organization: Department of Informatics, University of Oslo, Norway

Paul Eggert <eggert@twinsun.com> writes:
|
|   That's not quite what Naggum asked for.

Exactly, and the reason I wouldn't trust any GNU thing about conformance
to standards is the last sentence in the documentation:

|	We recommend, rather, that users take advantage of the
|	extensions of GNU C and disregard the limitations of other
|	compilers.

The effect of this is that people are locked into using free software.
(Only half a smiley on that one.  Flames to /dev/null.)

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      +47 295 0313
                        |  ISO 10744 HyTime   |
<erik@naggum.no>        |  ISO 10646 UCS      |      Memento, terrigena.
<enag@ifi.uio.no>       |  ISO  9899 C        |      Memento, vita brevis.
Newsgroups: comp.std.c
From: spuler@coral.cs.jcu.edu.au (David Spuler)
Subject: mixing prototyping and non-prototyping
Organization: James Cook University
Date: 13 Aug 92 23:42:25 GMT


What are the rules regarding mixing old-style and new-style functions in C
programs?  Specifically, what mixtures must a compiler support,and which can
be legally allowed to bomb?

Can a prototyped function be legally called without a prototype in scope?  
My understanding was that this sort of mixing was allowed except for varargs
functions, or prototyped functions with char/float/short parameters, but I
was recently told I was wrong.  Could someone clear it up for me.

Can a non-prototyped function be called with a prototype in scope?
I assume not.

Thanks,
David Spuler
--
David Spuler, James Cook University of North Queensland, Australia
Author of "Comprehensive C", Prentice-Hall, 1992, pp416, ISBN  0-13-156514-1
INTRO TOPICS: types, operators, structures, strings, fns, ptrs, files etc etc
ADVANCED TOPICS: efficiency, debugging, style, portability, large programs
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: File mode
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 13 Aug 1992 01:41:03 GMT

In article <1992Aug12.051036.13224@pasteur.Berkeley.EDU> johnm@cory.Berkeley.EDU (John D. Mitchell) writes:
>I've looked through the standard but haven't found any indication of
>whether or not the file mode specifiers are case sensitive or not (i.e. is
>a file mode "b+" == "B+")?

The standard defines the effects of several mode specifiers, all of which
are in lower case.  ("b+" is not among them, though "rb+" etc. are.)
The standard does not define the effects of mode specifiers in upper case.
Implementations are allowed to provide extensions, but portable programs
do not depend on them, and strictly conforming programs cannot.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
From: amn@unix.brighton.ac.uk (Anthony Naggs)
Newsgroups: comp.std.c
Subject: ANSI/ISO standard (surprisingly enough!) & extensions
Date: 18 Aug 92 02:01:02 GMT
Reply-To: amn@vms.brighton.ac.uk
Organization: University of Brighton, England

Sorry if these are FAQs, I haven't noticed a list here, if so please mail me.

Do any bodies, other than the British Standards Institute, perform validation
of compilers?  Which PC (MS-DOS) or Amiga products have passed such validation?

The British Standards Institute charges 168 pounds sterling ($330 US),
[yes, the price is correct - I checked the price list and by phone], for the
234 pages comprising BS ISO/IEC 9899:1990, (half price for members).  We have
to tolerate US books having the '$' scratched out & a pound sign drawn in, but
this seems bl**dy expensive!  Is this, or better still the ANSI version with
rationale, available at an affordable price?

Beyond my list, what major extensions are documented for ANSI C?
    Objective C - "Objective C" by Pinson & Wiener's book,
    C++         - [IMHO, hardly an extension the contradictions with ANSI C
                    appear to be increasing daily]
    Concurrent C - "The Concurrent C Programming Language" by Gehani & Roome,
                    1989, describes a K&R rather than ANSI extension. Omitting
                    control for sharing/copying data between processes and
                    control of process location on multiple processor systems.
                    Has this been updated functionally and/or syntactically
                    to ANSI style?

Thanks,
-- 
Anthony Naggs                    |  MAN I say what it occurs to me to say when
Janet:    amn@uk.ac.brighton.vms |      I think I hear people say things.
    or    xa329@uk.ac.city       |      More I cannot say.
Internet: amn@vms.brighton.ac.uk |
       or xa329@city.ac.uk)      |  (from The Hitch-Hiker's Guide to the Galaxy)
From: davisonj@bnr.ca (John Davison)
Newsgroups: comp.std.c
Subject: Re: mixing prototyping and non-prototyping
Date: 20 Aug 92 04:44:26 GMT
Organization: Bell-Northern Research, Richardson, Tx.


In article <28616@vedge.UUCP> hendrik@vedge.UUCP (Hendrik Boom) writes:
>Here's my standard handout on this subject:
...
>Please comment,
>especially if you detect errors in my interpretation.
>Any and all of a function
>definition, declaration, and call may contain information
>about the argument types, with varying significan[c]e.
...
>ANSI defines the old-stype functions to worl [sic] as follows.
...
>The old-style rules apply whenever a function has neither
>been declared with prototype syntax
>nor been defined with new-style syntax.

>To make this work at least some of the time,
>a function defined using old-style syntax,
>will expect its parameters to have been converted
>using the standard argument promotion rules.
>
>A function with a single real argument, such as
>	f(r)real r;{    }

        You did not define "real".

>(a)	Include parameters in function declarations
>	conditional on the absence of _NO_PROTO.
...
>Its use is not dictated or mentioned by the ANSI standard.

    To determine if a compiler is Standard C, the existence and value (should
be 1 in standard C) of __STDC__ should be checked.

        You may also want to employ the "#error" preprocessor directive to yell
at you if the configuration of compiler-supplied macros, values, etc. is such
that your program will not run and/or compile correctly without modification.


-- 
NOTE: I CAN'T SEND/RECEIVE E-MAIL HERE!!!  Use --> davisonj@ecn.purdue.edu <--
      During (roughly) August 20-25, I will be in transit.  Please be patient.
      The opinions and other information contained herein are not necessarily
      representative of Northern Telecom or any of its subsidiaries. 
Newsgroups: comp.std.c
From: davisonj@bnr.ca (John Davison)
Subject: ISO/IEC 9899:1990 (E) [1st ed] and American Nat'l Standard X3.159-1989
Summary: are they congruous?  are they the latest?
Keywords: C ISO/IEC 9899:1990 (E) American National Standard X3.159-1989
Organization: Bell-Northern Research, Richardson, Tx.
Date: Fri, 14 Aug 1992 18:22:54 GMT


        Despite the differences in wording and formatting, are _ISO/IEC_
_9899:1990_(E),_First_Edition_1990-12-15_ and _American_National_Standard_
_X3.159-1989_ different in any way with respect to the language specifications
or implications thereof?

        Do these two documents represent the most current and widespread C
standard(s)?

        Please tell me if the following statement is true: The C programming
language as defined by _ISO/IEC_9899:1990_(E),_First_Edition_1990-12-15_, the C
programming language as defined by _American_National_Standard_X3.159-1989_,
ISO C, and ANSI C are all one and the same thing, with no differences
whatsoever.

        If not true, what are the differences (the major ones, anyway)?

        Followup articles are encouraged.  (Electronic mail is hard for me to
access.)

        Thanks!


-- 
NOTE: The opinions and other information contained herein are not to be
      construed as representative of Northern Telecom or any of its
      subsidiaries.  Please direct all electronic mail to 
                   =======> davisonj@ecn.purdue.edu. <=======
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.std.c
Subject: Re: ANSI/ISO standard (surprisingly enough!) & extensions
Date: 18 Aug 1992 23:53:19 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com
Keywords: ISO ANSI

In article <1992Aug18.195516.24881@bnr.ca> davisonj@bnr.ca (John Davison) writes:
>        I asked this question before, and no one answered.  Here it comes
>again.  Surely one of you readers knows the answer!

Well, since none of the X3J11 experts chimed in the first time, I'll give
it a shot (note that my information is mostly based on my memory from past
postings in this newsgroup).

>        Despite the differences in wording and formatting, are _ISO/IEC_
>_9899:1990_(E),_First_Edition_1990-12-15_ and _American_National_Standard_
>_X3.159-1989_ different in any way with respect to the language specifications
>or implications thereof?

No.  ISO took the ANSI spec, removed the Rationale (which was non-binding
information), reformatted it according to their standards (for instance, I
think they removed the line numbers), and published it.  The sentences that
describe C are all the same as in the ANSI spec, but the look is different.

At the time it was being proposed as an ISO standard there was some concern
that changes might be made, but it never happened (it would have been
virtually impossible for the two standards to come out only a year apart if
any technical changes had been made, as the design and review process would
have taken longer than that -- there are shortcuts that can only be taken
when an approved national standard is being promoted to an international
standard).

>        Do these two documents represent the most current and widespread C
>standard(s)?

They are the only official standards for the C language in existence.  Most
vendors implementing C compilers for the last few years have been basing
them on this standard.

In addition, many vendors have also been implementing C++, a derivative of
C with a number of extensions, such as object-oriented functions, function
name overloading, generic templates, and condition handling.  There is a de
facto standard at the moment ("The Annotated C++ Reference Manual"), and
X3J16 is in the process of developing an ANSI standard for it.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.std.c
From: holger@zelator.in-berlin.de (Holger Lesch)
Subject: XOpen gencat, catopen... for sgi IRIS Indigo ?
Organization: Puplic-Access-Xenix-System
Date: Sun, 23 Aug 92 10:56:25 GMT


Hi there!

I'm looking for the XOpen nls-package (language independent message
catalogs) including gencat, catopen, ... for the sgi IRIS Indigo with
IRIX 4.0.1. May this be avialable as source or from sgi ?

thanx in anticipation

Holger
-- 
#############################################################
# Holger Lesch              email (privat) :                #
# Sybelstrasse 23               holger@zelator.in-berlin.de #
# W-1000 Berlin             email (non-privat):             #
# Tel. (030) 3243615                   holger@kom.sietec.de #
#############################################################
From: amn@unix.brighton.ac.uk (Anthony Naggs)
Newsgroups: comp.std.c
Subject: Re: ANSI/ISO standard (surprisingly enough!) & extensions
Date: 19 Aug 92 23:48:12 GMT
Reply-To: amn@vms.brighton.ac.uk
Organization: Brighton Polytechnic, England

Thanks all, I have now received info on acquiring standards.

From email I have received there appears to be a misunderstanding with my Q:
>Do any bodies, other than the British Standards Institute, perform validation
>of compilers?  Which PC (MS-DOS) or Amiga products have passed such validation?

I want to know about ANSI/ISO std conformance testing, tested products.  Some
people mentioned the Plum Hall validation suite  -  this is not of interest to
me.  PH may well be a useful test, but it only checks that a compiler accepts
the PH files & gives an output that runs correctly.  This seems to be a
drastically inadequate test for std compliance, my understanding is that:
1   It is only applicable to compilers that include a complete ANSI library,
    often not the case when targetting embedded systems, ...
2   It does not check that system constants (#define's) and function prototypes
    are in the correct header files, ...
3   It does not ensure that the compiler defaults to ANSI compliant mode, with
    language extensions being available only as an option.
4   It does not prevent tampering with the input (PH) files to get the desired
    output.
5   It does not reject compilers that accept invalid operations or illegal
    syntax.
6   It does not test typesafe linkage, where implemented :-)
7   ... other tests requiring impartial checking of compile or link errors, or
    inspection of development specification.

In my very humble opinion, claiming PH compliance for a compiler is like
saying a container is decorated with lead free paint, it tells me a criteria
that it meets - it does not tell me whether it will correctly compile any of
my code.  And when I'm targettng embedded systems, or storing ferric chloride,
the criteria may be entirely irrelevant to my application.

Regards,
-- 
Anthony Naggs                    |  MAN I say what it occurs to me to say when
Janet:    amn@uk.ac.brighton.vms |      I think I hear people say things.
    or    xa329@uk.ac.city       |      More I cannot say.
Internet: amn@vms.brighton.ac.uk |
       or xa329@city.ac.uk)      |  (from The Hitch-Hiker's Guide to the Galaxy)