HDTenEightyP/NetNews huggingface dataset:
From: pauljo@microsoft.com (Paul Johns)
Subject: Re: Operator Overloading problem
Date: 17 Dec 92 21:40:50 GMT
Organization: Microsoft, Redmond WA USA

Any time you have a class which contains a pointer to 
dynamically-allocated memory (as your class does), you
WILL NEED an appropriate:

	Assignment operator
	Copy constructor
	Destructor

You will likely also need a default constructor.

Your symptoms are consistent with forgetting one
or both of the assignment operator or copy constructor,
depending on how the addition operator was used. 
(Forgetting the destructor results in a memory leak.)

If you forget any of these, you'll end up with the
kinds of problems you're seeing.

Note that these problems can be silent:  since the
compiler provides you with these functions if you
don't provide them, you won't get any sort of
compiler error.

What I think is happening in your case is that the
compiler supplied assignment operator or copy 
constructor is just doing a memberwise copy of
your object.  Your addition function is creating
the temporary and allocating memory for it.  The
pointer to this memory is copied from the temporary
to the object to which you're assigning/copying
rather than copying the memory.

// Paul Johns

Newsgroups: comp.lang.c++
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: overloading operator new
Organization: University of Virginia
Date: Sat, 19 Dec 1992 19:50:13 GMT

marc@meadow.uucp (Marc Riehm) writes:
: My Turbo C++ 2.0 manual (the only C++ documentation I have available :( )
: says that the first argument of MyObject::new must be a size_t.  i.e. we
: overload new via a method which looks like...
: void *MyObject::new(size_t)
: They imply that there can be other arguments to MyObject::new.  Could anyone
: tell me whether or not this is true and, if it is, how to declare the method
: and how to use MyObject::new?  Are there any side effects on the constructor?

First, you have to keep in mind that implementations are allowed to
call operator new before calling constructors when you provide your
own operator new.

If you are going to use your own memory allocation scheme,
it will be easier to provide global operator new than
providing member operator new for each and every class.

If, on the other hand, you want to do specialized memory
allocation for some classes, you can do so by providing
member operator new to those classes.

For example,

class Pool {
	// memory pool class
public:
	void*	getmem (size_t sz);
	void	freemem (void* p);
};

class A {
	//...
public:
	A (int a) {...}
	~A () {...}

	void*	operator new (size_t sz, Pool& p) { return p.getmem (sz); }
	// since the above op new hides ::new, you may
	// need the following op new as well
	void*	operator new (size_t sz) { return ::new char[sz]; } 
	void	operator delete (void* p) {
		/* special allocation may require special deletion */
	}	
};

main ()
{
	Pool p;
	A*	a = new (p) A (5);
	// note the way the extra argument to A::operator new is passed.
}
Newsgroups: comp.lang.c++
Subject: Re: Complex Addition.
From: <GNR100@psuvm.psu.edu>
Date: Sun, 13 Dec 1992 18:36:34 EST
Organization: Penn State University

     What about multiplying?  Can this be done?
                      Gordon Rogers
                       gnr100@psuvm.psu.edu
Newsgroups: comp.lang.c++
From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Subject: Re: Survey: File Extension
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
	<1992Dec12.014834.926@netcom.com>
Date: 12 Dec 92 22:48:01 GMT


More important is consistancy within your project and compilers/tools
ought to be configurable to use just about any extension: .cc .cxx
.cpp .C whatever...
Newsgroups: comp.lang.c++
From: ort@netcom.com (David Oertel)
Subject: Re: Death of Borland C++ Compiler
Summary: BC++ works well
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sun, 20 Dec 1992 06:30:24 GMT



>I was a loyal Borland C++ compiler user.  I love the IDE environment 
>(though I only use it for creating the project file) and various tools 
>bundled.  But as my programs are becoming complex (using pointer, pointer 
>to pointer, pointer to pointer to pointer and farmalloc extensively), 
>Borland compiler begins to fall over.  One of my colleagues is also 
>suffering for the same experience when he tried to push the Borland compiler 
>to its limits.

I have to disagree with this.  I've been using BC++ intensively for 1 year
and have found it very robust.  When I started, I had many 'problems' which
resulted from poor style.  I don't want to jump to conclusions, but your
heavy use of indirection may suggest poor encapsulation.  Memory management
should be performed using new/delete, not malloc/free.  If this is your
real problem, there are many good books available to help you correct it.  I've
studied several of the books on the book list that gets posted here
occasionally, and have found each excellent.

hope this helps,
Dave Oertel
ort@netcom.com
-- 
Newsgroups: comp.lang.c++
From: ghica@fig.citib.com (Renato Ghica)
Subject: Standard  Components
Originator: ghica@duck
Organization: Citibank IBISM
Date: Fri, 18 Dec 1992 20:05:35 GMT


Has anyone been able to port Standard COmponents to a DOS
environment ?

e-mail if you have... thanks...
-- 

"I am a brain, Watson."
"These views are my own. / Mail me or Flame me"
Copyright (c) 1992 Renato Ghica / ghica@fig.citib.com
From: rose@claymore.com (Bob Rose)
Newsgroups: comp.lang.c++
Subject: Re: Seeking review of C/C++ debugging tools
Date: 17 Dec 1992 16:15:16 GMT
Organization: Saber Software
Distribution: world
Reply-To: rose@claymore.com
NNTP-Posting-Host: 140.239.1.29

In article 1926@cas.org, jcv26@cas.org (Jon Vander Hill) writes:
>At one time in the recent past, I saw a post that was an 
>independant comparative review of tools like dbx, CodeCenter,
>Purify, Sentinal, and so on.  Of course, now, when that 
>information is needed, I can't find it!  I'd greatly
>appreciate it if some kind soul would forward this (or similar)
>information to me by email.

Just a small correction to this: CodeCenter is the CenterLine C
development environment.  ObjectCenter is our C/C++ development
environment.

Sorry, I don't have the summary handy, but will be happy to
answer any email about ObjectCenter!

Good luck!
---
Bob Rose                    | UI Architecture - Design - Implementation 
CenterLine Software, Inc.   | C++, X Windows/OI
10 Fawcett Street           | rose@centerline.com
Cambridge MA 02138-1110     | Me: 617-498-3245  CenterLine: 617-498-3000

Newsgroups: comp.lang.c++
From: andrew@tagsys.com (Andrew Gideon)
Subject: USL C++ Standard Components - A bug?
Organization: TAG Systems inc.
Date: Sun, 13 Dec 1992 19:51:20 GMT


I have just started working with the USL/C++ Standard
Components for a new client.  Already, I may have found
a very serious problem.  I hope that I'm wrong.

I have been working with the Rogue Wave tools.h++ product for 
quite a while.  One of the first things that I did was
construct deep collections from the RW shallow collections.
It was nice to see that USL had already thought of this
(USL calls deep collections "object collections" and shallow
collections "pointer collections" - some people still publish
implementation {8^).

But in my first set of experiments, I immediately noticed
that something was wrong with the deep sets in USL.  

When insert()ing objects into a deep set, the copy
constructor is used to create new instances.  The object
passed in the insert() method is still owned by the caller
of insert() - the new copy is held by the set.

But when a deep set is destructed, the contained objects are 
NOT destructed.  Further, objects that are remove()ed are also 
not destructed.

I could find no way (w/o unsafe casts) to get around this.  
(And even with unsafe casts, I doubt that it would work)

This seems like a memory leak.  Am I missing something?
Help, please?

	Andrew Gideon




=== 
 -----------------------------------------------------------
| Andrew Gideon              |                              |
| Consultant                 |                              |
|                            |   TAG Systems inc.           |
| Tel: (201) 890-7189        |   D2-181 Long Hill Road      |
| Fax: (201) 890-1581        |   Little Falls, N.J., 07424  |
| andrew@tagsys.com          |                              |
 -----------------------------------------------------------
From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Newsgroups: comp.lang.c++
Subject: Re: Give me safe C++
Date: 16 Dec 92 19:39:00 GMT
	<1992Dec12.145403.26483@ucc.su.OZ.AU>
	<1992Dec14.190553.14838@mole-end.matawan.nj.us>
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.


>>>>> Regarding Re: Give me safe C++; mat@mole-end.matawan.nj.us adds:

    mat> Your high-level tools should be good enough that you'll never
    mat> think of using anything else for a job they can do.  But when
    mat> they can't do the job--or more likely, a small part of the
    mat> job--you shouldn't have to forsake your high-level tools
    mat> entirely as a punishment for once using a down-and-dirty
    mat> approach.

This is exactly the point I was trying to make.
Thanks for stating it so succinctly!
From: garp@isy.liu.se (Johan Garpendahl)
Newsgroups: comp.lang.c++
Subject: Old streams vs iostreams. What's the diff?
Date: 12 Dec 92 18:18:22 GMT
Organization: Dept of EE, University of Linkoping

Hello.

I wonder what the advantage with iostreams are compared to the old streams.

Also, how do I benefit from the fact that iostreams are implemented using 
multiple inheritance?

Are there any articles that I could look for that covers this topic?

	Johan

 
-- 
Johan Garpendahl                   | Email: garp@isy.liu.se
Linkoping University               | Phone: +46 - 13 - 28 13 24
Dept. of Electrical Engineering    | Fax  : +46 - 13 - 13 92 82
S-581 83  LINKOPING // SWEDEN      | May the Source be with you.
From: erc@netcom.com (Eric Smith)
Newsgroups: comp.lang.c++
Subject: Re: Why not nested functions ?
Keywords: nested functions, c++
Date: 16 Dec 92 23:23:09 GMT
Distribution: comp
Organization: Netcom - Online Communication Services (408 241-9760 guest)

In article <KRISS.92Dec16162433@blues.ibp.fr> grosjean@masi.ibp.fr writes:
>My point is that you can *simulate* nested functions using
>a local class. To call the function you call a member function
>of the local class, you explicitely give the syntaxic context 
>you need for the function copying the automatic variables
>you want to use in local class members variables.
>
>In one word : I *do* it, so it can be done.


The most important feature of a nested function is that you can call
it from an unrelated function, which has no knowledge of its context.

I don't see how this can be simulated without adding it as a feature
to the language, but I don't see any real reason for not adding that
feature.  It sure seems like it would make C++ a much more powerful
language, and that a lot of the most complicated code would be neater
and easier to work with.  It also doesn't seem very hard to implement,
using pointers to stack frame descriptors or something like that.

Or is there a way to simulate this feature using objects?  If so, can
someone please explain it clearly or refer us to a clear explanation?
The original poster seems to be describing a way to simulate a very
limited subset of this feature, in which it is necessary for all
functions invoking the nested function to have access to its context,
which sacrifices the biggest advantage of nested functions.
Newsgroups: comp.lang.c++
From: feustel@netcom.com (David Feustel)
Subject: So What About the New IBM C++?
Organization: DAFCO: OS/2 Software Support & Consulting
Distribution: comp
Date: Wed, 16 Dec 1992 01:07:46 GMT

So who's had a chance to evaluate the new IBM C++ compiler for OS/2?
What do you think of it?

-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
The Columbia River is now the most radioactive river in the world.

This environmental/nuclear nightmare, one of a series, brought to you
courtesy of General ("We Bring Good Things to Life") Electric.
Newsgroups: comp.lang.c++
From: stanleyr@kramden.nyu.edu (Rick Stanley)
Subject: Re: Survey: File Extension
Organization: New York University
Date: Sat, 12 Dec 1992 14:53:37 GMT

andy@federation.gatech.edu (Andy Register) writes:

>In article <1gb1h0INNle2@tsavo.hks.com> webb@hks.com writes:
> >I have a survey question for you all:
> >
> >	What extension do you believe is correct for C++ source code?
> >	Is a clear majority winner emerging?  The contenders are: .C, .c
> >	and .cxx. 

>don't forget .cpp for all us borland users.

>Toodles
>Andy

Microsoft C/C++ also uses .cpp extension.  Possibly others use this extension
as well.

Since filenames on DOS systems are not case sensitive, .C doesn't work. I would
vote for either .cxx or .cpp, with preference on the latter.  .cxx seems too
alien to C++.

Cheers!

-------------------------------------+-----------------------------------
Rick Stanley                         | R.S. Consultants  (212) 569-9304
stanleyr@acf14.nyu.edu               | 
Information Technologies Institute   |        C++ & C Language
New York University   NYC, NY  USA   | Programming, Training, Consulting
-------------------------------------+-----------------------------------
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Give me safe C++
Date: 18 Dec 92 13:48:42 GMT
Article-I.D.: alice.24437
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Dec17.192301.23525@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

> 	Next, I feel NO language has addressed the concept
> of coroutines (except possibly Simula?).

Well, there's the C++ task package.

More generally, coroutines require some kind of support for
multiple stacks, which can be a tricky problem in the absence
of garbage collection.  One would therefore expect to find
coroutine support in at least some languages that have
garbage collectors, and indeed there is: Icon and Scheme
come to mind, as well as local extensions in some implementations
of ML.
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: tgimber@mdw.mitre.org (Tedd W Gimber)
Subject: Re: A modest proposal...
Organization: Mitre Corporation, McLean, VA
Date: Fri, 11 Dec 1992 20:49:15 GMT

In article <1992Dec11.172729.20503@newshub.ariel.yorku.ca> cs911461@ariel.yorku.ca (C. Armour-Kidson) writes:
>
>
>comp.lang.c++'ers,
>
>Due to amount of traffic on this group concerning Borland C++ and
>other DOS specific compilers, would it be rude to suggest that 
>such material be moved to another newsgroup, say, comp.lang.c++.borland
>or comp.lang.c++.dos or something?  I can't speak for everyone but
>it's getting hard to find articles specific to C++.
>
>I apologise if I've been beating a dead horse.
>
>
>C. Armour-Kidson
>cs911461@ariel.yorku.ca

This was suggested several months ago, and the final result was that
if you had a comp.lang.c++.borland, you would have to create a 
comp.lang.c++.microsoft and a comp.lang.c++.zortech, and so on.
Given the types of posts we see on the net every day (Help me
program a btree routine for my final!  Hurry, it's due tomorrow!),
I don't think it would help.  I've found that setting up a kill file
with keys like Borland, Turbo, Vison, etc, works well.

Tedd
Newsgroups: comp.lang.c++
From: girod@tele.nokia.fi (Marc Girod)
Subject: Initialization of private static members
Reply-To: marc.girod@ntc.nokia.com
Organization: kpd
Distribution: comp
Date: Tue, 15 Dec 1992 14:59:03 GMT

Hi net world!

------------------------------------------------------------
// stinit.C

class A {
  private:
    A();
    static A a;
};

A A::a; //HP CC v 3.0: error: global scope cannot access A::A(): private  member (1298)
        //
        //GNU C++ version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
        //stinit.C: In function `void  _GLOBAL_$I$_1A$a ()':
        //stinit.C:5: constructor `A::A ()' is private
        //stinit.C:7: in base initialization for class `A'

------------------------------------------------------------

The ARM states p 180 that 'Static members obey the usual member access
rules except that they can be initialized (in file scope)'.

This allows a private static member to be initialized, as long as the
constructor for its class is public.

Are my compilers correct in refusing me the access to private
constructors, to build a private static member?

Sorry if this has already been dealt with...

Best Regards!
--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Virtual base classes
Keywords: virtual, class
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 17 Dec 1992 05:47:47 GMT

rmartin@thor.Rational.COM (Bob Martin) writes:

>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>|	As a rule of thumb, all public inheritance should be made virtual,
>|	private inheritance non-virtual. (See papers by Markku Sakkinen
>|	for a full explanation of why)
>
>I am in some disagreement with the above statement.  Virtual
>inheritance is a necessary evil IMHO.  It hobbles the language in
>several important ways.  It prevents valid downcasting.  (No flames
>please.  I know downcasting is suboptimal, but prior to covariant return
>types it is sometimes necessary).  Also, VI adds some minor
>inefficiencies to virtual dispatch.  The worst aspect of VI, and the
>one which I suspect makes you want to declare all public inheritance
>as virtual, is that it must be used long before you know you need it.
>i.e. In the diagram above, it is B and C which must virtually inherit
>from A, but it is not until you have recognized the need for F that
>you know that virtual inheritance is needed.  
>
>This is really quite sick.  Proper design of a project can alleviate
>this a bit since the design will alert you to the need before you have
>written any of the classes.  But the problem can still occur later if
>you extend the project by creating new classes.
>
>[...] I don't think it is acceptable to proliferate the
>disadvantages of virtual inheritance by making all public inheritance
>virtual.

You have listed three disadvantages.

     1. VI prevents downcasting.

	Well, unless you're willing to brave the flames, we can't really
	discuss this one much ;-) Suffice it to say that I for one don't
	consider this a disadvantage.

     2. VI must used long before you know you need it.

	On the contrary, it is NON-virtual inheritance that causes this
	problem. If you use the "all public inheritance should be virtual"
	rule, then this problem does not occur.

     3. VI is less efficient.
	True. But I wouldn't say that this "hobbles the language".
	The efficiency cost is necessary if classes are to be truly
	open.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Give me safe C++
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 17 Dec 1992 19:56:09 GMT

In article <724462415snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk writes:
>
>One of the drawbacks of C++ is that it is not always (often ?) clear 
>whether a particular line of code is doing something completely pure, or 
>is a nasty hack. My particular pet hate is the use of the same source code
>construct for casts and conversions, but there are many other examples.

	Bjarne hates this too, and has a proposal to fix it.
There will be a different syntax with long winded names for each
type of cast. (If the proposal is accepted)

-- 
;----------------------------------------------------------------------
        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: What is this CFRONT 3.0 warning message trying to tell me?
Organization: TauMetric Corporation
Date: Fri, 18 Dec 1992 17:41:59 GMT

erics@cadkey.com (Eric Smith) writes:

>In article <BzBzL2.5rx@apollo.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
>  ...
>>	    if (this != &rhs) {
>> ...

>Isn't there a problem with this code, since it checks to see if this
>is the same as the right hand side by pointer comparison?  Aren't
>pointer comparisons only defined if they point within the same object
>or array of objects?

>My reading of the ARM (section 5.9) says that this comparison is
>undefined (or rather implementation dependent).  ANSI C (actually, I'm
>looking in the ISO document, I'm not sure if the section numbers are
>the same) has similiar language in 6.3.8 and 6.3.9.

No, read those sections again.  You can compare any two pointers of
compatible type for equality (or inequality).  It is the other
comparisons ( > >= < <= ) which have additional restrictions.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Do temps hurt performance of overloaded +
Date: 17 Dec 92 21:03:57 GMT
Organization: Microsoft Corporation

In article <1gofq7INN8q@golden.kaleida.com> gordie@duts.ccc.amdahl.com writes:
|If I do the following to overload binary + for a class, will temporary
|objects be created? And if so, what can I do to prevent this, to get the best
|performance?
....
|inline Complex operator + (Complex& x, Complex& y)
|{
|	return Complex (x.real + y.real, x.imaginary + y.imaginary);
|} 

This of course is all very implementation dependent, but your approach
works well with my compiler, not only avoiding temporaries, but
actually resulting in compile-time evaluation of your
expressions involving stack variables.

In general where you pass-by-reference you should be passing by
const ref:

inline Complex operator + (const Complex& x, const Complex& y)

to indicate the procedure does not modify those referenced.
Organization: Penn State University
Date: Thu, 17 Dec 1992 11:04:31 EST
From: <GNR100@psuvm.psu.edu>
Newsgroups: comp.lang.c++
Subject: TSRs?

        Can someone help me find info on how to write TSRs in C/C++?
  I understand how they work, as I do how to write them in assembler.
  But I have no idea how to do this in structured code, other than
  writing an .exe type program, but instead of compiling to an .exe file,
  compile to an .asm file and then move the segment around and assemble/link.
                Any ideas?

                               Gordon Rogers
                               gnr100@psuvm.psu.edu


Newsgroups: comp.lang.c++