HDTenEightyP/NetNews huggingface dataset:
From: djbpitt+@pitt.edu (David J Birnbaum)
Newsgroups: comp.std.internat
Subject: Re: Language tagging
Date: 5 Jan 93 03:51:12 GMT
Organization: University of Pittsburgh

>>It is true that Vadim's character set always carries language
>>information along with it, while bare Unicode does not. A Unicode based
>>system, though, will require more than the bare character set (which is
>>why I refer to it as a "Unicode-based system," rather than simply as
>>"Unicode"). 
>
>Until we can figure how to attach the information, we can't use
>Unicode or "Unicode-based system".

The acceptance of a standard for attaching this information is important
and what I can do with Unicode in the absence of language tagging is
somewhat limited. I find "we can't use" unnecessarily hyperbolic and
pessimistic: ISO 8859/5 (Latin/Cyrillic) also contains no language
identifiers of any sort, either as higher-level tags or through
language-specific character ranges. That is, the need for language
information in coded texts is real, but their absence from character
sets is representative of many ISO standards and is not unique to Unicode.
I agree that language information will ultimately have to be
standardized, but I do not believe that this information necessarily has
to be an inherent part of the character set itself.

As for "figuring out how to attach this information," the problem is
far from solved, at least insofar as there are no widespread
implementations of standardized systems to deal with it, but SGML is
one candidate. I mention this not as a specific endorsement of SGML
(perhaps there are better structures and SGML is hardly in widespread
use), but as a reminder that there are efforts underway to develop a
standard for attaching language information. I, too, impatiently await
their ripening.

--David
--
-- 
Professor David J. Birnbaum         djbpitt+@pitt.edu [Internet]
The Royal York Apartments, #802     djbpitt@pittvms   [Bitnet]
3955 Bigelow Boulevard              voice: 1-412-687-4653
Pittsburgh, PA  15213  USA          fax:   1-412-624-9714
From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
Newsgroups: comp.std.internat
Subject: ISO paper sizes
Date: 4 Jan 1993 15:55:12 +0100
Organization: Regionales Rechenzentrum Erlangen
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de

Here for the aprox. 5% of the world population that don't use ISO paper sizes
the dimensions of 3 of the most popular sizes:

    A4    210 x 297 mm
    C5    162 x 229 mm (envelope for A4 folded to A6 format)
    DL    110 x 220 mm (envelope for A4 folded twice parallel)

1 inch is 25.4000000 mm.

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
---- simply not getting the most out of life possible. (Brian Downing) ----
Newsgroups: comp.std.internat
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.std.internat
Subject: Re: ISO paper sizes
Date: 11 Jan 93 00:24:37 GMT
Organization: CWI, Amsterdam

In article <19930110.007@erik.naggum.no> Erik Naggum <enag@ifi.uio.no> writes:
 > [Alasdair Grant]
 > :
 > |   1 SI inch is 2.54mm _exactly_, not just to 7 decimal places.
 > 
 > There is no Systeme International "inch".
 > 
 > |   But the people who don't use ISO paper sizes don't use SI inches
 > |   either, they use NIST inches, which differ from SI inches well before
 > |   the 8th decimal place.  (I don't know the exact details - after all,
 > |   why should I know about American internal standards?)
 > 
 > "NIST" inches were aligned with the SI units well before 1982 (my earliest
 > reference to 1 inch = 2.54 cm), except for the US Survey foot, which is
 > ~1.000002 ft, and reflects the old inch, for very sound reasons.
 > 
Quoting from my basic reference on units %, subject yard:
	"... In England until 1963 the Imperial Standard Yard was the legal
	unit of length.  It was defined in the Weights and Measures Act of
	1878 as the distance between two points on a specified metal bar.
	In 1963 the yard was redefined as being equal to 0.9144 metres
	exactly.
	  In the United States the yard is specified by the Mendenhall order
	of 1893 as being equal to 3600/3937 metre and this makes the U.S.
	yard equal to 0.91440183 metres, i.e. it is about 0.7 * 10-4 inches
	longer than the 1963 Standard Yard.
	  In 1959 the International yard (0.9144 m) was adopted in the
	British Commonwealth and the United States of America for scientific
	purposes.  This yard has no legal status for trade but it is used as
	the unit of length both by the British Standards Institution and the
	American Standards Association.  The International yard is exactly
	the same as the British 1963 yard. ..."
What can we conclude?  The remarks of another poster chime with this (1 m =
39.37 US inch).  The US inch/foot is not only used for Survey but also in
Trade.  Only for scientific purposes the International inch is used.  The
US inch is *not* equal to the old Imperial inch.  While ASA (now ANSI)
standardized on the International Inch (for scientific purposes), I do
think that NIST did standardize the US inch.  The conversion factor Eric
gave is correct.  Now, while my reference is a bit outdated, I do not
think much has been changed.
--
%  H.G.Jerrard & D.B.McNeill, A Dictionary of Scientific Units.  Science
   Paperbacks, Chapman & Hall Ltd., London, 1966.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.std.internat
Subject: Dumb Terry
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Date: 7 Jan 93 08:55:00 GMT
Organization: Tokyo Institute of Technology

In article <1993Jan7.063116.14846@fcom.cc.utah.edu>
	terry@cs.weber.edu (A Wizard of Earth C) writes:

>The
>collation sequences for Japanese, for instance, vary on pronuciation.  If
>it were the intent of Unicode to provide a unified collation mechanism,
>this would be a very strong argument against Chinese/Japanese unification.

You completely miss the point. Japanese Kanji does not have a unique
pronouciation, while Japanese word has.

>First, Unicode is not the sole definition of 10646; just the only currently
>defined character set within 10646.  There is no reason to throw out 10646
>because of Unicode (although I could make an argument for 32 bits being a
>nifty reason for doing so).

10646 explicitely assign corresponding C/J/K Han in GB, JIS and KCS national
standard to the same code point. Thus, expanding 10646 to 32 bit can't
re-separate the assignment.

That is, 10646 is unusable, because it is polluted with Unicode.

>Second, Unicode buys more than simply another character set; it buys the
>ability to produce non-conflicting monolingual localizations of software
>systems (as opposed to conflicting ones as a result of a lack of standards
>coordination with existing standards).  It also buys a platform for
>non-conflicting multinationalization (multilingual data processing) given
>a means of compounding documents by language/locale (there may be more than
>one locale per language).

For such a purpose, use EUC, which is the moderate subset of ISO 2022.

>The Unicode character set solves a number of long standing problems.

Unicode is a genuine mixture of past failures:

	1) 16 bitness from 8 bitness of ISO 8859/*
	2) statefullness (by signature) from ISO 2022
	3) combining characters from ISO 6937
	4) existence of full/half width character from JIS X0201/0208

and more, without solving any problems. And now, you are importing
one more failure: incorrect dependence on locale model.

						Masataka Ohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.std.internat
Subject: Re: The ultimate encoding
Date: 10 Jan 93 03:41:46 GMT
Organization: Tokyo Institute of Technology

In article <1993Jan9.220818.25882@enea.se>
	sommar@enea.se (Erland Sommarskog) writes:

>Seriously, I disagrees with the statement above, and I think most
>other people do. Putting the language into the coding gives more
>problems than it solves. How deal with umpteen instances of the
>same character because it is treated different language?

If an application must neglect language difference, it can do so in the
application.

>But Unicode is not a partial solution for the Soviet Union in the 1980s. 

Agreed.

>Unicode is a tool for complete solutions for the world in the 21st century.

Disagreed. Perhaps, you are trying to force all the people in the world
(or, at least Japanese) to use Latin alphabet only in the 21st century.

But, we won't.

						Masataka Ohta
From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
Newsgroups: comp.std.internat
Subject: Re: INTERNATIONALIZATION: JAPAN, FAR EAST
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Date: 8 Jan 93 01:20:31 GMT
Organization: MIT Artificial Intelligence Laboratory
NNTP-Posting-Host: wheat-chex.ai.mit.edu

In article <1ii3ctINNp4c@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
>All languages have a default sorting -- namely the one which is used in
>dictionaries.

Wrong.  Many writing systems have no single default.  Dictionary orders
are not unique in many writing systems.  For example, Tibetan, Burmese,
Vietnamese, just to name a few, have more than one dictionary ordering.
Different dictionaries in these languages often use different orders.

>They [10646 and Unicode] share the common design philosophy and the same
>fundamental mistakes.

Wrong.  They share the same fundamental strengths.  The only fundamental
mistake being discussed is the blind optimism of a few people
who think they can create perfection ex nihilo.  Perhaps you've been
overly influenced by some sort of utopian ideology?

>Then, we don't need one more sloppy standard.

Why don't you go reinvent history in your own image?  I'm sure you
will be so careful as to eliminate any sloppiness.

>10646 is inadequate for true multinationalization because it breaks
>existing OS semantics.

Existing OS semantics have no concept of multinationalization.  They
won't become fully multilingual without important changes.
For someone so little concerned with historical compatibility, you seem
overly invested in current OS technology.

Rather than continuing your foaming-at-the-mouth-diatribe against something
which -- as you've admitted -- you don't even have time to read about, why
don't you go off for a few years and create your ultimate perfection of
a character set, convince a large number of computer vendors that it is
worth implementing, then make sure it becomes an international standard.
When you've finished, come back and tell us how different it is from
Unicode/10646.  I am eagerly awaiting your report.

Glenn Adams
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.std.internat
Subject: Re: Future extension of ISO 10646
Date: 4 Jan 93 17:29:30 GMT
Organization: Tokyo Institute of Technology

In article <1993Jan4.102448.9710@cs.ruu.nl>
	jhelling@cs.ruu.nl (Jeroen Hellingman) writes:

>I think it would be much wiser to use I higher level coding to indicate the
>language of a string of characters.

As Unicode wrongly unified Chinese and Japanese characters, we need the
differentiation for simple everyday job.

It should be noted that, printers for simple everyday job outputs
differently shaped glyph for correnponding Chinese/Japanese characters.

						Masataka Ohta
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.std.internat
Subject: Re: islands
Date: 10 Jan 93 19:19:56 GMT
Organization: Auspex Systems, Santa Clara

>They currently use environment variables (e.g. "LANG") for "file
>typing".  This is how they can use the same "vi" binary in both Japan
>and Germany.

Actually, if they use the same "vi" binary in Japan, Germany, *and* the
US, they don't do Japanese EUC, because the "vi" that comes with SunOS
4.1[.x] is derived from the SVR3.1 one, which only does 8-bit character
sets.  They may have a "vi" that does 16-bit character sets as part of
Asian localization kits, and maybe the SVR4 "vi" that I assume comes
with SunOS 5.x handles 16-bit character sets.

The 4.1[.x] character-set handling stuff is set up to handle multiple
types of character sets, not just EUC, and that may be the way they
handle Unicode/UTF as well - depending on the setting of LANG, it'll do
ISO 8859/1, or 8859/n, or Japanese EUC, or Unicode/UTF, or....

They may also supply a program or programs to turn "plain text" files in
those character sets into UTF files, and to do the same with directories
(i.e., renaming files so that a file with a non-ASCII name in the
character set in question gets a new name that's the same name in UTF,
and possibly also fixing symbolic links).

Or they may do something else.
From: linke@sbi.sbi.com (User - Bill Linke)
Newsgroups: comp.std.c++
Subject: Re: pointer comparisons
Summary: why not restrict "object identity"?
Date: 9 Jan 93 01:22:33 GMT
Organization: Salomon Brothers Inc.
Originator: linke@kirin

In article <1993Jan7.145511.718@lpi.liant.com>, pkt@lpi.liant.com (Scott Turner) writes:
> 
> Identity of objects is more of the essence than storage, so it would be
> problematic to define the former in terms of the latter.

Even this is not so clear, is it?  "Identity" means to me that we can
distinguish between two instances of a class using only the attributes of the
class itself (i.e. without using anything from derived classes which the class
might happen to be a base class of).  This in turn implies that somewhere
within each instance is some storage which conceptually could hold some
identifying value.  (Otherwise, there would be no way for two instances to
have different attributes.)

In other words, it makes more sense to me to restrict the concept of
"object identity" as being meaningful *only* when applied to instances of
a class which contains storage members within itself or its ancestors.
(Then it doesn't really matter whether pointers to non-storage class objects
compare equal or not, because there is no "identity" to be found that way
in the first place.)

Bill Linke
linke@kirin.sbi.com
Newsgroups: comp.std.c++
Subject: Asking info about author of "Mastering Borland C++"
From: fen@vax1.mankato.msus.edu
Date: 5 Jan 93 02:15:49 -0600
Organization: Mankato State University

I need to contact Tom Swan, the author of "Mastering Borland C++" ASAP.
Someone knows his E-mail address or mailing address,please give me a E-mail at
IN%"fen@vax1.mankato.msus.edu".   Many Thanks in advance.
F Zhou
Newsgroups: comp.std.c++
From: dwr@cci632.cci.com (Donald W. Rouse II)
Subject: Re: Proposal for default scope
Organization: [Computer Consoles, Inc., Rochester, NY
Date: Fri, 8 Jan 1993 17:36:54 GMT

In article <1993Jan8.044714.2027@qualcomm.com> greg@qualcom.qualcomm.com (Greg Noel) writes:
[...]
>The semantics would be that all names defined in the scope would be visible
>within the scope (subject to the usual scoping/visibility rules, of course);
>names that were declared in the class description would be the only ones
>exported from the scope.  This would allow a helper function to be defined
>that had full access to the class private members, but still be type-safe,
>since the only way to access the helper functions would be from within the
>scope and the only way to enter the scope would be via the class interface.
>
>That is,
>	class Class {
>	public:  int func1();
>	};
>	Class:: {
>		int helper() { /* ... */ }
>		int func1() { /* code including calls to helper() */ }
>	}
>Since helper() is not declared in the class, it is not exported from the
>scope, while func1() is declared in the class, so it is exported in the
>normal fashion.
>

You can accomplish the same thing with
	class Class {
	private: static int helper ();
	public:  int func1();
	};
although you don't get the syntactic sugar.
Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Extra COntant definitions
Organization: TauMetric Corporation
Date: Thu, 7 Jan 1993 17:25:22 GMT

rodb@racerx.bridge.COM (Rod Burman) writes:

>It has just occured to me that since C++ is a strongly typed language
>it should provide intrinsic support for constants of all intrinsic types
>that is currently we have:

>		1	// int
>		1U	// unsigned int
>		1L	// long
>		1UL	// unsigned long

OK so far.

>		'\1'	// unsigned char ...

No.  This has type "char", a type distinct from both "signed char" and
"unsigned char".  It will usually have the same implementation as either
signed or unsigned char, you are not allowed to assume which.
Similarly, type int usually has the same implementation as either type
short or type long, but is always a type distinct from both.  Not all
current C++ implementations have the required three character types.

>		'\1'L	// wide unsigned char ...

No.  It will have whatever type the implementation chose for wide
characters, and may be any signed or unsigned integral type.  There
is no "signed wide character" or "unsigned wide character" type, just
plain "wide character", which may behave as either a signed or an
unsigned type.

>		"\1"	// unsigned char[]
>		"\1"L	// unsigned wide char  ...

No to both.  See above.

>This as I see it leaves room for:

>		1S	// short
>		1US	// unsigned short

... etc.

>Ofcourse you can always have:

>	(short) 1;	// etc

>and this may be more portable ...

Well, I would say it is more general, rather than more portable.

You could make a symmetry argument for the additional suffixes, but
I don't see that they solve any problem.  Although this would not
break any existing code, it might create readability problems.

For example, I don't like using the lower-case 'l' suffix, since 2l
looks too much like 21.  Similarly, some type faces make 'S' or 's'
hard to distinguish at a glance from a '5', particularly when you
are not expecting to see the letter 's'.

Whenever a short value appears in an expression it is immediately
promoted to type int.  For example, let XX stand for any integer
literal representable as a short, and XXs be that value with type
short as you request.  Let Z be a value of any scalar type.  Then
the three expressions
	XX + Z
	(short)XX + Z
	XXs + Z
must always have exactly the same effect.  The 's' suffix does not
allow the compiler to take any shortcuts it could not take without
the suffix.  (The suffix can only be applied to a literal, so the
compiler already knows whether the value is representable as a short.)

The only place a "short" suffix could make a difference is in
choosing an overloaded function:
	int foo(int);
	int foo(short);
	...
	foo(XX)		// calls foo(int)
	foo(XXs)	// calls foo(short)
Of course, we can always write
	foo((short)XX)	// calls foo(short)
for the rare cases when this arises.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: initialized 'global' (extern) char arrays
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 8 Jan 1993 01:23:49 GMT

jimlynch@netcom.com (Jim Lynch) writes:

>I am given to understand that the storage allocated by
>
>char *x = "abcde" ;
>
>is not writable.

Correct.

>The reason I ask is that I used such a construct in gcc-2.3.2 ...
[example omitted]
>... Shouldn't the compiler have warned me?

With gcc, use the -Wwrite-strings option. Here's an extract from the
manual:

	  -Wwrite-strings
	       Give string constants the type  const  char[length]  so
	       that copying the	address	of one into a non-const	char *
	       pointer will get	a warning.  These warnings  will  help
	       you  find  at  compile  time code that can try to write
	       into a string constant, but only	if you have been  very
	       careful	about  using  const in declarations and	proto-
	       types.  Otherwise, it will just be a nuisance; this  is
	       why we did not make `-Wall' request these warnings.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: pabloh@hpwala.wal.hp.com (Pablo Halpern )
Date: Mon, 4 Jan 1993 23:13:10 GMT
Subject: Re: Nested functions (was: Re: Zero-length structures and pointer comparisons)
Organization: Hewlett-Packard Company
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: pointer comparisons
Date: 05 Jan 93 00:49:50 GMT
Organization: Microsoft Corporation
Distribution: usa

|In article <9300300.29900@mulga.cs.mu.OZ.AU> (Fergus James HENDERSON) 
|writes:
|>   "The _sizeof_ operator yields the size, in bytes, of its operand".
|> I think that it would be a very brave compiler-writer whose compiler
|> made it unreliable to write() an object and read() it in again, because
|>   read(fd, &object, sizeof object);
|> randomly trashes the bytes past the end of the object.

Yet in the example I posted of a vacuous baseclass and a first member
of the base type, no such problem exists.  Sizeof == 1.  Bytes required
within the structure by the baseclass "subobject" == 0.  
And read(fd, &object, sizeof object) *does not* randomly trash the bytes
past the end of the object.  Further, this implementation is consistent
with the ANSI-C base document *mandate* that implementations do not
introduce padding into a structure before the first member. 
ANSI-C mandates that the address of the first member be the same as the 
address of the structure.  Unless there is overriding reason in the ARM
why this cannot be the case, then the ANSI-C base document ought to be
respected.  My claim is that there is no such overriding ARM requirement.

Xref: sparky comp.std.c++:1979 comp.lang.c++:18758
From: rodb@racerx.bridge.COM (Rod Burman)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Constants
Summary: How do constant arrays work?
Date: 6 Jan 93 17:14:26 GMT
Followup-To: comp.std.c++
Organization: Bridge Information Systems

Hi netters I'm having a slight portability problem which is this

class	base { /* stuff */ }
class	derv : public base { /* more stuff */ }

const	derv	array[2] = { { /* 0th element */ }, { /* 1st element */ } };

(I may have got this slightly wrong doing it from memory but, it is obvious
(I hope) that I'm trying to set up an array of constants) derv has the appropriate
constructor which uses a constructor in base) Now this all works fine with Borland C++
but when I try with DEC C++ (VAX/VMS) it fails, it seems that Borland gives me:

	for (i = 0; i < number_of_elements; i++) {
		derv(/* this = &array[i] */ /* constant stuff */);	// 'clever' constreuctor
	}
or equivalent done at compile time, DEC C++ does something more like:

	for (i = 0; i < number_of_elements; i++) {
		derv(/* this = &array[i]);			// default constructor
		derv(/* this = &temp */ /* constant stuff */);	// clever constructor
		derv(/* this = &array[i], */ temp);		// copy constructor
	}

I deduce this from the fact that if I make the default and copy constructors visible
(i.e. not private) the thing will compile. I also deduce that one of three things is
wrong:

	1)	I've done something silly and Borland C++ is just being kind to a moron
	2)	DEC C++ is stupid since it's method is not only much less efficient it also
		makes my code much more involved as each derv in my application gets immeadiately
		places on a queue somewhere so I have to destruct both the default constructed
		and temp ones or my queue has 3 * too many members
	3)	DEC C++ is right (i.e. doing what is to be expected) in which case the ARM is wrong
		since surely Borland is doing what one would expect? (Hence my post to comp.std.c++)

Anyone out there got an anwer?
		thanks Rod.
Newsgroups: comp.std.c++