HDTenEightyP/NetNews huggingface dataset:
From: martinea@ireq.hydro.qc.ca (Alain Martineau)
Newsgroups: comp.std.unix
Subject: Re: Questions on porting TLI to XTI standard
Date: 28 Sep 1992 12:26:21 -0700
Organization: Hydro Quebec
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: martinea@ireq.hydro.qc.ca (Alain Martineau)

In article <19nqm9INNhtl@ftp.UU.NET>, GC921111%PACEVM.bitnet@CUNYVM.CUNY.EDU (MANI) writes:
> I dont think XTI is Unix independent. ANYONE care to raise doubts?

I have been told that a version for VMS has been done at Digital, for internal
evaluation only, for now. Since VMS is XPG3 compliant and XTI will be in XPG4
it is about sure to end up being included in VMS some day.

Alain Martineau
Hydro Quebec
martineau@macmartineau.ccr.hydro.qc.ca


Volume-Number: Volume 29, Number 47
From: ejsvehla@happy.colorado.edu
Newsgroups: comp.std.unix
Subject: Participating in POSIX working groups
Date: 5 Oct 1992 12:35:31 -0700
Organization: University of Colorado, Boulder
X-Submissions: std-unix@uunet.uu.net

Submitted-by: ejsvehla@happy.colorado.edu

I am looking for information pertaining to participating in POSIX working
groups.  Does anybody out there know how to do this?
Any info would be greatly appreciated.

thanks in advance


Volume-Number: Volume 29, Number 48
From: eggert@twinsun.com (Paul Eggert)
Newsgroups: comp.std.unix
Subject: Re: experience w/ POSIX on vms and ultrix.
Date: 5 Oct 1992 12:37:06 -0700
Organization: Twin Sun, Inc
X-Submissions: std-unix@uunet.uu.net

Submitted-by: eggert@twinsun.com (Paul Eggert)

njr@texhrc.uucp (Nick J. Rees) writes:

>I am also very interested to hear from anyone who has had
>positive experience with VMS POSIX. I have been using it here
>and can find nothing good to say about it.
>Problems range from the mundane (incredibly slow, hopeless
>on-line documentation) to the rather more serious like not
>being able to use 'ar' unless you have system privilege. I
>would probably have more complaints than this, except I have
>not been able to do very much with it.

RCS, a widely used free version control system, was made Posix-compliant
about a year ago.  In the past, VMS users ported old RCS releases to
native VMS.  You'd think that VMS Posix would save these users a lot of
work, since it should be much easier to port new RCS releases to VMS Posix
than to native VMS.  But so far as I know, nobody has yet ported RCS to
VMS Posix.  I'm not a VMS expert, so I don't know the details, but the
general sentiment seems to be that if you really want to use RCS under
VMS, you have to port it to native VMS; VMS Posix doesn't do the job.

There's a big difference between conforming to a standard and supporting a
standard.  In the past, skeptics have suggested that the widely advertised
Posix interfaces for non-Unix operating systems from DEC and HP (and
promised interfaces from IBM and Microsoft) are merely smokescreens to
fool government bean counters who require Posix.  Early experience with
VMS Posix suggests that the skeptics may be right.  If so, this is bad
news for the open systems community.  It'll be worse news if Microsoft's
promised Posix interface for NT also turns out to be useless in practice.


Volume-Number: Volume 29, Number 49
From: sp@osf.org (Simon Patience)
Newsgroups: comp.std.unix
Subject: Re: Participating in POSIX working groups
Date: 6 Oct 1992 00:51:18 -0700
Organization: Open Software Foundation
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: sp@osf.org (Simon Patience)

In article <1aq5e3INN5rh@ftp.UU.NET>, ejsvehla@happy.colorado.edu writes:
> I am looking for information pertaining to participating in POSIX working
> groups.  Does anybody out there know how to do this?

Yes, go to the next POSIX meeting. It is in Utrecht, Netherlands starting
on the 26th of this month. I don't have the details, sorry.

Simon.

PS. Joining the IEEE also helps.

-- 
  Simon Patience
  Open Software Foundation			Phone: +33-76-63-48-72
  Research Institute				FAX:   +33-76-51-05-32
  2 Avenue De Vignate				Email: sp@gr.osf.org
  38610 Gieres, France				       uunet!gr.osf.org!sp


Volume-Number: Volume 29, Number 50
From: kverruyt@nl.oracle.com (Kees Verruyt)
Newsgroups: comp.std.misc
Subject: Re: X/Open article needed
Date: 2 Oct 92 07:52:45 GMT
Organization: Oracle Europe

Any X/Open documentation can be obtained from their office in the UK.

This is from their current list of publications:

	For all orders and ordering information, please contact:

        X/Open Company Limited (Publications)
        Oakwood House
        St. John's Estate
        Penn, High Wycombe
        Bucks, HP10 8HQ

        Tel: 0494 813844
        Fax: 0494 814989

The document you're looking for is now available as:

Distributed TP: The XA Specification                         $  53.00 UKL  30.00
          ISBN 1-872630-24-3        90 p. 220 g. ............Shipping Code A
[X/Open CAE Specification XO/CAE/91/300 or C193   2/92]
..... Was XO/SNAP/91/050 Distributed TP: The XA Specification 6/91

where shipping code A means:

        Code A $18.00 UKL10.00 per book

-- 
------------------------------------------------------------------------
Kees Verruijt                           Rijnzathe 6
Software Engineer Gateway development   3454 PV  DE MEERN
Oracle Europe                           The Netherlands
Email: kverruyt@nl.oracle.com           Tel: +31 3406 94886
   or: kverruyt@oracle.nl               Fax: +31 3406 65603
Newsgroups: comp.std.misc
From: vic@teal.csn.org (Victor E. Schoenberg)
Subject: X/Open article needed
Organization: Colorado SuperNet, Inc.
Date: Thu, 1 Oct 1992 16:25:43 GMT

I'm looking for the "X/Open Preliminary Specification (April 1990)
Distributed Transaction Processing: the XA Interface". Can someone
suggest how to obtain this? 

Thanks.
-- 
Vic Schoenberg
vic@csn.org
Newsgroups: comp.std.internat
From: acooper@nuustak.csir.co.za (Antony Cooper)
Subject: ANSI and NIST
Organization: Infotek, CSIR
Date: Mon, 05 Oct 92 17:19:11 GMT
Summary: Why both ANSI and NIST?
Keywords: ANSI, NIST

Hi

Why is there a need for both ANSI (American National Standards Institute)
and NIST (National Institute for Standards and Technology) in the USA?

I understand that ANSI is a private institution that does not actually
develop standards, but that it verifies that standards have been developed
properly, and that NIST is responsible for Federal standards in the USA,
such as FIPS (Federal Information Processing Standards).

Is there not an overlap between the two? Are ANSI standards automatically
accepted by NIST, and vice versa?

This is probably a FAQ, but I have not seen reference to it here.

As reception of news groups is not that reliable out here, I would appreciate
it if you could email replies. If there is any interest, I will summarise
and post.

Thanking you in anticipation
Antony

--
Antony Cooper                                        | Voice: +27 12 841 4121
acooper@nuustak.csir.co.za                           | Fax:   +27 12 841 4109
INFOTEK, CSIR, Box 395, Pretoria, 0001, South Africa | ICBM:   25 45S  28 16E
From: taylor@SunWorld.Com (Dave Taylor)
Newsgroups: comp.std.internat
Subject: Re: Names of Stds. Institutes in Iceland and Luxemburg?
Date: 29 Sep 92 16:05:21 GMT
Article-I.D.: netcom.lq+pvvh.taylor
Organization: SunWorld Magazine, San Francisco, CA: +1 (415) 267-1728

Antoni Drudis writes:

> Does anyone knows the acronyms (and names) of the standardization
> bodies in Iceland and Luxemburg?

I checked the appendix in "Global Software" and:

  Iceland
	Technological Institute of Iceland
	Standards Division
	Keldnaholt
	IS-112 Reykjavik

Couldn't find a specific organization for Luxembourg, but I
did have:

  European Community Official Publications Office
	Office des publications offielles des Communaute's europe'nnes
	2, rue Mercier
	L-2985 Luxembourg

Hope that helps.
						-- Dave Taylor
SunWorld Magazine
San Francisco, California

taylor@sunworld.com        			taylor@netcom.com
From: antoni@hpcupt1.cup.hp.com (Antoni Drudis)
Date: Fri, 25 Sep 1992 17:38:08 GMT
Subject: Names of Stds. Institutes in Iceland and Luxemburg?
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.std.internat

Does anyone knows the acronyms (and names) of the standardization
bodies in Iceland and Luxemburg?


thanks in advance!

Antoni Drudis

antoni@cup.hp.com


(this is just for curiosity. I was looking at an unofficial chart of 
CEN/CENELEC and all the countries had 'names' -i.e. AFNOR, DIN, etc.-
except Iceland and Luxemburg)
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Newsgroups: comp.std.internat
Subject: Re: ANSI and NIST
Keywords: ANSI, NIST
Date: 6 Oct 92 11:33:17 GMT
Organization: U of Cambridge, England


And can someone explain what National Information Standards Organisation
is? (as in NISO Z39.50, the information retrieval standard)
Newsgroups: comp.std.internat
From: mfc@medoc.aux.apple.com (Matt Caprile)
Subject: Re: ANSI and NIST
Date: Wed, 7 Oct 1992 01:58:34 GMT
Organization: A/UX Group, Apple Computer Inc, Cupertino, CA
Keywords: ANSI, NIST

In article <1992Oct05.171911.9981@nuustak.csir.co.za> acooper@nuustak.csir.co.za (Antony Cooper) writes:
>Why is there a need for both ANSI (American National Standards Institute)
>and NIST (National Institute for Standards and Technology) in the USA?
>
>I understand that ANSI is a private institution that does not actually
>develop standards, but that it verifies that standards have been developed
>properly, and that NIST is responsible for Federal standards in the USA,
>such as FIPS (Federal Information Processing Standards).
>
>Is there not an overlap between the two? Are ANSI standards automatically
>accepted by NIST, and vice versa?

(I decided to post this after emailing it to Mr. Cooper, and it bounced.)

ANSI does develop standards. It is the U.S. national representative to
I.S.O. (International Standards Organization). As such it participates
in developing I.S.O. standards. It also develops standards for the
U.S.  (e.g., the standard is meant to be just for the U.S., and is not
intended to be an international standard). In some cases ANSI uses
"accredited bodies" (I think that is the correct term) to develop
standards as a "sub-contractor". As an example, the I.E.E.E. did the
work for POSIX.1 for ANSI. As an example of ANSI doing standards
itself, ANSI did the ANSI C language standard. ANSI is supposed to be
THE (capitals for emphasis) standards setting body for the US. It does
much more than computer-related standards (just as ISO does). There are
standards for paper sized, electrical connections, keyboards, bolt (as
in machine screw) sizes, cable densities, etc.

NIST (among other things) "advises" the US government (or parts of it,
I've never been quite sure) for procurement specifications. As an
example, there is a NIST document that describes specifications for
"POSIX-type" operating systems environments that should be met when
bidding on government contracts that require said specifications. This
is not exactly the same thing as specifying conformance to a particular
standard. In the POSIX example :
 (1) POSIX.1 has many, many options. The NIST spec says which options
     have to be present
 (2) NIST sometimes will not wait for a standard. [NIST made specs
     using draft versions of POSIX.1 and POSIX.2.]

To resume, (and to grossly simplify) ANSI is the standards organization
for the US. NIST writes specifications to be used/met for government
contract bidding.

--

  --- Matthew Caprile    || Hey, I only speak for myself ! Even I  ---
  ---                    || won't admit to the opinions expressed  ---
  --- caprile@apple.com  || here, so don't expect my employer to.  ---
Newsgroups: comp.std.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Help Preprocessor
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Mon, 5 Oct 92 16:13:16 GMT

My apologies for the empty article that I just inadvertantly
distributed with this title.

In article <1992Oct4.085733.7703@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> I've got a few minor problems with the specifications for the
|> preprocessor.
|> 
|> The issue of incomplete /* comments in preprocessor commands is one.
|> 
|> #define fred a + /* incomplete
|> comment spans lines here */ b
|> 
|> Is the above legal?
|> 

I belive it is very likely that the final C++ standard will
adapt the  the ANSI/ISO C standard's preprocessing mechanism.
(The main difference is the existence of // comments).  Under
that assumption the above will certainly be legal.  Treatment
of "#include <...>" will also be essentially identical to
that in the C standard.  

But at the moment many C++ implementations are built on
non standard preprocessors and their handling of these
issues may not be identical to that of a standard conforming
C compiler.   For maximum portability, don't put comments
into #defines

    -- Jerry Schwarz

Newsgroups: comp.std.c++
From: vinoski@apollo.hp.com (Stephen Vinoski)
Subject: Re: Exception Specifications
Date: Thu, 1 Oct 1992 14:36:14 GMT
Organization: Hewlett-Packard Corporation, Chelmsford, MA

In article <1992Sep30.205656.10646@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>At the moment X3J16 is considering the implications of exceptions
>for stream classes.  Some think that streams should only
>be able to throw a particular kind of exception (tentatively
>named ios::failure). Others (including myself) feel that a stream
>should be able to throw an arbitrary exception. Remember, users
>can define their own kinds of streambufs, so X3J16 can't know in advance
>what kinds of conditions they might want to report.  
>
>My intuition (not based on experience I confess) is that in
>general it is more important to get specific information about
>the conditions that caused an exception than it it to know that
>it in occured in some stream operation. That is, it is better to
>know that there was an "out of memory" or "database corruption" problem
>than it is to know that there was a problem while doing a stream
>operation.  This leads me to the conclusion that the iostream library
>should not use failure clauses.

It seems like a compromise -- making ios::failure into a base class
from which other more specific exception types can be derived -- would
be the best approach.  Application code that can do something useful
with specific exceptions can then arrange to catch each one
individually, while code that cares only that an exception was thrown
but does not wish to catch each different type can arrange to catch
only the base class.

-steve
-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
Newsgroups: comp.std.c++
From: LANG@nvdv01.ind.e-technik.uni-stuttgart.de (MARTIN LANG)
Subject: static members and access control?
Organization: University of Stuttgart, IND (FRG)
Date: Mon, 5 Oct 1992 12:52:29 GMT
X-News-Reader: VMS NEWS 1.23


Follwing a short class declaration with a private static field of an
enumaration type. The enumaration is also declared private. The question
now is: is the initialization illegal or not.

I have tried it with two different compilers. Cfront compiles without
error, Zortech complains because the enumaration is private. The ARM is
not quite clear at this point. In chapter 11 page 239 it states:

   private: that is, its name can be used only by member functions and
	         friends of the class in which it is declared.

In my opinion a static member is neither a member function nor a friends.
Does this mean that Cfront is wrong?

class Test
{
	private:
		enum E1 { a,b};
		static E1 e;
};


E1 Test::e=Test::a;



Thanks,

Martin Lang
University of Stuttgart
Newsgroups: comp.std.c++
From: sdm@cs.brown.edu (Scott Meyers)
Subject: Exception Specifications
Organization: Brown University Department of Computer Science
Date: Tue, 29 Sep 1992 20:16:03 GMT

The more I think about it, the more I'm convinced that the uses for
exception specifications are astonishingly restricted.  As I see it, you
can't reliably put an exception specification on a function f if any of the
following are true:

    1.  A call to f might directly or indirectly lead to a call to g where
        g lacks an exception specification.  A special case of this is
        where g is a function written in another language, e.g., anything
        in the standard C library.  Recall that functions without exception
        specifications may throw anything.

    2.  f is a template function.  In this case, f must be instantiated
        using some unknown type T, and it is highly likey that f will
        invoke some T-specific function (e.g. member function of class T).
        However, there is no way to know what the exception specifications
        are on the T-specific functions.

    3.  f is a virtual function, because f may be redefined in a subclass
        by some function f' that contains an incompatible exception
        specification.  Recall that an exception specification is not part
        of a function's type.

The ARM refers to an exception specification as a "promise" (ARM 15.6.2c),
but the above points make clear that this promise can't be given very
often, or at least can't be relied upon very often.  Similarly, the
discussion of why exception specifications are so lax is discussed in ARM
15.5c.  The ARM also implies that special-purpose static analyzers would be
required to do much of anything with exception specifications, especially
in the presence of separate compilation.  (For example, if f contains an
exception specification and calls virtual function g which also contains an
exception specification, no warning can be issued if g is redefined by an
incompatible g' in a derived class that is contained in a separate
compilation unit.)

All of which leads me to believe that exception specifications are not
really designed for the "general use" suggested in the last paragraph of
commentary in ARM 15.5c.  That being the case, I'm tempted to suggest they
be removed from the language.  For the specialized applications that can
make use of them, an Anna-like annotation language seems more appropriate
than actual language support within C++.

Comments?

Scott


-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."
Newsgroups: comp.std.c++
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Exception Specifications
Organization: University of Jyvaskyla, Finland
Date: Mon, 5 Oct 1992 12:58:19 GMT

In article <1992Oct5.073509.1188@jyu.fi> sakkinen@jyu.fi (myself) writes:
>In article <23785@alice.att.com> ark@alice.UUCP () writes:
>>In article <1992Oct2.125244.14614@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>>These problems do not occur if you throw objects (rather than pointers)
>>and catch references.  In that case, the implementation takes care of
>>deleting things at the proper time.
>
>That is impossible!  If the exception argument has been allocated by 'new',
>the implementation cannot guess whether it should be deleted or not.
>It may well be an object used by an outer block or function,
>and which has not as its _only_ purpose to convey exception information.

Well, now I see that you must have had a tacit assumption:
that to 'throw objects' means to throw variables (objects)
that are _not_ allocated dynamically (from the heap).
Then you are correct, of course.  Proper deallocation is in
general a very tough problem for C++ programmers only with dynamic objects.

----------------------------------------------------------------------
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++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Exception Specifications
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 2 Oct 1992 19:22:09 GMT

[Sorry if this reaches anyone twice.
 The previous version had an unfortunate typo.]

sakkinen@jyu.fi (Markku Sakkinen) writes:

>jbn@lulea.trab.se (Johan Bengtsson) writes:
>>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>: sakkinen@jyu.fi (Markku Sakkinen) writes:
>>: 
>>: >I am afraid that distinguishing exceptions only by the type of the
>>: >'throw' expression is mostly overkill instead of improvement.
>>: > ...
>>: Is this so difficult?
>>: ...
>>: 	class MyException : Exception {};
>
>Here is only 1 exception, not 20.

I guess it is true that programmers just don't like verbosity.
OK, here is the succinctness-at-all-costs solution:

	#define e(x) class x : Exception {} ;
	e(e1)  e(e2)  e(e3)  e(e4)  e(e5)  e(e6)  e(e7)  e(e8)  e(e9)  e(e10)
	e(e11) e(e12) e(e13) e(e14) e(e15) e(e16) e(e17) e(e18) e(e19) e(e20)

Is that short enough, or should I remove all the unnecessary whitespace? ;-)

>In Ada, you would write:
>  excp1, excp2, excp2, ..., excp20: exception;
>In C++, you would write:
>  struct excp1 {};
>  struct excp2 {};
>   ...
>  struct excp20 {};
>and document somewhere that these classes are meant to function
>as "exception identifiers".

Actually, in C++ I would write
   struct excp1 : Exception {};
		^^^^^^^^^^^

>Inheritance between exceptions may be treacherous, since 'throw'
>does not work "virtually".  E.g., with Fergus's example:
>
>MyIntException mye (77);
>Exception *ep = mye;
This should be = &mye;
>throw *ep;
>
>Only Exception is thrown!

I think that this is unlikely to be a problem, since almost invariably
you know exactly what type of exception you wish to throw at the time
you are throwing it:

	if (some error condition) {
	    throw SomeException(...);
	}

It's a bit like constructors not being virtual: this is not a problem, since
when you are constructing an object, you know what type should be.

You can make throw behave virtually by throwing a pointer to the exception
instead of the exception itself:
	throw new SomeException(...)
although you need to take care to ensure that the storage is correctly
deallocated by the handler, to avoid memory leaks.

Note that "catch" *does* behave virtually.

	class Foo : Exception {
	    virtual void foo() { cout << "Foo::foo()" << endl; }
	};
	class Bar : Foo {
	    virtual void foo() { cout << "Bar::foo()" << endl; }

	main() {
	    try { throw Bar; }			// [ Fixed bug here :-) ]
	    catch (Foo& f) { f.foo(); }
	}

This will print Bar::foo(), not Foo::foo().

-- 
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!

Newsgroups: comp.std.c++,comp.lang.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: The concept of templates considered ill designed
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Tue, 6 Oct 92 00:55:50 GMT

In article <23796@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:
> In article <BvM0DE.EA7@watcgl.uwaterloo.ca> pfbertra@watcgl.uwaterloo.ca  
(Philippe F. Bertrand) writes:
> 
> > Also for code hiding, compilers should generate intermediate files for
> > templated code so that user's of a template class do not need to have 
> > access to the source.
> 
> This is primarily an implementation issue, not alnaugae issue.
> If enough people want compilers that behave that way, someone will
> create one.
> -- 
> 				--Andrew Koenig
> 				  ark@europa.att.com

It is not only an implementation issue, but aslo a language design issue.
The key thing is that WHY template users NEED to have the access to the 
template source. Such need comes from the template itself, not from any 
particular implementation. If the concept of template is not improved in 
language design, it is impossible to write a compiler that can hide the
template source code from the user.

David Shang

Newsgroups: comp.std.c++,comp.lang.c++