HDTenEightyP/NetNews huggingface dataset:
From: gas@spitfire.xtel.co.uk (Alan Shepherd)
Subject: virtual base classes
Keywords: virtual  
Organization: X-Tel Services Ltd.
Date: Fri, 9 Oct 92 11:23:19 GMT

I have a base class 'Object' (very original...) which has a number of
derived virtual classes.  

e.g. 

class foo: public virtual Object {...

class foo2: public virtual Object {...

When I try a statement of the following form:

Object* oneFoo2 = new foo2();

aFoo2 = (foo2) oneFoo2;

gcc complains like so:

cannot cast up from virtual baseclass `Object'

Can anyone explain (by email preferably) what is going wrong ?  Is it
a feature of C++, or just something I'm doing wrong with the virtual
keyword ?  I have hunted around Stroustrup's 2nd of "The C++
Programming Language" to no avail.

Thanks,

Alan Shepherd
From: dal@mdavcr.mda.ca (Dale Lutz)
Newsgroups: comp.lang.c++
Subject: Re: Distributed C++ System
Date: 12 Oct 92 17:44:33 GMT
Followup-To: comp.lang.c++
Organization: MacDonald Dettwiler, 13800 Commerce Parkway, Richmond, BC, Canada  V6V 2J3

I tried to reply directly via email but was unable to reach
"champ@ztivax.UUCP".  Anyway, I have nothing to suggest re: your query
about distributed C++ systems but I am very interested in the kinds of
pointers/responses you get.  Can you please forward on to me and/or
summarize to this newsgroup anything you find out in response to your
original query.

What I can suggest to you as far as C++ development in general is
concerned is that if you are using a "cfront" kind of preprocessor you
really should get Newcode Technology's "cback" product, which we found
reduced our executable size (and link times) by about 50%.  Its about
$700 US and for more info contact:

NewCode Technology Incorporated
200 Boston Avenue
Medford, MA, USA 02155
Tel: (617) 396-3009
Fax: (617) 395-9452
internet:  cybvax0!zeev@uunet.UU.NET

NOTE:  They also make a radically improved "malloc" which we are going
to give a try over the next month or so.

The other nifty product you may wish to consider using is something
called "SNIFF".  Its a very sophisticated browser/editor/development
environment for C++.  We really like it here.  For more info on SNIFF,
contact:

Christian Kleinferchner
takeFive Software
Jakob-Haringer-Strasse 8
A-5020 Salzburg, AUSTRIA
Tel +43 662 457915
Fax +43 662 457922
Email chris@takeFive.co.at

Hope some of this is of use.


Dale
(not affliated in any way with the above mentioned products)
-- 

---------------------------------------------------------------------------
Dale Lutz      - MacDonald Dettwiler Richmond, BC, CANADA -      dal@mda.ca

Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: GOTO, was: Tiny proposal for named loops.
Summary: Another way ...
Organization: :
Date: Fri, 9 Oct 1992 21:32:00 GMT

> With so many places for syntax failure, I fail to see how this
> would be easier to read if I refrained from using a "goto".
 
> btw: if anyone knows how to deal w/ reading formatted input from
> a stream more easily, PLEASE let me know!

I have my prejudices.  Here goes.  (I'm dropping large parts of the
code to hold the size down.)  (If speed is critical, make the comma-skip
inline and code it explicitly rather than using the manipulator; this
will save a function call per field, if that matters.)

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

/*
 *	skip_comma is used as a manipulator ... also skip_nl
 */
istream&
skip_comma( istream& i )
{
	skippast( i, ',' );
	return i;
}

istream&
skip_nl( istream& i )
{
	skippast( i, '\n' );
	return i;
}

inline int
peek_check( istream& i, char check )
{
	return i.peek == check;
}

/*
 *	If getqstring() returns the istream, as it ought, this isn't
 *	needed.  But just to be sure ...
 */
int istream&
i_getqstring( istream& i, char* str, int sz )
{
	getqstring( i, str, sz );
	return i;
}

istream &
getConfigLine(istream &in)
{
    // --Declarations ommitted
	//- config line:
	//	iLine#, iRing, iSwitchHook, iMute, "id", "fname", "m", "lname"

	if( ! ( in >> iLine >> skip_comma )
	 || peek_check( i, '\n' )
	 || ! ( in >> iRingSignal >> skip_comma )
	 || peek_check( i, '\n' )
	 || ! ( in >> iSwitchHook >> skip_comma )
	 || peek_check( i, '\n' )
	 || ! ( in >> iMute >> skip_comma )
	 || peek_check( i, '\n' )
	 || ! ( i_getqstring( in szId, ID_SIZE ) >> skip_comma )
	 || peek_check( i, '\n' )
	 || ! ( i_getqstring( in szFirst, NAME_SIZE ) >> skip_comma )
	 || peek_check( i, '\n' )
	 || ! ( i_getqstring( in szInitial, 1 ) >> skip_comma )
	 || peek_check( i, '\n' )
	 || ! ( i_getqstring( in szLast, NAME_SIZE ) >> skip_nl ) )
	{
		in.clear(in.rdstate() | ios::badbit);
	}

	return in;
}

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

It's just possible that a given compiler will gag on so long a
disjunction.  You could split this into several parts, repeating the
error handling once or twice.  Not too bad if you _had_ to do it.

C++ compiler writers--make sure the compiler can handle any disjunction,
conjunction, or illegitimate conjugal offspring thereof, that we might
throw at it.

There are further things that can be done with this; you should be
able to see them easily.

Here's the question: is a long disjunction or conjunction like this
_really_ good code?  Why not?  It's extremely regular, it expresses
the problem succinctly (and you can fine-tune the functions you use to
your own input management), and it clearly seperates error-handling
code, normal-case code, and universal code.  There are no random
branches, and the disjunction is can be read correctly as an N-way
disjunction (rather than a bushy tree of disjunctions).
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Const and Reference
Date: 9 Oct 92 14:17:16 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

gs4t@virginia.edu (Gnanasekaran Swaminathan) writes:
: : Shih-Hao Liu writes:
: : 4>     char a = '-';
: : 5>     const char &b = a;    // error: asignment to constant
: : 6> 
: : 7>     b = '+';
: 
: I think line 5 is correct as ARM p. 155 says, "A reference to a
: const T can be initialized with a const T or a plain T or something
: that can be converted into a plain T but not a volatile T."
: 
: Also ARM p. 154 says, "... if the reference is to a const an object
: of type will be created and initialized with the initializer."

You didn't read p154 through (and are also quoting out of context):

"If the initializer for a reference to type T is an lvalue of type T
 [irrelevant part omitted], the reference will refer to the initializer,
 otherwise if and only if [your quote above]"
 ^^^^^^^^^^^^^^^^^^^^^^^^

At the bottom of p154 is the final clarifying example:

double d;
const double& rcd =d; // refers to 'd'

: Hence, if you modify variable a above it would not get reflected
: in reference b.

Oh yes, it will.  It is called aliasing, and shows how an object
pointed to by a constant pointer/reference cannot be 100% trusted
to remain the same, since other non-constant names/references/pointers
may exist for the same object.

It seems like g++ creates a copy of 'a', and initializes 'b' with it.
This is wrong.  Interestingly, g++ does _not_ do this when passing
non-const objects to functions taking constant reference parameters.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: operator->() considered harmful
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 8 Oct 1992 04:07:20 GMT

In article <717931597snx@anwaya.demon.co.uk> jclf@anwaya.demon.co.uk (Jason Fordham) writes:
>
>In article <Br4tDn.Bnu@taligent.com> cep@taligent.com (Christophe Pettus) writes:
>
>> Again, I feel that overloadable operator->() is an error in the
>> language, a mis-feature.  It doesn't correspond to standard operator
>> syntax (a postfix operator that requires something special following
>> it?  Come on), and introduces problems like the overloable operator.()
>> nonsense.  There are much better ways of accomplishing the same thing.
>
>I know I'm entering into this late, have no C++ experience, but a
>reasonable grounding in OOP theory.
>
>It seems to me that this position is not sensible. If * is
>overloadable, then (since '(*struc).field' is historically
>equivalent to 'struc->field') -> has to be for orthogonality to
>be possible at all. Surely one must either make an orthogonal set
>possible for structures, or stick to the old definition forever.

	Does this mean you support overloadable operator.  ?

>
>It seems to me that there are three other, mutually related,
>arguments for overloading access operators:
>
>    o  reusable components
>    o  memory architectures
>    o  operating system implementation
>
>I can imagine that an OS designer who wished to provide an OS for
>platforms of different sizes with different numbers of processors
>and shared memory would want to be able to overload all the
>access operators.

	The problem is that overloading the existing access operators
is completely inadequate. Such a mechanism to be really
useful must be both generic and polymorphic, and this is not
possible in C++. 

	In particular, a class for which you have operator ->
overloaded is fine, but if you have 100 objects and want to
have 'handle' based access for all of them, you need 100
handle classes. If you want polymorphic handles (like
pointers) you cant use templates.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: rwk@silver.sbi.com (Richard W. Kreutzer Consultant)
Newsgroups: comp.lang.c++
Subject: Re: C++ Review in Unix Review
Date: 8 Oct 92 14:41:11 GMT
Organization: Integra Software Corporation
In-reply-to: MKK2@psuvm.psu.edu's message of 6 Oct 92 12:04:58 GMT

In article <92280.080458MKK2@psuvm.psu.edu> MKK2@psuvm.psu.edu writes:
Path: pivot-sts!sbi!internet!psinntp!psinntp!sgigate!olivea!spool.mu.edu!uwm.edu!wupost!psuvax1!psuvm!mkk2
   From: MKK2@psuvm.psu.edu
   Newsgroups: comp.lang.c++
   Date: 6 Oct 92 12:04:58 GMT
   Organization: Penn State University
   Lines: 7

   The current issue of Unix Review reviews three "native code C++ compilers
   for Intel".  Naturally 8-) they didn't include the GNU C++ compiler.  Besides
   the fact that FSF rarely advertises in Unix Review, can anyone think of
   a good argument for not including the GNU compiler?  It is a "native code"
   compiler, isn't it?

   email preferred

Yeah, what gives Unix Review?

Who did the review?  I would like to ask him why he didn't include gcc.  Did he
give an e-mail address?  If they didn't include gcc because they don't get
advertising dollars from FSF then the largest advertiser probably gets the
best review, right?
--

--
        Richard W. (Dick) Kreutzer
Net:    rwk@quark.sbi.com				CIS:	70702,2174
Voice:  +1(801)571-2446					FAX:	+1(801)571-2448
Mail:   Integra Software Corp.; 1378 Jasmine Avenue; Sandy, UT 84092 (USA)
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Proposal: Preconditions and PostConditions in C++
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 15 Oct 1992 13:41:53 GMT

In article <1992Oct13.164331.29699@genghis.borland.com> pete@genghis.borland.com (Pete Becker) writes:
>In article <1992Oct12.214358.33483@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:
>>
>>For myself, I don't expect to use private inheritance when I am doing the
>>system design.  Since anything done by it can be done by including data
>>members without excessive cost (as far as I can tell), it seems to me to be
>>conceptually cleaner to use a single approach.
>
>	If you use a member instead of inheriting you can't override virtual
>functions.  Whether this is a useful thing to be able to do is left as an
>exercise...
>	-- Pete
>
>
	Well, I've never done it, but here is an obvious idiom
for private inheritance:

	I want to implement an X using a P. P is an abstract class,
it has some primitive functions v1, v2 ... which are virtuals,
and some more comprehensive public members p1, p2, .. defined
in terms of v1, v2 ...


	I do

	class X : private P { ...
		v1(...
		v2(...

	In class X I override the virtuals v1, v2, v3 and so have 
private access to the public members p1, p2.. of P to easily
define the implementation of X:

	public:
		xmem(){ p1(); p2(); }


In short, implementations relying on abstract classes cannot
use composition directly. You may ask "Why not just make a
concrete class C : P and *use* that?" and the answer is
that the functions of C cannot depend on the (private) state
of X, at least not without passing to C a reference to the
X members *this, and also declaring C a friend.

-- 
;----------------------------------------------------------------------
        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: jjd@chinet.chi.il.us (Joe Durnavich)
Subject: Re: Re: GOTO, was: Tiny proposal for named loops.
Organization: Chinet - Public Access UNIX
Date: Tue, 6 Oct 1992 22:48:25 GMT

Jim Miller writes:

> One more story:  When adding new functionality to an existing product
> I found almost every procedure had at least one "GOTO 999", some had 
> several.  This PASCAL has no procedure "return" statements.  The
> consistency of the practice of "GOTO 999" being an error exit to
> each procedure's clean-up code resulted in easy to understand, easy to
> maintain code.  

The problem with that is not all procedures have only one clean-up
routine.  The clean-up code, in your case, has to figure out how far
the code made it into the procedure before bailing out.  That is, it
may have to figure out which files to close, which malloc'ed blocks
to free, etc.  This is more naturally done with nested if's.
-- 
Joe Durnavich
jjd@chinet.chi.il.us
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: requirement for overloaded operator must have class
Organization: TauMetric Corporation
Date: Wed, 14 Oct 1992 17:56:49 GMT

hartman@ulogic.UUCP (Richard M. Hartman) writes:

>I would like some explanation of the reasoning behind the rule
>that an overloaded operator must take at least one parameter
>of as "class" type.

One explanation:

Suppose we had
	int operator+(int, int);

When you write "i+j" or "k+2", the result would depend on whether a
prototype for that function were in scope.  This would be the source
of very subtle program bugs.

The requirement that overloaded operators must have a class parameter
means that an operator either has its predefined meaning or is illegal
without a prototype.  Operator "+" is not predefined for class types.

The guideline, stated in the ARM, is that C++ is extensible, not mutable.

Some operators have default semantics for classes.  Those operators
are further required to be members of a class for the above reason.
For example, assignment is predefined for class types, so a
user-defined assignment operator must be a member function.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: ded@aplcen.apl.jhu.edu (nod sivad)
Subject: virtual destructors
Reply-To: ded@aplcen.apl.jhu.edu (nod sivad)
Organization: Johns Hopkins University
Date: Mon, 12 Oct 92 16:40:43 GMT


Thanks to everyone who responded to my problem concerning the need
to call the destructors of derived objects with a base class 
pointer.  I said in my message what I really needed was a virtual
destructor.

The answer to my problem is...declare a virtual destructor.  Duh.

Yes, I've RTFM, perused the FAQ, books, magazines, etc.  Did I remember all 
that stuff?  Obviously not.  My only experience with the virtual keyword
was with virtual functions, and in that case one is required to name 
the functions identically.  I had the idea "virtualness" required identical 
names and thus didn't attempt it with differently named destructors.  Ah, well.

Now I wonder what other interesting uses one can make of "virtual." A whole 
new world has opened for me; perhaps I've stumbled upon virtual reality.

				me
From: pickerig@dns0.bham.ac.uk (Mr. G. Pickering)
Newsgroups: comp.lang.c++
Subject: Re: Can we use fread() and fwrite in C++? And how?
Date: 16 Oct 92 08:33:08 GMT
Organization: The University of Birmingham, England
X-Newsreader: TIN [version 1.1 PL6]

Erm, dumping structs to a file like this is at best, completely
non-portable. When I dump structs to files, I have to work with
my own pre-defined types (Byte, Word16 and Word32) and I always
have to send a tag to identify whether the data is stored as
Big-Endian or Little-Endian (Modifying the data at read time).

I would suggest overloading the operators '<<' and '>>' and using
streams for this job, and save the data individually. You will also
have to send some sort of header data to specify the type of the data
the big-endian stuff.

Guy.

--
Guy Pickering
Electronic Eng, University of Birmingham, Edgbaston, Birmingham. ENGLAND
G.PICKERING@uk.ac.bham  or pickering@uk.ac.bham.eee
--
"Simpleton?...Now I know that means something bad." - Kelly Bundy
Newsgroups: comp.lang.c++
From: lalford@fsu1.cc.fsu.edu (LYNN ALFORD)
Subject: Question for Borland c++ experts
News-Software: VAX/VMS VNEWS 1.3-4   
Reply-To: lalford@fsu1.cc.fsu.edu
Organization: Florida State University
Distribution:  world
Date: 12 OCT 92 13:51:09    

Eventually, I hope to install a full version of the Borland C++ package but 
for the moment, I am trying to install just a very basic and small set
of options.  My problem isn't hard disk space at the moment, after the 
installation, there is still 7 megabytes on the hard disk.  The problem is 
the DPMI part.  I just want to be able to play with the system for a bit 
on a Toshiba T1000xe with 8086 processor.  It has the 640 K of conventional 
memory needed, but will 1 megabyte of expanded memory allow the DPMI to 
operate or does it have to be extended memory (as mentioned in the Installing 
and Configuring guide)?  Frustrating to be able to have the files needed 
on the little computer and still not be able to use the programs.

It seems that buying expanded memory for this machine is possible, but not 
extended memory.

Lynn
From: reid@ss6.cps.msu.edu (Dr Richard J. Reid)
Newsgroups: comp.lang.c++
Subject: C++ Usage in CS1?
Date: 8 Oct 92 13:49:46 GMT
Organization: Department of Computer Science, Michigan State University
Originator: reid@ss6.cps.msu.edu


Among the 253 schools that have responded to our survey, the
following have indicated they are using

C++

in their CS1 course.

Do you know of any additions or corrections?

Thanks,

Dick

*************************** C++ ********************************

ITR, Rapperswil, Switzerland
Michigan State University
Oregon State University
Santa Clara University (Also reported using Ada in CS1)
University of Birmingham, UK
University of Virginia
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: Nested classes & Inheritance
Date: 9 Oct 92 19:09:31 GMT
Article-I.D.: alice.23850
Organization: AT&T Bell Laboratories, Murray Hill NJ



dcb@slsvitt (David Binderman 3841 @ SEL-Alcatel LTS Dept. US/ES) writes

 > Given the following code
 > 
 > class A {
 > public:
 >      class B { };
 > };
 > 
 > class C : public A {
 >     class D {
 >         B y;
 >     };
 > };
 > 
 > Then does the declaration of y require A::B or only B ?
 > Or, is B accessable from D directly ?
 > 
 > The ARM, Stroustrup 2 & Lippmann 2 didn't help in this case.

Well, the lookup rules in 10.4 of the manual (in the ARM or my 2nd
edition) ought to have helped. In a class, having looked locally,
you start looking for names in base classes. B is a name is the
scope of A so that the B in `B y;' must refer to A::B.

Names of nested classes obey all the usual lookup rules for member names.
Newsgroups: comp.lang.c++
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: C++ Programming Environment, recommendations wanted
Organization: Private
Date: Tue, 6 Oct 92 15:39:49 GMT


Hi, there.

I am going to buy an integrated development environment for C++.

It would be great, if some of you could give comments to the following
products. If there was such a discussion before in this newsgroup,
please let me know the date.

The comments sould not of the form 'X is bad, Y is good'. The
interesting informations are details, good or bad ideas, impractical
ways to do some things and so on.

The interesting products are (other suggestions welcomes):

- Centerline Objectcenter
- ParcPlace Objectworks C++ (now in Version 3.0). 
	I am interested in infos about 2.4, too.
- Liant LPI C++

I am going to use it on a SPARCstation (under X11, not Openwindows).

What I need: 

- An environment with integrated debugger and editor with quick
turnaround (for example, jumping to compiler's messages in source
code), 

- a browser for the classes. The classes should be seperated in
a tree of Categories (like smalltalk) and be read in the editor by
clicking them in the tree.  

- an inspector for the variables of an
instance. This should be similar to smalltalk. The top level of
variable is show directly, the variables, that contain other objects
with serveral variables should be shown, when you click their name in
the top level.

It is o.k., when to C++-Environment does not implement all of these
things directly, but uses emacs, for example.

Not so important is:
- Multiuser-Support
- Revision Control
- Cross-Reference Browser


I suggest, that Object-Center is the best tool for this. The question
is, is it worth that money ?

Objectworks C++ 3.0 is a new release. Anybody worked with it so far ?

Liant is cheap. Is it useable ?

Another question could be, if anybody has build parts of such a
environment around emacs and gdb. It would be not GUI-based, but good
tree-based editing of class defintions and inspecting multiple levels
of instance variables seems to be possible.

Last, it would be good, if you send US prices for the products, so I
can see, what extra fee the german dealers add.

I will summarise all articles and mail, I you wish.

Thanks.
	Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer, cracauer@wavehh.hanse.de
Waldstrasse 200, W-2000 Norderstedt, Germany
Tel.: +49 / 522 18 29, Fax.: +49 / 522 85 36
From: Richard.W..Kreutzer.Consultant@f1.n100.z60.wlink.nl (Richard W. Kreutzer Consultant)
Newsgroups: comp.lang.c++
Subject: My objects are too big - why?
Date: Sun, 11 Oct 1992 23:19:18 -0100

Organization: Integra Software Corporation

In article <1992Oct9.175014.15457@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes: