HDTenEightyP/NetNews huggingface dataset:
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 02:00:42 GMT

In article <1992Oct5.160022.29224@genghis.borland.com> pete@genghis.borland.com  
(Pete Becker) writes:
> 
> 	But this has very little to do with templates.  Constrained parameters
> and no further knowledge of the actual type is equivalent, as far as I can 
> see, to simply carrying around a pointer to the actual class, and dealing 
> with it only through the known interface.  You don't need templates to 
> implement this, and I don't see that there's anything gained by using the 
> template mechanism to do it.

Really? In my O-O design experience, it is very common to have a generic 
model which is composed of several sub-models:

   M < SM1, SM2, SM3 >

and then use the genric model to produce another generic model M':

   M' < SM1', SM2', SM3' >

with more detailed specification. Sub-models in M' are usually covariantly
specified. As far as I can see, only constrained parameterized class can 
support this concept. Sure, we can use pointers or even void* to implement 
this concept, but it is never a serious programming style. To be honest, I 
did not implement this concept in template (it's hard to figure out how can 
template to support this), instead, I use pointers. But I have to use 
expressions like:

    ((Derived*)->foo((DeriveInput*) input);
    ((SubDerived*)(((Derived*)->sub_model)->)->sub_foo();
    ((SubSubDerived*)(((SubDerived*)((((Derived*)->sub_model)->)->...;
    ...

How ugly they are!

> 	Templates avoid the extra indirection that's needed when you don't
> know what type you're dealing with.

It is an implementation issue. Eiffel uses pointers to access to members of 
the type which is a parameter. There is an alternative way to implement 
them without indirection. Indirection is required only when the polymorphism 
is used. For example:

  class BaseList < class EleType[Base], int size >
  { public:     // make data member public for simplifying the example 
      EleType eles[size];
  };

  BaseList * bl;
  BaseList<class EleType=Derived, size=10> dl;
  bl = &dl;

  bl->eles[2];  // dynamically computing the size of EleType is required
  dl.eles[2];   // address is computed statically

Constrained parameterized classes does not necessarily have extra 
indirection. Indirection is needed only when polymorphism based on 
the parameterized classes is required. And such polymorphism is NOT 
supported by C++ templates.

David Shang


 

Newsgroups: comp.std.c++
From: dfarber@serpente.eecom.gatech.edu (FARBER)
Subject: C++ Lang. specs.
Organization: Computer Engineering Group, Georgia Tech, Atlanta, GA 30332-0250
Date: Mon, 5 Oct 1992 19:02:12 GMT


  I've got a friend who writes compilers for a living. He would like to
write a C++ compiler, but can't find anything that will give him the
_complete_ specs for a C++ implementation.
  Where could he get a set of C++ specs suitable for creating a compiler?

----Dave


-- 
-------------------------------------------------------------------
		   Georgia Institute of Technology
      School of Electrical Engineering, Atlanta, GA  30332-0250
		    E-MAIL: dfarber@eecom.gatech.edu
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Exception Specifications
Date: 1 Oct 92 12:05:45 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
: 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.
: >Suppose for instance that you have 20 distinct exceptions,
: >which only need to pass an integer's worth of information
: >to their handlers (or perhaps no data at all).
: >You have to declare a class for each of them.
: 
: Is this so difficult?
: 
: 	class MyException : Exception {};
: 
: 	struct MyIntException : Exception {
: 	    int value;
: 	    MyIntException(int value_) : value(value_) {}
: 	};

Note that Markku said distinguishing exceptions only by the type.
                                                ^^^^
The alternative to class MyIntException with 20 distinct instances
is 20 subclasses to MyIntException (which IMHO _is_ overkill).

I do not advocate a single exception class, it just seems to me that
the exception class hierarchy runs the risk of being overused for too
many tasks:

1 data representation		(MyIntException,MyStringException)
2 exception gravity		(MyErrors, MyWarnings)
3 identifying specific errors	(MyClassIsIllBecauseTheMoonIsFull)
4 identifying the throwing class(ios::failure, MyBase::failure)

Combined with exception specifications (throw clauses), I think this
proliferation of exception classes can be quite a maintenance problem,
unless the exception hierarchies are very carefully designed (using MI).

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Xref: sparky comp.std.c++:1293 comp.lang.c++:14477
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: The concept of templates considered ill designed
Date: 3 Oct 92 09:07:15 GMT
	<1992Oct2.144959.18480@cadsun.corp.mot.com>
Reply-To: tmb@idiap.ch
Followup-To: comp.std.c++
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: shang@corp.mot.com's message of 2 Oct 92 14:49:59 GMT

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

   In article <1992Oct1.140643.9775@cadsun.corp.mot.com> shang@corp.mot.com I  
   wrote:
   Template is not a self-enclosed type-safe language feature, i.e. it cannot be  
   compiled separately to ensure type-error free. All type errors about the 
   class parameters are checked when the template is used.

Yes. However, the reason for this is not intrinsic in the template
concept, but in the way templates were "integrated" with overloading
in C++.

					Thomas.
From: ddv@unix.brighton.ac.uk (Domenico De Vitto)
Newsgroups: comp.std.c++
Subject: Extended Double ?
Date: 5 Oct 92 11:42:42 GMT
Organization: University of Brighton, UK


Is there a any classes anywhere that allow greater presision than long double
?

Ideally one where only memory was a limit would be best.

Surely _somone_ has written something like this ?

TIA,

Dom De Vitto
Newsgroups: comp.std.c++,comp.lang.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:03:37 GMT

Newsgroups: comp.std.c++
From: holiday@bnr.ca (Matthew Holiday)
Subject: Re: Exception Specifications
Reply-To: holiday@bnr.ca
Organization: Bell-Northern Research, Richardson, TX
Date: Thu, 01 Oct 1992 14:33:55 GMT

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.

One thing that bugs me about having "lots" of exception types that could be
thrown is the degree of coupling that will result between parts of the program.

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

It might be better to cause the functions in the objects interface (the top
level functions of the object) to throw only a limited set of exceptions, perhaps
only one, and handle all other exceptions themselves (print an error message or
log, take some constructive action, etc.).  The client's response to failure
of an object might be to destroy and recreate the object, and reattempt the
operation, or call a "recover" function in that object, etc.

There is a measure of philosophical difference here.  If all parts of the program
are written by the same team, then the team can determine the safe degree of 
coupling between objects and their clients.  On the other hand, if a program is
to be created from reusable (perhaps third-party) software libraries, then coupling
should be minimized -- otherwise, why use objects at all?

-- 
Matt Holiday                                         #include <std/disclaimer>
holiday@bnr.ca
BNR Richardson, TX
Newsgroups: comp.std.c++
From: davisonj@en.ecn.purdue.edu (John M Davison)
Subject: Re: Need info to bring mouse into program.
Followup-To: alt.flame
Summary: T. Furnell is abusing the USENET
Organization: Purdue University Engineering Computer Network
Date: Thu, 1 Oct 92 20:16:02 GMT

In article <1992Oct1.084052.12584@monu6.cc.monash.edu.au> s1159377@giaeb.cc.monash.edu.au (T.  FOOEY..  Furnell.) writes:
>I have solved my previous problem with programming for the svga monitor,
>(Thanks for all the help) Now I am trying to bring mouse use into the
>same program. 

        Unless you're talking about the creation of an ANSI "mouse" library
for ANSI C++, get off of this newsgroup.


-- 
John Davison
davisonj@ecn.purdue.edu
From: bk@ccwf.cc.utexas.edu
Newsgroups: comp.std.c++
Subject: Location of ARM?
Summary: Location of ARM?
Date: 28 Sep 92 16:17:59 GMT
Followup-To: comp.std.c++
Distribution: inet
Organization: The University of Texas at Austin, Austin TX

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.

Rob
-- 
=============

bk@ccwf.cc.utexas.edu
The University of Texas @ Austin
Newsgroups: comp.std.c++,comp.lang.c++
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: The concept of templates considered ill designed
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Tue, 6 Oct 1992 17:41:29 GMT

In article <1992Oct6.020042.11130@cadsun.corp.mot.com> shang@corp.mot.com writes:
>In article <1992Oct5.160022.29224@genghis.borland.com> pete@genghis.borland.com  
>(Pete Becker) writes:
>> 
>> 	But this has very little to do with templates.  Constrained parameters
>> and no further knowledge of the actual type is equivalent, as far as I can 
>> see, to simply carrying around a pointer to the actual class, and dealing 
>> with it only through the known interface.  You don't need templates to 
>> implement this, and I don't see that there's anything gained by using the 
>> template mechanism to do it.
>
>Really? In my O-O design experience, it is very common to have a generic 
>model which is composed of several sub-models:
>
>   M < SM1, SM2, SM3 >
>
>and then use the genric model to produce another generic model M':
>
>   M' < SM1', SM2', SM3' >
>
>with more detailed specification.

	I seem to have not made myself clear.  What I was responding to was
the claim that constrained parameters ALLOW THE TEMPLATE DEFINITION TO BE
COMPILED INDEPENDENTLY OF ANY PARTICULAR INSTANTIATION.  While that's
certainly true, it offers very little beyond what's currently available
without using templates, precisely because the compiler knows nothing about
the actual types of the template parameters.
	If you want constrained templates AND independent compilation of
template definitions, you've already got it.  But don't call it a template.
Call it a forwarding class.
	-- Pete
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: Sat, 3 Oct 1992 04:24:22 GMT

sakkinen@jyu.fi (Markku Sakkinen) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>> ...
>>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.

You can't throw a reference.
	
	Exception value;
	Exception& reference = value;
	throw reference;

This will throw the value refered to by the reference, not the reference
itself.  [Well, this is what I infer from reading the RM] 

>>	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);
	This throws an (Exception *)
>Exception ex (0);
>throw ex;
	This just throws an Exception.
	So you can distinguish between them by

	try ...
	catch(Exception *e_ptr) {
		...
		delete e_ptr;
	}
	catch(Exception& e) {
		...
	}

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

Actually, this is just a reason to always catch exceptions by reference.
Then the handler can call virtual functions in the exception object.

Raising an exception is then equivalent to passing an object to a function
that takes a reference parameter. Of course, in both cases you can't
*guarantee* that the exception handler / receiving function will actually
call any virtual functions, but you know that if it does then the behaviour
will be appropriately polymorphic.

-- 
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++
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Exception Specifications
Organization: University of Jyvaskyla, Finland
Date: Wed, 30 Sep 1992 16:16:41 GMT

In article <lci3ptINN3m3@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
> ...
>I'd suggest studying the exception specifications in Modula-3 (latest
>version).  Those are based on years of experience with Cedar and
> ...
>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).

I am afraid that distinguishing exceptions only by the type of the
'throw' expression is mostly overkill instead of improvement.
Suppose for instance that you have 20 distinct exceptions,
which only need to pass an integer's worth of information
to their handlers (or perhaps no data at all).
You have to declare a class for each of them.

John Skaller has remarked that the exception handling principle
requires run-time type information in the implementation,
a thing against which Bjarne Stroustrup has so steadfastly fought
all these years.  (Of course this does not necessarily mean that
the information would be available to the lowly programmers
to misuse.)

Obviously, inheritance between exceptions can be nice
in some situations.  That is one advantage of the C++ scheme.

----------------------------------------------------------------------
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: holiday@bnr.ca (Matthew Holiday)
Subject: Re: Exception Specifications
Reply-To: holiday@bnr.ca
Organization: Bell-Northern Research, Richardson, TX
Date: Thu, 01 Oct 1992 14:23:02 GMT

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

I don't think (1) and (2) are real problems; the funtion f should catch all
exceptions except the ones it lists in its exception specification.

(3) is a real problem; either the rules on exception specifications as part
of the function signature need to be changed (a la Modula-3), or they won't
be very safe.  I'd rather see them done as in Modula-3 (but still allow the
default -- no specification -- to allow all exceptions to be thrown).

-- 
Matt Holiday                                      #include <std/disclaimer>
holiday@bnr.ca
BNR Richardson, TX
Newsgroups: comp.std.c++
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Exception Specifications
Organization: University of Jyvaskyla, Finland
Date: Thu, 1 Oct 1992 15:10:52 GMT

In article <5035@holden.lulea.trab.se> 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.

>: 
>: 	struct MyIntException : Exception {
>: 	    int value;
>: 	    MyIntException(int value_) : value(value_) {}
>: 	};

Likewise.

>
>Note that Markku said distinguishing exceptions only by the type.
>                                                ^^^^
>The alternative to class MyIntException with 20 distinct instances
>is 20 subclasses to MyIntException (which IMHO _is_ overkill).
> ...

Yes, that's what I had in mind.  Or actually that those exceptions
would not be related to each other at all, thus no inheritance relationship.
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".
(Admitted, if the exceptions are somehow related, one can declare
them as the constants of a new enumeration type, as suggested
in Stroustrup's book.  The situation is then almost as in Ada.)

Of course, one defect in Ada's exception mechanism is that no additional
information can be passed together with the exception itself,
and that has been corrected in C++.

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!

----------------------------------------------------------------------
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: sakkinen@jyu.fi (Markku Sakkinen)
Newsgroups: comp.std.c++
Subject: Re: Extended Double ?
Date: 5 Oct 92 13:46:16 GMT
Organization: University of Jyvaskyla, Finland

In article <1992Oct5.114242.15590@unix.brighton.ac.uk> ddv@unix.brighton.ac.uk (Domenico De Vitto) writes:
>
>Is there a any classes anywhere that allow greater presision than long double
>?
>
>Ideally one where only memory was a limit would be best.
> ...

Hmm:  already calculating 1./3. would then exhaust memory.
I think that unlimited-precision _rational_ arithmetic packages
have been built for several languages (don't know about C++).

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