HDTenEightyP/NetNews huggingface dataset:
From: jas@dcs.warwick.ac.uk (Jason Morris)
Subject: Operator Overloading problem
Organization: Department of Computer Science, Warwick University, England
Date: Wed, 16 Dec 1992 19:27:56 GMT


  I have a class, Matrix, and I want to overload the operators +,-,* etc.
Matrix has a private member Data, which is a pointer to some dynamically
allocated storage. Matrix() allocates this storage, and ~Matrix() frees it.
Fine so far.
  Now I want to overload, say, operator+. The problem is that I want to take 
lhs and rhs Matrix arguements, and return the answer in a third Matrix. I
can't pass in a reference to the third Matrix, as operator+ has to take only
two arguements. I can't just pass back a reference to a Matrix declared within
the operator+() function, as it goes out of scope when the function exits.
  So I ended up with:

    friend Matrix operator+(Matrix& lhs,Matrix& rhs);

  And I just do "return <local Matrix>"

  The problem now is that although I'm getting back a copy of the local
variable, not the original (scope is okay), when the operator+ function
returns the destructor is called for the local Matrix, thus deleting the free
store that the data is held in. As my copy has the same value for the pointer
Data, it is now pointing to a useless storage area.

  Question is: How should I be doing this? Surely I don't have to use a
function add(Matrix lhs,Matrix rhs,Matrix answer)? That seems to render the
operator overloading pretty useless.

    Jas.
Newsgroups: comp.lang.c++
From: bjl2k@helga10.acc.Virginia.EDU (Beng-Jit  Lim)
Subject: Re:Borland C++ 3.1 with application and frameworks 
Organization: University of Virginia
Date: Wed, 16 Dec 1992 00:18:10 GMT


			For Sale:
Borland C++ 3.1 with application and frameworks complete with manuals.
Original price is over $600.  I am selling it for $200 (super deal!!).
Call BJ at 804-296-3025 or e-mail to bjl2k@virginia.edu.
From: lanceo@cs.utexas.edu (L. Lance Obermeyer)
Newsgroups: comp.lang.c++
Subject: pointer to methods in g++
Date: 11 Dec 1992 14:01:40 -0600
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: latexo.cs.utexas.edu
Keywords: method, address, gnu, pointer

Hi *

I am having a problem with pointers to methods in g++.

For example,

// bar.h
class bar
{	// ...
	void	myfunc(void (bar::*funcptr) (void*));
	// ...
};

gives me the error message
  "parse error before funcptr"
  "myfunc declared as function returning a function"
  "parse error before )"

But this same code snippet compiles fine under sun CC 2.0.

Is this a gnu bug, or am I missing something?

Thanks,
	Lance	
	lanceo@cs.utexas.edu
From: bab@se39.wg2.waii.com (Brian Button)
Newsgroups: comp.lang.c++
Subject: Re: A modest proposal...
Date: 13 Dec 92 19:04:03 GMT
	<1992Dec12.143432.24959@ucc.su.OZ.AU>
Organization: Western Geophysical Exploration Products
In-reply-to: maxtal@extro.ucc.su.OZ.AU's message of 12 Dec 92 14:34:32 GMT


-->"John" == John MAX Skaller <maxtal@extro.ucc.su.OZ.AU> writes:

John> How about if we started posting C++ questions
John> to comp.std.c++ instead, and left comp.land.c++ for all other
John> issues?

Please don't do this. comp.std.c++ is for posts and questions
regarding the standardization of c++, NOT for general c++ questions.

The net is set up correctly. If a person has a PC programming problem,
they should take to comp.os.msdos.programmer, a Unix problem should be
taken to comp.unix.programmer, etc.

Posters should read the FAQ and bear in mind the charter of a group
before posting to it.

Follow-ups to this should really be posted to news.groups, not
comp.lang.c++. 

bab
--
|-----------------------|----------------------------------------------------|
| Brian Button          | email : button@wg2.waii.com                        |
| Design Engineer       |         71023.276@compuserve.com                   |
| Western Geophysical   | voice : (713)964-6221                              |
| 3600 Briarpark        |----------------------------------------------------|
| Houston, Texas  77042 |                  Opinions Be Mine!!                |
|-----------------------|----------------------------------------------------|
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: portability
Date: 11 Dec 92 22:31:58 GMT
Organization: Microsoft Corporation

In article <719@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
|In article <1992Dec04.235922.12074@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
|>
|>In my experience C++ code is MUCH more portable than C because much of
|>the system-dependency hacks tend to be naturally encapsulated in one
|>class.  So one tends to find the system dependency once in one class,
|>fix it, and then "never" run into that problem again.  In "C" code I
|>tend to find the same system-dependent hack in the code over and over
|>again at different locations or in slightly different forms.
|
|Of course, in well written C the system-dependant stuff should
|be isolated into sub-routines, which are clearly labeled as
|system dependant.			;-)

Such is the difference between theory and practice.  I'm saying in
my experience, in practice, the C++ code proves to be easier to port.
This is because [I believe] that the use of classes leads naturally to
at least some degree of encapsulation and modularity.  C programmers can
and do write code without either.  Its great to talk about portability, 
as long as one realizes that the vast majority of C/C++ code is written
without any attempt at portability.
From: roger@genie.UUCP (Roger H. Scott)
Newsgroups: comp.lang.c++
Subject: Re: do variable names in header and source need to match
Date: 11 Dec 92 04:30:08 GMT
Reply-To: roger@genie.UUCP (Roger H. Scott)
Organization: proCASE Corporation, Santa Clara, CA

In article <1992Dec3.112538.11314@unix.brighton.ac.uk> je@unix.brighton.ac.uk (John English) writes:
>...
>One extension to the language is the ability to use arg names given in
>declarations to identify parameter ordering in calls (like Ada). For example:
>
>   int f (int x = 0, int y = 0, int z = 0);
>   f (10, z:5);   // equivalent to f (10, 0, 5);
>
>Obviously if names aren't given in the declaration, you can't do this.
>If they are, it would seem to make sense to use them somehow!
>This doesn't imply that the names in the definition have to match.

I believe it does.  Consider the following:

extern void f(int a =0, int b =0);
extern void g(int a =0, int b =0);

void g(int b, int a) { // recent C++ disallows default parameter values here
	...
}

void h(int b =0, int a =0) {
	...
}

...
	// what do these mean?
	f(a:3);
	g(a:3);
	h(a:3);


This example shows that you can have a declaration, a declaration and a
definition, or only a definition, for such a function.  If you don't require
the declaration formal parameter names to match those in the definition how
are you going to come up with consistent, unambiguous semantics for the three
calls above?
From: tpm@ecs (TP Monks)
Newsgroups: comp.lang.c++
Subject: ambiguity in subclass
Date: 17 Dec 92 11:21:16 GMT


I've run into a problem where I'm not quite sure how to implement something.

I wanted to implement a set of classes using templates which have a
set of member functions like this:

template<class T> struct bill {
	bill() {}
	T& operator*(T);
	T& operator+(T);
	T& operator-(T);
	T& operator/(T);
}

These are used to implement some arithmetic and other operations on 
small arrays.  I wish to create a well known set of subclasses which
further overload these operations:

struct ted : public bill<float> {	
	ted() {}
	ted& operator*(bogus);
}
struct bogus : public bill<short> {	
	bogus() {}
	bogus& operator*(ted);
}

Of course, this can't be done because, because of ambiguity:
ted t;
ted t1=t*.1;		// error, operator*(float) is hidden
		  
I could get round it by using:
ted t1=t.bill<float>::operator*(.1);	// ok
But lets face it, its just not the same.			 

I could also get round it by adding another member fn to bill and ted
along the lines of:
inline ted& ted::operator*(float a) { return bill<float>::operator*(a);}
I could go further and implement *,+,-,etc using macros but surely this
is clumsy and must be unecessary.

Please tell me if there is something fundamentally wrong with my thinking.
(Please *don't* tell me if I forgot a ; or something!!!)
If there isn't, surely what I am doing is a common problem.  In this
case, what is the best way to solve this problem and implement my classes?

Help!

Tim

--
-----------------------------------------------------------------------------
Tim Monks                                Vision, Speech and Signal Processing
tpm@ecs.soton.ac.uk                                    Southampton University
Tel: +44 (703) 592774                                   Fax: +44 (703) 592895
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Temporaries
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 15 Dec 1992 14:34:06 GMT

In article <1992Dec6.204110.3073@news.cs.brandeis.edu> dernis@binah.cc.brandeis.edu writes:
>Hi,
> Could someone explain how temporaries are identified and handled?

	A class with properly defined constructors and destructors will
be handled 'just like an int'.

>If an overloaded operator produces a temporary(by declaring a new variable)
>to hold the result of an arithemetic op how is it destroyed?  

	Wrong question. Right question: *When* is it destroyed?
	Answer: it is implementation defined, the upcoming standard
	ought to have more words on this, however.

>What if the
>operator returns a pointer to it?  Is the compiler smart enough not to destroy
>it?  

	Same as if the object was an int. Return a pointer to an object
on the stack, the pointer dangles. Return a pointer to a heap object,
its up to you to delete it. Best to return a copy of the object,
then the compiler deletes it.

>
>If it an object with an array type allocated dynamically, the destructor will 
>have to include a delete statement to get rid of the array, right?  If info is 
>passed by reference then two objects will share the same array, if one of the 
>objects is destroyed what happens to the array?  

	It is deleted, just like you told the system to delete it.
The other reference is trash. Same as for int.
>
>I would appreciate an answer on the net, either a response or FAQ list 
>(how do you access the FAQ list?).  I am out of money after buying the
>computer, compiler, and Lippman's book C++ Primer.  Does he discuss
>this?  I couldn't find it, but I haven't really looked through it
>thoroughly?

	None of these issues really differ from the same questions
in C. All that differs is that you can now make new types
that act like 'int'.

	While there are other techniques, using this idiom
is a good was to start off. See Coplien for explict details of how to
write classes using the Orthodox Idiom.

-- 
;----------------------------------------------------------------------
        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: jimad@microsoft.com (Jim Adcock)
Subject: Re: IS C++ a language for the "average programmer"
Date: 14 Dec 92 22:09:24 GMT
Organization: Microsoft Corporation

In article <1992Dec12.234407.15044@ennews.eas.asu.edu> gopi@enuxha.eas.asu.edu (Bulusu Gopi Kumar) writes:

|I have been following a lot of articles on this group for sometime now.
|There seems to be a lot of confusion on a large number of topics in c++
|among the programmers! Is this because of the fact that c++ is a relatively
|new language ? Is it because c++ is becoming more and more complex by the
|addition of features like "TEMPLATES". Infact even after 2 years of reading
|and reading (though without much of project experience) I often get confused
|with some combinations of c++ features.Is it that "complex" projects can be
|handled by only complex languages ? Any takers for this question ? 

First, note that most languages are much more complicated than most 
programmers realize.  Most "C" programmers don't know C, don't know
they don't know C, and don't care that they don't know what they don't know.
Partially this is because good printed reference documentation on most
languages have been very hard to come by.  How many "C" programmers have
a copy of the ANSI-C standard, for example?  Fortunately Bjarne did a 
pretty good job early on of documenting C++, and C++ programmers are 
knowledgable enough to *want* to learn the language, such that a very
large number of C++ programmers keep a copy of the ARM close at hand.
You can't buy a copy of the ANSI-C standard at your local computer book
store!

Secondly, note that not every programmer on a project needs to know
the whole C++ language.  Most "average sized" [?] projects can get away
with one "guru" who handles the nasty bits such as MI, templated classes,
exceptions architecture, etc, as the need arises.  If the average programmer
understands SI, OOP, virtual functions, etc, they have what in practice they
need to know.

Finally, realize that much of the conversations on comp.lang.c++ is just 
intellectual game playing between "language lawyers" pushing the 
three sigma envelope of the language.  Such games are fun for learning
and clarify the edges of the language, but don't mean much towards shipping
product.  C++ is not a goal in itself, but rather a tool to be used in
achieving other, meaningful, goals.
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: & of inline functions
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 18 Dec 1992 13:51:47 GMT

dgrammel@dgrammel.mentorg.com (Dave Grammel) writes:

>x9999bvj@maple.circa.ufl.edu writes:
>|> 
>|> What is the official method for handling taking the address of an inline
>|> function?

It's exactly the same as taking the address of non-inline functions.

>Don't make it inline.

Dave Grammel is wrong here. Go ahead and make it inline.

-- 
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: Ulrich.Breymann%p17.f2002.n241.z2@fidonet.org (Ulrich Breymann)
Newsgroups: comp.lang.c++
Subject: Date -> Day of week conversion
Date: 14 Dec 92 15:57:00 GMT
Article-I.D.: fast.724698107.AA07504

hello Ijaz,
try this :

// dow (day of week) computes weekday in the range 14.9.1752..31.12.2399
// So=0  Mo=1... Sa =6
int dow(int d,int m, int y)      // day month year
{
  return (3*y-7*(y+(m+9)/12)/4+23*m/9+d+3
         -((y-(m<3))/100+1)*3/4)%7;
}

bye ! Uli
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Virtual base classes
Reply-To: nikki@trmphrst.demon.co.uk
To: kotula@camax.com
Date: Tue, 08 Dec 92 19:24:41  GMT
Organization: Trumphurst Ltd.

In article <1992Dec2.163139.8326@camax.com> you write:
> Me and this other guy (who shall remain nameless) have been trying to
> figure out the appropriate use for virtual base classes.  Given the
> following inheritance hierarchy:
> 
> 	A
>        / \
>        B C
>        | |
>        D E
>        \/
> 	F
> 
> where we only want one copy of A, which set of inheritances should be
> virtual?
> 
>     1) A to B  and  A to C
> 			   or
>     2) D to F  and  E to F
> 
> I suspect that either will work, but which is best, and why?
Only 1 will work.

> My understanding is that the semantics of diamond inheritance is an inherent
> problem in OO techniques.  At the moment I'm more concerned about
> pragmatics, though.  For instance:
> 
>     1) Are most implementations of virtual base classes reliable?
No.

>     2) What compilers are not reliable in this respect?
To my knowledge, Zortech C++ 3.0r4 and Borland C++ 3.0. I have heard that 
at least one cfront based compiler also has problems.

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

From nikki@trmphrst.demon.co.uk  Thu Dec 10 12:58:16 1992
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Virtual base classes
Reply-To: nikki@trmphrst.demon.co.uk
X-Mailer: cppnews $Revision: 1.30 $
Date: Wed, 09 Dec 92 19:22:15  GMT
Organization: Trumphurst Ltd.

In article <9212082108.AA25407@kotula.SGI> you write:
> > >     1) Are most implementations of virtual base classes reliable?
> > No.
> 
> Do you know if the errors are at compile-time or run-time?  What are
> some of the manifestations?
Borland gives errors at compile time for the following ...

class base {
public:
	virtual void abstract() = 0;
	};

class d1 : virtual public base {
public:
	virtual void abstract() { }
	};

class d2 : virtual public base {
	};

class d3 : public d1, public d2 {
	};

d3 Ad3;		// Borland thinks this is an abstract class. I don't.

Zortech gives runtime errors (i.e. sometimes crashes horribly) with 
similar code (but which does some real work). This is caused by the thunk 
which adjusts the offset to the this pointer getting the adjustment 
wrong.

I don't know about cfront, I can't afford it :-)

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




Markku Sakkinen also forwarded several interesting papers he's written on
the general subjects of problems with multiple inheritance.


-- 
-------------------------------------------------------------------------------
jeff                |   The doctors say there's a 50-50 chance that he'll
kotula@camax.com    |   live...although there's only a 10 percent chance of
Camax Systems, Inc. |	that.
From: larsn@Autodesk.COM (Lars Nyman)
Newsgroups: comp.lang.c++
Subject: Re: What is this CFRONT 3.0 warning message trying to tell me?
Date: 18 Dec 92 21:21:03 GMT
Organization: Autodesk Inc., Sausalito CA, USA

erics@cadkey.com (Eric Smith) writes:
| In article <BzBzL2.5rx@apollo.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
| |	Thing &
| |	Thing::operator=(
| |	    const Thing &rhs	// note the addition of const here
| |	)
| |	{
| |	    if (this != &rhs) {
| |		if (str != 0) {
| |		    free(str);
| |		}
| |		s = strdup(rhs.str);
| |	    }
| |	    return *this;
| |	}
| 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.

I reach the same conclusion reading ARM...

... that this commonly suggested convention of avoiding problems w/ 
assignment to "the same object" is implementation dependent (and 
thus rather useless).

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: Tue, 15 Dec 1992 13:47:13 GMT

In article <WARSAW.92Dec12174137@anthem.nlm.nih.gov> warsaw@nlm.nih.gov (Barry A. Warsaw) writes:
>
>>>>>> "John" == John MAX Skaller <maxtal@extro.ucc.su.OZ.AU> writes:
>
>    John> 	While tending to support your liking of the C++ 'hybrid'
>    John> approach, I'm not so sure about 'seamlessly', are you?
>
>I think it is rather seamless in the sense that I can solve problems
>(or typically, subproblems of a larger, integrated system) using a
>functional, ADT, and/or OOP approach, and I can develop all these
>parts in a single language.  Everything doesn't have to be a class in
>C++ and not all classes have to use inheritance and polymorphism. My
>only point was that I don't have to jump through hoops to solve a
>problem using these different abstraction levels.  Maybe we're talking
>about different things when we say "seamless"?

	No, I agree in principle and practice with you. 
But there continue to be annoying problems. An example:
I want an abstract base class X with an operation f that returns
an X, so I can provide some implementation

	class Y : X { .. Y f(); .. }

where f is virtual. But I cant.
How do I declare X::f? If I use

	X X::f()

it is illegal, due to different return types. If I use a reference

	X& X::f();
	X& Y::f();

it is fine syntactically, but C++ has no garbage collection,
so if in Y::f is have

	.. return new Y;

then the object gets lost in an expression and cant be deleted.
This problem doesnt arise in Eiffel, *because* it has garbage
collection.

In C++ you can sort of work around this, but only be introducing
another layer of classes that act as references to the real objects.
But thats not seamless integration, I have to rework ALL my code
to accommodate this design change.

This explains why good vendor libraries that do this sort of
work for you are incompatible, (and are thus also 'bad')
they use different techniques
for repressenting classes .. because the base language itself
is not adequate.

(Adding GC solves some of these problems, but many remain.
There is probably no general solution, of course.
At least on smaller projects these issues tend not to arise,
however. Large scale integration is a different class of
problem I think.)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: x9999bvj@maple.circa.ufl.edu
Newsgroups: comp.lang.c++
Subject: Static vars in member functions
Date: 13 Dec 92 18:55:40 GMT
Reply-To: X9999BVJ@oak.circa.ufl.edu
Organization: Center for Instructional and Research Computing Activities


When calling a function of a class with a static variable declared in it,
what is the standardized behaviour for that variable?

E.g.

class Foo
{
   public:
      void Blah( void );
};

void Foo::Blah( void )
{
static int i;

   i++;
};

void main( void )
{
Foo a, b;

   a.Blah();
   b.Blah();
   a.Blah();
}

When the second "a.Blah()" is executed, will i be 2 or 3?

Brian
From: cs911461@ariel.yorku.ca (C. Armour-Kidson)
Newsgroups: comp.lang.c++
Subject: Re: A modest proposal...
Date: 14 Dec 92 21:45:48 GMT
Organization: York University, Toronto, Canada
Originator: cs911461@a01.ariel.yorku.ca



Thanks to all who expressed an opinion to my original 
post.  I have discovered to my delight that a kill
file works nicely so I don't have to read all that 
Borland stuff  ;-)

It's true.  Splitting would be a bad idea.


cak
Newsgroups: comp.lang.c++
From: esova@magnus.acs.ohio-state.edu (Edward R Sova)
Subject: Re: Zortech C++ v3.1
Organization: The Ohio State University
Distribution: usa
Date: Wed, 16 Dec 1992 17:40:12 GMT

>Are you saying that Symantec is shipping a 32-bit c compiler that can't debug
>its own generated code? I find this hard to believe. If its true I'll be
>returning Zortech 3.1 that I just ordered ASAP!!
>
>|> >I'd appreciate a Semantic response.
>|> 
>|> I don't work for Symantec.  I work for FlashTek who supplied the DOS 
>|> extender DOSX, debugger (ZDB) and FG to Symantec.
>
>What is 'FG' ?
>
>-- 
FG I believe is Flash Graphics, a contemporary of BGI.

  ___
  \  \      Mr. Ed on rollerblades?  Nah, that's:
  _\  \      esova@magnus.acs.ohio-state.edu       Prodigy:CBGX09A
 \_____\       but his friends call him Ed,
 o o o o                    yeah that Ed Sova Kid, he answers to anything.

Newsgroups: comp.lang.c++