HDTenEightyP/NetNews huggingface dataset:
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Exception Specifications
Organization: University of Jyvaskyla, Finland
Date: Fri, 2 Oct 1992 12:52:44 GMT

In article <9227620.2176@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>sakkinen@jyu.fi (Markku Sakkinen) writes:
>> ...
>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? ;-)

Not being a C or C++ fan, I don't like succinctness at all costs.
In this case, I like succinctness without cost a la Ada.

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

What would that buy you?  See below.

>>Inheritance between exceptions may be treacherous, since 'throw'
>>does not work "virtually".  E.g., with Fergus's example:
>> ...
> ...
>You can make throw behave virtually by throwing a pointer to the exception
>instead of the exception itself:

(Or a reference.)  Yes, I must admit that this problem is not very severe.

>	throw new SomeException(...)
>although you need to take care to ensure that the storage is correctly
>deallocated by the handler, to avoid memory leaks.

The example is not the best possible one, since here the exact type
of the referenced object is in fact statically known.
The handler has no way to know when it has to delete the exception object,
short of there being a quasi-Boolean field 'delete_me' in Exception.
Thus:

struct Exception { int delete_me; };
throw new Exception (1);
Exception ex (0);
throw ex;

And now to a perhaps better reason why using inheritance with exceptions
(as suggested by you above) may be treacherous.
Whenever there exists a handler for _any_ ancestor (base class) of the
class of the exception object, that handler will be happily executed.
Thus, if an instance of a class derived from Exception is thrown,
there is no guarantee that any more specific handler than that
of Exception will be invoked.
This is essentially different from virtual functions, with which it is
guaranteed that dynamic binding will find the function appropriate
for the true class of the 'this' object.

----------------------------------------------------------------------
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
----------------------------------------------------------------------
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.std.c++
Subject: Re: Exception Specifications
Date: 30 Sep 92 02:21:49 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

In article <1992Sep29.201603.19289@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>The more I think about it, the more I'm convinced that the uses for
>exception specifications are astonishingly restricted.  ...
...
>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.

I'd suggest studying the exception specifications in Modula-3 (latest
version).  Those are based on years of experience with Cedar and
Modula-2+, as well as a study of the effects of changing the exception
specification rules a large body of software already written in
Modula-2+.  Modula-3 has "object methods" that are more or less
equivalent to C++ "virtual member functions", so the rebinding problem
does not go away.

As I recall, the M-3 rules are:

   no specification is equivalent to "no exceptions raised".

   the set of exceptions raised is part of a function type.

   assignment to function variables and/or binding to object methods
   must be type correct (i.e., in V := F, the set of exceptions raised
   by F must be a subset of the exceptions raised by V -- this is
   checked statically).

   if a function F calls a function G, static checking may provide
   a warning if G can raise an exception not in the list of exceptions
   raised by F.  If this happens at run-time, the exception is
   converted to a "failure exception" that can only be caught by
        TRY ... EXCEPT ... ELSE <catch it here> END
   though finalization clauses will be executed.

I do not know how this corresponds to the exception specifications for
C++; I only know that these are sane and that they work.  The use of
objects types as exception types (as in C++) appears to be compatible
with this, and an improvement (at least in the case of single
inheritance).

David Chase
Sun
Newsgroups: comp.std.c++
From: arthur@solomon.technet.sg (Arthur Sombrito)
Subject: Re: Forward declaration of classes
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 7 Oct 1992 03:15:00 GMT

Manapragada Srinivas (srinivas@lgc.com) wrote:
: Is the following forward declaration valid?
: 
: 		class foo : public bar;
: 
: Where I am trying to declare that foo is a class which is publicly derived from 
: bar. It works like a charm in g++ 2.2.2, whereas SUN CC2.1 results in a syntax
: error. Which behaviour conforms to the standard? The ARM is silent on this
: issue. When I followed the grammar in the appendix the above type of syntax did
: not seem to be valid.
: 
: I would apreciate it very much if someone could shed some light on the above.
: 
: Thanks,
: Srinivas
: -- 
: Yonder, beyond the event horizon!

--

I would say that is an invalid syntax since it is not in the grammar.


Newsgroups: comp.std.c++
From: gfung@dazixca.ingr.com (Glenn H. Fung,7543,)
Subject: TI class library (wanted)
Reply-To: gfung@dazixca.ingr.com
Organization: Dazix an intergraph Company.
Date: Wed, 30 Sep 1992 23:53:04 GMT


I am looking for an C++ class library, its name probably called TI class lib from Texas Instrument. 
I am involved in a graduate project which require that library.
Please email me the information if you can.

Thanks in advance
From: pjl@sparc22.cs.uiuc.edu (Paul Lucas)
Newsgroups: comp.std.c++
Subject: Re: Location of ARM?
Date: 28 Sep 92 21:20:22 GMT
Distribution: usa
Organization: University of Illinois at Urbana-Champaign

In <80633@ut-emx.uucp> bk@ccwf.cc.utexas.edu writes:

>Where might I find the ARM that has been mentioned in several
>of this newsgroup's articles?  I am interested in reviewing this
>document so that I may become aware of the recommended stand-
>ardizations being made to c++.  

>I appreciate any assistance, and please excuse me for my
>ignorance in this matter.

>Thanks,  look forward to hearing from you.

*****>	Any reasonable-stocked book store.  If it's not on the shelf
	have them order it:

		The Annotated C++ Reference Manual
		M. Ellis, B. Stroustrup.
		Addison-Wesley

		~$32.00
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: checker@acf5.NYU.EDU (checker)
Newsgroups: comp.std.c++
Subject: Re: Forward declaration of classes
Date: 2 Oct 92 04:16:26 GMT
Organization: New York University

srinivas@lgc.com (Manapragada Srinivas) writes:
>Is the following forward declaration valid?
>		class foo : public bar;

No.  I think the standards committee is looking into different ways of
`forward declaring' more information.  Nested types also present similar
problems.

Chris

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 01:19:51 GMT

In article <23808@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:
> In article <0enxJ1W00awTMNepU8@andrew.cmu.edu>, osoelgaultier+@CMU.EDU  
(Stefan Monnier) writes:
> 
> > As are currently implemented templates, you don't know
> > anything about the actual type at compile-time.
> > So that no method calls or variable accesses can be compiled
> > for any variable of 'template type'.
> 
> But you still haven't answered my question.
> 
> My question was: what reason do you have to believe that
> adding inheritance constraints would solve the problem?
> 
> In thinking about the answer, don't forget about inline functions.
> -- 
> 				--Andrew Koenig
> 				  ark@europa.att.com

Please note that a constrained parameterized class is a completely 
different language concept from C++ template, though it can replace the  
template concept anyway.

A constrained parameterized class is an abstract class. You need not to
"instantiate" it before using it. Compilers can generate real executable 
codes for member functions defned in a constrained parameteried class. 
Once a parameterized class is compiled separately, the compiler can 
ensure no type-error related to the usage of the class parameters. 
Therefore, there is no need to expose the source code to the user. What 
the user need to prove is that whether his/her actual parameter is 
conformable to the class parameter specification. For library-developers, 
since the code is already generated by the compiler and built into a 
library, it is no longer needed for them to ship the source code with 
their products.

Inline functions are an independent language issue.

David Shang


Xref: sparky comp.std.c++:1300 comp.lang.c++:14513
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: The concept of templates considered ill designed
Date: 5 Oct 92 02:44:53 GMT
Article-I.D.: alice.23801
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <Ienr=wm00awU8A=Ecc@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:

> But the suggested 'templates with type constraint' would
> permit to change it into an implementation issue.

Really?  Why do you think so?
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.std.c++
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Exception Specifications
Organization: University of Jyvaskyla, Finland
Date: Mon, 5 Oct 1992 07:35:09 GMT

In article <23785@alice.att.com> ark@alice.UUCP () writes:
>In article <1992Oct2.125244.14614@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>
>> The handler has no way to know when it has to delete the exception object,
>> short of there being a quasi-Boolean field 'delete_me' in Exception.
>> ...
>
>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.

----------------------------------------------------------------------
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: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Help Preprocessor
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 4 Oct 1992 08:57:33 GMT

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?

The ARM claims

"The source text is decomposed into preprocessing tokens and sequences
of white space. A single white space replaces each comment. A source
file may not end in a partial comment.

[Then, on the next pass]

"Preprocessing directives are executed and macros expanded".

This is a bit tricky. For a start this seems to imply
preprocessor commands can be continued by comments, since
the comments are just replaced by white.

But then it is absurd because if all the newlines were replaced
by white (they are white anyhow) then there would be no way
to delimit the end of the preprocessor command.

Secondly, there might be problems with

#include <filename>

since the < and > are toke. But the filename is implementation dependent.
To fix this, one would have to parse the '#include' tokenising
the rest of the line. (contrary to the ARM requirement).

Any help?


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: pabloh@hpwala.wal.hp.com (Pablo Halpern )
Newsgroups: comp.std.c++
Subject: Re: Suggestion for an alternative pointer/handle/memory consept
Date: 29 Sep 92 17:50:41 GMT
Organization: Hewlett-Packard Company

In article <1992Sep24.191342.15458@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
|> My question is that: is it possible to write class of a special
|> memory reference protocol that can be used exactly the same way 
|> as a standard pointer is used in C++?
|> 
|> With language-supported pointers, we can write:
|> 
|>    BaseClass * bp;
|>    DerivedClass * dp;
|>    ...
|>    bp = dp = new DerivedClass(...);
|>    bp->SomeVirtualFunction(...);
|>    ...
|> 
|> "BaseClass*" can be viewed as a type of pointer<BaseClass>, and
|> "DerivedClass*" as pointer<DerivedClass>, where pointer is a
|> standard memory reference.
|> 
|> Now, we consider the MS Windows's memory protocol. Is it possible
|> to write codes as follows:
|> 
|>   HANDLE<BaseClass> bh;
|>   HANDLE<DerivedClass> dh;
|>   ...
|>   bh = dh = new DerivedClass(...);
|>   bh->SomeVirtualFunctions(...);
|> 
|> Further, is it possible to write codes that independent to any
|> particular memory reference protocols? Like:
|> 
|>   REF<BaseClass> bref;
|>   REF<DerivedClass> dref;
|>   ...
|>   bref = dref = new DerivedClass(...);
|>   bref->SomeVirtualFunctions(...);

I do not have a complete solution, but here are some ideas:

Implement a base template class with a pointer-like interface:

template <class T>
class INDIRECT
{
public:
  INDIRECT();
  INDIRECT(const INDIRECT &);
  virtual ~INDIRECT();
  virtual T& operator *();
  virtual T* operator ->() { return & this->operator*(); }
  virtual INDIRECT& New(params);
  virtual void Delete();

  // Assignment and equality operators, etc. ...
};

Then derive a class for each special kind of indirection.

template <class T>
class SMART_POINTER : public INDIRECT<T>
{
  ...
};

template <class T>
class HANDLE : public INDIRECT<T>
{
  ...
};


Instead of using operator new(), you call the New() member function on the
indirect object:

  i.New(args);     instead of    i = new T(args);

One of the  biggest disadvantage to this approach is that the New()
function must take the same parameters regardless of the type of T.  This
can be as follows:

template <class T>
class INDIRECT
{
  ...
  virtual INDIRECT& New(const T&);
  ...
};

HANDLE<String> hs;
hs.New(String("abc"));

This is, of course, very kludgy and could result in undesirable side
effects if the constructor for String is called twice.  I told you it
wasn't a complete solution.  Just some food for thought.



- Pablo

------------------------------------------------------------------------
Pablo Halpern             (617) 290-3542
HP Waltham                pabloh@hpwarq.wal.hp.com

I am self-employed, so my opinions *do* reflect those of my employer.
However, they may not reflect the opinions of my client.
------------------------------------------------------------------------
Newsgroups: comp.std.c++
From: pena@niksula.hut.fi (Olli-Matti Penttinen)
Subject: Re: Exception Specifications
Organization: Helsinki University of Technology, Finland
	<1992Oct01.143355.27847@bnr.ca>
Date: 3 Oct 92 01:54:09

Matt> If an object can throw 18 exception types, then clients will need
Matt> to understand all those types, and their implications -- and
Matt> perhaps then, something of the internal workings of that object,
Matt> in order to understand how to respond to a particular exception.

By carefully deriving exception types, the clients needn't worry about
details they really don't understand or care about.

Matt> It might be better to cause the functions in the objects
Matt> interface (the top level functions of the object) to throw only a
Matt> limited set of exceptions, perhaps only one, and handle all other
Matt> exceptions themselves (print an error message or log, take some
Matt> constructive action, etc.).

Rather, let them throw any number of exceptions, but make sure the
exception types have a limited number of distinct base classes. The
ability to derive exception types is the very feature that makes C++
exceptions superior to -- say, Ada's. Client code can catch them with
the accuracy it needs to instead of what the library says.


==pena
--
Olli-Matti Penttinen <pena@niksula.cs.hut.fi>
Lehdesniityntie 3 F 91
00340 HELSINKI                     "When in doubt, use brute force."
tel. + 358 0 1399 0110                -- Ken Thompson
From: niklas@appli.se (Niklas Hallqvist)
Newsgroups: comp.std.c++
Subject: Re: Exception Specifications
Date: 2 Oct 92 13:33:43 GMT
Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN

sakkinen@jyu.fi (Markku Sakkinen) writes:

:Inheritance between exceptions may be treacherous, since 'throw'
:does not work "virtually".  E.g., with Fergus's example:

:MyIntException mye (77);
:Exception *ep = mye;
:throw *ep;

:Only Exception is thrown!

Of course, that's no different from an ordinary call.  If you want
virtualness, you have to use pointers or references, as usual.

class Failure {
public:
  virtual int retry() = 0;
};

template < class T >
class MemFailure {
  int (*a_retry)(const T&);
  T a_context;
protected:
  virtual void get_more_memory () { free (some_extra_storage); }
public:
  MemFailure (int (*the_retry)(const T&), T the_context)
    : a_retry (the_retry), a_context (the_context) {}
  int retry() { get_more_memory (); return a_retry(a_context); }
};

void foo()
{
  try
    {
      bar ();
    }
  catch (Failure f)	// Oops!
    {
      if (f.retry ())	// Pure method call :-(
	throw;
    }
  try
    {
      bar ();
    }
  catch (Failure& f)	// OK!
    {
      if (f.retry ())
	throw;
    }
}
int my_retry (int)
{
  return 1;
}

void bar ()
{
  static MemFailure<int> mf(my_retry, 0);
  Failure& rf = mf;
  Failure* pf = &mf;
  switch (rand () & 1)
    {
    case 0:
      throw rf;	// OK!
      break;
    case 1:
      throw *pf;	// Oops, slicing :-(
      break;
    }
}

Niklas
-- 
Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!seunet!appli!niklas
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Exception Specifications
Date: 1 Oct 92 11:47:28 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

jss@lucid.com (Jerry Schwarz) writes:
: 
: The later included the only people (a medical software group at HP)
: with experience using exceptions in C++. I asked them whether "out
: of memory" had to always be included on their lists and they said
: they didn't treat "out of memory" as an exception.

I think the issue is broader than that.  It is likely (IMO) that certain
"system failure" exceptions will occur at unexpected times.  Examples
include "out of memory", "invalid pointer dereference", "divide by zero",
"OODB deadlock" etc.

For a program where it is unacceptable to terminate when this happens,
the ARM provides the opportunity to replace the predefined unexpected()
function with a custom one.  Suppose you wish to nevertheless
propagate these exceptions to a CATCH block, no matter what
the exception specifications say.  Is it OK for unexpected() to
simply rethrow the exception?

If this is _not_ allowed, then I'm afraid many functions (for example
in life-critical systems) _must_ specify every "system failure" like
exception, causing an avalanche of these throughout the entire program.
Commercial libraries will need these too (to enable the broadest usage).

: 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.

But they may inherit their exception types from ios::failure, no?
Does bring more structure to stream error handling, IMHO.
Derived streambufs will be required to catch and translate non-ios
exceptions.

: [...]This leads me to the conclusion that the iostream library
: should not use failure clauses.

But this means every function using streams must catch all exceptions,
or refrain from using exception clauses, and the functions calling those
functions, and so on.  We end up with programs with either a lot
CATCH blocks, or very few failure clauses.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.std.c++,comp.lang.c++
Date: Tue,  6 Oct 1992 19:31:26 -0400 
From: Stefan Monnier <osoelgaultier+@CMU.EDU>
Subject: Re: The concept of templates considered ill designed
	<23822@alice.att.com>

Excerpts from netnews.comp.lang.c++: 6-Oct-92 Re: The concept of
template.. Andrew Koenig@alice.att. (1825)
> If we call f with an argument of type Bar, it will fail during instantiation
> with an ambiguity error.  The only way to avoid this is to say that the type
> constraint also constrains the call of t.mem(0) to just those instances of
> mem defined in the base class -- but in that case, you will still get in
> trouble with this one:

> 	class Baz: public Foo {
> 	public:
> 		void mem(long);
> 		void mem(double);
> 	};

> because now *neither* of the variants of Baz::mem matches the one in Foo.
> Thus, you have two choices:

> 	1. Attempt to call Baz::mem(int), which doesn't exist;

> 	2. Call Foo::mem(int), in which case you might as well not
> 	   bother using templates at all, or

> 	3. Give an ambiguity error, in which case you can't type-check
> 	   the original template.

> My point in giving this example is to show that statements like `constraining
> template types makes compile-time type checking possible' cannot be made
> casually -- it is the responsibility of the person making such a statement
> to provide evidence that the statement is indeed true.

> This stuff is **difficult**!  Don't take it lightly!
> -- 
> 				--Andrew Koenig
> 				  ark@europa.att.com

What's the problem ?

Why not take option 2 ?

Every Baz object has method Foo::mem(int) cause it has inherited it
from Foo.
If you don't agree with it, why use inheritance ?

And if you would like it to call anything else, then you programming 
style seems weird to me !!!

	Stefan

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------





Xref: sparky comp.std.c++:1299 comp.lang.c++:14509