HDTenEightyP/NetNews huggingface dataset:
From: baldwin@cps.msu.edu (Reid A Baldwin)
Newsgroups: comp.lang.c++
Subject: eliminating automatic calls to member destructors
Date: 4 Jan 93 17:03:44 GMT
Organization: Dept. of Computer Science, Michigan State University
NNTP-Posting-Host: pacific.cps.msu.edu

I am implementing a program that uses persistent objects. Some of the
the classes I use have an integer delete_status member. When delete_status
is 0, the object should not be deleted. My intention was to implement
this feature by redefining the delete operator so that is checks the
delete_status before calling the regular delete operator, and doesn't call
it if delete_status is 0. That works fine. However, the destructors are
automatically being called for each of the data members of the class.
Some of these data members call delete for parts of their data structures.
So, some of the data structure gets deleted anyway.

I could find an in-elegant solution by associating another delete_status
member with each of the data members that call delete. Setting them all
correctly seems quite error prone. Also, if someone derives classes from
my classes and they add data members with destructors that call delete,
they would have to know about maintaining a delete_status. This solution
doesn't satisfy me.

Instead, I would like to avoid the calls to the member destructors in
the first place. I don't know how to communicate this to the compiler so
it doesn't insert them automatically after each return. Is there some kind
of super-return statement that doesn't automatically destroy the members?

Thanks for any help,
Reid Baldwin
baldwin@cps.msu.edu
Newsgroups: comp.lang.c++
From: sdm@cs.brown.edu (Scott Meyers)
Subject: Location of FAQ and Product List
Organization: Brown University Department of Computer Science
Distribution: usa
Date: Wed, 6 Jan 1993 17:00:39 GMT

I can't remember where the FAQ for this group is, nor the location of the
C++ Products List.  I'd appreciate it if somebody would remind me.  I
promise to write it down this time.

Thanks,

Scott

-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."
Newsgroups: comp.lang.c++
From: mbersohn@alchemy.chem.utoronto.ca (M. Bersohn)
Subject: A Fine Beginner's Book on C++
Originator: mbersohn@plumbum.chem.utoronto.ca
Organization: University of Toronto Chemistry Department
Date: Sun, 10 Jan 1993 09:53:24 GMT

As the best beginner's book on C++ for somebody who knows C I
recommend TEACH YOURSELF C++ by Herbert Schildt, published by Osborne
McGraw Hill  ISBN 0-07-881760-9 
It is only a primer. There is no depth and it lacks detail; for
example templates are not mentioned. BUT, there is a superb
wealth of practice examples with answers and frequent quizzes
with answers. The progression is quite gradual. This book is
a highly efficient way to get started with C++, provided you
know C. Incidentally this book is not mentioned in the FAQ.
From: Neal.Sanche@ttlg.UUCP (Neal Sanche)
Sender: postmaster@ttlg.UUCP
Newsgroups: comp.lang.c++
Subject: Borland C++ & TVision
Date: 11 Jan 93  07:30:00 mst

To: chris@cad.gatech.edu (Chris McClellen) 
 On 01-09-93 Chris McClellen wrote to All... 
 
 CM> I am using Borland C++ 3.1 with TVision.  Currently, I am running 
 CM> into a problem with the Help subsystem.... 
 
 You require the patches to Borland C++ 3.1. There is a patch for the 
 assertion error included. 
 
 CM> Secondly, BC++'s TVision screen IO is absolutly slow compared to 
 CM> Pascal's TVision.  WHat can I do to speed C++'s tvision up? 
 
 I too have noticed the slow screen I/O. I am almost ready to go back 
 to Turbo Pascal.... But part of me says, "Hey! Wait!" BC++ comes with 
 such a great library of objects. I'm willing to put up with slow 
 screen refreshes for the ability to get what I need done. 
 
 If you come up with a solution to this slowness, could you let me know? 
 
 -Neal 
 
... OFFLINE 1.41 

 * Origin: Paradigm BBS: A programmer's paradise. (42:100/11)
Newsgroups: comp.lang.c++
From: psrc@pegasus.att.com (Paul S R Chisholm)
Subject: Re: C++ Answer Book - new revision?
Reply-To: psrc@pegasus.att.com (Paul S R Chisholm)
Organization: AT&T Bell Laboratories
Date: Wed, 6 Jan 1993 05:03:22 GMT
Summary: he's working on it!
Keywords: ARM  Tony Hansen

In article <1993Jan3.111317.631@elroy.jpl.nasa.gov> earle@elroy.jpl.nasa.gov (Greg Earle - Gainfully Unemployed) writes:
>Does anyone know if Mr. Hansen plans on an updated version to correspond with
>the Second Edition of TC++PL, as Tondo & Gimpel did with their "The C Answer
>Book"?

Yes, he plans on it.  In fact, he's working on it.  (Unless he's
reading netnews . . . yo, Tony, back to work!-)

Paul S. R. Chisholm, AT&T Bell Laboratories/EasyLink Services,
att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company (or Tony), I'm just speaking my mind.
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Small objs & When/whether to overload "new" with statics
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Tue, 5 Jan 1993 18:34:19 +0000

In article <1993Jan04.162941.13841@rchland.ibm.com> lwloen@rchland.vnet.ibm.com writes:
[ BitRef class def omitted]

> Now, I am less interested in the particular virtues and vices of 
> BitRef per se than in what to do _in general_ with helper objects of
> that kind.  Note carefully that in the normal course of events, BitRef
> will never be formally declared.  It will arise, normally, as a temporary
> in various objects' operator[].  There are many such potential objects.
> 
> Optimizing such objects can be important, especially if they "help" 
> functions like operator[], because they may appear in inner "for" loops.

One obvious optimisation would be to adjust data to point to the actual 
byte containing the bit you want, so that loc is always between 0 and 7.

> I especially wonder about "new" and "delete".
> 
> For machines with enough registers, one presumes that the above code 
> could work out fairly nicely, as is.  Each data element of an instance 
> of BitRef could imaginably have both of its small pieces optimized into 
> a register, especially since the compiler, since it creates it, is in 
> full control of how long the instances live.
> 
> For a PC-type machine, however, such optimization seems unlikely (is
> that so?).  

It is so on all the compilers I have used. I don't think I have ever seen 
a PC compiler optimise a structure into registers.

> Therefore, _if_ the compiler's generation of "temps" uses
> new and delete, one would be tempted to add something like the following
> to BitRef

Ah, but they don't (as a rule), they allocate space on the stack.

-- 
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Xref: sparky comp.lang.c++:18996 comp.object:4759
From: alane@wozzle.linet.org (J. Alan Eldridge)
Newsgroups: comp.lang.c++,comp.object
Subject: Re: Pros and cons of C++
Date: 12 Jan 93 02:10:48 GMT
Organization: Disorganization

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

> 3.  There is an Obj-C front end for Borland C.

(serious questions) Where? From whom? (couldn't resist) Why?

alane@wozzle.linet.org (J. Alan Eldridge)
Fido: The University of Walamaloo 1:272/38.473
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Newsgroups: comp.lang.c++
Subject: Re: Borland C++ 3.1 problem under DOS
Date: 7 Jan 93 17:09:27 GMT
Organization: Texas Instruments Inc

In <1993Jan5.083609.4987@mnemosyne.cs.du.edu> skwok@nyx.cs.du.edu (Stephen Kwok) writes:


>I have installed Borland C++ 3.1 on my PC, but I have problem when 
>running BC.EXE under DOS, my machine will hang whenever I run BC.EXE.
>But when I start up the compiler under Window 3.1, I believe it is 
>BCW.EXE, it works.  Any idea or comment on what the problem is?

>Machine config:  Intel 486DX-33, 8M memory, Trident TVGA 8900C, 200M HD

>Thanks for any help in advance.

Do you have EMS386.sys or a similar EMS memory provider installed?
The newer Borland C++ compilers *require* 2BM of accessible memory.
Your problem may be that Windows provides EMS services but you don't
have an EMS provider installed when you aren't inside Windows.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Newbie Wants Advice on C-Programming
Summary: ``Begin by drawing your Free Body Diagram ...''
Organization: :
Date: Thu, 7 Jan 1993 05:06:03 GMT

In article <810@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman) writes:
> In article <1993Jan4.091953.29873@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
> >Perhaps what is needed is being a skilled programmer and a skilled
> >program architect/designer.
 
> And which books would you recommend to start us on the way to
> being a skilled software designer?		<g,d,r>

To start on the way ... I almost hate to say this:

	Kernighan & Plauger
	_The Elements of Programming Style_
	2nd edition

(You did say `to start.')
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: pauljo@microsoft.com (Paul Johns)
Subject: Re: A Fine Beginner's Book on C++
Date: 11 Jan 93 22:26:34 GMT
Organization: Microsoft Corp.

This is the one C++ book I've seen that I judge
"not acceptable."  I don't know if there's a later
edition, but I wouldn't trust a later edition if
there were one, frankly.

That's because the edition I've seen is worse than 
shallow:  it's wrong.  The author has no concept of a 
copy constructor.  His solution for passing a string 
object which contains a pointer to the dynamically-
allocated string to a function by value is "Don't.
It doesn't seem to work."
  
He notes that the destructor for the class gets 
called twice while the constructors he wrote are 
only called once; he never explains why.  That's
because he doesn't know about copy constructors at
all; let alone the one the compiler generates for you!

Understanding constructors and destructors is 
absolutely essential for understanding how to write 
non-trivial classes.  A book that misses this misses
the core of C++.

Buy a book from someone who knows how to program in C++
instead.  And if you've used this book, read a better
book to undo the damage.

By the way, I've noticed a lot of posts on here from
people who are clueless about copy constructors:  could
this book be part of the reason why?  :)
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Not supposed to use static variables in me
Date: 7 Jan 93 16:40:23 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: TIN [version 1.1 + PL8]

Jim Heliotis (Heliotis.ROCH803@xerox.com) wrote:
: In article 725838896@unix1.tcd.ie, ghawkins@unix1.tcd.ie (George C. Hawkins) writes:
: >
: >If a member function wants to remember a value between calls to it
: >then it must store that value in a varaible visible to all member
: >functions. Is this right? I was doing:
[...]
: >void Foo::bar()
: >{
: >	static int remember;
[...]
: >But was rather upset to find that all instances of Foo shared the
: >same 'remember'.


: I have not yet seen the answer to this question that I consider most
: straightforward.  You should declare "remember" as a member variable
: (non-static).  The only disadvantage to that, possibly, is that any
: member function can access it that way.

Interestingly, introducing "remember" as a _protected_ (non-static)
data member in a _base_ class gives him the added protection.  A given
member function in the (now derived) class can only access "remember"
through the "this" pointer.  Of course, "remember" is now open to attack
from further subclasses.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
From: tk@dcs.ed.ac.uk (Tommy Kelly)
Newsgroups: cs.questions,comp.lang.c++
Subject: Dynamic Multidimensional Array Allocation in C++
Date: 4 Jan 93 15:41:06 GMT
Reply-To: tk@dcs.ed.ac.uk (Tommy Kelly)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U

How do I implement a dynamically configurable two dimensional array in C++?

For one dimension its easy, but doing:

my_type *my_type_var = new my_type[a][b];

doesn't seem to work.

thanks for any help.

tk
Newsgroups: comp.lang.c++
From: emt1@cunixf.cc.columbia.edu (Eduardo Miguel Thieberger)
Subject: C++ with templates on a Mac
Keywords: templates Macintoshc
Organization: Columbia University
Date: Wed, 6 Jan 1993 19:55:33 GMT

 
Is there a good C++ compiler for the Apple Macintosh that implements templates?
 
Bob Wilber  rew@lightstn.com
Newsgroups: comp.lang.c++
From: S103408@UMRVMB.umr.edu
Subject: Re: oopslooking for PerClass/SizeFreeList, oops
Date: Wed, 6 Jan 1993 23:55:30 GMT
Organization: Univ of MO - Rolla

Ok, BC++3.1 isn't working due to > 64K code segment.

Anybody out there have any experience with:
MetaWare High C++
Zortech C++
Watcom 9.0 C++

that can tell me if these can do 32bit flat memory model coding
with dos and a dos-extender?  Can I malloc() objects > 64K ?
Are there outrageous liscensing restrictions on the generated code?
Can I link in the extender or does it have to be already running?
They all cost a fortune, so some info would be welcome.
Please e-mail responses to:
S103408@UMRVMB.UMR.EDU

John Ham
From: heiniw@eebsun1.eeb.ele.tue.nl (Heini Withagen)
Newsgroups: comp.lang.c++
Subject: Problems with gcc/g++ and profiling
Date: 12 Jan 93 15:40:09 GMT
Organization: Electronic Circuit Design Group, Eindhoven University of Technology, The Netherlands



I am having trouble with gcc/g++ 2.2.2 compiling programs with -pg
options for profiling. I have been looking what g++ actually does
during compilation/linking (-v option) and compared this to 'cc' (on 
a SUN Sparc).

It seem that g++ is linking the wrong libraries which do not contain
the right function for profiling. When I try to make a seperate call
to the linker with the same libraries substituded as with 'cc', I get
a long list of 'Undefined' names which look like 'LBE??' and 'LBB??'.


Does anyone know the answer to my problems ?? Please help me, because
I am getting quite desperate.


Thanks very much in advance,

Heini Withagen
Department of Electrical Engineering EH 9.29
Eindhoven Technical University
P.O. Box 513
5600 MB Eindhoven
The Netherlands
Phone: 31-40472366
Fax:   31-40455674
E-mail: heiniw@eeb.ele.tue.nl
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: why `int X: :X()' ?
Date: 12 Jan 93 10:13:31 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: TIN [version 1.1 + PL8]

Richard M. Hartman (hartman@ulogic.UUCP) wrote:
: In article <5501@miramon.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
: >Matt Wette (mwette@csi.jpl.nasa.gov) wrote:
: >
: >: Why are constructor and destructor functions usually declared to return
: >: ints when the usage typically warrents a `void' declaration.
: >
: >The "default int" rule does not apply to constructors and destructors.
: >You can't return an "int" from those functions.  You can't explicitly
: >mark them as procedures (void) either.
: >
: >I'd say that "default void" (as for constructors and destructors)
: >makes more sense than "default int".  Having no default type at all
: >makes the most sense, avoiding compiler and programmer confusion.

: I'd say you are misleading yourself.  The best way (IMHO) to think
: of constructors is returning the type for which they are a constructor.

There are two useful ways to think of constructors, your way and my way.

My way (implementation side):
	"a constructor has no return value"
Your way (usage side):
	"a call of a constructor returns an object"

This is similar to the duality of overloaded "new" operators,
from the implementation side it is a function size_t --> void*.
From the usage side it is a different beast, returning a typed
pointer.

In both cases the compiler inserts a bit of extra code when
the function is used.

: but if you start thinking of

: 	void classType::classType() {}

: Then declarations such as:

: 	classType classInstance = classType();

This is an explicit constructor call (see the ARM, p266,267).
You are not calling the classType::classType() function directly.
The compiler inserts code to allocate space for a temporary "classType"
object, and then calls classType::classType() function (which has
no return value, but instead relies on the "this" pointer for
access to the object to be constructed).

You cannot say "return classType(somevalue)" inside
classType::classType() (which would be the consequence
if constructors had an implied non-void return type).

-- 
--------------------------------------------------------------------------
| 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: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Passing 2-d arrys to functions
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 9 Jan 1993 16:10:19 GMT

In article <MATT.93Jan8111148@physics2.berkeley.edu> matt@physics.berkeley.edu writes:
>In article <726521188snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
>
>I happen to be of this opinion.  I believe that a well-designed array
>class is essential, and should be part of the C++ Standard Library.
>(Actually, make that several well-designed array classes; probably the
>right solution is to have one class for one-dimensional arrays, and
>another for multi-dimensional arrays.)  Now that templates are part of
>the language, this is more practical than it used to be.

	Not that simple! Even for 1-dimensional arrays,
several classes might be needed.

>
>I've written my own array classes (I imagine that we all have), but it
>would be nice if I could count on arrays being there in every
>implementation.

	What we need standardised most is an ABSTRACT array class.

	template<class T>
	class Array<T> {
	public:
		virtual T& operator[](int)=0;
		virtual const T& operator[](int)const =0;
		virtual int count()const=0;
		int operator+()const{return count();}
		virtual ~Array(){}
	};

Thats mine. A 'simulation' of unsafe C like arrays:

	template<class T, int len>
	class CArray : public virtual  Array<T> {
		T data[len];
		virtual void check(int)const{}
	public:
		T& operator[](int i){check(i); return data[i];}
		const T& operator[](int i)const {check(i); return data[i];}
		int count()const{return len;}
	};

Note the rare private virtual function 'check'.
And a safe one:

	template<class T, int len>
	class CheckedCArray : public virtual CArray<T,len> {
		void check(int i)const{assert(i<count());}
	};

Now do it all over again, but use a pointer to a 'new'ed
array instead of 'data'. (In preparation for
deriving arrays of variable length)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: vkessler@ncratl.AtlantaGA.NCR.COM (Vance Kessler)
Newsgroups: comp.lang.c++
Subject: Private vs. Protected
Date: 12 Jan 93 13:28:29 GMT
Organization: NCR Engineering and Manufacturing Atlanta -- Atlanta, GA


I would like to get your feelings as to when to use private versus when to use
protected.

I generally make instance variables protected to give direct access to
sub-classes.  But, I am thinking that it might make maintenance easier to make
them private and always access them through protected access functions.

I would appreciate your opinions on this.

Vance Kessler
vkessler@ncratl.atlantaga.ncr.com
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Static global initialization outside of main() legal?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 4 Jan 1993 15:38:06 GMT

In article <GIROD.93Jan4122311@kilohp.kiloapo.ts.tele.nokia.fi> marc.girod@ntc.nokia.com writes:
>>>>>> On Thu, 31 Dec 1992 19:11:23 GMT, nagle@netcom.com (John Nagle) said:
>John>        You're working in a very messy area of C++.  The order in which
>John> things happen during static initialization isn't the same in different
>John> compilers.  
>
>Things are not so bad as John states! 

	Oh yes they are!

>The most important is
>guaranteed: that "the initialisation [...] in a translation unit is
>done before the first use of any function or object defined in that
>translation unit". 

	This is not guarranteed at all, even if it says it is!

>There remains the "pathologic" case of mutual
>dependencies, dealt with in the annotation part of the ARM for 3.4,

	This is not how it works. There is no general solution
to the problem, so no algorithms can be written to solve it.

	Typically, what happens is static variables are initialised
to a constant value first (0 if not otherwise specified)
then modules get initialised in the order of linkage, 
and variables in each module in the order of writing.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: How to limit string output length w/ stream manips?
Organization: TauMetric Corporation
Date: Fri, 8 Jan 1993 18:32:39 GMT

af458@yfn.ysu.edu (Jon K. Salmon) writes:


>I would like to limit the output length of a string sent to an
>output stream.  For example, given a string...

>  const char *Bob = "1234567890ABCDEF";

> ... to output "12345"?

As with printf(), the iostream inserters never truncate a value; output
width is a minimum, not an absolute.

If you want to truncate a string, you have to do the truncation yourself.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c++