HDTenEightyP/NetNews huggingface dataset:
From: pete@genghis.borland.com (Pete Becker)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: Preconditions and PostConditions in C++
Date: 15 Oct 92 17:32:49 GMT
Organization: Borland International
Originator: pete@genghis.borland.com

In article <1992Oct14.220138.38339@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:
>
>How about:
>       class Base
>       {
>	   virtual void g();
>       public:
>	   void f() { g(); }
>	   void h();
>       };
>
>       class Derived : public Base
>       {
>       public:
>	   virtual void g();
>       };
>
>       class New
>       {
>	   Derived x;
>	   virtual void g() {x.g();}
>       public:
>	   virtual void f() {x.f();}
>       }

	class DerivedFromNew : public New
	{
	   virtual void g();
	};

	This g() does not override the g() in Derived, so the 'x' object's 
behavior is not changed.  By making Base a member instead of a base,
inheritance from it is cut off.
	Okay, I confess, that's not completely true.  There are further hacks
that can be done, like changing Derived to hold a pointer to a New, and
overriding g() in Derived to check that pointer and call New::g() if the
pointer isn't null, and New::g() will usually just be a callback into Derived,
but it can be overridden, and that will, in turn, affect the behavior of 'x'.
	But why go through all that effort?  The mechanism is already there:
private inheritance.
	-- Pete
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: Wed, 14 Oct 1992 11:19:14 GMT

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.


	No, you cant override virtual functions using composition.
You can with private inheritance.

	Note that inheritance is at best convenient without
virtuals, (saves writing forwarding functions), never required.
If you dont override a virtual you should think twice about
using inheritance instead of composition.

-- 
;----------------------------------------------------------------------
        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: holerbch@phoenix.Princeton.EDU (Uwe Hollerbach)
Subject: Re: Problem with GCC, or wild pointer
Originator: news@nimaster
Organization: Princeton University
Date: Wed, 14 Oct 1992 19:06:30 GMT

In article <1992Oct14.051643.18881@Princeton.EDU> I wrote

[Problems with gcc on Iris; identical code on RS/6000 with xlC,
sparcstation with gcc, Iris with CC (cfront), and PC with Turbo C++
works correctly; what's going on?]

I seem to have found a solution to my problem. When using gcc, I was
importing compiler options from a default file; to wit, I was using
	gcc -O -ansi -pedantic -Wall -c ...
I just glanced at this a few minutes ago, and it occurred to me that
C++ is not in fact ANSI C. I accordingly removed the -ansi (and had
to remove the -pedantic as well) and recompiled everything. It worked!
I don't know why this had this effect, but I'm happy. Thanks for listening!
-- 
Uwe Hollerbach          uh@acm.princeton.edu  or  uh@alumni.caltech.edu
"In His infinite mercy, Allah does not subtract from one's alloted span those
hours which are spent in contemplation of net.news. All praise be to Allah."
-- an obscure commentator on the early work of Al-Khowariszmi
Newsgroups: comp.lang.c++
From: feustel@netcom.com (David Feustel)
Subject: Re: Data structures book for C++...????
Organization: DAFCO: OS/2 Software Support & Consulting
Date: Sun, 11 Oct 1992 23:17:36 GMT

Check out "C++ Components and Algorithms" by Scott Robert Ladd.
(ISBN 1-55851-227-6, M&T Books, $39.95, disk included) and see if it's
what you're looking for..
-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
[.sig on vacation]
Newsgroups: comp.lang.c++
From: James B. Wilkinson <wilkins@cs.cofc.edu>
Subject: Will someone look at a problem and help us?
X-Xxdate: Wed, 7 Oct 92 14:46:18 GMT
Organization: The College of Charleston
X-Useragent: Nuntius v1.1.1d12
Date: Wed, 7 Oct 92 18:44:11 GMT

I have a student who is trying to learn C++ on his own.  He has a problem
with
a construct he is trying to use, and nobody around here knows enough about
C++ to do him any good.  Would somebody volunteer to let me mail them the
relevant code and compiler error messages?  It's not all that big.  Elm
says
that his message to me is 81 lines.

Thanks.

-------------------------------------------------------------
Jimmy Wilkinson            | Professor of Computer Science
wilkins@cs.cofc.edu       | The College of Charleston
(803) 792-8160             | Charleston      SC        29424
Newsgroups: comp.lang.c++
From: todd@behemoth.genetics.wisc.edu (Todd Richmond)
Subject: Does Borland C++ 3.1 have good online help?
Organization: UW Genetix
Distribution: comp
Date: Wed, 14 Oct 1992 19:56:46 GMT


Subject line says it all.  The university has a site
license for Borland products and I can get the actual
software for a really small fee and a licensing fee.
However the documentation is a significant chunk of
change which I would rather not buy unless I have to.
So can I get by without it or am I going to run into
severe difficulties in the long run?

Thanks,

Todd
--
*********************************************************
Todd Richmond  UW-Madison Dept of Genetics
todd@genetics.wisc.edu         
**insert standard disclaimer**
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Newsgroups: comp.lang.c++
Subject: Re: downcasting (was Re: GOTOo wars)
Date: 11 Oct 92 18:46:32 GMT
Organization: Trumphurst Ltd.
ReplyTo: nikki@trmphrst.35demon.co.uk
X-Mailer: cppnews $Revision: 1.19 $


In article <407@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:

> I do not have heterogenous lists, but in order to implement a StudentList
> I have to derive from List, which returns Object * (StudentObj is derived
> from Object, and can thus be placed on an NIH List).  When I get a 
> Student from the List it is an Object * and I have to cast to
> StudentObj *.  I know that all members of the list are going to be
> StudentObj, but I still have to do the stupid downcast because I am
> using SOMEONE ELSE'S List class as a base class.
..
> Ahhhh.  Here we go.  This is what the NIH library does.  As I
> mentioned in my original post, the access functions return
> only Object *:
> 
> 	Object  *List::get() 
> 
> to use it I have to do:
> 
> 	StudentObj *pStu = StudentObj::castdown(myList.get(key));
If you don't have templates, downcasting appears to be the only way to 
achieve what you (and many others) want. However, you need to watch out 
for some pitfalls.

If you publicly derive your StudentObjList class from the NIH List, you 
allow the StudentObjList to be treated as a List. This means some code 
could add some other kind of Object to your List. When you retrieve this 
unwanted Object, you will have problems - you will cast it to a StudentObj
when it isn't one, giving the famous "undefined behaviour".

What you need to do is to PRIVATELY derive from List, so this can' 
happen. This means you will need to redefine all the List methods in your 
derived class, but these redefinitions can usually be inline, so there is 
no performance hit.

Of course, this is where templates would be useful - you can set up a 
template to privately derive a List for any particular kind of Object 
automatically. However, as you don't have templates, you should look into 
"generic.h" (or similar) which is an include file containing macro 
definitions that were the precursor to templates. These enable you to do 
most of what templates offer (albeit in a much less neat way).
---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
Newsgroups: comp.lang.c++
From: dlsteven@nyx.cs.du.edu (Doug Stevens)
Subject: pointers to functions
Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept.
Date: Mon, 12 Oct 92 18:42:56 GMT

I am using a pointer to call a function in a program I am writing.  The function
will execute, but after it finishes the computer hangs.  It seems that it
doesn't know where to return to.  Here is a breif description of what is 
happening:

1. Define prototype of int login(void *).
2. Create struct selectitem {
			char *choice;
			int (*execute)(void *);
				};
	within class pulldown.
3. Within class salesanal, which also has 2. in it's list of
	header files, 
	selectitem userlist[]={{"Login",login},..... 
	is declared.
4. userlist[0] is passed to pulldown.
5. int pulldown::run(int number, void *data) { //number=0
	int ret;

	ret=(*(box->list[number].execute))(data); //box->list is of
				              //type selectitem.
	return ret;
	}

login does execute, but when it gets to the last } the computer
hangs.  It's like it doesn't know where to return to.

Thanx for the help....
Doug







Newsgroups: comp.lang.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Proposal: Preconditions and PostConditions in C++
Date: Fri, 16 Oct 1992 18:51:18 GMT
Organization: Security APL, Inc.

In article <1992Oct15.173249.15242@genghis.borland.com> pete@genghis.borland.com (Pete Becker) writes:
>In article <1992Oct14.220138.38339@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:
>>How about:
>>       class Base
>>       {
>>	   virtual void g();
>>       public:
>>	   void f() { g(); }
>>	   void h();
>>       };
>>
>>       class Derived : public Base
>>       {
>>       public:
>>	   virtual void g();
>>       };
>>
>>       class New
>>       {
>>	   Derived x;
>>	   virtual void g() {x.g();}
>>       public:
>>	   virtual void f() {x.f();}
>>       }
>
>	class DerivedFromNew : public New
>	{
>	   virtual void g();
>	};
>
>	This g() does not override the g() in Derived, so the 'x' object's 
>behavior is not changed.  By making Base a member instead of a base,
>inheritance from it is cut off.

So what?  It isn't the behavior of x we care about, but the behavior of the
objects of class New and its subclasses.
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Proposal: Preconditions and PostConditions in C++
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 16 Oct 1992 14:02:05 GMT

dl@g.g.oswego.edu (Doug Lea) writes:

>typedef Month ConstrainedInt<monthOK>;

That should be: typedef ConstrainedInt<monthOK> month;

>Smart Wrapper Classes
>
>The examples in the previous section all dealt with constrained
>built-in types, and worked by duplicating known interfaces.
>This technique cannot generally work for user-defined types.
>However, equivalently useful effects may be had via ``smart
>pointers''.
>
>Smart pointers are classes that overload ` operator ->()'
>and related operators to that the classes ``look'' like pointers.
>Howver, upon dereference, they may perform any kind of
>processing whatsoever (so long as they ultimately dereference
>to the declared type.)
>
>For example, suppose a programmer wished to declare a ` Parser'
>class that used a ` Stack' that was constrained to never be full.
>In A++, this might look like:
>
>
>class Parser
>{
>  Stack* s;
>always:  !s.full();
>  //...
>}
>
>
>This effect may be obtained instead through:
>
>int notFull(Stack* s) { return !s.full(); }
>
>typedef notFullStack  ConstrainedPtr<Stack, notFull>;

Again, that should be
    typedef ConstrainedPtr<Stack, notFull> notFullStack;

>class Parser
>{
>  notFullStack* s;
>  //...
>}

Actually, don't you really want to do
    typedef ConstrainedPtr<Stack, notFull> notFullStackPtr;
    ...
    notFullStackPtr s;
?

>Constrained smart pointer classes share with constrained builtins the
>minor problem in C++ of possessing occasionally detectable differences
>from the classes they replace {edelson}. In partial compensation,
>beyond the explicit constraint checking they perform, they also
>provide protection against errors like performing pointer arithematic.

One of the major problems with smart pointer classes is the inabilty to
write corresponding smart reference classes. This forces your users to use
pointers and pointer syntax even when it is very inappropriate. It also
means that smart pointers are less like builtin pointers, because you
cannot maintain the identity
	smartptr->member === (*smartptr).member

The reason that you can write smart pointer classes but not smart reference
classes is that operator->() can be overloaded but not operator.().
This is IMHO a rather gratuitous non-orthogonality, and I believe that it
should be removed from the language.

For those that are interested, I have modified g++ 2.2.2 to allow
overloading of operator.(), and I can provide the patch for this on request.
Someday I may get around to incorporating this change into the standard
g++ release, if the g++ maintainers are agreeable.

-- 
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: pluto@cs.ucsd.edu (Mark Plutowksi)
Newsgroups: comp.lang.c++
Subject: Re: C++ for Sparcs: recommendations?
Date: 8 Oct 92 04:20:12 GMT


I'm replying to what
emike@sdc.com (E. Mike Durbin) writes:


>In article <39052@sdcc12.ucsd.edu> pluto@cs.ucsd.edu (Mark Plutowksi) writes:
>  >
>  >Dear Cross-Training C++ Wizards, (i.e., you use both PC & Sparc)
>  >Is there a C++ compiler for Sparc stations that 
>  >	- is up to date with the Real Thing (the Xerox "standard")

>I wasn't aware that there was a "Xerox" standard for C++.

	viz., cfront, version 3.0


>  >	- is cheaper than the Real Thing

>If free cheap enough?


	It is my understanding that this is expensive,
	and besides, isn't cfront just a C++ to C 
	translator, rather than a true compiler?

>  >	- has a gui debugger with keyword-sensitive on-line help
>  >	- has object browsing
>  >	- has project management (I haven't used make.exe all year.)

>I just got my brand new copy of SPARCworks Professional C++ 3.0
>which does all of this (but I haven't played with it yet).


	Thanks, this is good news to me. Prices?



>  >	- has gui-building capabilities ala BC++'s OWL & Protogen,
>  >	  but for X Windows instead.

>There are lots of C++ based gui buildes, and even more C based gui
>builders.  Some, such as Objectcenter and (presumably) ParcPlace
>(both of which supply the Solbourne C++ toolkit and GUI builder)
>provide compilers, debugger, browsers, etc., as well.  (I use and
>VERY MUCH like the Solbourne C++ toolkit).




>Check out the GNU compilers, 

	I have. I used g++ all of last year.  Gave up
	on it before the new version came out this year,
	but I understand that that was only a bug fix anyway.
	It (g++) had some nice features, but I would rather
	have something solid that is well supported, has
	a nice development environment.  If it
	keeps up with new developments in the language,
	that is a plus, also.  Gnu (although I think gnu's C
	is great and fast from what my friends say) fails on
	all of these points, or at least it did last year 
	when I was entrenched in it - although to my knowledge
	nothing has changed enough to make me go back to it.
	Free is not a great deal when it wastes my time,
	which to me is quite valuable.

>SPARCworks Professional C++ (Requires
>Solaris 2.0) and the Objectcenter or ParcPlac C++ GUI (Based on
>Solbourne's OI toolkit) and compilers environments.

>E. Mike Durbin
>emike@obs.com or emike@sdc.com


	Again, thanks for these tips - does anyone have price lists
	for these?  (This is for academic research here at UCSD.)
From: engelsma@golden.cps.msu.edu (Jonathan Engelsma (Reid))
Newsgroups: comp.lang.c++
Subject: Where do I report this...?
Date: 7 Oct 92 15:50:31 GMT
Organization: Dept. of Computer Science, Michigan State University


I've located a bug in the AT&T C++ task library.   Can somebody
from AT&T (or anyone else) tell me who I should report this problem
to?  I have a short example program which illustrates the prob.

Thanks.
-------------------------------------------------------------------------
Jonathan R. Engelsma                            Michigan State University
                                                     Department of
E-mail:   engelsma@cps.msu.edu                     Computer Science
	  uunet!frith!engelsma	
	  uunet!frith!jresys!engelsma (home)	
-------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: jenings@fc.sde.hp.com (Byron Jenings)
Subject: Re: Source code for AT&T Codelibs
Organization: HP SESD, Fort Collins, CO
X-Newsreader: TIN [version 1.1.4 PL6]
Date: Wed, 14 Oct 1992 01:59:59 GMT

Chris Curtin (chris@bwilab3.UUCP) wrote:
: I use HP's C++ compiler on series 700 and 800s. HP provides a library called
: 'codelibes' that is from the AT&T C++ compiler distribution. HP says that 
: you must get the source for these libraries from AT&T. 
: 
: Does anyone know how much AT&T would charge for this?  The HP reponse center
: engineer did not know, nor did he know who to get in touch with to find
: out. The name and phone number of someone at AT&T would also be helpful.

There may have been some confusion about which library you were
referring to, since there is more than one library.  If you mean the
codelibs library that contains things like bitset, dynarray,
hashtable, heap, longer, etc., then that is in fact an HP-invented
library which contains no AT&T code.  I'm afraid I don't know,
however, whether a source licensing program is in place.

If this is the library you were interested in, have the support
engineer contact someone in SESD marketing for an official answer.
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Boolean Tests on Streams
Organization: TauMetric Corporation
Date: Sat, 10 Oct 1992 16:43:13 GMT

male@eso.mc.xerox.com (Ron Male 73628 - SST/SETA) writes:

>There seem to be two elementary approaches to performing boolean tests
>on streams:

>1)  while (cin >> ch)
>       {...}

>2)  if (cin)
>       {...}

>I've been unsuccessfully trying to find out what is going on under
>the hood in these cases.

In case #1, the >> operator is overloaded and is resolved to the call
	cin.istream::operator >> (T&)
where T is the type of 'ch'.  The return type of each overloaded >>
is 'istream&', which is therefore the type of the expression in parens.

Cases #1 and #2 therefore resolve to the same thing.  In this context,
the language requires a value of 'scalar' type: an integer, enum,
floating-point, or pointer type.  An istream (or istream&) is none of
these, so we look for user-defined conversions.

Base class ios has a user-defined conversion to type void*, which fills
the bill, and there is no other usable conversion available.  So the
construction
	if (cin)
is evaluated as
	if ( ((ios)cin).operator void*() )
and "if(cin>>ch)" is treated similarly.  The result of the conversion
is a void*, which is implicitly compared to a null pointer.

The only remaining question is the semantics of the conversion to void*.
The conversion is meant to be a test of the state of the stream.  The
state information is kept in the virtual base class ios, which is why
the conversion function is also there.  If the stream is in a 'failed'
or 'bad' state, a null pointer is returned; otherwise a non-null
pointer is returned.  Therefore, the test "if(str)" for some stream str
passes if the stream is OK.

There is another test available:
	if( ! cin ) ...
In this case, the function ios::operator!() is invoked directly,
rather than the user-defined conversion.  Its semantics are the
opposite of the void* conversion:  it returns 0 if the stream is
OK, 1 if not.

Both of these are "pure" functions, which only test the state of the
stream and do not modify it.  This means that
	if( str ) A; else B;
and
	if( ! str ) B; else A;
have exactly the same effect.

One thing to watch out for is that EOF is considered OK on input.  This
means that a construction like
	while(istr) { ... }
takes one more trip around the loop after EOF.  An input operation in
the loop will fail at EOF, so the stream will be in a failed state
and finally terminate.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: streams
Date: 15 Oct 92 23:14:51 GMT
Organization: negligable

re: method #2 above, if you use a process(istream &) function then
you can also iterate on a file list (i.e. take more then one file
on the command line) more conveniently than the using the other method.

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Nobody has ever had a sexual fantasy about being tied
 to a bed and ravished by somebody dressed as a liberal."    -P.J. O'Rourke

Xref: sparky comp.lang.c++:14819 comp.sys.hp:11546
From: chris@bwilab3.UUCP (Chris Curtin)
Newsgroups: comp.lang.c++,comp.sys.hp
Subject: Source code for AT&T Codelibs
Date: 9 Oct 92 20:24:35 GMT
Followup-To: comp.lang.c++
Organization: Bradley Ward Inc., Atlanta, Ga


I use HP's C++ compiler on series 700 and 800s. HP provides a library called
'codelibes' that is from the AT&T C++ compiler distribution. HP says that 
you must get the source for these libraries from AT&T. 

Does anyone know how much AT&T would charge for this?  The HP reponse center
engineer did not know, nor did he know who to get in touch with to find
out. The name and phone number of someone at AT&T would also be helpful.

Thanks

Chris
-- 
--
Christopher M. Curtin				Bradley Ward Systems, Inc.
gatech!warlord!bwilab3!chris			5901-A Peachtree Dunwoody Rd
						Atlanta, Ga 30350
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Only 'public' stuff in .h file?
Date: 8 Oct 92 08:31:12 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: rmartin@donner.Rational.COM's message of 7 Oct 92 03:51:29 GMT

In article <rmartin.718429889@donner> rmartin@donner.Rational.COM (Bob Martin) writes:

   mark@sdd.hp.com (Mark Overton) writes:

   |I'm really hoping that C++ will let me totally hide all implementation
   |info from the "user" of a class.  This means the .h file for the class
   |must contain solely the public interface, and not contain any private
   |members (which would be in the .cpp file).
   |
   |Is such separation of public and private members possible?

   Yes, indirectly.

   Create an abstract class which your class inherits from, and which
   defines pure virtual functions for all the methods of your class.
   Now, only the instantiator of your class needs to see its [.h] file,
   all other users can deal with your class via a pointer or reference to
   the abstract base, and so only need to include the .cpp file of the
   abstract base.  Thus all the private and protected crud in your file
   is hidden from your users.

Of course, you pay in performance for this luxury.

					Thomas.