HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.std.misc
Subject: Re: Common Lisp is a dpANS in Public Review
Date: 24 Aug 1992 03:20:59 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <#7-nz!r.thinman@netcom.com> thinman@netcom.com (Technically Sweet) writes:
>johnl@iecc.cambridge.ma.us (John R. Levine) writes:
>>An advantage of the current system
>>is that standards are paid for by people who actually use them.
>A disadvantage of the current system is that 95% of the standards
>arrived at are technically garbage.  Down with ANSI!
>
>X, FDDI, PEX, OSI, ...  The last really good one was Ethernet,
>and they had that forced down their throats.

That list could hardly be considered a condemnation of the ANSI
standardization process, since none of those were developed using that
process.  X and PEX were developed privately by consortia, FDDI was
developed by CCITT (or maybe IEEE or ISO, I'm not sure), and OSI is being
developed by ISO.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.std.misc
From: thinman@netcom.com (Technically Sweet)
Subject: Re: Common Lisp is a dpANS in Public Review
Date: Sun, 23 Aug 92 22:53:12 GMT
Organization: International Foundation for Internal Freedom

johnl@iecc.cambridge.ma.us (John R. Levine) writes:

>But so far
>nobody has come up with a plausible way to make up for the lost revenue
>that ANSI needs to stay in business.  An advantage of the current system
>is that standards are paid for by people who actually use them.

A disadvantage of the current system is that 95% of the standards
arrived at are technically garbage.  Down with ANSI!

X, FDDI, PEX, OSI, ...  The last really good one was Ethernet,
and they had that forced down their throats.


-- 

Lance Norskog

Data is not information is not knowledge is not wisdom.
Newsgroups: comp.std.internat
From: jkp@cs.HUT.FI (Jyrki Kuoppala)
Subject: RFD: comp.international
Followup-To: news.groups
Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala)
Organization: Helsinki University of Technology, Finland
Date: Tue, 1 Sep 1992 03:19:38 GMT

A repost from news.announce.newgroups et al:

From: Jyrki Kuoppala <jkp@cs.hut.fi>
Subject: RFD: comp.international
Followup-To: news.groups
Organization: Helsinki University of Technology, Finland.
Date: Tue, 1 Sep 1992 00:54:36 GMT

This is a request for discussion regarding creation of an unmoderated
newsgroup for discussing internation aspects of computers, computer
software, telecommunications and so on.

comp.international	Discussions on hardware & software in international use.

Comp.international is a group for discussing design and use of
computer hardware and software (and other material in the field of
computing) around the world, ie. how to provide for differences in
character sets, cultural environments, styles in writing dates,
electrical and other requirements, legal requirements and so on.

The discussion on this proposal will take place in news.groups.

Please see the pertinent postings in news.answers and
news.announce.newgroups for the rules that will be followed in
creating a newsgroup (<spaf-howto_711614959@cs.purdue.edu>).

//Jyrki
From: melby@dove.yk.Fujitsu.CO.JP (John B. Melby)
Newsgroups: comp.std.internat
Subject: Re: International character sets
Date: 4 Sep 92 02:45:46 GMT
Organization: Open Systems Dept. Div. 2 Sect. 1, FUJITSU LTD.
In-reply-to: andrew@cursci.co.uk's message of 4 Sep 92 02:42:38 JST

>what I really want is a full description of either a 16-bit or
>32-bit character sequences that will include all the roman chars and their
>accented chars in a sequence that I can sort on.

Keep in mind that sorting methods are locale/implementation-dependent.
For example, an English-based sorting system will put Angstrom (with an
A-ring) before Zyzzyva, but a Swedish-based sorting system will put them
in the opposite order (since A-ring comes after Z).  To give a slightly
trickier example, a Spanish-based sorting system will put "llama" after
"LZH," because "ll" is a separate letter which comes between "l" and "m."

-----
John B. Melby
Fujitsu Limited, Yokohama
melby%yk.fujitsu.co.jp@fai.com
From: keld@login.dkuug.dk (Keld J|rn Simonsen)
Newsgroups: comp.std.internat
Subject: Re: ISO 639 language list wanted
Date: 4 Sep 92 14:25:53 GMT

There is a copy off ISO 639 in dkuug.dk:i18n/ISO_639

There is a more comprehensive list forthcoming in a new ISO standard,
I do not have the number right here.

Keld Simonsen
Newsgroups: comp.std.internat
From: a0047@aix370.rrz.Uni-Koeln.DE (Andreas Strotmann)
Subject: comp.std.internat archive
Reply-To: a0047@aix370.rrz.Uni-Koeln.DE (Andreas Strotmann)
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Date: Wed, 02 Sep 92 17:34:38 GMT

In article <1992Aug25.105342.189801@rrz.uni-koeln.de>  I asked:

> 
>  - Does anyone archive comp.std.internat?  Where?

Dominic Dunlop <dominic@natcorp.ox.ac.uk> answered (some stuff deleted)

> I keep a personal archive.  I have a little more than 1.25 megabytes,
> going back to 17 June 1991 on-line.  It would be easiest if I could
> ftp it over to a public drop directory which you can access.  Can you
> name one.  (We do not have one here at Oxford, and my sysetm is not
> set up for anonymous ftp.)

His archive is now available via anonymous FTP as

  ftp.uni-koeln.de:pub/misc/comp.std.internat.Z

in the form of a compressed mail archive.  He says he's also got archives
around that go further back if anyone's interested.

Thanks, Dominic!

Andreas Strotmann
From: keld@login.dkuug.dk (Keld J|rn Simonsen)
Newsgroups: comp.std.internat
Subject: Re: International character sets
Date: 4 Sep 92 14:28:52 GMT

andrew@cursci.co.uk (Andrew Trotman) writes:


>Anyone out there got a description of any character sets and collating
>sequences that include all the roman characters and accented roman
>characters?

I am not sure if anybody really knows how many roman letters and
accented letters there exist, but a fair part have been tabled and
sorted in some POSIX compliant locales available at dkuug.dk in
the directory i18n. The locales also include specification of
greek and Cyrillic and Kana sorting.

As noted in another article the sorting sequences are different for
at least some languages. The locales available at Dkuug.dk covers 

                        da_DK                 Danish
                        en_DK                 English

The English one is actually intended to be quite general, also
covering languages as German, French, Italian, Portuguese, Dutch,
Vietnamese, Greek, Russian and Japanese

>Someone was telling me about ISO stuff and how there were a whole load of
>8-bit sets that define most of the european characters.  That would be kind
>of useful, but what I really want is a full description of either a 16-bit or
>32-bit character sequences that will include all the roman chars and their
>accented chars in a sequence that I can sort on.

There are also provided POSIX charmaps for ISO 10646 - only a part tho,
something like 2000 characters. And about 100 other character sets
like the ISO 8859 series, PC codepages, EBCDICs are also described
via POSIX charmaps.

Keld Simonsen
From: dominic@natcorp.ox.ac.uk (Dominic Dunlop)
Newsgroups: comp.std.internat
Subject: ISO 639 language list wanted
Summary: Begging letter
Date: 4 Sep 92 11:33:00 GMT
Organization: British National Corpus, Oxford University, GB
Originator: dominic@onions.natcorp.ox.ac.uk

Does any kind soul out there feel like sending me or pointing me at an
on-line version of the codes from ISO 639:1988, Code for the
representation of names of languages?  I need the information, but
laziness prompts me to write a begging letter before keying or
scanning the stuff in.

Also, while I'm here, is anyone aware of a list more comprehensive
than ISO 639 (covering many archaic or dead languages, for example)?
-- 
Dominic Dunlop
Newsgroups: comp.std.internat
From: andrew@cursci.co.uk (Andrew Trotman)
Newsgroups: comp.std.internat
Subject: International character sets
Date: 3 Sep 92 17:42:38 GMT
Organization: Current Science


Anyone out there got a description of any character sets and collating
sequences that include all the roman characters and accented roman
characters?

Someone was telling me about ISO stuff and how there were a whole load of
8-bit sets that define most of the european characters.  That would be kind
of useful, but what I really want is a full description of either a 16-bit or
32-bit character sequences that will include all the roman chars and their
accented chars in a sequence that I can sort on.

I guess someone has a PostScript file or something?

Thanks

Andrew
andrew@cursci.co.uk
Newsgroups: comp.std.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: What does "::" really mean?
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Fri, 4 Sep 92 14:06:15 GMT


I'd like to add something to my last post on this subject.

Consider an example:

class AA
{ public:
    class NAA {};
};

class AA1: public AA
{ public:
    class AA
    {  public:
         class NAA{};
    };
};

class AA2: public AA
{ public:
    class AA
    {  public:
         class NAA{};
    };
};

class BB: public AA1, public AA2
{
   AA1::AA::NAA  x;     // what is the type of x???
};

What is the type of member "x" in class BB?

We should use:

   AA1.AA.NAA

to denote the class NAA nested in class AA nested in class AA1, and use

   AA1::AA.NAA

to denote the class NAA nested in the base class AA of AA1.

To conclude, we use"::" to denote a specific base when the member is ambiguous  
due to multiple inheritace, and we use "." to denote the member or property of  
a qualifying entity ( an object or a class ).

David Shang

Newsgroups: comp.std.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Destruction of Temporaries, Yet Another Posting
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Wed, 2 Sep 92 17:18:59 GMT

In article <1992Sep2.143007.5655@bnrmtl.bnr.ca>, john@bnrmtl.bnr.ca (John Hickin) writes:
|> 
|> A compiler using the const temporary approach and a thoughtful programmer
|> can combine to make code like that of the String example safer:
|> 
|>    class String { public:
|>        operator const char*(); // NON-const
|>        String( const char* );
|>        ...
|>    };
|> 

Making the function that gives the pointer to char a non-const is a mistake.
The function may modify the underlying representation, but it certainly
does not modify the represented character sequence.  There is no
reason that I shouldn't be able to apply it to a const String

|>    String h( "hello " ), w( "world" );
|>    const char* p = h + w;

A careful programmer might have written

	const String h("hello "), w(" world") ;

and be surprised that  (const char*)h isn't allowed.

String with a conversion operator seems to have caught on in this
newsgroup as "the" example for discussing lifetime of temporaries.
It should be noted that because of all the problems associated with
such an operator the x3j16 library working group has decided that
this functionality will be provided by an ordinary member function
and not by a conversion operator.

I believe the use of the implicitly invoked conversion operator
obscures the issue of lifetime of temporaries and that we should 
be writing the above example out in full as.

	const char* p = (h+w).pchar();

  -- Jerry Schwarz
From: juul@diku.dk (Anders Juul Munch)
Newsgroups: comp.std.c++
Subject: Re: this == 0 for nonvirtual functions
Keywords: this virtual function undefined
Date: 25 Aug 92 17:28:50 GMT
Organization: Department of Computer Science, U of Copenhagen

pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:

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

You are deleting the first list member using its own DeleteAll method and
the other members using the first member's DeleteAll method.
To see what the problems can arise from this, make DeleteAll virtual and
redefine it in a subclass:
	class MyLink : Link {
	  void DeleteAll() { ExtraBookkeeping(); Link::DeleteAll(); }
	};

Now MyLink's will be DeleteAll'ed with the wrong method if a plain Link
heads the list. And to make things worse, such a bug would be almost
impossible to find.

However, 
	static Link::DeleteAll(Link* head);
does not have this problem and also note that  `head' can legally be NULL,
solving your original problem.

Anders Munch		|  Department of Computer Science
juul@diku.dk		|  University of Copenhagen, Denmark
"Confused? The thing is to get confused at a higher level" - Jorgen Thorslund
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: this == 0 for nonvirtual functions
Date: 25 Aug 92 19:22:45 GMT
Organization: Microsoft Corporation
Distribution: usa
Keywords: this virtual function undefined

In article <1992Aug21.044448.8282@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
|	If programmers elected not to check the this pointer, then the
|	program, if a member is accessed via a null-this, would most
|	likely crash or at least be undefined; this is _exactly_ the
|	way language is defined now; hence, for programmers who ignore
|	it, the (errant) behavior of their programs is unchanged.
|
|	*****************************************************************
|	Hence, adding my proposal changes nothing for those who ignore
|	it.
|	*****************************************************************
|
|	Again, all I want is the *call* to succeed; after that, I'm on
|	my own.

The call already doesn't necessarily succeed in the virtual case.
The call already doesn't necessarily succeed in the null-this-from-a-ref case.
You are asking for support for a special case where a non-virtual member
function is invoked via a null pointer.  Asking for this singular special
case seems awfully non-orthogonal to me.  If you were to insist on this,
then it should work for null-refs and for virtual functions....

|	Perhaps [with regard to users checking null tests]; but I think
|	that one of the _themes_ of programming in C++ is to eliminate
|	tedium and errors introduced thereby: virtual functions
|	eliminate switch statements missing a case; exception-handling
|	will eliminate having to check the return value from new to see
|	if it failed, etc.
|
|	I see my (modest) proposal in the same light.

In the early days of Objective-C method invocation on a null pointer was
defined to be a no-op.  The result was intended to save programmers from
having to handle special cases.  In practice the result was that it took
about a week to track down each case where some method was invoked on
a null pointer -- because the result of such a mistake was a null pointer
-- resulting in another no-op method call, resulting in a null pointer --
resulting in another no-op call.  Fortunately, we had access to source and
quickly patched the method dispatch routine so that invoking a method via
a null pointer resulted instead in an assert.  Then bugs were caught quickly.

Therefore I suggest rather than allowing method invocation on null pointers
what one really needs is a good way to always assert on such "mistakes."
Allowing overloadable operator dot is one step in this direction.  Further,
defining null ptr invocations as being illegal *allows* quality compiler
implementations the option of inserting runtime checks on such illegalities
during debug mode.  Better yet would be if C++ supported better ways to specify
class invarients checking on method dispatch and return.

Newsgroups: comp.std.c++
From: oherb@jhunix.hcf.jhu.edu (Zoher B Bambot)
Subject: Re: Expanding enumerators in inheriting classes
Keywords: inheritance, enumerator
Organization: HAC - Johns Hopkins University, Baltimore
Date: Tue, 25 Aug 1992 20:33:09 GMT


I am working on developing classes for simulation of finite element meshes
using the object-oriented language c++. I would be grateful if anyone could
send me any programs in c++ which would help me in my work. Also has anyone 
developed a class for the simulation of a FEM for any particular structure.
You can mail them to me at my e-mail address and then I will summarize in
the net. Also are there any ftp sites from where I could get any useful
information. Thanx in advance.
                         Zoher.
Newsgroups: comp.std.c++
From: john@bnrmtl.bnr.ca (John Hickin)
Subject: Destruction of Temporaries, Yet Another Posting
Reply-To: bnrmtl!john@larry.mcrcim.mcgill.edu
Organization: Bell Northern Research Montreal, Canada.
Date: Wed, 2 Sep 92 14:30:07 GMT

It seems to me that much of the trouble comes from exporting the details of an
object's internal representation from a function that the compiler can apply
automatically to a temporary ojbect.  Simple prevention can avoid most of the
problems:

   1. Avoid exporting the details of an object's internal representation,
      especially when the offending function can be applied automatically by
      the compiler such as the famous String :: operator const char*().
      It is interesting to note that the ANSI String proposal renames this
      function to const char* String :: cStr().

   2. Try to write your code to avoid the generation of temporaries.  

Of course one can always generate cases where recommendation 2 will fail you
and I personally don't like the idea a lot as it can really cramp your style.
So here is a modest proposal:

   Make temporaries const objects
   Avoid problems due to their early destruction by making dangerous
   value taking operations non-const.

A compiler using the const temporary approach and a thoughtful programmer
can combine to make code like that of the String example safer:

   class String { public:
       operator const char*(); // NON-const
       String( const char* );
       ...
   };

   String h( "hello " ), w( "world" );
   const char* p = h + w;
   //
   //  compiler flags this statement:
   //     Error: non-const member function applied to (const) temporary object.

Of course this could break a lot of existing code.

-- 
John Hickin      Bell-Northern Research, Montreal, Quebec
(514) 765-8888   bnrmtl!john@larry.mcrcim.mcgill.edu
Newsgroups: comp.std.c++
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: Re: Which delete operator should be called?
Organization: Mentor Graphics Corp. - IC Group
Date: Thu, 3 Sep 1992 17:11:47 GMT

In article <BRENNAN.92Sep3010854@yosemite.hal.com> brennan@hal.com (Dave Brennan) writes:

>Somewhat related to this, I need to be able to call the virtual destructor
>of an object without deleting it.  I can't get any compilers to accept any
>destructor calling syntax other than "class::~class()" (where "class" is a
>class name).  In cfront this syntax DOES call the virtual destructor (ie:
>if I call "base::~base()" from a base method, the derived destructor is
>called).  Lucid CC it only called the base class destructor, which seems
>like the correct behavior.  g++ 2.2.2 wouldn't accept any kind of explicit
>calls to a destructor.  Can anyone tell me how to call a virtual destructor
>in a way that least cfront 2.1 will accept and is correct C++?
>

#include <iostream.h>
 
class A {
public:
        A() {}
        virtual ~A() {cout << "A's dtor" << endl;}

        virtual void callDtorInPlace() {this->A::~A();}
           // legal code. Will work in both 2.1 and 3.0

//      virtual void callDtorInPlace() {this->~A();}
           // legal code, but doesn't work in 2.1.
           // Works ok in 3.0

//      virtual void callDtorInPlace() {A::~A();}
                // This is illegal, but works under 2.1.
                // 3.0 compiles this, but doesn't produce any output.
};

class B : public A {
public:
        B() {}
        ~B() {cout << "B's dtor" << endl;}

        void callDtorInPlace() {this->B::~B();}
           // legal code. works with both 2.1 and 3.0

//        void callDtorInPlace() {this->~B();}
           // legal code which does not work with 2.1. Works ok with 3.0

//      virtual void callDtorInPlace() {B::~B();}
           // illegal code which works with 2.1
};

main()
{
        A *a = new B();
        a->callDtorInPlace();
}
-- 
I speak for none but myself.

Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
From: hendrik@vedge.UUCP (Hendrik Boom)
Newsgroups: comp.std.c++
Subject: conversions and overloading
Date: 24 Aug 92 18:10:13 GMT
Organization: Visual Edge Software, St. Laurent, Quebec

Does anyone have a non-proprietary algorithm -- efficient or not --
for resolving type conversions and overloaded functions in the various
contexts in which they occur (including templated and the type conversions
involved in exception-handling)?  The ARM does not seem to be a model of 
precision in all the dark corners.


-- 
-------------------------------------------------------
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: pete@genghis.borland.com (Pete Becker)
Subject: Re: Which delete operator should be called?
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Thu, 3 Sep 1992 18:22:46 GMT

In article <BRENNAN.92Sep3095303@yosemite.hal.com> brennan@hal.com (Dave Brennan) writes:
>I didn't have my copy of ARM handy when I posted, and I see that it also
>says is 12.4 (p. 278) "When invoked by the delete operator, memory is freed
>by the destructor for the most derived class of the object using an
>operator delete ()."
>
>What it doesn't say is which operator delete.  This tends to imply that the
>operator delete of the most derived class should be used, but as my
>previous post showed it is only used when the class being deleted has a
>virtual destructor.  This quote implies that the operator delete of the
>most derived class will be called when any object is deleted?
>
>Cany anyone clarify this?
>

	Don't make this problem harder than it really is.  Destructors and
operator delete aren't magic.  Just rephrase the question in terms of normal
functions:

	class Base
	{
	public:
	    static void operation();
	    void f() { operation(); }
	    virtual void g() { operation(); }
	};

	class Derived : public Base
	{
	public:
	    static void operation();
	    void f() { operation(); }
	    virtual void g() { operation(); }
	};

	Base *bp = new Derived;
	bp->f();	// invokes Base::f(), which calls Base::operation()
	bp->g();	// invokes Derived::g(), which calls 
			// Derived::operation()

Newsgroups: comp.std.c++
From: bglenden@colobus.cv.nrao.edu (Brian Glendenning)
Subject: Run-time type information proposals
Organization: National Radio Astronomy Observatory
Date: Thu, 27 Aug 1992 16:32:53 GMT


I am very interested in hearing about rtti proposals that are being
considered by the standardization committee.

I would appreciate it if the text of any such proposals could be
forwarded to me. I will post a brief summary of the various proposals
to the net (unless someone more knowledgeable does it instead). Thank
you.

Brian
--
       Brian Glendenning - National Radio Astronomy Observatory
bglenden@nrao.edu          Charlottesville Va.           (804) 296-0286