HDTenEightyP/NetNews huggingface dataset:
From: John Matthews <jm@vcd.hp.com>
Subject: Default assignment semantics
Organization: Hewlett-Packard
X-Useragent: Nuntius v1.1a5
Date: Mon, 14 Sep 1992 02:57:55 GMT

As I understand it, if a class does not have an explicitly defined
assignment operator, a default assignment operator is generated
by the compiler. This default operator simply does a member-wise
assignment. As has been pointed out many times, these semantics
are dangerous for classes that have pointers to dynamically created
objects as fields.

It seems to me that a more robust default assignment operator would
have the following semantics:

  1) Invoke the destructor of the object being assigned to.
  2) Invoke the copy constructor on the object being assigned
      to, taking as an argument the object being assigned from.

In the case where a class has no user defined destructor or copy
constructor, the above semantics devolves to member-wise
assignment, just as before. However, for classes that have
user defined destructors and copy constructors, (as all classes
that have pointers to dynamic objects should) the above
semantics generates code that is much safer. Take for example a
String class, whose constructor allocates a character buffer for
a string, and whose destructor frees that buffer. The user-defined
copy constructor would construct its String object with a separately
allocated character buffer of the same size as its String argument,
and perform a string copy between the two character buffers.

Under the current default assignment operator semantics, for every  
String assignment made, a character buffer is 'leaked', and two
pointers to the same buffer are made.  Under the above semantics,
however, the assignee String first has its buffer deallocated, and
then recieves a new buffer from the copy constructor, just like you
would expect.

Since this is not the semantics of the current assignment operator,
a user defined assignment operator needs to be defined whenever
a user defined destructor or copy constructor exists for a class.
Thus what I want to do in most of my assignment operators is
explicitly invoke the corresponding destructor and copy constructor.

I know how to explicitly call a destructor on an object, but how do
you explicitly call a copy constructor on what used to be an object?
The only way I know of to do this is to overload operator new() with a
pointer argument. The overloaded new() operator would just return
the pointer. I could then write an assignment operator like the following
for any class X:

        X& X::operator=( const X& from )
        {
                  this->~X();                                   // invoke
destructor.
                  new(this) X(from);                       // invoke copy
constructor.
                  return( *this );
        }

However overloading new seems a little kludgy when all I want to
do is call a constructor on a specific object reference.

Please reply via this notes group, I don't currently have access to an
email server.

Thanks,
John Matthews
Hewlett-Packard
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Newsgroups: comp.lang.c++
Subject: Re: Need Help on trivial issue
Date: 13 Sep 92 17:33:08 GMT
Organization: Computer Science, University of Melbourne, Australia

gtj@goanna.cs.rmit.oz.au (Glenn T Jayaputera) writes:

>Hi, I need help on the following program.  The problem I have is if I
>input the value > 1.1 the string "Yahooo....." is only printed once.
>I dont Understand why n==of only for a value of 0.5 not 1.0, 1.5, 2.0, etc.
>
>Can somebody please pointed out which part I am missing.
>
>#include <iostream.h>
>
>main()  {
>  double x;
>  double n=0.1, of=0.5;
>
>  cout << "Input x : "; cin >> x;
>
>  while (n<x)  {
>    n += 0.1;
>    if (n==of)  {
>      cout << "Yahooooo...\n";
>      of +=0.5;
>    }
>  }
>}

The problem is caused by rounding errors. n will have a value like
	0.9999999999999999999
and the test "if (n == 1.0)" will fail.

Because of this problem, you should almost never use equality tests between
floating point numbers, and a good compiler would warn you when you do.
Instead you should rephrase the test as
	const double tolerance = 1.0E-6;
	...
	if (fabs(n-of) < tolerance) {		// absolute difference less
						// than tolerance
or
	if (fabs(n-of) / fabs(of) < tolerance) {
						// relative difference less
						// than tolerance

Read any good book on numerical computation.

-- 
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!
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: Subscripting with multiple arguments
Date: 16 Sep 92 06:05:14 GMT
Article-I.D.: arolla.TMB.92Sep16020514
	<MATT.92Sep14161955@physics.berkeley.edu>
	<TMB.92Sep15134433@arolla.idiap.ch> <jac.716576376@moonshine>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: jac@moonshine.llnl.gov's message of 15 Sep 92 16:59:36 GMT

In article <jac.716576376@moonshine> jac@moonshine.llnl.gov (James A. Crotinger) writes:

   tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
   > What you can do, however, is to share a lot of code among the
   > different array classes. For example, you might have your
   > multidimensional array inherit from your 1D array.

     Not publicly, I hope. There is no "is a" relationship in that
   direction. (Well, you can say that a 2D array of floats is a 1D array
   of 1D arrays of floats, but that's not the same as inheritance since
   the types of the 2D and "outer" 1D arrays are different.)  In one of
   our class libraries we did implement "Vector" (1D array) as inheriting
   from "Matrix" (2D array). This makes sense since a Vector is just a
   Matrix with only 1 column. Thus you can safely pass a Vector to any
   function which operates on Matrices, etc. You would not want to try to
   do the reverse.

Actually, an n-dimensional array "is a" concatenation of n-1
dimensional arrays, quite naturally, so public inheritance does make
sense. For reasons of efficiency, it may still be better to have a
specialized class unrelated to all the others for each dimensionality.

The case of vectors and matrices is very different from the case of
arrays, since there is a lot of additional structure. In fact, I don't
think there is a single clean way to express the relationship between
vectors and matrices within the OO paradigm, since these relationships
don't form a taxonomy. Sometimes, it makes sense to view a vector as a
one-column (or one-row) matrix, while at other times, it makes sense
to view an N x M matrix as an NM dimensional vector.

In such cases where different taxonomies are plausible, it is usually
best not to use any taxonomy and rely on explicity conversion
functions. So, I think Vector should not inherit from Matrix, and
Matrix should not inherit from Vector.

					Thomas.
Newsgroups: comp.lang.c++
From: klb@stiatl.salestech.com (Kathy Ball)
Newsgroups: comp.lang.c++
Subject: Re: Booch notation in PC CASE tools
Date: 10 Sep 92 13:10:44 GMT
Organization: Sales Technologies, Inc.

KOCHER@141.58.123.1 (HARTMUT KOCHER) writes:

>In the product news section of the latest "C++ Report" I found 
>two PC-based CASE tools that support the Booch notation. 
>The first company mentioned is Popkin Software and Systems 
>Inc. and their product is called "System Architect". The second 
>product is "Object System/Designer" from Palladio Software.
>Can someone provide the addresses, fax numbers, or email 
>addresses of the companies?
>Has anyone any experience with those products he'd like to 
>share or can someone provide more information? Which one 
>would you prefer?


I just purchased a copy of Booch's book, and it came with an
offer for more information about a program that supports
the Booch notation.  The program is produced by Rational, which
is where Grady Booch is the Director of Software Engineering Programs.
I've sent for the information, but I'm interested in other 
more objective opinions, if anyone has any.

Just another option.

Kathy.
__

-- 
Kathy Ball                                             uupsi!stiatl!klb
Sales Technologies, Inc	                              klb@salestech.com
3399 Peachtree Rd, NE
Atlanta, GA  30326                               voice:  (404) 841-4159
From: RICHARD@CLYDE.ttt.kth.se
Newsgroups: comp.lang.c++
Subject: HELP: aggregate type question.
Date: 7 Sep 92 20:02:03 GMT
Organization: Department of TeleTransmission Theory


I try to make a struct by inheriting from two other classes:


struct Sequence {
	Sequence () {}
};

struct List : public Sequence {
	List () {}
};

struct Symbol {
	virtual int X();
};

struct Null : public Symbol, public List
{
	virtual int X();
};

I compile with GCC 2.2.2, and it gives me the following error message:

	`List' fails to be an aggregate typedef.

on the line which starts with "struct Null".

First of all, I have no idea for now what an "aggregate typedef" is. Knowing
would help a lot. No, I have not the ARM handy...

So please, tell me what I am doing wrong here...

--
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++!
! Richard Levitte, System manager       ! tel: int+46-8-790 64 23           !
! Royal Institute of Technology         ! fax: int+46-8-791 76 54           !
! Department of Teletransmition Theory  ! Internet: richard@ttt.kth.se      !
! S-100 44 Stockholm, Sweden            !                                   !
!---------------------------------------------------------------------------!
From: eric@tfs.com (Eric Smith)
Subject: Re: Answers on a postcard...
Organization: TFS
Date: Sun, 13 Sep 1992 20:45:00 GMT

In article <1992Sep13.160033.7735@taumet.com> steve@taumet.com (Steve Clamage) writes:
...
>It would be possible to change the rules so that order of evaluation
>was preserved for overloaded versions of operators "&&", "||", and ",".
>Any proposal to do so would have to show some good reason why the

Why not just require all function arguments to always be evaluated left
to right?  That would simplify the language, shorten its description,
make it easier for novices to learn, and would not break any existing
bug-free code.  I never did understand the value of leaving such
questions open, which accomplishes nothing useful and makes bugs
behave differently with different compilers.
From: gordie@duts.ccc.amdahl.com (Gordie Freedman)
Newsgroups: comp.lang.c++
Subject: Re: Question on Borland C++ and new
Date: 10 Sep 92 00:36:22 GMT
Reply-To: gordie@duts.ccc.amdahl.com
Organization: Happy hacker bait and tackle shop

Thanks to all who replied to me about this. I tried the large memory model and also changed some memory allocation to break up a large chunk (possibly > 64k) into 
smaller chunks and everything works.

---
Gordie Freedman: gordie@kaleida.com Sigs are for kids
From: aldavi01@romulus.spd.louisville.edu (Arlie Davis)
Newsgroups: comp.lang.c++
Subject: Re: Answers on a postcard...
Date: 14 Sep 92 16:52:41 GMT
Organization: University of Louisville

In <1992Sep13.204500.16311@tfs.com> eric@tfs.com (Eric Smith) writes:

> In article <1992Sep13.160033.7735@taumet.com> steve@taumet.com (Steve Clamage) writes:
> ...
> >It would be possible to change the rules so that order of evaluation
> >was preserved for overloaded versions of operators "&&", "||", and ",".
> >Any proposal to do so would have to show some good reason why the

> Why not just require all function arguments to always be evaluated left
> to right?  That would simplify the language, shorten its description,
> make it easier for novices to learn, and would not break any existing
> bug-free code.  I never did understand the value of leaving such
> questions open, which accomplishes nothing useful and makes bugs
> behave differently with different compilers.

NO.  From what I understand, the things in the ANSI C standard and in
the ARM that are left undefined are done so to allow different
architectures to compile and run C in the fastest / best manner
possible, while still conforming to the standard.

If you require / define something, such as the sequence of evaluation
for parameters of a function call, you potentially require some
compiler X for some machine Y to go to extremes in order to remain
conformant with the standard.  With the problem above, you might have
one environment in which function calls were fastest when the
first parameters were pushed first, but on another machine with a
completely different environment pushing the last parameters first
makes the most sense.  (I have never heard of an environment which
evaluates / pushes function args in forward order, but who knows.)
On some architectures, function arguments may be evaluated
simultaneously!

So, if you rigidly define the sequence of evaluation, you potentially
wound many C compilers + architectures.  Same goes for many other
things that are marked "undefined" or "architecture dependent".
(I remember a debate on the remainder operator, in which some people
wanted to define the result of the remainder operator for negative
operands.  Someone pointed out that the native assembler instruction
for remainder varies from architecture to architecture, and that
requiring all C compilers to return the same value for negative
operands for remainder would mean that *many* compilers would have to
generate many more opcodes in order to satisfy the standard.)

Even if all the architectures that we *ever* used did everything in
the same way ( ;) ), I would still want some of the things in ANSI C
/ the ARM left undefined, because relying on them encourages poor
programming practice, in my opinion.  Example: Using post-increment
on the same variable twice in the same expression.


-- 
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null
From: hwrvo@kato.lahabra.chevron.com (W.R. Volz)
Newsgroups: comp.lang.c++
Subject: Re: malloc or new in c++
Date: 9 Sep 92 16:45:26 GMT
Organization: Chevron Oil Field Research Company

In article <gate.8NagqB1w165w@toz.buffalo.ny.us>, cyberman@toz.buffalo.ny.us (Cyberman) writes:
|> 
|>      -=> Chuang He spoke of "malloc or new in c++" <=-
|>     To All at 08-31-92  19:44
|>  The FAQ states NOT to use malloc in C++ programs it's thier only
|>  for backwards compatibility [ie compile older files on a C++
|>  compilor].
|> 
|> Yes use ALL new and delete statements and eliminate all malloc
|> and free function calls!  This will more than likely solve at
|> least 1 potential problem.
|> 

Let me get this straight: Are you saying that there is a problem of using
malloc in a c++ program? I realize that if I malloc some memory, then
I need to free it with free(). And if a create a new object with new, then I
delete with delete. I wouldn't 'free' an object allocated with 'new' and 
'delete' an object allocated with 'malloc'. But if there is an incompatibility 
in c++ between (malloc,free) and (new,delete), I don't know how one can mix
any program that uses both allocatation schemes. This would seem to indicate
that all existing code would have to be rewritten. It this true. If so, it
could just spell the death of c++. The c code base is just too large.

-- 

======================
Bill Volz
Chevron Oil Field Research Co.
Exploration Research/Geophysics Division.
P.O. Box 446, La Habra, CA 90633-0446
Phone: (310) 694-9340
Newsgroups: comp.lang.c++
From: krauskop@en.ecn.purdue.edu (Curtis D Krauskopf)
Newsgroups: comp.lang.c++
Subject: Re: FULL HOUSE
Date: 13 Sep 92 20:29:50 GMT
Organization: Purdue University Engineering Computer Network

The method you have chosen measures the accuracy of your random number
generator.  To get a real answer for the probability of a full house,
you will need to modify the program so that it evaluates all 52C5
possible hands.  

Obviously, you won't want to do that (unless you have a Cray handy for
a couple hours!).  So the next best thing is to notice that any hand
with three different cards can not be a full house and design the
algorithm to skip situations where you have ABCCC, CABCC, CCABC and
CCCAB.  You can even refine it further with a little creativity.

Curtis
From: patrice@cs.concordia.ca (SCATTOLIN patrice)
Newsgroups: comp.lang.c++
Subject: BC++ 3.1 BUG: getting an UNREACHABLE CODE WARNING!
Date: 5 Sep 92 20:27:57 GMT
Organization: Computer Science, Concordia University, Montreal, Quebec


I am using BC++ 3.1 and I get  compilation  warnings:
one of which is:


     WARNING: UNREACHABLE CODE in the following code at the next to last line:


		  tek_complex newcomplex(1,1);
		  SIGNALRANGE i;
		   cout <<"GAZOU\n";
		   getch();



However the program exeutes the statement that it claims is unreachable
"cout<<"GAZOU\n"



The warning will disapear when I comment the following code:


	  friend ostream& operator<<(ostream& os, signal_buffer<sig>& a)
      	 {
          		SIGNALRANGE i;
   	           for (i=a.strt;i<a.end;i++)
	                os << a.dv[i];
	           return os;
             }


This piece of code belongs to a templace declaring signal_buffer in a .h. 
If anyone can provide an answer please tell me. It's an annoying 
warning because it's wrong and you chase it down and can't do 
anything about it!.

Thanks




-- 
Patrice Scattolin
					patrice@cs.concordia.ca
Concordia University			Montreal, Canada
"I am so far north that Santa lives two blocks from me"
Newsgroups: comp.lang.c++
From: larner@atd.mke.ab.com (Dan Larner)
Subject: return type CObject*&
Reply-To: larner@atd.mke.ab.com
Organization: Allen Bradley Co.
Date: Tue, 15 Sep 1992 20:52:31 GMT

I've just begun to use Microsoft's foundation class libraries
and have come across many member functions that are declared 
with a CObject*& return type ( e.g. CObject*& GetHead(); )
I think it has to do with assignment to function call results,
but could someone please clarify the meaning and intended use
of the *&   ?

---

grep technokicks *.*  | more  +++++++++++++++++++++++++++++++
                                                             |
Dan Larner              larner@atd.mke.ab.com                |
                                                             |
Allen Bradley Co.       (414) 382-4096                       |
All opinions expressed are solely my own, not my employer's. |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.lang.c++
Date: Mon, 14 Sep 1992 15:00:44 -0400 
From: Stefan Monnier <sm86+@andrew.cmu.edu>
Subject: Re: Virtual methods
	<1992Sep14.145950.7661@us-es.sel.de>

Excerpts from netnews.comp.lang.c++: 14-Sep-92 Virtual methods
Dalton@us-es.sel.de (664)
> This reminds me of a question which I've been meaning to ask for some
> time now. Ignoring performance issues, why would one not declare every
> method in a class virtual? What circumstances might preclude its use?

> -- 
> Brendan J. Dalton (brendan@us-es.sel.de)
> ----------------------------------------
> Ritheann an fear seo ar phoitin


You've got it: performance issue !
(well, there could be some other issues: arrange so that future
subclasses can't change that method (protection). But is it
really useful ?)
BTW: Gcc has a commandline option which declares all methods 
as virtual !  OOP is just so much less powerful without virtuality !


	Stefan Monnier

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------





Newsgroups: comp.lang.c++
From: car@access.digex.com (Mr. Blue)
Subject: Reference as a return type
Organization: Express Access Online Communications, Greenbelt, MD USA
Date: Mon, 7 Sep 1992 18:53:50 GMT


I'm probably asking a question that belongs in FAQ, (and if there
is such a list of question for this newsgroup I'd be grateful if someone
emailed it to me)

Anyway my question is this: Whats the difference between returning a
pointer to a class and a reference to a class from a member function??
I mean a reference is just a pointer, isn't it? However I get the feeling
that the semantics are very different, i.e. copy constructors are called,
etc. Can someone tell me what happens on the run time stack to contrast
the 2 cases? I know this is probably a naieve question,but I'm still
learning so forgive me.

Thanks,
Chris

Newsgroups: comp.lang.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: zero-length datatype
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Distribution: comp
Date: Mon, 14 Sep 92 15:26:27 GMT

In article <BuFx0t.IFA@intime.intime.COM> scottm@intime.intime.COM (Scott  
Michel) writes:
> However, it's clear that the reason why C++ doesn't allow one to have
> a zero length object is that all instances of objects must be unique.

An empty object has no state. You are not necessary to distinguish one 
empty object from the other. If a class can instantiate distinguished 
objects, it must be a non-empty class.

> This is a Reasonable Thing, otherwise you'd end up with real confusion
> in the language as to whether or not an object is really a stand-in or
> alias for another, and whether or not the object exists in the first
> place. 

Since you are not neccessary to distinguish non-state objects, you are 
not neccessary to distinguish whether a non-state object is a stand-in 
or alias. With zero-length assumption, you can still use object address 
in implementation to judge whether such an object exists (newed with 
initialization). But again, you can not, nor need, using object address 
to ditinguish them from one to other.

> Is one zero-length object itself or a meta object for another?

C++ has not meta-object. If an object has an ditinguishable meta object, 
it does have states.
 
> According to Aristotle's theory of classes (and his philosophy as a whole)
> you'd force yourself into a situation where something can be itself and
> not itself similtaneously. 

In fact, an empty class only has a single object instance. Therefore, 
when I say we need not distinguish non-state objects, they are still
distinguishable. It does not violate Aritotle's class thoery.  We 
should distinguish the storage that holds the object and the object 
itself. We cannot distinguish non-state object through its storage, 
since it occupies no storage.

David Shang
From: gtj@goanna.cs.rmit.oz.au (Glenn T Jayaputera)
Newsgroups: comp.lang.c++
Subject: Need Help on trivial issue
Date: 13 Sep 92 12:23:56 GMT
Organization: RMIT Department of Computer Science

Hi, I need help on the following program.  The problem I have is if I
input the value > 1.1 the string "Yahooo....." is only printed once.
I dont Understand why n==of only for a value of 0.5 not 1.0, 1.5, 2.0, etc.

Can somebody please pointed out which part I am missing.

#include <iostream.h>

main()  {
  double x;
  double n=0.1, of=0.5;

  cout << "Input x : "; cin >> x;

  while (n<x)  {
    n += 0.1;
    if (n==of)  {
      cout << "Yahooooo...\n";
      of +=0.5;
    }
  }
}

Thanks in advance
Glenn Jayaputera