HDTenEightyP/NetNews huggingface dataset:
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: RUN TIME ARRAY INDEX ERRORS
Organization: University of Illinois at Urbana-Champaign
Distribution: na
Date: Thu, 19 Nov 1992 17:16:29 GMT

In <1992Nov19.102258.4237@alchemy.chem.utoronto.ca> mbersohn@alchemy.chem.utoronto.ca (M. Bersohn) writes:

>Hello experienced people!
>     There seem to be two ways to detect array index errors at
>run time. One is to explicitly check the index.
>int x[20];

>if (j >= 0 && j < 20 && function1(x[j]))
>    ...
>     The other way is the C++ way,to overload the [] operator.
>     Explicit checks clutter the code enormously. The operator
>overloading method is transparent to us unless we remember the
>class definition. It's neat.

*****>	Of course, you have to have a class for which [] is overloaded;
	you can't overload [] for built-in types.

>     My question to ask you is this: How did C survive all these
>years without such an obviously essential feature? How was
>anybody able to construct programs of 100,000 plus lines of C
>that worked well,without this feature? I'm a naive programmer;
>there is some magic there that escapes me.

*****>	Obviously, in a working program, range checks serve only to
	degrade performance.  To not go outside of vector bounds, just
	don't do it.  Simple.  If you're dealing with a vector, you
	should know its size or know what the sentenel is; if you don't,
	you shouldn't be using the vector in the first place.

		Patient:	"Doctor, it hurts when I do this."
		Doctor:		"So don't do that."
	
	For its alleged weaknesses, C is lean, fast, portable, close to
	the machine, and flexible (unlike straight-jacket languages like
	Pascal).  Languages shouldn't be defined to have a zillion
	built-in checks to save programmers from themselves, IMHO.

	BTW, it is possible to perform source-to-source translations in
	C to have the code peppered with range-checking code or I
	imagine that some vendor's compilers have the option of doing
	something similar by inserting range-checking code.  Such checks
	would be disabled for a final product, of course.

	There are far more serious bugs in programs than range-checking
	errors, so catching those doesn't make a dent anyway, IMHO.
	Errors in algorithms, misreading or misinterpretation of
	specifications, logic-erros, (typographical errors like that
	one), ad nausium, are out there; range-checks are the tip of the
	proverbial ice-berg, but if you use a vector properly, as I
	originally stated, you should have no range errors.

	(Oh, I can just see the responses to this coming. :) )
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Should I use a generic object which all others inherit from
Date: 18 Nov 92 12:41:12 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

cshaver@informix.com (Craig Shaver) writes:
: In article <3762@news.cerf.net> hlf@nic.cerf.net (Howard Ferguson) writes:
: >I am working on the early stages of design on an embedded C++
: >project. One of the decisions which we will have to make in the
: >near future is whether to make all of the objects inherit from 
: >onie generic object at the top of the tree or to go for the forest 
: >approach. 
: >
:
: An embedded system!  C++!?  JUST USE C!!!!
: 
: UNLESS ....
: 
: You have some of the benefits of OOP in mind, such as inheritance, reuse, 
: and information hiding.  Then if you are willing to take small dings in
: performance go all the way and use the tree approach as pioneered by
: Smalltalk.  I recently saw a review of the toy code that comes with the
: borland compiler.  The article's author commented that the tree type
: libraries were "passe" because of templates.  What a stupid thing to say!
: 
: One of the big wins of OOP is reuse.  By using an inheritance structure
: you can reuse existing code and do incremental development.  Related and
: unrelated classes can be used in the same context where a similar protocol
: is enforced.

Perhaps you would then kindly enlighten the rest of us:

If I go for the tree approach, with a base class MyObject inherited
by all my classes, how am I going to reuse _your_ classes, which all
inherit from class YourObject?  Multiple inheritance?  What
if the protocol of my base class conflicts with your base class?
How do I reuse tree-type libraries from several sources, each with
it's own base class protocol?

Enforcing a common protocol (by inheritance) for all your classes,
_hampers_ reuse of your classes by anyone except yourself.

Once a reference to an object has been passed as a generic
object reference, for example into a collection, how do you (safely)
call the actual methods of the objects (derived) class?

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: gregc@eagle.fsl.noaa.gov (Greg Compestine)
Subject: Re: Complexity in the eyes of the beholder?
Organization: Forecast Systems Lab, NOAA - Boulder CO, USA
Date: Fri, 20 Nov 1992 01:17:20 GMT

andrew@tagsys.com (Andrew Gideon) writes:

>Specifics: I am of the "small class" and "mixin" school.
>I tend to write small classes, with tight functionality.
>I then combine these into classes providing greater and
>greater functionality.

	[stuff deleted]
>  In trying to understand a class, he
>is forced to recurse too frequently and too far.

>Unfortunately, I do understand his point.  I too have been
>frustrated similarly - by my own code!  But this seems an
>acceptable cost for having a system that can eventually 
>be understood.  Besides, I seem to be used to this form
>of reverse engineering.

>Am I wrong?  Is he?  Am I missing something obvious?
>Any comments welcome.

>Thanks for your attention.

>	- Andrew Gideon


   I believe his objection stems from trying to find all
the methods deep level class is inheriting.  With the
default collection of Unix tools, it can be a really
tedious job to sort out all the relations among classes,
especially when you are debugging one with a lot of
inherited functionality.  It seems to me the problem is 
accessability.  I recently received a demo of ObjectWorks 
and its class browsing utilities.  The thing is very 
versatile and has good performance.  It allows you to get
at the inheritance tree of any class with very little 
effort.  My first reaction was to find my boss and ask if 
we could get it for Christmas.  If you have a chance,
I'd recommend you and your coworker checking into this
or some other class browser tool, and see if this addresses
your problem.


gerG                          Gee, I hope I'm not saying "OOPs!"
                                  at the end of this project.
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: base classes and typedef not working?
Summary: it's a bug: BC++ doesn't allow typedef in member init. list
Date: 19 Nov 92 21:41:32 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <1992Nov14.190608.28656@muddcs.claremont.edu> dfoster@jarthur.claremont.edu (Derek R. Foster) writes:
>In BC++ 3.1 the following code produces the error
>"MatrixBase is not a base class of Matrix"
>
>typedef Array2<Scalar> MatrixBase;
>
>class Matrix : public MatrixBase
>{
>  Matrix(int row, int col) : MatrixBase(row,col) {}; // error occurs here
>};

Actually, this bug shows up whether or not you're using templates
(though there are other typedef bugs specific to templates).  A
constructor's member initialization list appears to be the only place
BC++ 3.1 has problems using a typedef instead of the actual class
name.  I've already reported this to bugs@borland.com (no reply or
tech. support).  Just put the actual class name in for now, maybe
marking it with a comment so you can fix it later.  If you'd like a
copy of my bug reports (mostly template related), just email me.

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

	typedef Base B;

	class Derived : public B {
	public:
	   Derived()
	      : B() {}  // BC++ error, but legal code.  Use "Base()" for now.
	   virtual void f() {
	      B::f();   // okay, no complaints from BC++
	      //...
	      }
	};

Jamshid Afshar
jamshid@emx.utexas.edu
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Using delete with arrays - help please!
Organization: TauMetric Corporation
Date: Mon, 16 Nov 1992 17:50:13 GMT

srlncnc@gopher.dosli.govt.nz (Chris Crook) writes:

>My understanding is that I can allocate an array of class instances using
>the syntax
>   MyClass *arrayOfInstances = new MyClass[arraySize];
>and that when I want to delete it I use
>   delete [] arrayOfInstances

Correct (I added the missing "*" to the original example).

>What I am puzzled about is the wide use of arrays of characters in
>the Borland code examples in which the arrays are allocated as
>   char *aBuffer = new char[bufferSize];
>   delete aBuffer;

>Can you tell me why this works? Why doesn't it need the [] after the
>delete operator?

The effect of the second example is undefined.  Portable programs
must use the array form of "delete" when and only when the array form
of "new" was used to allocate the array.

In some implementations, the array form of "delete" does nothing
special when the array base type has no destructor.  In such
implementations you would get the same effect with either of
	delete aBuffer;
	delete [] aBuffer;
because type "char" has no destructor.

You cannot rely on this behavior, however, and any sort of error might
occur as the result of mixing the two styles of "new" and "delete".
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
Subject: Re: delete with arrays - help please
From: srlncnc@gopher.dosli.govt.nz (Chris Crook)
Date: Wed, 18 Nov 1992 18:14:25 GMT
Organization: Department of Survey and Land Information, New Zealand


If responding e-mail please use this address:

       From: carroll@sde.mdso.vf.ge.com (Carroll James)

The reason for this is simple. new and delete really use 'malloc' and 'free' 
(or similar systems calls to the heap manager) to allocate a bocks of memory.

The heap manager knows how big of a block has been allocated but it DOES NOT
know anything about data types in those blocks. Because of this the call of the
destructors is done in C++ and not by the 'system' (in this case, the heap 
manager, which is part of the system).

In older versions of C++ (2.0 ?) you couldnt use a [] without a number in it 
because the delete operator (which is really a library routine in C++) didnt
get a count from the heap manager. The entire reason for the [n] was for the
delete operation to call the destructor 'n' times. In newer versions of C++ 
the delete operator became smart enough to know (or to figure out based on size
of element being deleted and the size of the block allocated) what 'n' is and
call the destructor that many times.

In either case (i.e. delete x, or delete [n] x) a call is made to 'free' 
(which would look like free(x)) at which point the entire block is freed by
the heap manager. The problem is that for Object instancted with destructors,
the destructors will not all be called unless the [n] is supplied (remember
that delete without [] or [n] assumes there is only one).

For built in types or object instances that dont have destructors, the total block
of memory is freed. Therefore for these instances or built in types the overall
effect is the same for both 'delete x' and 'delete [] x'.

I think ARM mentions some precautions to take. I personally dont like making a 
distinction between built in types and object instances when it can be avoided
but in this case it will work.


				Jim Carroll

PS Could you do me a favor and Post this to the newsgroup since that capability
has been disabled on our server.
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Newsgroups: comp.lang.c++
Subject: Re: template member func:  class X { template<class T> f(T& x) {...}}
Date: 22 Nov 92 21:03:14 GMT
Organization: University of Virginia

mg@elan (Michael Golan) writes:
: Why isnt this allowed?
: 
: class File {
: 	binwrite(void *buf,size_t sz) {...} // write buf of length sz 
: public:
: 	template<class T> write(T& buf) { binwrite(buf,sizeof(T)); }
: };

Because there is an alternate way to do the same.

template <class T>
class File {
    void binwrite(void* buf, int sz) {}
public:
    void write(T* b) { binwrite(b, sizeof(T)); }
};

main()
{
    File<int> f;
    int	 i = 0;

    f.write(&i);
}

-Sekar
From: eburk@lisa.sfsu.edu (Eli Burk)
Newsgroups: comp.lang.c++
Subject: beginner: how do I use cc++?
Keywords: cc++
Date: 22 Nov 92 05:16:03 GMT
Reply-To: eburk@futonsfsu.edu (Eli Burk)

Hello

### NOTE
I wouldn't have posted while just starting to learn a language, but there is
scant documentation on using c++ on the gnu cc++ compiler on Nexts. Also at
our computer lab such information is horded like a precious commodity.

*!!! email responces please !!!*

I'm trying to learn C++ (I have experience with C.). I started with the
simplest of example code. At this point I'm just using examples from my 
books. But I don't know how to make the books examples work.

--- the script file that i was told to use
#!/bin/sh
it=$1
echo "C++ $it"

 cc++ $it -I/usr/local/lib/g++-include -g -O -fstrength-reduce   
-felide-constructors -fschedule-insns -fdelayed-branch -fsave-memoized    
-DNO_GNULIB3 -DNO_LIBGXX_MALLOC -pipe -o  a.out -L/usr/local/lib -lg++ -lm

--- a c++ file that doesn't work
#include <stream.h>
// #include <iomanip.h> 	// not in the library

main()
{	
	cout << hex;
	cout << 13;
	cout.width(25);
	cout << "testing";	
	cout << setw(25);
	cout << "testing";	
}
--- output 
lisa> !cx
cx testing02.c
C++ testing02.c
testing02.c: In function int main ():
testing02.c:6: cannot resolve overloaded function `hex' based on non-function  
type
testing02.c:6: type conversion required for type `ostream'
testing02.c:8: no member function `ostream::width'
testing02.c:10: warning: implicit declaration of function `setw'


--
#### Re: NT: clean design (NoT!) (was Re: OS/2 because! (was NT: Why?) ####
acronym: a word (as radar or snafu) formed from the initial letter or letters 
         of each of the successive parts or major parts of a compound term 
Defintion by webster *not* my me     eburk@{sutro,springfield,futon,sfsuvax1}
Xref: sparky comp.lang.c++:16437 comp.lang.c:16683
From: northrup@dolphin.cps.msu.edu (Frank Northrup)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re:  *** IMPORTANT DISCOVERY *** from knaggs@cps.msu.edu
Date: 17 Nov 92 16:59:30 GMT
Organization: Dept. of Computer Science, Michigan State University

FYI:

	-Yes, knaggs@cps.msu.edu's "IMPORTANT DISCOVERY" posting
	 was inappropriate for comp.lang.c++ and comp.lang.c.
	-I had his login shell changed to get him to discuss it
	 with me.  So far, he has apparently ignored it, probably
	 because...
	-His account was already (i.e. *before* he sent the posting)
	 scheduled to be deleted (due to not being a MSU Computer 
	 Science student, faculty, or staff, and not currently taking 
	 a MSU Computer Science course).
	-And as should be obvious... he was not speaking for 
	 MSU Computer Science Department, nor Michigan State
	 University...

				--Frank Northrup,
				  Computing Facilities Coordinator
				  Computer Science Department
				  Michigan State University
				  northrup@cps.msu.edu
From: skochhar@cvbnet.prime.com (Sandeep Kochhar x4618 5-2)
Newsgroups: comp.lang.c++
Subject: Protected Derivation
Date: 16 Nov 92 14:06:25 GMT
Distribution: usa
Organization: Computervision

hi!
In the ARM, I seem to find to mention/explanation of protected derivation
(i.e., class Foo: protected B {...};).  But I know some compilers support
it... Is it a recent addition to the ARM or the language?  Where is
it explained?  What does it mean (briefly)?

Thanks.
Sandeep Kochhar
Computervision, MS 5-2            email: skochhar@cvbnet.prime.com
14 Crosby Drive                   tel:   (617) 275-1800 x 4618          
Bedford, MA 01730                 fax:   (617) 275-8506
From: franl@centerline.com (Fran Litterio)
Newsgroups: comp.lang.c++
Subject: Re: Criticisms Wanted
Date: 21 Nov 92 15:10:02
Organization: CenterLine Software, Inc.
NNTP-Posting-Host: 140.239.3.116
In-reply-to: sailer@hpuerca.atl.hp.com's message of Fri, 20 Nov 1992 00:14:02 GMT

sailer@hpuerca.atl.hp.com (Lee Sailer) writes:

> perhaps a good compromise is "literate programming".  In LP, the documentation
> and the code are the same thing.  As implemented by web, filters exist
> which convert the well-documented code to user readable documentation.  Other
> filters convert the same code into stuff the compiler can use.

Take that code-to-doc filter one step further: an expert system
digests the code and the human asks it technical, highly abstract
questions in a natural language.  The "documentation" would never be
out of sync with the source.
--
franl@centerline.com   || Fran Litterio, CenterLine Software R&D
617-498-3255           || 10 Fawcett St, Cambridge, MA, USA 02138-1110
"So what we've decided to do is set you up in Cicely, situated
 in an area that we Alaskans refer to as The Alaskan Riviera."
Newsgroups: comp.lang.c++
From: skdutta@ucs.att.com (Saumen Dutta)
Subject: C++ products List ....
Organization: AT&T Universal Card Services, Jacksonville FL
Date: Fri, 20 Nov 1992 11:10:00 GMT

For those who have send replies to the C++ product list
at cs.tamu.edu, please send them again to the return address
of this posting. My mails from cs.tamu.edu are not
getting forwarded properly.

Thanks
skdutta
From: doug@foxtrot.ccmrc.ucsb.edu (Douglas Scott)
Newsgroups: comp.lang.c++
Subject: Re: How to keep a member from being deleted thru a pointer?
Date: 17 Nov 92 03:55:47 GMT
Distribution: usa
Organization: Center for Computer Music Research and Composition, UCSB

In article <1e567gINNi16@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992Nov15.035153.18866@u.washington.edu> chuan@stein.u.washington.edu (Chuan Lee) writes:
>>Now if someone does a
>>	delete c.getItem("a member");
>>instead of using
>>	c.removeItem("a member");
>>  So how can I prevent that from happening?
>
>Make Item's destructor private.  Then only members and friends of Item can
>delete instances of Item.
>
>Note, however, that this will also prevent non-members/friends from
>declaring automatic Item variables, since they would have to invoke the
>destructor when the variable's scope ends.

I believe you can solve this by doing the following:

	const Item* Collection::getItem(const char*) {...}

If I am not mistaken, you cannot call delete on a const return value.  Anyone
else know for sure?




-- 
Douglas Scott                              (805)893-8352
Center for Computer Music Research and Composition
University of California, Santa Barbara
Internet: (NeXTMail ok)   <doug@foxtrot.ccmrc.ucsb.edu>
From: huw@siesoft.co.uk (Huw Roberts)
Newsgroups: comp.lang.c++
Subject: iostreams bug in BC?
Summary: I have an iostream program which behaves differently in BC++ and cfront
Keywords: whitespace; stream; borland; cfront; fail
Date: 18 Nov 92 15:49:25 GMT
Organization: Siemens Nixdorf Information Systems Ltd.
X-Newsreader: Tin 1.1 PL4

I have a problem with BC++ 3.1.  I'm not sure what the correct behaviour is
so I can't tell whether or not it's a bug.  The program certainly behaves
differently on cfront:

    ...
    istrstream fred (" 35    ");
    int x;
    fred >> x >> ws;
    if (fred.fail())
	cout << "You're kidding!`n";

Borland produces the message, cfront does not.

* Is this a bug in the Borland iostream library?
* Does anyone have a reference to an ARM equivalent for the stram library -
  The C++ Programming Language (2nd Ed.) doesn't go into quite enough detail
  in this area.

Huw
--
Huw Roberts (huw@siesoft.co.uk) Siemens Nixdorf Information Systems Ltd.
+44 344 850982                  Oldbury, Bracknell, Berks. RG12 4FZ England
Xref: sparky comp.lang.c++:16724 comp.unix.aix:11824
From: jeff@kuhub.cc.ukans.edu (Jeff Bangert)
Newsgroups: comp.lang.c++,comp.unix.aix
Subject: g++ on AIX 3.2?
Date: 22 Nov 92 15:51:56 GMT
Article-I.D.: kuhub.1992Nov22.095156.45021
Organization: University of Kansas Academic Computing Services

Does g++ run OK under AIX 3.2?

I'd like to implement it -- but I'm not experienced at AIX -- and
there is a systems person who will help -- but she says that she heard
there was a problem, but doesn't remember the details.

Thanks for the help,

-- 
Jeff Bangert			jeff@kuhub.cc.ukans.edu
Computer Center			jeff@ukanvax.bitnet
University of Kansas
Lawrence, KS 66045
(913)864-0466
Newsgroups: comp.lang.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: virtual functions need virtual destructors ?
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 23 Nov 1992 17:08:37 GMT

In <kilitzir.722528914@news.forth.gr> kilitzir@antigone.csi.forth.gr (Xristos Kilitzirakis) writes:

>Why do virtual functions need virtual destructors ?

*****>	They don't.  A _class_ that has virtual functions often
	requires a virtual d'tor if and only if objects of that class
	are deleted via a pointer to a class that is a base of that
	class so an object of the right size is deleted.

>Hope to be easy question.

*****>	The answer is also in any C++ book.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: maudl@csv.warwick.ac.uk (Mr M C Graham)
Newsgroups: comp.lang.c++
Subject: Wanted: C/C++ matrix handling routines.
Date: 21 Nov 1992 18:46:40 -0000
Organization: Computing Services, University of Warwick, UK
Distribution: world
NNTP-Posting-Host: lily.csv.warwick.ac.uk

Does anyone know of a library of matrix routines for C or C++? I guess
I'd ideally like a C++ matrix class with all the operator functions defined to 
work on matrices. If not then any general purpose C matrix handling routines
would be very welcome. I could do it all myself but there must be something 
already floating around.

Cheers,
Mark Graham


Please mail anything you have to:

maudl@csv.warwick.ac.uk

Newsgroups: comp.lang.c++
From: moudgill@cs.cornell.edu ( Mayan Moudgill)
Subject: Is there a workaround for this bug?
Summary: parser bug for templates
Keywords: template, bug, example, 3.01
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Fri, 20 Nov 1992 22:12:52 GMT

I discovered what appears to be a bug in the AT&T C++ 3.01 compiler.
I've included two files which demonstrate it. The first one compiles
correctly, the second doesn't. Both files declare a particular inline
function. The first one defines it inside the class, and it compiles
correctly. The second defines it below the class, and it does not compile.
If it *IS* a bug, who should I report it to.

*Please* reply be e-mail. Thanks,
:)
Mayan

------------- CUT HERE FOR CORRECT PROGRAM -------------------
template <unsigned sz> class Vector;
template <unsigned sz> class VectorBind;

template <unsigned sz>
class VectorBind {
public:
   inline  VectorBind()
      {
      }
};

template <unsigned sz>
class Vector {
public:
   inline VectorBind<sz>    operator [] (unsigned)
   {
      return VectorBind<sz>();
   }
};

main()
{
Vector<16u>  v;
    (void)v[8];
}

------------- CUT HERE FOR INCORRECT PROGRAM -------------------
template <unsigned sz> class Vector;
template <unsigned sz> class VectorBind;

template <unsigned sz>
class VectorBind {
public:
   inline              VectorBind()
      {
      }
};

template <unsigned sz>
class Vector {
public:
   inline VectorBind<sz>    operator [] (unsigned);
};

template <unsigned sz>
inline VectorBind<sz>     Vector<sz>::operator [] (unsigned val)
{
   return VectorBind<sz>();
}

main()
{
Vector<16u>  v;
    (void)v[8];
}
Xref: sparky comp.lang.c++:16402 comp.lang.c:16632 comp.os.msdos.programmer:10684