HDTenEightyP/NetNews huggingface dataset:
From: tpm@ecs (TP Monks)
Newsgroups: comp.lang.c++
Subject: Re: ambiguity in subclass
Date: 18 Dec 92 10:15:04 GMT

Excuse the repost, but I'd really love an answer to this one.
HELP!


>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
From: je@unix.brighton.ac.uk (John English)
Newsgroups: comp.lang.c++
Subject: Re: do variable names in header and source need to match
Date: 14 Dec 92 10:59:05 GMT
Organization: University of Brighton, UK

roger@genie.UUCP (Roger H. Scott) writes:
: 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);
I would say they mean f(3,0), g(3,0) and h(0,3) respectively. The point
at which you can supply defaults (i.e. the first declaration) would be
the point at which you take parameter names. The names in the definition
(not the declaration) of g are ignored.
: 
: 
: 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?
-- 
-------------------------------------------------------------------------------
John English			| Fudd's first law of opposition:
Dept. of Computing		|    If you push something hard enough, it
University of Brighton		|    *will* fall over.
E-mail: je@unix.brighton.ac.uk	| Testlicle's deviant to Fudd's law:
Fax:    0273 642405		|    What goes in, must come out.
-------------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: darcys@fraser.sfu.ca (Darcy Smith)
Subject: Re: Survey: File Extension
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Tue, 15 Dec 1992 02:10:16 GMT

In article <389.412.uupcb@hpbs938.boi.hp.com> mike.quinlan%phant@hpbs938.boi.hp.com (Mike Quinlan)  writes:
>webb>I have a survey question for you all:
>webb>
>webb>   What extension do you believe is correct for C++ source code?
>webb>   Is a clear majority winner emerging?  The contenders are: .C, .c
>webb>   and .cxx.
>
>andy>don't forget .cpp for all us borland users.
>
>    Why not use .c++ for c++ programs?
>---
> * Ever stop to think and forget to start again?            
>                                                                                                                                                   
well mabey 'cause DOS don't support ++ as an extension.
So if your looking for a standard that is not it!

I forget how all of this started - but is it really crucial?

D'Arcy
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: Survey: File Extension
Date: 12 Dec 92 14:21:30 GMT
Article-I.D.: alice.24394
Organization: AT&T Bell Laboratories, Murray Hill NJ



erc@netcom.com (Eric Smith @ Netcom) conjectures:

 > I think ... the name
 > C++ wasn't originally intended to be pronounced "see plus plus", as the
 > ++ operator was originally called the increment operator, and a lot of
 > C programmers considered people who called it "plus plus" to be
 > uneducated.  But that has gradually changed over the years, and now the
 > majority calls C++ "see plus plus" 

C++ was always pronounced C plus plus.
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Survey: File Extension
Organization: Rational
Date: Tue, 15 Dec 1992 13:53:40 GMT

bjoerns@PROBLEM_WITH_INEWS_GATEWAY_FILE (Bjoern Stabell) writes:

>Was .cpp the original C++ extension?

I don't think so.  The first edition of "The C++ Programming language"
in 1986 used the file extension:  ".c".  I think is explains why there
is now such confusion about file extentions.  We werent willing to
have C++ programs use the same extension that our C programs used.

--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: vinoski@ch.apollo.hp.com (Stephen Vinoski)
Newsgroups: comp.lang.c++
Subject: Re: What is this CFRONT 3.0 warning message trying to tell me?
Date: 16 Dec 92 02:43:50 GMT
Organization: Hewlett-Packard Corporation, Chelmsford, MA

In article <1992Dec15.183649.20994@delfin.com> mark@delfin.com writes:
>I'm porting a large application from a CFRONT 2.1-based compiler (Sun) to
>a CFRONT 3.0-based compiler (Solbourne). The following warning message
>has me somewhat mystified:
>
>"main.cc", line 31: warning: temporary used for non-const Thing& argument; no changes will be propagated to actual argument (anachronism)
>
>I've boiled the offending code down to:
>
>#include <string.h>
>#include <malloc.h>
>#include <stdio.h>
>class Thing
>{
>   public:
>
>   char *str;
>   Thing(){ str = (char *)0; };
>   Thing(char *s){str=strdup(s);};
>   Thing &operator = ( Thing & rhs  );
>};
>
>Thing &
>Thing::operator = ( Thing & rhs )
>{
>   if( this->str )free( this->str );
>   strcpy( this->str, rhs.str );
>   return *this;
>}
>
>Thing getThing()
>{
>   Thing t("a thing");
>   return t;
>}
>
>main()
>{
>   Thing t1("");
>   t1 = getThing();             // warning
>   printf("value: %s\n", t1.str );
>
>   Thing t2 = getThing();       // no warning
>   printf("value: %s\n", t2.str );
>}

The warning is mainly caused by the non-const by-reference argument to
Thing::operator=().  For this case, the compiler is generating code
similar to this:

	Thing temp = getThing();
	t1.operator=(temp);

The warning is effectively telling you that any changes that
Thing::operator=() makes to its argument will not affect the value of
the temporary object returned by getThing().

The no warning case is a constructor.  The code

	Thing t2 = getThing();

is in this case exactly equivalent to this invocation of the copy
constructor:

	Thing t2(getThing());

In other words, Thing::operator=() is not invoked.  See the ARM,
section 12.6.1, page 284.

BTW, there are problems with your assignment operator.  What if a
Thing object is assigned to itself?

	Thing t1("oops");
	t1 = t1;

Your assignment operator first frees any memory pointed at by the
Thing::str data member, then copies directly into that freed memory.
For self-assignment, it is also copying from that same freed memory.

To fix all of these problems, you should reimplement the assignment
operator as follows:

	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;
	}

I used free() and strdup() since that is what you used in your char*
constructor, but you could also use new and delete, as you probably
know.

-steve

Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Need help implementic data structures of generic objects
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 19 Dec 1992 19:22:59 GMT

In article <724476558snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk writes:
>In article <1992Dec13.002551.778@informix.com> cshaver@informix.com (Craig Shaver) writes:
>
>> This group seems to be biased against inheritance techniques in all cases.
>
>No, this group merely states that heterogeneous collections (and certain 
>other things) are difficult to implement in statically typed languages 
>like C++, because they are incompatible with static typing.

	Heterogeneity has nothing to do with inheritance.
It is perfectly feasible and only mildly naughty to have collections
of objects selected from a finite set of totally different
predeclared classes.

	The mechanism for this already exists, it is the union.

	union U {A a; B b; C c; };
	U u[20]; // heterogenous collection
	
[ ... ]
>
>This is the major problem with such systems - you end up with hundreds of 
>virtual functions in the base Object, most of which will not be used 
>(indeed, have no meaning) in a particular derived class. It can work, but 
>it is not elegant C++.

	Actually, it CANNOT work without downcasting and RTTI because
the open/closed principle requires that it be possible to CLOSE off
the class 'Object' once and for all.

>
>And as for inheritance, in C++ it is for expressing an "is-a" 
>relationship. Templates are for expressing genericity.

	It can and is (mis-, over-, ab-) used for very much more than
this in C++, in particular, it is used as a convenient form of
composition (inclusion) and also for convenient reuse.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: chris.sokol@factory.com (Chris Sokol) 
Newsgroups: comp.lang.c++
Subject: Who is wrong? me, BC , G
Date: 11 Dec 92 03:15:00 GMT
Distribution: world
Organization: Invention Factory's BBS - New York City, NY - 212-274-8298v.32bis
Reply-To: chris.sokol@factory.com (Chris Sokol) 

48ganelin@cua.edu writes:

>The next small program compiles with GNUC but not with BorlandC 2.0 &3.1
>and not with SGI CC compiler.
>(Of course, linker error with GNUC because += not defined ).

>-------------------cut here ------------------

>class A
>{
>public:
>  A & operator += ( const A & x ) ;
>};

>class B : public A
>{
>public:
>  B & operator += ( const int x ) ;
>};

>void main ()
>{
> B  x , y ;
> x += y ;            //  BorlandC complains here !!!!
>}

>--------------cut here --------------------------
>Because two out of three used compilers refused to compile it I
> expect that standart does not allow to do such thing.

>WHY !!!!!

>I read that every time I should use   " BaseClass & "
>I can always use " DerivedClass& ".

>Is it true ? If yes what is wrong with the above program ?

If you wish to use a method of class B which has been derived from class A by
name, several dos compilers (BC/Zortech) complain if the overloading function
does not take the same number/type of parameters.

The fix is to specify the operator to be used, as in:

A::x += y;

chris.sokol@factory.com
---
 . SLMR 2.1a . Recursive, adj.: see Recursive.
                                                                                                                          
Newsgroups: comp.lang.c++
From: erc@netcom.com (Eric Smith)
Subject: Re: Criticisms Wanted:Callbacks&Runtime methods
Keywords: callbacks C++ Runtime methods
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Sun, 13 Dec 1992 12:12:21 GMT

In article <Bz6MHn.Apw@fiu.edu> feathers@serss0 (Michael Feathers) writes:
>   #system echo __FILE__ __LINE__    // Show people where the processing is now


Actually, echo is a poor example for that, because it could be implemented as
#message __FILE__ __LINE__
or something like that, with no need to worry about operating system or shell
compatibility.
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: IS C++ a language for the "average programmer"
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 16 Dec 1992 14:32:14 GMT

In article <15DEC199210345433@zeus.tamu.edu> sam4628@zeus.tamu.edu writes:

>Yes, but does OO _really_ allow you to tackle a more complex problem?
>Or does it just allow you a new "notation" which is conveniently adapted
>to the more complex type of problems?  I've never heard of a programming
>goal which absolutely required OO to achieve it 

	It is not the programming goals that are so important as
the meta-goals. For example, correctness, development speed
through re-usability etc. To achive these we *do* need better languages
and design techniques.

-- 
;----------------------------------------------------------------------
        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: pauljo@microsoft.com (Paul Johns)
Subject: Re: Do temps hurt performance of overloaded +
Date: 17 Dec 92 21:07:48 GMT
Organization: Microsoft, Redmond WA USA

Whether or not temporaries are created is up the implementation,
provided that the implementation meets the other requirements
of the language.

In your case, you've done about all you can to avoid creation
of temporaries:

	You've made the parameters to Complex::operator +
	references, which will keep copies of the operands
	from being made for pass-by-value.

	You've made the function inline, which allows the
	compiler to optimize away the temporary for the 
	return value if it can.

However, for the statement "c = a + b;" the compiler would have to 
construct a temporary for the return value, then use the assignment 
operator to assign it.  I don't think that the compiler is allowed 
to optimize this away.  (Although since you don't define 
Complex::operator =, some compilers could optimize if you hadn't
provided a copy constructor.  Usually if you provide a copy constructor,
you'll need an assignment operator; in your case, the copy constructor
wasn't really necessary.)

If you'd waited to declare c, then written "Complex c = a + b;", 
the compiler could eliminate the temporary if it wanted to.  
The elimination of temporaries (and their constructor/destructor 
calls) is the main reason for allowing declarations to appear 
anywhere in C++.

As it is now, you'll have constructor calls for c and the temporary,
a call to c's assignment operator, and destructor calls for c and
the temporary.  Changing the assignment to a declaration would
at minimum change the assignment operator call to a copy constructor
call; but it would probably eliminate the assignment operator call
along with the construction and destruction of the temporary.

So, your code would be more efficient if you waited to declare c
until you could initialize it.  This is SOP for C++ anyway, and
good programming practice.

I'm not sure how smart most compilers will be about passing
"a + b" to operator new.  You may have no choice but to use a
temporary here.

Note, however, that in all cases the creation of temporaries
is pretty much comparable to what you'd get for built-in types.

There's one other change I'd make:  pass your parameters in by
const reference rather than plain reference.  Starting in version
2.1, you cannot preform any conversions on parameters that are
passed by plain reference.  That would mean that you could ONLY
pass two Complexes to the operator function--you could not pass
one int or double or anything else.  Also, you could not pass
a const Complex as it is now.  So the prototype would become:

	Complex::operator +(const Complex &x, const Complex &y);

(On the other hand, using a non-const reference means that your
users will have to make type conversions explicit, which might not
be a bad idea when you're seeking efficiency through not creating
temporaries.)

// Paul Johns
Newsgroups: comp.lang.c++
From: 76336.3114@CompuServe.COM (Kevin Dean)
Subject: Private base classes
Date: 13 Dec 92 17:03:15 GMT

I tried to do the following in Borland C++:

class A {};
class B : private A {};
class C1 : public B, public A {};

BC++ naturally warned me about A being both a direct and indirect base
class of C1 and so refused to compile it.  I was able to get around the
problem:

class CA : public A {};
class C2 : public B, public CA {};

My first thought, however, was that the declaration of C1 should have
been allowed.  If A is a private base class of B, no class derived from B
can access A so there should be no ambiguity in accessing members of A
from C1: the only A visible is the direct base class of C1.

This leads to an interesting hole in the C++ programming paradigm.  A
class derived from B has no access to or knowledge of the private portion
of B (I'm ignoring friendship here).  Up until now, I have always believed
that, as long as the public and protected interfaces don't change, I can
do whatever I like with the implementation of B, including changing its
private interface.  If, as I did in this case, I decide that B (and other
related classes) can be better implemented with A as a private base, I
need to know everything about classes derived from B so that I can be sure
that everything will compile.  In other words, I need to have forward
knowledge of all classes that are or could be derived from B.  Similarly,
I need to know more about B than just its public and protected interfaces;
I need to know what its private base classes are before I can reliably use
it as a base class.

Any thoughts?

Kevin Dean

SNAG: acronym for Sensitive New-Age Goof, one who, usually without any
relevant experience, is always willing to enlighten the ignorant masses
on the social issue of the day.  Have you hit any SNAGs lately?
From: matt@physics.berkeley.edu (Matt Austern)
Newsgroups: comp.lang.c++
Subject: Re: Survey: File Extensio
Date: 14 Dec 92 20:59:01
Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
Distribution: world
Reply-To: matt@physics.berkeley.edu
NNTP-Posting-Host: physics.berkeley.edu
In-reply-to: mike.quinlan%phant@hpbs938.boi.hp.com's message of 14 Dec 92 18:18:00 GMT

In article <389.412.uupcb@hpbs938.boi.hp.com> mike.quinlan%phant@hpbs938.boi.hp.com (Mike Quinlan)  writes:

> 
>     Why not use .c++ for c++ programs?

Because, like .C, this is not possible for users of certain operating
systems.

There really isn't much reason that we have to standardize on any one
extension; editors and compilers ought to be able to cope with
whatever the user chooses.
--
Matthew Austern                   Just keep yelling until you attract a
(510) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
matt@physics.berkeley.edu         solutions, become a part of the problem!
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Give me safe C++
Date: 16 Dec 92 17:22:06 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: TIN [version 1.1 + PL8]

Nikki Locke (nikki@trmphrst.demon.co.uk) wrote:
: 
: How about a -safe-c++-only switch to the compiler :-)

What part of C++ is "safe" depends on the users.  Some users never
make mistakes with pointers (I'm not one of them), while others
would like to stay away from for example pointer arithmetic.

A project might have guidelines on these issues, like

"don't use virtual inheritance and/or MI"
"don't use pointer arithmetic"
"always check the result of new for NULL"

If a compiler supported a small script language for such usage constraints,
then it would be easy to automatically check those things.  Violations
should generate warnings.

Even a rather simple script language (perhaps #pragma based), that enables
warning generation for the most commonly regarded "unsafe" features would
IMHO be worth something.

I imagine it would not be excessively difficult to add such support
in a compiler.

-- 
--------------------------------------------------------------------------
| 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: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Public access to private data member
Date: Fri, 11 Dec 1992 18:10:16 GMT
Organization: University of Birmingham

In article <28575.9212111556@louis.ecs.soton.ac.uk>, Stuart Maclean <S.D.Maclean@ecs.soton.ac.uk> writes:
> Hi all, I'm new to C++ and am wading through Lippman's Primer. I am
> puzzled by a certain example. The basis of my query is easily seen
> with some code. Apologies if this is a FAQ.
It is.                    
 
  [ class def'n deleted ]

> void Screen::copy( Screen& s )
> {
>   delete screen;
>   height = s.height;
>   width = s.width;
> 
>   blah blah blah
> }
> 
> My question is;
>   Why are the data members s.height and s.width accessible to copy,
>   even though both height and width are declared private. Is
>   it just because s happens to be of the same class as the target
>   object ??

Yes in C++ classes (not objects) have private members. The reasoning is
that privacy is there to give the class implementor the freedom to
re-implement. This may be a less than totally OO standpoint but
pragmatically it works well.
-- 
    \\   ( )    No Bullshit!     |  Email: B.A.McCauley@bham.ac.uk   
 .  _\\__[oo        from         |  Voice: +44 21 471 3789 (home)
.__/  \\ /\@    /~)  /~[   /\/[  |    Fax: +44 21 625 2175 (work)
.  l___\\      /~~) /~~[  /   [  |  Snail: 197 Harborne Lane,
 # ll  l\\    ~~~~ ~   ~ ~    ~  |         Birmingham, B29 6SS, UK
###LL  LL\\   (Brian McCauley)   |   ICBM: 52.5N 1.9W
Newsgroups: comp.lang.c++