HDTenEightyP/NetNews huggingface dataset:
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Allocating arrays larger than 64K with new?
Date: 17 Aug 92 22:59:46 GMT
Organization: Microsoft Corporation

In article <1992Aug9.152253.11345@newshub.sdsu.edu> add@newshub.sdsu.edu (James D. Murray) writes:
>
>Just how does one use 'new' to allocate an array larger than 'size_t'
>bytes in size?

Two ideas.  This first one is what I prefer, namely write a "smart array":

class HugeArray
{
	void* phugearray;
	HugeArray(long size) { phugearray = huge_alloc(size); }
	....
};

main()
{
	HugeArray* p = new HugeArray(10000000);
}


Second Idea:  declare a custom new with a "placement" parameter that specifies
the number of elements:

void* operator new(size_t size, long nelements)
{ return huge_alloc(size*nelements); }

main()
{
	double* hugearray = new(1000000) double;
}

This second approach has the disadvantage of not calling the "right" 
number of constructors, when used with classes that have constructors.
Xref: sparky comp.lang.c++:12282 comp.object:3188 comp.databases:6081
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.c++,comp.object,comp.databases
Subject: Re: Object What is an OODBMS?
Date: 12 Aug 92 14:21:27 GMT
Followup-To: comp.lang.c++
Organization: Department of Computer Science, University of Manchester
In-reply-to: jrobie@netmbx.netmbx.de's message of 12 Aug 92 07:02:30 GMT

In article <RCZ5NS@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
   When we create a new class we frequently want to use code or data 
   that already exist in another class.  For instance, if we have a class 
   called LinkedList we might choose to use this when implementing our 
   stack.  In fact, we might say that a Stack is a LinkedList which also 
   has the push() and pop() functions.  We can do this directly using a 
   mechanism called inheritence:

       class Stack : public LinkedList
       {
       public:
	   void    push(int i);
	   int    pop();
       };

   In this example we would call LinkedList the base class and Stack the 
   derived class.

Is this generally considered good use/example of inheritance?
I don't think a "Stack is a LinkedList" at all, rather a
LinkedList is a possible implementation of a Stack.  I'd therefore use
parametric rather than inclusion polymorphism to represent this (i.e.
use a template in C++ speak).  Is my preference for parametric rather
than inclusion polymorphism blinding me to some advantage in the
above?

bevan
Newsgroups: comp.lang.c++
From: J.March@lut.ac.uk
Subject: Abstract Data Type libraries ?
Keywords: adt abstract data type library
Reply-To: J.March@lut.ac.uk (Jon March)
Organization: Loughborough University, UK.
Date: Sat, 22 Aug 92 12:39:57 GMT


Does anyone know where I can ftp libraries of abstract data types from?

I am particularly intrested in anything to do with list, tree and lattice
implementations at the moment.

Please mail replies and I'll sumarise.
j.march@lut.ac.uk
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.lang.c++
Subject: Re: Downcasting (was: Re: run-time type checking)
Date: 15 Aug 92 00:01:01 GMT
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

In article <9222715.29197@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>jbn@lulea.trab.se (Johan Bengtsson) writes:
>
>>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>>:
>>:There are other ways than tagged pointers to make downcasting
>>:sound. One might be to declare the derived classes that you want
>
>If I pass you a Base*, I expect that you will only be able to modify it
>using the Base interface. Thus if you want to be able to modify it using
>the Derived interface, then the conversion from Base* to Derived* should
>be an explicit part of the Base interface.
>
>The real drawback is the amount of typing required. This can be reduced
>with macros if desired.
>

	Or with tagged pointers. They're meant to optimise the
typing down to the amount needed and no more, excepting for
the interface declarations.

	[A,B,C]*p;
	p->print();

Calls A::print(), B::print(), C::print() depending. Even less
typing than for the downcasting proposal. Indeed, one of the
criticisms of tagged pointers is that REAMS AND REAMS of code
can be generated by the compiler from a few simple uses.

	[A,B,C,D,E] *a, *b, *c;

	f(a,b,c);

Generates switches to call up to 625 different cases. If f
is a template function, all 625 cases of the function will be
created as well!



-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: hwrvo@kato.lahabra.chevron.com (W.R. Volz)
Newsgroups: comp.lang.c++
Subject: OOD and Inheritance question
Date: 21 Aug 92 17:28:58 GMT
Organization: Chevron Oil Field Research Company

I have a question on how to design a set of classes. It probably has a really
simple answer. But here goes anyway:

Let's say I have a class called Card (A playing card).
A collection of Cards is a CardPile. So this implies maybe a linked list.

Question 1: How should CardPile have the link installed: inherited or member
data? A link is not a Card so maybe it should be a data member. On the other
hand, I can create a new entity of CardPile by inheriting from both
Card and Link. (similar to inheriting from class Boy and class Scout to
make a new class BoyScout.) What would be best or does it depend a lot of 
how I'm going to use CardPile? 

Question 2: I might want to add member functions that draw the card to make
a new class of CardView. Should this inherit from Card or CardPile. Or should
CardPile inherit from CardView which inherits from Card?

     A                              B
class Card                     class Card
class CardPile : Card      or  class CardView Card
class CardView : CardPile      class CardPile : CardView

In A, I can have a pile of cards or a visible pile of cards. But the drawing
functionality for drawing a card should probably not be inheriter from CardPile,
but should be inherited as in B. But in B, I can't just have a pile of card
without visibility functions. It seems that this would be a good place for
templates:

class Card
class CardView
class CardPile <T>

I seem to have just answered my own question here. But anyother opinions?

-- 

======================
Bill Volz
Chevron Oil Field Research Co.
Exploration Research/Geophysics Division.
P.O. Box 446, La Habra, CA 90633-0446
Phone: (310) 694-9340
Xref: sparky comp.lang.c++:12280 comp.std.c++:1078
From: bill@sunquest.UUCP (Bill Raves)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: destruction of temporaries
Date: 12 Aug 92 23:31:55 GMT
Followup-To: comp.lang.c++
Organization: Sunquest Information Systems, Tucson

We have encountered some widely different behavior in compilers (e.g.
DEC C++ and cfront) with respect to the destruction of unnamed temporaries
in contexts where a pointer or reference to object data is returned.
We realize that compiler implementors have been given latitude in this
area (see $12.2 of the ARM) and that the ANSI C++ standards committee is
discussing this issue. We also realize that the manifestations of this
behavior may introduce subtle bugs in code. The question is "How can
we prevent these problems from getting into production code?".

One suggestion is to promulgate stylistic guidelines which caution
against troublesome usage. For example, Jim Adcock has suggested
(<70784@microsoft.UUCP>) "NEVER rely on unnamed temporaries to do
anything...", but this would seem to erode the expressiveness of the
language: constructs like "foo(x + y)" and "foo()[i]" would no longer
be permissible. Henricson & Nyquist suggest "Do not write code which is
dependent on the lifetime of a temporary object" but this seems too
vague, especially for novice programmers, and seems to require us to
know the details of the implementation.  What *specific* guidelines
would you suggest for avoiding potential problems with unnamed tem-
poraries?


-- 
Bill Raves				bill@sunquest.com
Sunquest Information Systems		sunquest!bill@arizona.edu
Tucson, AZ                              {arizona,uunet}!sunquest!bill
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 21 Aug 92 20:06:25 GMT
Article-I.D.: arolla.TMB.92Aug21160625
	<TMB.92Aug19113657@arolla.idiap.ch>
	<1992Aug20.092752.29529@mole-end.matawan.nj.us>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: mat@mole-end.matawan.nj.us's message of 20 Aug 92 09:27:52 GMT

From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 21 Aug 92 18:45:56 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: mat@mole-end.matawan.nj.us's message of 20 Aug 92 09:27:52 GMT

In article <1992Aug20.092752.29529@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:

   In article <TMB.92Aug19113657@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
   Here's a thought.  There was, at one time, a suggestion for an `operator
   void()' that describes the action of throwing away a value.  It gets used
   for anything except the intialization of an object.  Would the `operator
   void()' concept describe the point at which the temporary must be
   discarded?

Under either rule, expressions can already be rewritten to obtain the
desired lifetime. For example:

	X result = x.a().b().c().d();

Language: early destruction, Wanted: late destruction:

	X a = x.a();
	X b = a.b();
	X c = b.c();
	X result = c.d();

Language: late destruction, Wanted: early destruction:

	X a = x.a();
	X b = a.b();
	destroy(a);
	X c = b.c();
	destroy(b);
	X result = c.d();
	destroy(c);

The question is: what should be the default. I don't think that
mandatory late destruction solves anything, because if you start
relying on the persistence of temporaries in expressions, the next
step is that you'll get confused about why they don't hang around for
the whole block.

					Thomas.
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 15 Aug 92 01:26:40 GMT
Reply-To: tmb@idiap.ch
Followup-To: comp.lang.c++
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: bill@sunquest.UUCP's message of 12 Aug 92 23:31:55 GMT


   One suggestion is to promulgate stylistic guidelines which caution
   against troublesome usage. For example, Jim Adcock has suggested
   (<70784@microsoft.UUCP>) "NEVER rely on unnamed temporaries to do
   anything...", but this would seem to erode the expressiveness of the
   language: constructs like "foo(x + y)" and "foo()[i]" would no longer
   be permissible. Henricson & Nyquist suggest "Do not write code which is
   dependent on the lifetime of a temporary object" but this seems too
   vague, especially for novice programmers, and seems to require us to
   know the details of the implementation.  What *specific* guidelines
   would you suggest for avoiding potential problems with unnamed tem-
   poraries?

I think any of these problems can only occur if you use pointers to
temporary objects, or pointers to their contents.

Assume the following definitions are in effect:

	Str::operator char*() ...
	Str operator+(Str&,Str&) ...
	void f(char*) ...
	void g(Str*) ...
	char *Str::h() ...

Then, the following expressions are bad:

(1)	f((char*)(x+y));
(2)	g(&(x+y));
(3)	f((x+y).h());
(4)	f(x+y);

(Str::pointer() returns some pointer to the interior of the object).

Now, (1) and (2) can be avoided by not casting to a pointer types or
taking the address of anything other than a variable.

(3) is a little trickier. Generally, any member function that returns
a pointer type should be viewed with suspicion. But you really have to
know what you are doing:

	char *Str::h1() { return new char; }
	char *Str::h2() { return this->data; }

Of these, h1 is OK, while h2 could fail for a temporary. The same is
true for functions that return pointers and take reference arguments:

	char *h3(Str &x) { return x.data; }

(4) can be avoided by not defining cast operators that convert your
class to a pointer type; doing so is inviting trouble, even if it
looks cute.

					Thomas.
Newsgroups: comp.lang.c++
From: kring@efes.physik.uni-kl.de (Jochen Voss)
Subject: classes for algebraic structures - need help
Organization: FB Physik, Universitaet Kaiserslautern, Germany
Date: Mon, 17 Aug 1992 14:54:49 GMT

I want to implement some classes for groups, rings, ... . I wanted to write some abstract
classes like

class group {
public:
    virtual  group  operator+(group) = 0;
    ...
}

and to derive classes for real groups like Z[2] ( {0,1}, 0+0 == 1+1 == 0, 0+1 == 1+0 == 1 ).
But how do I do this: I want to override the operator+ with something like

    z2  operator+(z2);

because only elements of type z2 (and not of type group) can be added to elements of type z2.
How do I do this.

Please mail me!

--
VinK - Voss is not Kring

You can e-mail me at `kring@physik.uni-kl.de'.
(use `c/o Jochen' in the Subject)
Newsgroups: comp.lang.c++
From: glw@io.uswest.com (Glenn Williams)
Subject: Re: Garbage Collection for C++
Organization: US WEST Communications
Date: Thu, 13 Aug 1992 15:39:55 GMT

In the book Tools 4 there are several articles of GC using C++. The only one I have is:

Experiences Building an Object-Oriented System in C++
P.W. Madamy, R.H. Campbell, P. Kougiouris
Illinois U. ( USA )

Last year I had to write a GC and found several other articles in the IEEE journals. I don't have all the references any longer but it was fairly easy to find.

Some of the others are:

Comparing Mark-and-sweep and Stop-and-Copy Garbage Collection
Benjamin Zorn
Department of Computer Science, University of Colorado at Boulder

Garbage Collection of Distrubuted Objects
Sanjay Mehta and Thomas W. Christopher
Department of Computer Science
Illinois Institue of Technology, Chicago IL 60616

Garbage Collection of Actors
Dennis Kafura, Department of Computer Science, Virginia Polytechnic Institute
Doug Washabaugh, Digital Equipment Corporation
Jeff Nelson, Digital Equipment Corporation

Mark DURING Sweep rather than Mark THEN Sweep
Christian Queinnec, LIX, Ecole Polytechnique
Barbara Beaudoing, LIX et SAGEM
Jean-Pierre Queille, SAGEM

There is a collector available from Hans-J. Boehm and Alan J. Demers. I believe it is in the public domain and is based on algorithms described in their paper:

Garbage Collection in an Uncooperative Environment
Boehm, H and M. Weiser
Software Practice and Experience

This is all pretty interesting reading, hope it helps.


glenn williams
US WEST
Newsgroups: comp.lang.c++
From: svenning@cc.curtin.edu.au
Subject: SEEKING C/C++ LIBRARIES (URGENTLY!)
Organization: Curtin University of Technology
Date: Tue, 18 Aug 1992 04:29:09 GMT

Hello,

     I am urgently seeking c++ / c libraries for use in my project, as I
am currently studying Comp. sys. engineering at Curtin Uni in Australia.
If anyone knows the whereabouts of an ftp site on the net, or, alternatively
can provide me directly with some routines (mainly GUI oriented or search/
sort algorithms) I would be most grateful. My project revolves around
the development of a database oriented package.

                                             Regards,
                                                     Todd Venning.
                                                     
                                             e-mail: svenning@cc.curtin.edu.au




Newsgroups: comp.lang.c++
From: abed@venus.wustl.edu (Abed M. Hammoud)
Subject: Gnu make and C++
Reply-To: abed@saturn.wustl.edu
Organization: Washington University, ESSRL
Date: Wed, 12 Aug 1992 19:04:38 GMT


I am not sure this question belong here so please no flames. 

I have a collection of C++ routines that I use a make file to build a
library out of them which I latter link to.

I've been using the sun make utility. Recently we've installed the
Gnu make. I would like to know if its worth my time to change to the gnu make.
Also what does it do that is better than the sun make? Does it offer
better things as far as dealing with template classes?

My final question is, do you think it would be easy to adapt my current
make file so I can use gnu make...

If some body have a make file that build a library and would like
to share it I would appreciate it.


Thanks, 

+-------------------------------------------------+-----------------------+
|Abed M. Hammoud (KB0INX)			  | abed@saturn.wustl.edu |
|Washington University.				  | Office:               |
|Electronic Systems & Signals Research Laboratory.| -Voice:(314) 935-7547 |
|Department of Electrical/Biomedical Engineering. | -FAX:  (314) 935-4842 |
|Campus Box 1161, One Brookings Drive.		  |			  |
|St. Louis, MO , 63130 USA			  |                       |
+-------------------------------------------------+-----------------------+
Newsgroups: comp.lang.c++
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Downcasting (was: Re: run-time type checking)
Date: 13 Aug 92 10:20:49 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
:
:There are other ways than tagged pointers to make downcasting
:sound. One might be to declare the derived classes that you want
:to downcast to in the base class FROM which you want to downcast:
:	class Base { //....
:		operator Derived1*() =0;
:		operator Derived2*() =0;
:	};
:Now what does this do? Well, it preserved th open/closed principle
:and encapsulation and the explicit interfaces principle.

What if someone using your classes decides to add a Derived3 class
to which downcasting should be possible?  He must modifiy your
class Base, for which he may not have source code.

Does not (help) preserve the open/closed principle at all, IMHO.
-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| jbn@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490              |
--------------------------------------------------------------------------
From: ajayshah@almaak.usc.edu (Ajay Shah)
Newsgroups: comp.lang.c++
Subject: Re: Numerical Recipes in C++?
Date: 21 Aug 1992 19:39:49 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: almaak.usc.edu

In <SINAI.92Aug11105913@biltong.sono.uucp> sinai@sono.uucp (Julian &) writes:
>application I'm working on. So I trotted out the venerable "Numerical
>Recipes in C" bible and quickly realized that their algorithms could
>do with an object-oriented facelift. So here's the question:

NR in C++ is due within a few months.

        -ans.
-- 
Ajay Shah, (213)749-8133, ajayshah@usc.edu
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c++
Subject: Doubly-linked list trick (was Re: Garbage Collection for C++)
Date: 17 Aug 1992 19:49:54 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <2009@appli.se> niklas@appli.se (Niklas Hallqvist) writes:
>When you want to do a doubly linked list to the cost of a singly
>linked one (i.e. in mem. space).  Instead of having two pointers
>for the link in each node, take the "previous" and "next" pointers
>and XOR them, and store the result!

Problems:

1) XOR isn't defined for pointers in C/C++.

2) You could cast the pointers to suitably large integers and XOR those,
but the result of casting the integers back into pointers is
implementation-dependent or undefined (I don't remember which, but either
way it's not portable).

3) It's only useful if you always traverse the list from one end or the
other, since you need to know what to XOR each combined pointer with in
order to get one of the original pointers.  But one of the main reasons for
using a doubly-linked list is so that you can start with any entry in the
list and get to the rest.

3a) In particular, how would you do a circular doubly-linked list with this
scheme?  When it starts out, the node's previous and next pointers would
both be the same (they point to itself) and the result of the XOR would be
0.  But that's also the result when the circular list has two elements,
since the previous and next nodes would always be the "other" node.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Garbage Collection for C++
Date: 17 Aug 92 23:07:47 GMT
Organization: Microsoft Corporation

In article <1992Aug11.043907.21096@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
|Sure. The question is, how to use those library functions - which are legion -
|with the new GC data structures? We don't want to have to write new versions
|of them without good cause.

This problem is already addressed in Modula-3, for example, which already
has reference counting, and further has the ability to call "C" code.
See "Systems Programming in Modula-3" as a start.

Newsgroups: comp.lang.c++
From: bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565)
Subject: Re: Garbage Collection for C++
Originator: bcannard@hppcb36
Date: Sat, 15 Aug 1992 00:55:42 GMT
Organization: Mentor Graphics 
Keywords: 
Followup-To: 


In article <1992Aug14.101226.6929@ericsson.se>, jonas@beppe.ericsson.se (Jonas Nygren) writes:
|> I do not know if this really went out. So I am reposting my own article.
|> /jonas
|> 
|> In article 16572@ericsson.se, jonas@beppe.ericsson.se (Jonas Nygren) writes:
[snip]
|> > I am experimenting with a reference counting scheme where the ref-counter is
|> > placed in a class 'object', which every class that want to be shared must
|> > inherit. To work with multipel inheritance class 'object' should be declared
|> > public virtual. Class 'object' also has the information wether the object was
|> > dynamically allocated or not. 
[snip]

Reference counting suffers serious drawbacks:

1. It can't handle cyclic data structures

2. It is one of the most inefficient forms of garbage collection known to man.

The main reason I'm pushing for true garbage collection is that I consider
reference counting (which I already have) to be an unacceptably poor solution.
-- 
bob_cannard@mentorg.com         "Human beings? ... Well, I suppose they are a
                                 form of life, even if they are unspeakable"
Exprssed opinions are not necessarily those of Mentor Graphics Corporation.
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: Doubly-linked list trick (was Re: Garbage Collection for C++)
Date: 19 Aug 1992 17:52:15 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <TMB.92Aug19133241@arolla.idiap.ch> tmb@idiap.ch writes:
>PS: Where was the outcry of indignation when, all of a sudden,
>uninitialized static member definitions didn't count as definitions
>anymore? Unlike restricting encoded pointers, this did force me to
>change some of _my_ source code.

The outcry was mainly in gnu.g++.help and gnu.g++.bug, which got a lot
of "bug reports" and screaming when g++ implemented the new rule.  Since
the installation procedure has been cleaned up, it's been the single
most frequently posted article.




--
Joe Buck	jbuck@ohm.berkeley.edu