HDTenEightyP/NetNews huggingface dataset:
From: niklas@appli.se (Niklas Hallqvist)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 19 Aug 92 08:54:52 GMT
Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

>niklas@appli.se (Niklas Hallqvist) writes:

>   I just wanted to say that conservative GC won't really help in all
>   situations.  Jonathan Shapiro taught me this useful trick once.
>   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!

>   Now you just need to store two entry consecutive points into the
>   list, and make an iterator intelligent enough to work things out.
>   This is of course a very special trick, but it IS useful, and it
>   shows NO GC strategy always wins unless the programmer explicitly
>   can tell what objects are live/dead, but then again, we're back to
>   explicit memory management.

>You didn't take that seriously, did you? In any case, it's an old hat
>and it's unportable (*).

Well, I did mean it seriously, in order to show C++ rules need to be changed
to allow even conservative GC.  It's only unportable between environments
which don't have sufficiently sized integers to store pointers in.  If you
restrict your program to only work on more "normal" architectures it IS
defined.  Read ARM 5.4!  Of course, this means conservative GC is
implementable on architectures where no integer type can hold a void pointer,
but otherwise it is NOT.  Do I miss anything in my thinking?

>Incidentally, there is a widely used, simple, efficient, more general,
>and completely portable technique for getting the same kinds of
>storage savings as with the XOR trick.

Oh?  I can't think of any completely portable transformation of two pointers
into a single field where you can get one of the pointers back if you know
the other.  Subtraction, for example, is only defined if the pointers are
pointing into the same array (ARM 5.7).  Maybe I'm on a soapbox when I
assume a doubly linked listnode must be able to encode TWO pointers.
And "widely used"?  I have read lots and lots of source for over ten years
and I have obviously missed it.  Please show us this trick!

>(*) In C++, there is no guarantee that there exists an integral type
>large enough to hold a pointer; ARM p.67-68.

So you had read this section, and still think GC can be done, if the text isn't
changed to something like:

"All pointer to integer conversions and back are implementation defined."
-- 
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
Newsgroups: comp.lang.c++
From: dxs@evolving.com (Dan Stanger)
Subject: class used only once
Date: Thu, 20 Aug 1992 17:14:13 GMT
Organization: Evolving Systems, Inc.

i am developing a program containing a set of routines and data
where the data would have only one instance of it.  i am interested
in comments regarding making it a class vs putting it in a seperate
file and only exporting the routines that i need.
any comments would be appreciated.
thanks, dxs
Newsgroups: comp.lang.c++
From: vadim@cix.compulink.co.uk (Vadim Lebedev)
Subject: Language extension
Reply-To: vadim@cix.compulink.co.uk
Date: Thu, 13 Aug 1992 23:17:33 +0000


While thinking about various RTTI, XRTTI and GC proposals
for C++ i've stumbled on following idea:
Many of the modern computer programs such as communication programs,
word processors, CAD systems, e-mail systems provides a means to tailor
them to match user needs by offering some kind of script language.
It just occured that the same mechanism could be provided in the
compiler.  A scripting language which could access and manipulate
compiler data structures. Such a thing will give almost unlimited
language extension possibilites and that WITHOUT need to change the
language itself.

With souch a feauture RTTI, EXCEPTION HANDLING, GC, PRE- and POST- 
method conditions, class invariants, all become
possible without modifying the language. The stadards commetee will
simply have to agree on library interface to all these features.

With such a feauture one could write following to add persistemcy
to his classes:

class Something
{
 
public:

    doSomeThing();
 
 Something( int a, b, c);
 Something(float x);
protected:
 int x, y;
};

 

template <class T>
class Persistent: public T, public PersitentObj
{
public:
 // Generates the same constructors as class T
 #for f in  #methods(T) 
  #if f == T::T
   Persistent(#arglist(f)) : T(#params()) { }
  #endif
 #endfor

private:
 // Generate the store method
 virtual storeOn(PStream &s)
 {
  #for a in #attributes(T)
    s.store(T::a);
     #endfor
 }
 
};
  

Or to add a class invariants: 


template <class T, class Expr>
class Constrained : public T
{
private:
    // generate invariant checking method
 void check() { assert(Expr); }
public:
 // add invariant checking for all public methods
 #for f in  #methods(T) 
  #if #visibility(T::f) == public
   #typeof(f) f(#arglist(T::f)) {
      check();
      #if #typeof(T::f) != #typeof(void)
       #typeof(T::f) ret = 
      #endif
        T::f(#params());
      check();
      #if #typeof(T::f) != #typeof(void)
         return ret;
      #endif
  #endif
 #endfor

public:
 // Generates the same PUBLIC constructors as class T
 #for f in  #methods(T) 
  #if f == T::T  && #visibility(f) == public
   Constrained(#arglist(f)) : T(#params()) { check(); }
  #endif
 #endfor

};



Actually the TI  C++ Preprocessor has somewhat similar capabilities,
but it is limited by fact that it is a PREPROCESSOR, and does not
have full access to all compiler data structures.


What do you think?
-----------------------------------------------------------------------
Vadim Lebedev                      |   Kortex International
vadim@cix.compulink.co.uk          |   139-147 av. Paul-Vaillant Couturier
                                   |   93126 La Courneuve - CEDEX, France
From: wallis@sieras.enet.dec.com (Barry L. Wallis)
Newsgroups: comp.lang.c++
Subject: Re: Stream I/O in Turbo C++
Date: 17 Aug 92 21:11:23 GMT
Organization: Digital Equipment Corporation


In article <1992Aug16.023318.17440@news2.cis.umn.edu>, esper@cs35b.cs.umn.edu (Dave Sherohman) writes...
>OK, another question for you.  (As was guessed after my last one, I'm fairly
>new to C++... BTW, the actual problem with the struc claiming to have been
>redefined was that the .h file it was in was included twice into one .cpp
>file...  Oops...)  I'm playing with mixing windowing and stream I/O, and I
>can't figure out how to get the window to scroll properly.  When I hit the
>bottom of the window, 'cprintf("\r\n");' will send a linefeed and scroll the
>window up one line, but 'cout << "\r\n";' wraps the cursor back to the top
>of the screen instead of scrolling it.  How can I get the scrolling to work
>without resorting to using cprintf?
> 

Check out the constream object. It is new to version 3.x and is the stream
equivalent to conio.h. It includes member functions to handle text mode windows
with the stream keeping track of which window you are using. The interface can
be found in <constrea.h>

---
Barry L. Wallis			wallis@sieras.enet.dec.com
Database Consultant		Prodigy (don't laugh): DNMX41A
U.S. Production Systems Resource Center
Los Angeles, CA			"No one voted for me, I represent myself"
---
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Return value for the constructors.
Date: 19 Aug 92 20:46:04 GMT
Article-I.D.: alice.23491
Reply-To: ark@alice.UUCP ()
Distribution: usa
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <H575V1E@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:

> But note this example from the ARM, page 62:

> 	complex* p = new complex(i++);
> 	if (p == 0)  // allocation failed!

This is a characteristic of new-expressions, not constructors.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++,comp.lang.misc
From: edwin@sfu.ca
Subject: TeamWork vs C++
Summary: Need info on TeamWork vs C++
Keywords: Cadre,TeamWork,CenterLine,C++
Organization: CS, SFU, Burnaby, B.C., CANADA
Distribution: na
Date: Tue, 18 Aug 1992 19:06:31 GMT

Hello everyone.

I would like to have some information on the following few things:

1)	I understood that CenterLine's CodeCenter can talk to Cadre's
	TeamWork/SD, but is it possible for CenterLine's ObjectCenter to 
	Cadre's TeamWork/IM ? 

2)	If (1) is possible, then how can I set it up and run it together ?
	Do I need to do  TeamWork/IM --> TeamWork/SD  &  
	                 CodeCenter --> ObjectCenter 

3)	Does anyone know the E-mail address of Cadre Compnay ?
	(note: I already have the e-mail address for CenterLine.)

Your help to any of the questions will be sincerely appreciate.


--Edwin Cheng, thanks so much.
  CSIL Administrator, SFU
  Email:  edwin@sfu.ca
Newsgroups: comp.lang.c++
From: adc@tardis.msu.edu (Alan D. Cabrera)
Subject: indent for C++
Reply-To: adc@tardis.msu.edu
Organization: Michigan State University
Date: Fri, 21 Aug 92 14:35:48 GMT


Is there an indent program for C++?



---
Alan Cabrera				internet:  adc@tardis.cl.msu.edu
Computer Laboratory			phone:     (517) 353-3027
Michigan State University		fax:       (517) 353-9847
514 Computer Center			bitnet:    CABRERA@MSU
East Lansing, MI 48824

Newsgroups: comp.lang.c++,comp.lang.c,comp.std.c++,comp.std.c
From: long@skorpio.usask.ca (Sed's Warren Long)
Subject: Looking for C++ Guidelines/Standards
Summary: C++ guidelines
Organization: University of Saskatchewan, Saskatoon, Canada
Date: Wed, 19 Aug 1992 16:30:02 GMT


Hello,

There is a good book called "C Programming Guidelines" by        
Thomas Plum which describes style and standards when 
programming in C.
Is there something similar for C++ ?

Any response is greatly appreciated.

Thank you,

WL

long@skorpio.usask.ca
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c++
Subject: Re: Libraries which depend on compiler (mangling).
Date: 19 Aug 92 17:31:01 GMT
Article-I.D.: early-bi.16u0glINN84a
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <Bt8922.ED4@fulcrum.bt.co.uk> rct@fulcrum.bt.co.uk (Richard Taylor) writes:
>I suspect this is probably an old chesnut, but I'm new to C++, and have just
>come across the fact that different compilers mangle names in different
>ways (g++ and cfront, in particular).
>This means that when I purchase a library of objects (which happen to have
>been compiled with cfront) I cannot compile my own code (with g++) and link
>it together with the object library, without also purchasing cfront.  In a
>world of releatively portable code, this is an incredible oversight.

Is this in the FAQ yet?

You're confusing portability with interoperability.  Name mangling is only
a small part of the interoperability problem between code generated by
different compilers.  Other differences include: layout of virtual tables,
layout of class members (in particular, the order of members when multiple
inheritance is used), how "this" is passed in the calling sequence of
member functions, and how global initializers are executed.

Until all such things are standardized, there's no point in standardizing
the name mangling.  In fact, compilers are *encouraged* to use unique
mangling schemes, so that the user finds out that he's trying to mix code
from different compilers, which is not likely to work because of the other
problems.

BTW, C has similar problems, although not to as large an extent.  By
default GCC uses a different mechanism for returning structure values from
functions than most PCC-based C compilers.  You have to remember to give
GCC the -fpcc-struct-return option to force it to use the older convention
(it's not used by default because it may be less efficient and
non-reentrant).  And if you have a program that must be linked with two
libraries, one of which was compiled with the PCC convention and the other
with GCC's default, you could be screwed.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: saito@sdr.slb.com (Naoki Saito)
Newsgroups: comp.lang.c++
Subject: Books and PD domain programs for binary tree etc.
Keywords: binary tree, elementary data structures.
Date: 18 Aug 92 20:37:37 GMT
Reply-To: saito@sdr.slb.com
Organization: Schlumberger-Doll Research

Dear C++ gurus,
I would like to know good C++ books explaining elementary data structures
such as binary tree.  I also would like to know some public domain programs of
binary trees.
Books:
I know a book "A C++ Toolkit" by J.S.Shapiro.  It explains a bit of binary tree,
but only describes the class implementation, not the actual use of the binary trees.
Programs:
I know libg++ contains many list, linked list things, but I don't think it contains
binary trees.

Any information is appreciated.

---
Naoki Saito (saito@sdr.slb.com or saito@math.yale.edu)
Schlumberger-Doll Research and Yale University
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: C++ 3.0 and exceptions
Organization: University of Illinois at Urbana-Champaign
Date: Wed, 19 Aug 1992 16:41:54 GMT

In <MATTHEW.92Aug19105738@matthew.ntl02.decnet.nokia.fi> matthew@ntl02.decnet.nokia.fi (Matthew Faupel) writes:

>Could anyone please confirm or deny the fact that exceptions as described in
>Bjarne Stroustrup's 2nd edition of the C++ Programming Language are *not*
>supported by v3.0 of the language?

*****>	They are not supported in cfront 3.0.x.

>Follow-up question: If they are not supported, when will they be?

*****>	Presumeably in 4.0; probably in about a year.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: lattanzi@wsl.dec.com (Len Lattanzi)
Subject: Re: Downcasting (was: Re: run-time type checking)
Keywords: polymorphism, RTTI, downcasts.
Organization: Western Software Lab
Date: Thu, 13 Aug 92 07:42:32 GMT

In article <9222518.29381@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
:
:This is a good idea.
:In particular, it seems that this technique much reduces the attraction of
:the current proposal to allow downcasting, because users can achieve virtually
:the same effect themselves - they just have to make the interface explicit.
:
:For example
:
:	class Base {
:		...
:		operator Derived1*() { return 0; }
Better make that virtual operator Derived1*()
:	};
:
:	class Derived1() {
:		...
:		operator Derived1*() { return this; }
:	};
:
:	Base *base_p;
:	...
:	Derived1 *derived1_p = (Derived *) *base_p;
:	if (derived_p) { ... }
:
Biggest drawback is that Base must know about every derived class and
provide a virtual type conversion. But it is a usable poor-man's RTTI.

--
\
 Len Lattanzi (Migration Software Systems Ltd 408 452 0527) <len@migration.com>
From: daniel.edelson@inria.fr (Daniel R. Edelson)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Keywords: temporaries,destruction,statements,block,early
Date: 20 Aug 92 11:35:22 GMT
Reply-To: Daniel R. Edelson <daniel.edelson@inria.fr>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France


I'm not an expert on this issue, and so will just make one
quick point and then shut up.

In article <23487@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
|> In article <3920@starlab.UUCP> mi@starlab.UUCP (Michael Hoennig) writes:
|> 
|> 	3. I have heard comments from users who really want temporaries
|> 	   cleaned up early if possible.  Typically they are using linear
|> 	   algrbra packages and write things like this:
|> 
|> 		Matrix D = A * B * C;
|> 	   
|> 	   and do not want the intermediate result A * B to hang around
|> 	   until the end of the block.  Of course they can't enclose this
|> 	   in braces because then that would tear down D as well.  Moreover,
|> 
|> 		Matrix D;
|> 		{
|> 			D = A * B * C;
|> 		}
|> 
|> 	   in addition to being ungainly, substitutes assignment for
|> 	   initialization.  This can be significantly slower in some
|> 	   implementations.

It seems as though there is a tension between early destruction and
late destruction. The numerical scientists prefer early destruction 
because their temporaries are very large and consume substantial
resources. Some others advocate late destruction because that
reduces the likelihood of dangling references.

My only observation is that correctness may be more important
than efficiency. Though early destruction may make some programs
run faster, will it introduce a disproportionate number of errors?

Also, what language will the Standard use to specify this. Assume
that the Standard defines when temporaries are destroyed. My fear
is that it will become 'undefined behavior' to hold a reference to
a temporary beyond the point where the temporary may have been
destroyed. Undefined behavior means that the programmer is wrong
but the compiler need not say anything. Thus, this can lead to
insiduous bugs that only appear under certain compilers, or
perhaps only with optimization enabled, etc.

Mere Mortals (tm) should be able to understand why their C++
program is or is not legal, without having to pester their
local guru every 15 minutes. (You can tell that my prime 
consideration is not job security.)

|> 				--Andrew Koenig
|> 				  ark@europa.att.com

Daniel.Edelson@inria.fr
From: kring@efes.physik.uni-kl.de (Jochen Voss)
Subject: Overloading Parent Declaration: Bug or Feature?
Organization: FB Physik, Universitaet Kaiserslautern, Germany
Date: Thu, 20 Aug 1992 14:18:30 GMT

I tried to compile the following program with GNU C++ version 2.1
(Atari ST, Patchlevel 2):

	#include <stream.h>

	class B {
	public:
	    void f(int x)	{ cout << "B::f(" << x << ")\n"; }
	};

	class D : public B {
	public:
	    void f(char *str)	{ cout << "D::f(" << str << ")\n"; }
	};

	main()
	{
	    D d;

	    d.f(1);		// (*) should be an error ?
	    d.f("hallo");
	}

It compiles without warnings (even with the -Wall flag set) and outputs
	B::f(1)
	D::f(hallo)
when run.  But in Bjarne Stroustrup's Book `Die C++ Programmiersprache'
(2. Auflage, 1992) in section R.13.1 he writes that the statement at the (*)
is an error because D::f(char*) hides B::f(int). B::f(int) is not overloaded
with D::f(char*) because the functions have different scopes.

Is this a bug or a feature? Shouldn't I at least get a warning?

--
VinK - Voss is not Kring

You can e-mail me at `kring@physik.uni-kl.de'.
(use `c/o Jochen' in the Subject)
From: u8903845@cs.uow.edu.au (Anil Sachdeva)
Newsgroups: comp.lang.c++
Subject: Graph Library ?
Keywords: Graph
Date: 18 Aug 92 04:16:44 GMT
Organization: Dept of Computer Science, Wollongong University, Australia

Hi I was wondering , If there is any Graph Library Around . 
Shortest Distance and etc . In C++ or in C .

Thanks

u8903845@cs.uow.edu.au
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: Class Template Member Function returning pointer to function
Summary: I think it's a Borland bug
Date: 14 Aug 92 09:16:11 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <1992Aug7.204148.20180@cunews.carleton.ca> nholtz@zonker.cascade.carleton.ca (Neal Holtz) writes:
>    template <class T>
>    class Queue {
>      public:
>        typedef void (*FullQHandler)(Queue<T>&);
>        FullQHandler setHandler( FullQHandler fn );
>    };
>[...]
>An obvious thought might be to fully qualify the typedef name and
>do this:
>    template <class T>
>    Queue<T>::FullQHandler
>    Queue<T>::setHandler( Queue<T>::FullQHandler fn ) { ... }
>
>I haven't checked all of the rules in the ARM or in C++PL2, but the
>latter in section r.7.1.6 seems to allow "Queue<T>::FullQHandler" as
>a qualified-type-name and thus as a type-specifier.  Borland C++ 3.0
>however does not allow it, simply saying "Declaration syntax error"
>If this is not a Borland Bug, how do I do it????

I believe it is a Borland bug.  I reported it back in Dec. 91 but they
didn't fix it in 3.1.  Can someone confirm that it is a bug?  BC++
seems to really get confused with templates when you start playing
around with nested types and with friends.  Other than using the real
type, I don't know of a workaround for this bug.

Btw, I send all BC++ bugs I find to bugs@borland.com (just for
reports, no reply) and to the the (unofficial) TC++/BC++ mailing list
TCPLUS-L.  To subscribe, send mail to listserv@ucf1vm.cc.ucf.edu
containing the line:
   subscribe tcplus-l Your Name

BC++ 3.1 fixed a lot of 3.0 bugs, but it still has several, mostly
template-related bugs.  I can send you a copy of my 3.0 or 3.1 bug
reports if you like.

Jamshid Afshar
jamshid@emx.utexas.edu
Newsgroups: comp.lang.c++
From: abed@venus.wustl.edu (Abed M. Hammoud)
Subject: Reference counting for vectors, (Tony Hansen's book).
Reply-To: abed@saturn.wustl.edu
Organization: Washington University, ESSRL
Date: Fri, 14 Aug 1992 16:47:19 GMT


Hello, 

I was trying to implement the vector class using the method suggested
by tony Hansen. i.e reference counting. the following code is taken
from Hansen's book (C++ Answer book). There is some thing that doesn't
seems correct. Please let me know what you think.

For example the way the code work is:

Assume you declare a vector of size 10 and initialize it to all 5:
  
	vector A(10, 5); 

Then assume you declare another vector B and set its elements equal
to those of A, i.e you can say:

	vector B(10); B = A; 

	or 

	vector B = A; 

then lets say you wanted to change the contents of B. By doing so
the contents of A also changes.

The following code is the test program that I used. I compiled it
using g++ on a sun sparc machine please compile it and see for your
self.

I think this is a very bad design. But I am not sure if there is something
that I am missing. Could somebody please comment. 

By the way does any body know if Hansen's working on a new version of the
book.

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




/*-----------------cut here and save rest in foo.c------------------*/
/*-----------------then compile and see for yourself  -------------*/

#include <iostream.h>

class vector
{
   struct vrep
      {
	 float *f; 
	 int refcnt; 
	 int length; 
      } *p; 
public:
   vector(int size, float init = 0.0); 
   vector(vector& x); 
   ~vector(); 
   vector& operator = (vector& vec);
   float& operator [] (int i); 
   friend ostream& operator << (ostream&, vector&); 
}; 

vector::vector(int size, float init)
{
   p = new vrep; 
   p->f = new float [p->length = size]; 
   for (int i = 0; i < size; i++)
      p->f[i] = init; 
   p->refcnt = 1; 
}

vector::~vector()
{
   if (--p->refcnt == 0) {
      delete p->f; 
      delete p; 
   }
}

vector::vector(vector& x)
{
   x.p->refcnt++; 
   p = x.p; 
}

vector& vector::operator = (vector& vec) {
   vec.p->refcnt++; 
   if (--p->refcnt == 0) {
      delete p->f; 
      delete p; 
   }
   p = vec.p; 
   return *this; 
}

float& vector::operator[] (int i)
{
   return p->f[(i >= 0) && (i < p->length) ? i : 0]; 
}

ostream& operator << (ostream& out, vector& v)
{
   out << v.p->length << endl; 

   float *f = v.p->f; 
   int l = v.p->length; 
   for (int i = 0; i < l; i++)
      out << *f++ << endl; 
   return out << endl; 
}

main()
{
   vector A(5, 3); 
   vector B = A; 
   cout << A << B << endl; 

   cin >> B[2]; 
   cout << A << B << endl; 
}