HDTenEightyP/NetNews huggingface dataset:
From: enag@ifi.uio.no (Erik Naggum)
Newsgroups: comp.std.internat,comp.misc
Subject: Re: ISO 10646 the final character set?
Date: 12 Aug 92 19:57:26 GMT
Organization: Department of Informatics, University of Oslo, Norway

I wrote:
||
||  Voting terminated on 1992-04-10...

John H. Jenkins <jenkinsj@blowfish.taligent.com> wrote:
|
|   The vote actually ended at the end of May.  Some countries got their
|   votes in late and were not counted.

Yes, that's right.  I confused the votes on ISO 10744 and ISO 10646.
1992-05-30 was the vote termination date for ISO DIS 10646.

|   I believe that the comments from Poland and Tunisia were not
|   accomodated for reasons similar to Turkey's (who wanted Latin 9 used
|   instead of Latin 1 in the first 256 code points; nobody else would
|   agree to that).  The UK and Denmark were accomodated and appear to
|   be satisfied with the accomodations.

Part of the reason Denmark voted NO was to allay the Turkish claims,
too.  This was a formally supported move, but several countries just
voted YES to indicate their displeasure.

|   Turkey, BTW, used its diplomatic corps to exert pressure on other
|   countries to go along with them.  I think this backfired and lost
|   them sympathy rather than winning them any.

Certainly!  Norway got into voting at the behest of Iceland, who were
worried about ISO 8859-1 being replaced, and their ETH and THORN going
the way of the dodo.  Turkey had completely neglected to allow for the
characters they suggested to be replaced, which also made people angry
at them.  I saw both letters, and found Turkey totally mindless.
Iceland's concern was understandable, but they did at least not use
their diplomatic corps to counter-act Turkey.

|   BTW, I'm told that 10646 set a record for the number of countries
|   participating in the vote.

Maybe we can "thank" Turkey for that... :-)

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.
From: jenkinsj@blowfish.taligent.com (John H. Jenkins)
Newsgroups: comp.std.internat
Subject: Re: ISO 10646 the final character set?
Date: 12 Aug 92 15:45:15 GMT
Followup-To: comp.std.internat,comp.misc
Organization: Taligent, Inc.

In article <23302B@erik.naggum.no>, enag@ifi.uio.no (Erik Naggum) wrote:
> 
> Fritz Whittington <fritz@ra.csc.ti.com> writes:
> |
> |   I believe that the revised standard will come up for vote again
> |   around the end of the year.
> 
> This is incorrect.  Voting terminated on 1992-04-10, and ISO DIS 10646
> became ISO 10646, a fully official International Standard.  It has not
> been published and made available, yet that I know of.  Partly due to
> the size of the standard, partly due to the number of comments with
> votes, which I think have been reconciled by now (with the exception of
> Turkey's irrational request to replace ISO 8859-1 in the 00xx "row" with
> their favorite set, and Japan's more reasonable concerns).
> 

The vote actually ended at the end of May.  Some countries got their votes
in late and were not counted.   

I believe that the comments from Poland and Tunisia were not accomodated
for reasons similar to Turkey's (who wanted Latin 9 used instead of Latin 1
in the first 256 code points; nobody else would agree to that).  The UK and
Denmark were accomodated and appear to be satisfied with the accomodations.
 

Turkey, BTW, used its diplomatic corps to exert pressure on other countries
to go along with them.  I think this backfired and lost them sympathy
rather than winning them any.  

There was a lot of effort expended to try to satisfy Korea, but it's
unclear whether it actually did.  There is considerable disagreement within
Korea as to whether precomposed or combining methods should be used to
represent Hangul; the IS includes both, but only by putting several
thousand precomposed Hangul within the user space (unofficially, of
course). Nobody can tell if Korea will, in the end, find this satisfactory
or not.

One of Japan's reasons for voting no was procedural (they felt that it
violated ISO procedures to have a second DIS with so many fundamental
changes).  This could not be accomodated.  Some of their technical comments
were accomodated and some weren't.  For example, Japan's desire to have a
swap zone within 10646 large enough to hold all of JIS was generally felt
to be unreasonable, given the fact that everything in JIS is already
included in the CJK-JRG URO (which is part of 10646). 

BTW, I'm told that 10646 set a record for the number of countries
participating in the vote.  

John H. Jenkins
John_Jenkins@taligent.com

#include <std_disclaimer.h.>
Newsgroups: comp.std.internat
From: samuell@cis.uab.edu ('s)
Subject: IRDS
Keywords: IRDS, repository, CASE
Organization: University of Alabama at Birmingham
Distribution: usa
Date: Thu, 20 Aug 1992 18:58:42 GMT

Can someone please tell me what the acronym IRDS stands for?

Also, I would like to know which X3 group is doing the standards
development in this area.  And, if possible who the chair of
that committee is and what his/her organizational affiliation
and telephone number are.


Ihanks in advance,


Bobb Samuell
samuell@cis.uab.edu
Xref: sparky comp.std.internat:623 comp.std.c:2475
From: aaron@iit.com (Aaron Emigh)
Newsgroups: comp.std.c++
Subject: Accessing nested classes from friend functions
Keywords: template class friend
Date: 17 Aug 92 23:01:18 GMT
Reply-To: aaron@iit.com (Aaron Emigh)
Organization: Integrated Information Technology

I was trying to write a friend function of a template class containing
another class taking a pointer to the internal class as an argument, and
couldn't find any way to get my compiler (Borland C++ 3.0) to accept it.
I couldn't find anything clear in my documentation, so I'm wondering if
there is a defined syntax for doing this.

In case I'm not being clear, here's an example of what I mean (semantic
content has been reduced to null in the interests of brevity).

// A do-nothing template class containing only another class and a
// friend function, for demonstration purposes.

template <class type_instance_t>
class class_t {
  class internal_t {
    type_instance_t foo;
  };
  friend void frob_class (internal_t *);
};


// Here's the question: how do I declare a friend function that takes a
// class nested inside a template class as an argument?

template <class type_instance_t>
void frob_class (class_t<type_instance_t>::internal_t *arg)
{
}

For my application, declaring internal_t separately and making
class_t its friend works fine, but is less correct in terms of the
operations I am supporting.  Is there a defined way of implementing this
with the class definitions nested?

Aaron Emigh
aaron@iit.com
Newsgroups: comp.std.c++
From: vinoski@apollo.hp.com (Stephen Vinoski)
Subject: const and template parameters
Originator: vinoski@zep_r.ch.apollo.hp.com
Date: Mon, 17 Aug 1992 21:57:58 GMT
Organization: Hewlett-Packard Company, Apollo Division - Chelmsford, MA


Recently I wondered about the use of const for the arguments of class
template member functions and function templates.  For example, given
this function template:

	template<class T>
	void
	tfunc(const T arg) { // ... }

what happens when the type ``int *'' is used for the formal template
parameter ``T''?

Mentally, one might make the parameter substitution and come up with
the following equivalent function:

	void tfunc(const int *arg);

Under this interpretation, the argument appears to be a pointer to
const int.

What actually should happen, though, is that const should apply to
``T'', so that the type parameter substitution results in

	void tfunc(int *const arg);

with the argument actually being a const pointer to int.

The latter interpretation is exactly the same as the "const applied to
typedef" problem:

	typedef int *IntPtr;
	const IntPtr int_ptr;

Here, int_ptr is a const pointer to int (sometimes much to the
amazement of C++ novices :-)).

It appears that the use of const under these circumstances is somewhat
misleading, and perhaps buys us very little.  Should developers leave
const out of these areas of function and class templates?  Your
thoughts?

thanks,
-steve

-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
From: checker@acf5.NYU.EDU (checker)
Newsgroups: comp.std.c++
Subject: Re: const and template parameters
Date: 18 Aug 92 16:25:20 GMT
Organization: New York University

vinoski@apollo.hp.com (Stephen Vinoski) writes:
>	void tfunc(int *const arg);
>with the argument actually being a const pointer to int.
>The latter interpretation is exactly the same as the "const applied to
>typedef" problem:
>	typedef int *IntPtr;
>	const IntPtr int_ptr;
>Here, int_ptr is a const pointer to int (sometimes much to the
>amazement of C++ novices :-)).

The `solution' is to write your declarations like this:

simple-type-name type-specifiers

that means

int const foo;
instead of
const int foo;

The only disadvantage of doing it this way is that hardly anybody does.
I find it much clearer, especially when you get into complicated
declarations.

Chris
Newsgroups: comp.std.c++
From: hildum@ntmtv.UUCP (Eric Hildum)
Subject: Re: Expanding enumerators in inheriting classes
Keywords: inheritance, enumerator
Organization: Northern Telecom Inc, Mountain View, CA
Date: Wed, 12 Aug 1992 19:22:00 GMT

In article <1992Aug11.190816.8623@inmet.camb.inmet.com>, stt@spock.camb.inmet.com (Tucker Taft) writes:
|> 
|> We considered supporting enumeration type extension in Ada 9X, but
|> ultimately dropped it.  One issue (among others) was that values from distinct
|> enumeration extensions of a parent enumeration type
|> might have the same associated integer "code,"
|> making direct comparison between them less meaningful.  That is, equality
|> could be defined, but less-than/greater-than became relatively meaningfless.

Good point; however, C++ already allows duplicate codes, and it is not clear 
why you would want (or would even be allowed to perform) comparisons between
DISTINCT enumeration extensions. I supose you could do it by defining a friend
function of both classes, in which case the meaning of such operations is up
to the implementor of the classes.


|> 
|> 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), whereas with enumeration extension
this could be done by the compilier automatically.

				Eric
Newsgroups: comp.std.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: this == 0 for nonvirtual functions
Keywords: this virtual function undefined
Organization: University of Illinois at Urbana-Champaign
Date: Tue, 18 Aug 1992 04:56:05 GMT

	The ARM, p. 176 says:

		The effect of calling nonstatic member function of a
		class C for something that is not an object of class C
		is undefined.

		For example,

			((X*)0)->f();
		
		is not guaratneed to work. ... Even for non-virtual
		functions, one should expect this trick to fail
		eventually because specialized C++ implementations might
		assume something about the contents of objects even when
		calling nonvirtual functions.  In particular, on might
		expect implementaions instrumented for debugging,
		interpretersm and implementations supporting dynamic
		loading to be sensitive to "housekeeping" information
		placed in the objects by the compiler.

		Natually, this trick would work only f() either checks
		its 'this' pointer before accessing any members or...
	
	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).

	The alleged existence of "specialized C++ implementations" seems
	rather a "fringe" reason for saying that it's undefined; the
	standard could *make* it defined.

	The last paragraph is also vague; does it really mean "...this
	trick is *guaranteed* to work only if f() either checks its
	'this' pointer before accessing any members...?"

	The simple example where this is handly is a linked-list class
	where the objects are always dealt with via pointer.  The class,
	in its quest for robustness, could easily check its 'this'
	pointer before doing anything; consider also:

		void Link::DeleteAll() {
			for ( Link *p = this, *q; p; p = q ) {
				q = p->next;
				delete p;
			}
		}
	
	There's an initial test on 'this' so if I call DeleteAll() with
	a nil pointer, it should do nothing.  It would be nice to not
	have to check for nil in such cases; requiring it is prone to
	user error.

	To reiterate, all I would like is to guarantee that the *call*
	to a non-virtual member-function will succeed and that it's my
	responsibility to check for a non-nil 'this'.

	Comments?

-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.std.c++
From: mendell@turing.toronto.edu (Mark Mendell)
Subject: Re: constructors and exceptions
Organization: IBM Toronto Lab
Date: 21 Aug 92 03:25:04 GMT

Real working exception handling in the IBM xlC C++ compiler on the RS/6000:

In article <2286@devnull.mpd.tandem.com> you write:
>
>Could one of the ANSI-C++ folks that have "paper experience" :-)
>with how exception handling is supposed to work give a summary of how
>will an exception thrown from a constructor interact with objects
>previously constructed in the same "try" block.

An exception in a constructor will destroy the object being constructed
(as far as it has been constructed), then destroy all previously constructed
objects in the try block, and then try matching the catch clauses.  This will
repeat up the static and dynamic blocks until a catch block is found that
matches the exception, or else terminate() will be called.

>
>Also would you please illuminate us on how an exception thrown from
>the constructor of a derived object (which executes after the construction
>of the base object) interacts with the destruction of the base object.
>Will the destructor for the base object be called when the exception
>is thrown?

Any part of the object that has been created will be destroyed (in reverse
order).  In particular the base destructor will be called, but not the 
derived destructor, because the derived object isn't completely contructed
yet.

>
>What about an exception thrown from a signal handler (yuck!) that
>interrupted the construction of an object?

Under xlC, you are not allowed to do a throw from a signal handler.  This
restriction is due to the implementation of exception handling.  Different
implementations might allow you to do this.  On the other hand, the only
portable action allowed by ANSI C in a signal handler is to set a variable
of type sigatomic_t.
-- 
Mark Mendell
IBM Toronto Lab
mendell@torolab6.vnet.ibm.com
From: rgp@mpd.tandem.com (Ramon Pantin)
Newsgroups: comp.std.c++
Subject: constructors and exceptions
Date: 21 Aug 92 03:00:24 GMT
Organization: Tandem Computers, Micro-Products Division
Originator: rgp@seiko.mpd.tandem.com


Could one of the ANSI-C++ folks that have "paper experience" :-)
with how exception handling is supposed to work give a summary of how
will an exception thrown from a constructor interact with objects
previously constructed in the same "try" block.

Also would you please illuminate us on how an exception thrown from
the constructor of a derived object (which executes after the construction
of the base object) interacts with the destruction of the base object.
Will the destructor for the base object be called when the exception
is thrown?

What about an exception thrown from a signal handler (yuck!) that
interrupted the construction of an object?

Ramon Pantin
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: this == 0 for nonvirtual functions
Date: 20 Aug 92 21:54:55 GMT
Organization: Microsoft Corporation
Keywords: this virtual function undefined

In article <1992Aug18.045605.14220@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
|	To reiterate, all I would like is to guarantee that the *call*
|	to a non-virtual member-function will succeed and that it's my
|	responsibility to check for a non-nil 'this'.

First, note that this would not come at "zero" cost.  As in the case of
assigning to a reference, requiring "this" to be non-null allows compilers
to avoid generating code to preserve nullness when adjusting pointers
in the case of MI.  In the case of references, this issue has already
been reviewed and decided upon: one is not allowed to have null references.

Further, note that member functions can be called either on a pointer or
on a reference.  If the language were to PERMIT calling member functions
on a null pointer, such would not ALLOW *you* to test for null "this" inside
you member functions, but rather would REQUIRE all of *us* to test for
null "this" inside ALL *our* non-virtual member functions -- because a user
of our class such as yourself could then legally call *our* member functions via
a null pointer.  If such were the case then, the only sane remedy C++
programmers would have would be to declare all their member functions virtual.
Then *you* *still* could not legally call these members on a null pointer --
but many member functions would now be needlessly slow and generate needlessly
large code.

I suggess instead that you use friend functions or static member functions 
where you feel you must address null pointers implicitly.  Alternately, note
that the users of your class may be the ones in the best position to perform
the null pointer tests [explicitly].
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: this == 0 for nonvirtual functions
Keywords: this virtual function undefined
Date: 22 Aug 92 15:52:58 GMT
Article-I.D.: alice.23528
Reply-To: ark@alice.UUCP ()
Distribution: usa
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Aug22.011400.14896@sunb10.cs.uiuc.edu> pjl@sparc6.cs.uiuc.edu (Paul Lucas) writes:

> 	The example I gave was the member-function:

> 		void Link::DeleteAll() {
> 			for ( Link *p = this, *q; p; p = q ) {
> 				q = p->next;
> 				delete p;
> 			}
> 		}

Because this example ultimately says `delete this' (because p == this
and it says `delete p'), I am already tempted to dismiss it out of hand.
I think it's a Bad Idea to write member functions that invalidate their
object, because it is so far away from what lots of people will expect.

Putting that aside, though, I don't see why it's any harder to make DeleteAll
a static member function with an explicit pointer argument:

	/* static */ void Link::DeleteAll(Link* p) {
		for (Link* q; p; p = q) {
			q = p->next;
			delete p;
		}
	}

The code is about the same length; the only difference in use is that
instead of saying

	foo->DeleteAll();

you say

	Link::DeleteAll(foo);

So I don't think this example is a particularly telling argument.

Ditto for the next example (omitted for brevity).

> 	Again, to reiterate (for Andrew's sake), I think it's a
> 	zero-cost feature; code that works now will continue to work,

It is not a zero-cost feature, because it would require compilers to
generate extra code for every call of a member function inherited
from a base class in the presence of virtual inheritance.

> 	and programmers who ignore it will be unaffected, i.e., if they
> 	don't check 'this' their programs will exhibit undefined
> 	behavior (by trying to access members) and "undefined behavior"
> 	is what happens now anyway.

The feature would prohibit C++ implementations from detecting this==0
as an error, which would make at least some genuine mistakes harder to find.


-- 
				--Andrew Koenig
				  ark@europa.att.com
From: cmhui@cucs18.cs.cuhk.hk (Hui Chau Man)
Newsgroups: comp.std.c++
Subject: Oasys contact wanted
Date: 14 Aug 92 02:41:29 GMT
Organization: Faculty of Engineering, The Chinese U. of Hong Kong

Dear netters,

Can anybody tell me the contact FAX number of Oasys. Oasys is the
developer of Green Hill C and Green Hill C++ compiler.

Thanks in advance.


C.M. Hui
Dept. of Computer Science
The Chinese University of Hongkong
Shatin, N.T.
Hongkong

Internet: cmhui@cucs18.cs.cuhk.hk
FAX: (852) 6035024
From: jamshid@emx.cc.utexas.edu (Jamshid Afshar)
Newsgroups: comp.std.c++
Subject: 'inline' in friend declaration legal?
Date: 13 Aug 92 00:51:58 GMT
Organization: The University of Texas at Austin; Austin, Texas

I believe the following is legal:

   inline void foo();
   class X {
      friend void foo();
   };
   main() { foo(); return 0; }
   inline void foo() {}

, but is 'inline' allowed in a friend declaration?

   class X {
      inline friend void foo();  // is 'inline' legal?
   };
   main() { foo(); return 0; }
   inline void foo() {}

BC++ 3.1 says no, but I think it's a compiler bug.  cfront and others
apparently allow it.  Can someone who is good with grammars confirm
this bug, please?  Post or e-mail and I'll post.

Thanks, Jamshid Afshar
jamshid@emx.utexas.edu
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: this == 0 for nonvirtual functions
Date: Sat, 22 Aug 1992 03:17:40 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
|In <1992Aug20.215455.17279@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
|
|>In article <1992Aug18.045605.14220@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
|>|	To reiterate, all I would like is to guarantee that the *call*
|>|	to a non-virtual member-function will succeed and that it's my
|>|	responsibility to check for a non-nil 'this'.
|
|>First, note that this would not come at "zero" cost.  As in the case of
|>assigning to a reference, requiring "this" to be non-null allows compilers
|>to avoid generating code to preserve nullness when adjusting pointers
|>in the case of MI.  In the case of references, this issue has already
|>been reviewed and decided upon: one is not allowed to have null references.
|
|	I was under the impression that for MI, once a this pointer became
|	zero it has to stay zero, so it constitutes a special-case now.
|	Hence, why wouldn't be a zero-cost feature?


class Derived : public Base1, public Base2 {};
Derived* p;
Base2* q = p;
	// Here the compiler must guarantee that if p was 0,
	// then q will be 0.  This might require extra code
	// to be generated and executed.

p->Base2::f();
	// Here the compiler is allowed to _assume_ that p is not 0,
	// so the extra code to handle the case p == 0 is not needed.

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca