HDTenEightyP/NetNews huggingface dataset:
From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
Newsgroups: comp.std.internat,comp.fonts
Subject: Wanted: Dead or Alive!
Date: 5 Sep 92 00:44:49 GMT
Followup-To: comp.std.internat
Organization: MIT Artificial Intelligence Laboratory

I am posting the following request from Rick McGowan, the Chair of the
Unicode New Scripts Subcommittee, who is seeking information on a
variety of scripts for potential inclusion in a future version of
Unicode.

Glenn Adams

*** INCLUDED MESSAGE FOLLOWS ***

  From: Rick_McGowan@next.com (Rick McGowan)
  Date: Fri, 4 Sep 92 17:25:19 -0700
  To: unicode@sun.com
  Subject: Wanted!  (Advertisement)

  WANTED.  Dead or Alive.  Information concerning any of the following
  scripts.  Prefer information in the form of repertoire listings,
  explanatory material, or bibliographic references to significant sources
  of information easily obtainable by mere mortals within the boundaries of
  the continental US.  Please contact me if you have sighted any of these.
  Allow 10-14 working days for reply.  Void where prohibited.  Post in plain
  sight.

	  Rick_McGowan@NeXT.COM

  Ahom
  Albanian (Buthakukye)
  Assyrian cuneiform
  Avesta (Pazand)
  Aymara script
  Aztec pictograms
  Babylonian cuneiform
  Bamum (Cameroon)
  Buhid
  Chakma
  Cham
  Chieng Mai
  Chola
  Ge'ez script (not modern Ethiopic)
  Hittite hieroglyphics (not the syllabic set)
  Iberian
  Indus Valley script
  Kaithi (original writing for Bihari)
  Kauder script (Micmac Indians)
  Khitan characters
  Khotanese
  Kok Turki runes (Orkhon script)
  Kuoyu
  Lahnda (original writing for Punjabi)
  Lolo script
  Maghreb
  Manchu (Mongolian form)
  Mandaean
  Mangyan
  Manichaean
  Mayan hieroglyphics
  Modi
  Moso (Nasi) ideograms
  Moso phonetic script
  Nuchen characters
  Osmanya script (new script for Somalian)
  Pahlavik (Cursive Pahlavi)
  Parthian
  Paucartambo script
  Phaistos disk script
  Pollard phonetic script
  Proto-Byblic
  Proto-Elamic
  Pyu
  Rejang (on Sumatra)
  Rongo-rongo (Easter Island script)
  Samaritan
  Satavahana
  Sogdian (Uzbekistan)
  Sumerian pictograms
  Tai Lu script
  Tai Nua script
  Tankri
  Vai (Liberia)
  Woleai (Caroline)
  Xixia
From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
Newsgroups: comp.std.internat
Subject: Re: Unicode documentation wanted
Date: 10 Sep 92 12:07:51 GMT
Article-I.D.: life.27734
Organization: MIT Artificial Intelligence Laboratory


  In article <1992Sep9.110612.20495@dde.dk> ct@dde.dk (Claus Tondering) writes:
  >When and how can I obtain version 1.1 of the Unicode standard?

Unicode 1.1 has not yet been written.  Unicode Version 1.0, Volumes I and II
are both available from Addison-Wesley, ISBN 0-201-56788-1 and 0-201-60845-6,
respectively.  Volume II contains the Han (Chinese Hanzi, Japanese Kanji,
Korean Hanja) listings; these are the same as ISO10646 so will not be modified
for Unicode 1.1.  Chapter 1.0 of volume II is entitle "Unification of the
Unicode Standard and ISO 10646" and covers most of the changes that will
appear in Unicode 1.1 as a result of the merger with ISO10646; some additional
changes are not present here due to final changes to the ISO10646 standard
by WG2 in Korea in July.

Glenn Adams
Xref: sparky comp.std.internat:647 soc.culture.turkish:9822 soc.culture.nordic:5592
From: landauer@morocco.Eng.Sun.COM (Doug Landauer)
Newsgroups: comp.std.c++
Subject: Re: Status of C++ standard?
Date: 11 Sep 1992 00:41:13 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: morocco

> 1.  What is the official name of the C++ standard that is being developed
>     (e.g. ANSI X1234.567 or something like that).

First, let's look at the story for the C (not C++) language, for some
real examples of the names of these kinds of things.  The official name
of the international standard for C is something like "ISO 9899".  The
name of the committee that developed that standard is (I believe)
ISO/IEC JTC1 SC22/WG14.  The official name of the ANSI standard for C
is "ANSI X3.1989".  The name of the committee that developed that
standard is ANSI X3J11.  Important points to note are (1) neither
standard was named until after it existed; and (2) the name of the
standard is not particularly related to the name of the committee
that produced that standard.

Now, back to C++.  The C++ standard, since it does not yet exist, has
no name.  The *committee* that is working on a future standard has an
official name which is an expansion of the following:
	ISO/IEC JTC1 SC22/WG21
This is an international committee.  (I'm not up on exactly what all of
the letters stand for.  "J" stands for "Joint".  :-)

One of the national member bodies of this committee represents the US.
That member body is largely, but not exactly the same as the ANSI
committee that you may have been thinking of; its name is ANSI X3J16.

The good news (relative to C) is that the ANSI X3J16 and ISO...WG21
groups have set up their rules for maximum cooperation in producing a
single standard document.  The bad news (for you, apparently) is that
it has no name yet, and won't until it is finished.

> 2.  The status of the standard, and any informed estimates of when
>	it might be formally adopted.

My guess is 1995; some people think 1994, and a few think maybe 1993.

	In all controversies, it is better to wait the decisions of
	time, which are slow and sure, than to take those of synods,
	which are often hasty and injudicious.
		-- J. Priestley, 1761, not talking about X3J16/WG21
-- 
Doug Landauer -- landauer@eng.sun.com
SUNW[STE]->SunPro::Languages.IPE(C++);
Newsgroups: comp.std.c++
From: ppc1@cec1.wustl.edu (Peter Pui Tak Chiu)
Subject: FULL HOUSE
Organization: Washington University, St. Louis MO
Date: Sun, 13 Sep 1992 14:43:41 GMT


hi everyone,

i am trying to find the probability of getting a hand of full house from a
shuffled deck of 52 cards.

theoretically, the probability (i think) is:

        (13 * 4C2) * (12 * 4C3)
        -----------------------  =  0.001440576
                 52C5

but i wrote a c program to calculate this probability and the results turn
out to be very different.

here is part of the results i have:

* the first column denotes the number of trials
* the second column denotes the probability obtained so far


5400000 0.00420815
5410000 0.00420758
5420000 0.00420867
5430000 0.00420829
5440000 0.00420937
5450000 0.00421046
5460000 0.00421154
5470000 0.00420987
5480000 0.00420967
5490000 0.00420765
5500000 0.004208  ..... this means after 5500000 trials, the prob. is 0.004208


from these results, i conclude that the probability would be pretty much around
0.00421 which is very different from the theoretical value.

does anyone know why???

i have included the program i wrote.  it is written in C++ and is very crude...
please try it and give me some feedback.

thanx a lot!

pete


// To calculate the probability of getting a full house

#include <iostream.h>
#include <time.h>
#include <stdlib.h>
#include <math.h>

int BAD,hand[5];		// BAD when the hand dealt is illegal
				// e.g. 5 of the same kind.
				// hand is an array holding the cards dealt
long COUNTER=0, GOOD=0;		// COUNTER = # of trials
				// GOOD = # of full house dealt


void init(){
for(int i=0;i<5;i++)hand[i]=rand()%13;	// deal the cards
}

int fullhouse(){			// determine if fullhouse or illegal
int counter[13],flag3=0,flag2=0;
BAD=0;
for(int i=0;i<13;i++)counter[i]=0;
for(i=0;i<5;i++)counter[hand[i]]++;
for(i=0;i<13;i++){
	if(counter[i]==3)flag3++;	// detect for 3 of a kind
	if(counter[i]==2)flag2++;	// detect for a pair
	if(counter[i]>4)BAD=1;}		// detect for a bad hand
return((flag3==1) && (flag2==1));
}

main(){
srand((unsigned)time(NULL));		// initialize random seed
while(1){
init();					// deal the cards
if(fullhouse())GOOD++;			// if a FULLHOUSE is dealt, increment
					// GOOD
if(!BAD)COUNTER++;			// if the hand dealt is legal
					// increment COUNTER
if(!fmod(COUNTER,10000))cerr<<COUNTER<<" "<<double(GOOD)/COUNTER<<"\n";
	// print out the result every 10000 trials in the format:
	// [ # of trials ] [ probability obtained so far to get full house ]
}}
Newsgroups: comp.std.c++
From: moudgill@cs.cornell.edu ( Mayan Moudgill)
Subject: Is coercion to a reference defined?
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Sun, 6 Sep 1992 18:29:05 GMT

I'm trying to implement an embedded list template class.
It looks something like:

template <class T> class emList {
   ...
   emList *    _next;
   T           _value;
   ...
};

I'd like to define TWO functions:

     operator T () { return _value;}

and
     operator T& () { return _value;}

Is the second definition legal?
How would the compiler resolve them?

:)
Mayan
From: kurr@ctron.com (Ron Kurr)
Newsgroups: comp.std.c++
Subject: C access to C++ code
Keywords: C C++
Date: 15 Sep 92 18:51:31 GMT
Reply-To: kurr@ctron.com
Organization: Cabletron Systems, Inc.

Ron D. Kurr kurr@ctron.com

I need to know how I can link C++ code into a C program.  I
understand that there are issues concerning static objects which are
handled by patch/munch in the C++ environment.  Is it possible, in a
strictly C environment, to link to a C++ library and create a working
executable?  Enquiring minds want to know.

Thanks,

Ron
Newsgroups: comp.std.c++,comp.lang.c++
From: jbuck@ohm.berkeley.edu (Joe Buck)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: Exponentiation operator proposal
Date: 14 Sep 1992 17:30:30 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: ohm.berkeley.edu


>How frequent is a**p anyway? (has anyone got any data?) How confusing
>would it really be? Many people use spaces to clarify (to their eyes,
>if not to everyone else's) code, e.g. a * *p. Also, not all overloading
>creates confusion, especially when identifier names are chosen with
>a minimum of care (want would x**e mean? a**xptr mean?). I doubt the
>case is clear cut.

About the most frequent operation in digital signal processing is some
form of the dot product.  Consider

double dotProduct(double *x, double *y, int n) {
	double sum = 0.0;
	while (--n >= 0) sum += *x++ * *y++;
	return sum;
}

I guarantee (as someone who's written a large amount of numerical C
and C++ code) that there is a great deal of code of the above type,
and while I'm generally careful to space it as above, I've seen code
that doesn't have this spacing.

You'd break programs, no ifs, ands, or buts about it.  It's true that
this breakage would be detected at compile time (the right argument to
'**' would be a pointer).

As Dr. Stroustrup suggested, an alternative would be to have '*' '*'
mean exponentiation and handle x '*' '*' ptr as a special case, so
it would keep its meaning of dereference-and-multiply.  That would
work, as best I can tell, for C, but in C++, '*' might be overloaded
for the unary or binary case.  This hack wouldn't work then or would
cause nasty surprises.

I think Matt Austern's analysis is basically correct: the exponentiation
operator should be a token, one not appearing in the language currently
so that it cannot break existing programs.  Those in favor of ** must
show, IMHO, that it would break virtually no programs, and this can't
be done without introducing a series of hacks.  If every other language
used **, this would be a strong argument in its favor, but many languages
use ^ instead.

Furthermore, there are three other considerations: the ability to construct
the corresponding assignment operator (eliminating !), the
internationalization issues (eliminating several characters like @ that
aren't on all keyboards), and avoiding breaking analogies between
operators (there is a relation between & and &&, and | and ||, which
should not be violated for ^ and ^^).

>I am not arguing that ** is THE right solution, but that given the
>demand for it and the lack of ginuinely nice alternatives ** should
>not be written off without a thought and/or in the belief that it
>is technically infeasible to provide it.

Before Fortran, no one thought ** should mean exponentiation.  Any
reasonable token choice that doesn't violate one of the above
considerations will work.  Austern's *^ is as good as any.



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.std.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: Proposal: Semantic Change on Operator "::"
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Distribution: World
Date: Fri, 11 Sep 92 18:24:05 GMT

In article <1992Sep11.173823.17289@cadsun.corp.mot.com> shang@corp.mot.com  
(David (Lujun) Shang) writes:

> In example:
> 
>         class A { public: static int i; };
>         class A_ { public: static int i; };
>         class B: public A { public: static A_ A;   };
>         B b;
> 
> "B.A::i" denotes the integer of A_;
> "B::A.i" denotes the integer of A;
> 
Sorry, should be 

"B.A.i" denotes the integer of A_;
"B.A::i" denotes the integer of A;

Note that "::" has a hihger priority than ".".

David Shang
Newsgroups: comp.std.c++,comp.lang.c++
From: rr@world.std.com (Robert I Ransbottom)
Subject: Re: Exponentiation operator proposal
Summary: ^^ better than ** or *^
Organization: The World Public Access UNIX, Brookline, MA
Date: Sun, 13 Sep 1992 23:58:39 GMT

In article <1992Sep13.193507.27813@ima.isc.com> karl@ima.isc.com (Karl Heuer) writes:
>In article <23660@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:

>>Comments on Mat Austern's proposal for an exponentiation operator

>>[By defining `**' to have semantics of TIMES FETCH when the right operand

>I considered this when I wrote my exponentiation essay.  I decided that it
>might be possible, but it's way too confusing!  This would be a kludge of the
>highest order.  It's much better to use syntax that's not already taken --
>I've adopted "*^", as suggested by someone else some years ago.  (A hybrid of
>"**" and "^", sort of.)

I agree ** is confusing, given the potential frequency of both "dat**ptr" and
"dat**dat" it seems like a waste to deciphering such.  The proponents
of **expon want a convenience. 

I think that ^^ would be more satisfying to both pointer-ers and math-ers.  

    1. Its not already taken!
    2. Its not already taken!
    3. Its not already taken!
    .   .   .    .      .
    .   .   .    .      .
    n. Its easier to type than Karl's *^. 
    n+1. No more damaging if mistyped.
    n+2. The contexts of exponentiation and exclusive-or have less overlap
    	than multiplication & indirection and exponentiation.

My vote is behind a keyword like

	operator consistent { *=, /=, -=, += }

which would shorthand consistent derivatives  X= from X and =.
The longhand is simple enough to generate, but is more difficult to
read/verify given alien code.
-- 
rr@world.std.com  Robert Ransbottom

"Maintaining correct attributions is extremely important." -- anonymous
Newsgroups: comp.std.c++
From: hbf@durin.uio.no (Hallvard B Furuseth)
Subject: static virtual
Organization: University of Oslo, Norway
Date: Tue, 15 Sep 1992 12:59:18 GMT

Why are static virtual functions illegal?  This would be useful for
functions such as `virtual int SymbolTable::compare(char *, char *)'.
It's a waste to pass a pointer to `this' to those functions.

And while I'm writing: How about static virtual variables?  These would
be useful for per-class data such as a "description" fields for a class.
Maybe only const variables should be allowed though.
--

Hallvard
Newsgroups: comp.std.c++,comp.lang.c++
From: karl@ima.isc.com (Karl Heuer)
Subject: Re: Exponentiation operator proposal
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Sun, 13 Sep 1992 19:35:07 GMT

In article <23660@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>Comments on Mat Austern's proposal for an exponentiation operator

I missed that one, but I've posted about exponentiation a few times myself.

>(1) I think overloading and inlining ...

My only objection to this method (other than the perceived aesthetic
superiority of an infix operator) is that the later example
>	void f(double d, int i) { ... pow(d,i); ... }
inline-expands to something that always runtime-compares the variable i with
certain small integers before invoking the true function _pow().  In some
sense it would be better to do this only when i is a constant (in which case
it's a compile-time compare), and have the non-constant-exponent case simply
call the true function immediately.

This could be accomplished with one addition to the language:
	isconstant(expr) - an operator that returns 1 if expr is a
	constant expression, or 0 if not.  If the operand involves
	formal parameters to an inline function, the actual arguments
	are used.

>(2) I think we could actually get ** as the exponentiation operator.
>[By defining `**' to have semantics of TIMES FETCH when the right operand
>is a pointer]

I considered this when I wrote my exponentiation essay.  I decided that it
might be possible, but it's way too confusing!  This would be a kludge of the
highest order.  It's much better to use syntax that's not already taken --
I've adopted "*^", as suggested by someone else some years ago.  (A hybrid of
"**" and "^", sort of.)

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.std.c++
From: cline@sun.soe.clarkson.edu (Marshall Cline)
Subject: Re: Is coercion to a reference defined?
Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline)
Organization: Paradigm Shift, Inc (C++/Reuse/OOD/OO-mgmt training)
Date: Wed, 9 Sep 1992 04:58:00 GMT

In article <1992Sep6.182905.6603@cs.cornell.edu> moudgill@cs.cornell.edu ( Mayan Moudgill) writes:
...
>I'd like to define TWO functions:
>     operator T () { return _value;}
>and
>     operator T& () { return _value;}

They would, as stated, be ambiguous.  However, you can make the first one
a `const' member function, thereby disambiguating them based on the constness
of the object being converted to a T.

++Marshall
--
Marshall Cline
--
Marshall P. Cline, Ph.D. / Paradigm Shift, Inc / 65 N Main St/Norwood, NY 13668
cline@sun.soe.clarkson.edu / 315-353-4585 / FAX: 315-353-6100
Maintainer, C++ FAQ
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 9 Sep 92 19:26:46 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
: 
: Secondly, some comments about C++.
: In ANSI C, pointer comparisons between pointers to unrelated objects (ie.
: objects that are not both members of the same aggregate) cause undefined
: behavior,

Small clarifications:

The ARM is explicit about the relational operators (<,>,<=,>=),
and then goes on to say the equality operators are "exactly analogous".
Anyway, comparison with pointers to members of the same aggregate are only
defined if they belong to the same access zone (simplified).  Also,
pointer comparison within the same array is supported.

:I believe. For example, the following program
: 	#include <assert.h>
: 	int main() {
: 		int x,y;
: 		assert(&x != &y);
: 	}
: should cause undefined behavior. [Is this correct?]

I'd say yes.  On a segmented architecture (can you say 'PC'?)
pointer comparison need not use the full 32 bits for pointer comparison,
instead a 16 bit offset may be used (note that this limits arrays to 64 KB).

I wonder if the 'PC' segmented architecture will reappear in the
first 64 bit processors (representing pointers as 32 bit offsets within
up to 2^32 segments)?  Does anyone have any info on this?

Anyway, the current rules do seem to cause trouble for the common (?)
idiom for operator =:

const T& operator = ( const T& t )
{
	if ( &t == this ) return;	// avoid self-assignment
	// ...
}

Is the above idiom broken?
Should the current rules be changed (inflicting a small performance penalty
on some machines)?

: Given that this is the case, it seems contradictory that repeated calls to
: operator new(0) are required to return pointers to "distinct objects".
: How could a conforming program possibly detect whether this requirement
: was actually met? Surely the following program
: 	#include <assert.h>
: 	int main() {
: 		assert(operator new(0) != operator new(0));
: 	}

If sizeof(long) >= sizeof(void*), then you should be able to
test like this:

assert( (long)p1 != (long)p2 );

since a pointer stored in an integer variable must keep all information
needed to restore the pointer (if the integer type is large enough).

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Newsgroups: comp.std.c++
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Zero-length structures and pointer comparisons
Organization: University of Jyvaskyla, Finland
Date: Thu, 10 Sep 1992 09:49:57 GMT

In article <4945@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>:  [ ... ]
>  [ ... ]
>:I believe. For example, the following program
>: 	#include <assert.h>
>: 	int main() {
>: 		int x,y;
>: 		assert(&x != &y);
>: 	}
>: should cause undefined behavior. [Is this correct?]
>
>I'd say yes.  On a segmented architecture (can you say 'PC'?)
>pointer comparison need not use the full 32 bits for pointer comparison,
>instead a 16 bit offset may be used (note that this limits arrays to 64 KB).
>  [ ... ]
>Anyway, the current rules do seem to cause trouble for the common (?)
>idiom for operator =:
>
>const T& operator = ( const T& t )
>{
>	if ( &t == this ) return;	// avoid self-assignment
>	// ...
>}
>
>Is the above idiom broken?
>Should the current rules be changed (inflicting a small performance penalty
>on some machines)?

Oh dear, why have I not noted this _horrible_ defect in the language
definition before?  Probably because it was too bad to be suspected.
The above idiom is certainly common, and it is used in Stroustrup's
own books.  The first example I could found now in "The C++ P. L." (2. ed.)
is in 8.3.3 (p. 266).  In one member function of the list class there is
code like this:
	slink* f = last->next;
	if (f == last)
		last = 0;
	else
		last->next = f->next;

I can see no warning in the vicinity telling that the meaning of this code
is implementation dependent or undefined!

My opinion:  the idiom is sensible, in many cases even necessary.
It is the pertinent part in the language definition that is broken,
obviously (as explained by Johan above) in order to facilitate
efficient implementation on obsolescent machine architectures.
Was it William Wulf who wrote approximately: "More sins in programming
are committed in the name of efficiency than all other reasons combined,
including sheer stupidity"?

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.std.c++