HDTenEightyP/NetNews huggingface dataset:
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Newsgroups: comp.lang.c++
Subject: Re: c++ & c+++
Date: 11 Nov 92 13:35:34 GMT
Reply-To: nikki@trmphrst.demon.co.uk
Organization: Trumphurst Ltd.
X-Mailer: cppnews $Revision: 1.20 $

In article <1992Nov8.222637.5773@nmsu.edu> willittl@spock.NMSU.Edu (William  Little) writes:
> My employer recently bought Borland c++ compiler for
> windows and told me he bought some new C+++.  I personally
> have never heard of C+++.  Has anybody else?  
Nope !

> Now, on to my c++ questions.
Question concerning the meaning of the scope resolution omitted.

This is a fine time to remind everyone about the C++ Frequently Asked 
Questions list. Many thanks to Marshall Cline for compiling and
maintaining it. 

It can be obtained ...

Via ftp - Anonymous ftp from sun.soe.clarkson.edu [128.153.12.3] :pub/C++/FAQ

Via mail - send mail 
To: archive-server@sun.soe.clarkson.edu
Subject: send C++/FAQ

-- 
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.
Newsgroups: comp.lang.c++
From: grier@bnr.ca (Brian Grier)
Subject: Re: Bad 'for' statement?
Organization: Bell Northern Research
Date: Thu, 12 Nov 1992 20:47:49 GMT

> Hi,

> Could you tell me if this is really a syntax error as AT&T 2.1 reports?

>   for(int i=0, int j=10;   i<10;   i++, j++)
>   {
>     // do something
>   }
> Thanks,

> Guy

I tried this on g++, and HP cc both gives an unexpected symbol: "int" error.
I tried the HP compiler in both K&R and ANSI modes

I suggest moving the declarations out of the 'for'statement.

Brian, WS1S
Bell Northern Research
Research Triangle Park, NC
bjgrier@bnr.ca
Newsgroups: comp.lang.c++
From: trumpet-user@csc.cuhk.hk (Default Trumpet User)
Subject: Declaration Syntax Error
Keywords: Declaration Syntax Error
Organization: CUHK
Date: Sat, 7 Nov 1992 15:10:08 GMT

Could someone tell me why I got the captioned error message once I declared 
the following function:

int (*abcd) (int i)
{ 
	...
}


Walter
a008700@hp9000.csc.cuhk.hk
Newsgroups: comp.lang.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Declaration Syntax Error
Date: Sun, 8 Nov 1992 10:04:12 GMT
Organization: University of Birmingham

In article <trumpet-user.1.721149008@csc.cuhk.hk>, trumpet-user@csc.cuhk.hk (Default Trumpet User) writes:
> Could someone tell me why I got the captioned error message once I declared 
> the following function:
> 
> int (*abcd) (int i)
> { 
> 	...
> }
Yes because abcd is not a function, it's a pointer to a function and you're not
allowed to initialise a pointer to a function to an anonymous function in C++.

What you meant is either :
  static int anon_func (int i) { ... }
  int (*abcd) (int i) = anon_func;
which makes abcd point to a static function which is the nearest thing you get
to an anonymous function in C++

Or more likely:
  int *abcd(int i) {...}
which makes abcd a function returning a pointer to an integer

Please mail me as I'm not sure that my postings are gettimg out of our news
server.
     
    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)
 .  _\\__[oo 
.__/  \\ /\@  E-mail: B.A.McCauley@bham.ac.uk
.  l___\\        Fax: +44 21 625 2175
 # ll  l\\     Snail: 197 Harborne Lane, Birmingham, B29 6SS, UK
###LL  LL\\     ICBM: 52.5N 1.9W
Newsgroups: comp.lang.c++
From: srheintze@happy.colorado.edu
Subject: Wanted: Red-Black Trees
Organization: University of Colorado, Boulder
Date: 11 Nov 92 10:31:56 MDT

Does anyone have source to an implementation of Red-Black trees?
I was going to type one in from a textbook (anyone know of a text book that has 
Red-Black tree?) but if anyone has a softcopy it would save me the trouble.

Does anyone understand the performance difference between red-black trees and
AVL trees?  Does anyone have  reference on this topic?

			Thanks,
				Sieg
Newsgroups: comp.lang.c++
From: ameesh@lsil.com (Ameesh Desai)
Newsgroups: comp.lang.c++
Subject: Re: deleting objects and destructors in derive
Date: 5 Nov 92 23:09:04 GMT
Reply-To: ameesh@lsil.com
Organization: LSI Logic Corporation

Use virtual dtors !

Ameesh
---
______________________________     o__            
| _   /|     Ameesh Desai     \    ,>/_                              
| \`O.o'     LSI Logic Corp.   \__(_)`(_)_              email: ameesh@lsil.com
| =(_|_)=    MS E192, 1501 McCarthy Blvd. \             fax  : (408) 433-6802
|____U_______Milpitas, CA 95035____________\____________voice: (408) 433-4097 
Newsgroups: comp.lang.c++
From: barhydt@pioneer.arc.nasa.gov (William Barhydt -- GDP)
Subject: Re: RPCGEN/C++
Keywords: rpcgen c++
Reply-To: barhydt@pioneer.arc.nasa.gov (William Barhydt -- GDP)
Organization: NASA Ames Res. Ctr. Mtn Vw CA 94035
Date: Sat, 7 Nov 1992 00:15:56 GMT


|>>  The source for the new I/O stream library and the XDR/RPC
|>>  classes discussed in this paper is public available for 
|>>  free distribution.  Interested parties should contact 
|>>  the authors for more information.
|>>and gives the authors' email addresses:
|>>  {minnear|muckel|russo}@cs.purdue.edu
|>>HOWEVER, I have *repeatedly* tried to contact the authors to
|>>get the software and have not yet succeeded.  :-( :-{
|>
|>  1. Did anybody succeed in getting this or some similar software?
|>  2. Can somebody give me pointers to getting the 1992 USENIX C++ proceedings.
|>  3. Do any of you have more info on rpcgen/C++.
|>

There is another version of rpcgen called RPCGEN.NEW
available as part of the TIRPC release .  This is not
yet available under system V.  Anyway this new version
supports C++.  I am not sure if this is the same library
discussed in the paper referenced above about it might be.

TIRPC is available via anonymous ftp from uunet.uu.net
in the /networking directory as a compressed tar
file tirpcsrc.tar.Z.  Requires Sun OS4.1 

I have not tried this at all.

Good luck...

Bill
----------------------------------------------------------------------------
William J. Barhydt			Inet:	barhydt@george.arc.nasa.gov
NASA Ames Research Center		Phone:	(415) 604-6559
Computer Systems and Research Division	FAX:	(415) 604-3080
Systems Integration Branch
Graphics Development Project
----------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: joe@proto.com (Joe Huffman)
Subject: Re: Info on IBM compatible C/C++ compiler needed!
Organization: FlashTek, Inc.
Date: Wed, 11 Nov 1992 08:19:10 GMT

nikki@trmphrst.demon.co.uk (Nikki Locke) writes:

>Zortech - Was once the best. 
>No templates or exceptions. The debugger is good, except for the 
>occasional bug, and the fact that Symantec can't support it any more.
>There hasn't been a new release of Zortech since Symantec
>took over (must be a year, now). Symantec say they won't do a new release
>until they've got the bugs out, but lots of people have got fed up
>waiting. 

Symantec took over a year ago in September.  Since then they lost most of
their developers (hence Nikki's comment to the effect that Symantec can't
support the debugger -- Symantec doesn't have the source code and the
developer that does have it now works for FlashTek, Inc.).

However, a ray of hope for Zortech now shines through (if you look close
enough).  FlashTek (where three of the developers now work and sell their
products) and Symantec have, in essence, declared a cease fire.  They are
even talking directly without the lawyers.  And soon you will start finding
coupons in the Zortech boxes for discounts on FlashTek products (such as
the latest version of Flash Graphics, the 32-bit DOS extender, and the
debugger).  You may even be able to get a coupon from Symantec/Zortech
technical support (Tom Leonard at Symantec should have received them by
now) if you talk really nice.  The FlashTek developers are even providing
some guideance on the beta version of the next DOS release of the compiler.

Although Symantec hasn't announced an actual ship date for the next 
release, they have mentioned on Compuserve (and other places -- I believe)
that one is coming out 'soon'.  It will provide templates, precompiled 
headers, and nested classes.  With the addition of the FlashTek products 
(available NOW for Zortech 3.0r4) it will have source level debugging, 
virtual memory, memory mapped files, and TSR support for 32-bit protected 
mode applications, and faster, smaller, more functional Flash Graphics.

Provided that there are no further 'misunderstandings' between 
FlashTek and Symantec (and nuclear war breaks out again) Symantec may 
actually be able to ship something new in the near future.  Contact
Symantec or FlashTek for more details on their respective products.

Joe Huffman
President
Joe Huffman
FlashTek, Inc.                  FlashTek, Ltd.
121 Sweet Ave                   Partnership House
Moscow, Idaho 83843             Grantham, Lincs
U.S.A.                          NG31 9ST  England

FAX:    208-882-7275            FAX:   +44-476-61382
Voice:  208-882-6893            Voice: +44-476-74108
Orders: 800-397-7310
Email:  flashtek@proto.com      Email: flashtek@cix.compulink.co.uk
CIS:    71332,203               CIS: 100042,1673
-- 
netcom!proto!joe
joe@proto.com
Newsgroups: comp.lang.c++
From: brianm@cc.gatech.edu (Brian N. Miller)
Subject: Re: member test?
Reply-To: brianm@cc.gatech.edu (Brian N. Miller)
Organization: College of Computing, Georgia Institute of Technology
Date: Wed, 11 Nov 1992 17:13:41 GMT

In article <1992Nov10.070124.5763@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>
>C++ is almost the only OOPL
>I know of in which you cannot ask the dynamic type of an object.

Yeah, that is kind of anoying.

If we only had source level read permission on an object's virtual function
table (VFT), we could do alot at run and compile time, like determine the 
class of an object or determine if two classes have the same implementation
of a common method.

Of course writable VFT's are a whole nother matter.
From: ezachris@cochiti.ucs.indiana.edu
Newsgroups: comp.lang.c++
Subject: ProtoGen from Borland
Date: 13 Nov 92 20:50:11 GMT
Organization: Indiana University


I have Turbo C++ 3.1 for Windows with OWL and Resource Workshop.

Borland's offering the ProtoGen code generator for just $49.90.
Does anbody know anything about this?
Is it worth spending fifty bucks for?

Many thanks in advance.

Espen Zachrisen
Indiana University
Newsgroups: comp.lang.c++
From: dlc@ddsdx2.jhuapl.edu (Dave Collard x7468)
Subject: Re: Wanted: Red-Black Trees
Organization: Johns Hopkins University
Distribution: usa
Date: Wed, 11 Nov 92 18:24:56 GMT

In <1992Nov11.103156.1@happy.colorado.edu> srheintze@happy.colorado.edu writes:

>Does anyone have source to an implementation of Red-Black trees?
Yes, but I cannot give you my version.  A 'C' version was posted 
to comp.sources.misc back in February by James Plank at
jsp@Princeton.EDU

I have that and can mail it to you if you want.  I have never run or
built or tested it.  It is in shar format. 

csh> ls -l rbtree
-rw-r--r--   1 dlc      general     30193 Nov 11 13:16 rbtree

>I was going to type one in from a textbook (anyone know of a text book that has 
>Red-Black tree?) but if anyone has a softcopy it would save me the trouble.

Two references:  _Algorithms_ Robert Sedgewick 1983 Addison-Wesley
                 _Introduction to Algorithms_ by Cormen, Leiserson, Rivest 
                   1990 Massachusetts Institute of Technology

Cormen has a much better (read: easier to understand) description of red-black
trees.  However, the Sedgewick algorithm is more efficient in storage because
the parent of each node is not stored.  I have also tested both algorithms and
the Sedgewick algorithm keeps the height of the tree slightly less than the
Cormen algorithm.  I never figured out exactly why.

The basic properties of a red-black tree are:

  1) Nodes are colored red or black
  2) Null leaves are considered black
  3) Children of red nodes are black
  4) Every simple path from a node to a descendant
     leaf contains the same number of black nodes

                 
>Does anyone understand the performance difference between red-black trees and
>AVL trees?  Does anyone have  reference on this topic?

See above.

--Thor
collard@capsrv.jhuapl.edu
dlc@ddsdx2.jhuapl.edu
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Newsgroups: comp.lang.c++
Subject: Re: member test?
Date: 11 Nov 92 12:15:35 GMT
Reply-To: nikki@trmphrst.demon.co.uk
Organization: Trumphurst Ltd.
X-Mailer: cppnews $Revision: 1.20 $

In article <1992Nov10.070124.5763@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
> In article <EB.92Nov9085335@ascent.ascent.com> eb@ascent.com (Ed Barton) writes:
> >In article <1992Nov6.081658.29693@bernina.ethz.ch> haechler@bernina.ethz.ch (Stefan Haechler) writes:
> >
> >   How can I know which dynamic type has a variable ?
> > ...
> > ...
> >The software-design answer is that you shouldn't have to know the
> >answer to this question, and that there may be something wrong with
> >the design if you need to ask it.  If you know only that something is
> >a pointer-to-A, you should be using only the methods and virtual
> >functions that are part of the interface defined by class A.
> > ...
> 
> Come on, there are many fully reasonable and legitimate situations
> in which one needs to know this.  And C++ is almost the only OOPL
> I know of in which you cannot ask the dynamic type of an object.
I disagree. There are (IMHO) a very few, highly specialised cases in which
it is NECESSARY to know the dynamic type of an object. 

The most convincing example I have come across is where objects are
transferred between different invokations of a program (e.g. over
networks, or by storing to disk and retrieving at some later time). 

In all such examples I have seen, additional information is also required
(e.g some kind of type coding system for the data transfer, and some
means of reconstructing an object of the appropriate type at the other
end). 

Of course, it is often EASIER to design a system with run-time type 
identification, but I respectfully suggest that the extra effort put into 
designing without using such information will pay off in a more robust and
maintainable system.

-- 
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.
Newsgroups: comp.lang.c++
From: walduck@mpr.ca (Andrew Walduck)
Subject: Re: Multiple Header Files Problem
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Tue, 10 Nov 92 16:45:47 GMT

In article <rmartin.721359424@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>A more interesting variation on this issue is the problem of "circular
>inclusion".  Consider a source file: "a.h" which includes "b.h".
>However, "b.h" includes "a.h".  This trivial example will fail to
>compile.  Unless the compiler is very clever (I haven't seen one yet),
>it will sit and spin until it exhauses some resouce (usually memory),
>and then it will die a horrible death.  If it prints an error at all,
>the error is nearly certain to have nothing to do with the circular
>containment.

Why not just wrap your headers in:

#ifndef someUniqueIdentiferPerFile_inc
#define someUniqueIdentiferPerFile_inc

#include <someotherfile.h>

// grotty code goes here...
#endif

It solves the problem for us...(between this and forward declarations...)


Andrew

-- 
Andrew Walduck, MPR Canada, walduck@mprgate.mpr.ca
-------------------------------------------------------------------------------
(I hope someone will flatter me by using this as a .sig quote...)
 -- Reid Kneeland
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: Const Inheritance
Date: 11 Nov 92 22:06:34 GMT
Organization: negligable

I modestly propose that setWidth() & setHeight() are entirely inapproprate
for the heirarchy (not the single class, but the heirarchy taken as a whole).

How about:

	class Rectangle : public graphicObject
		{
		...
		float fWidth, fHeight;
		float fRatio;
		public:
			virtual setHeight(float fNewHeight);
			virtual setAspectRatio(float fNew);
		...
		};


	Rectangle::setHeight(float fNewHeight)
	{
	fHeight = fNewHeight;
	fWidth	= fHeight * fRatio;
	redraw();
	}

	Rectangle::setAspectRatio(float newRatio) 
	{
	fRatio = fNew;
	setHeight(fHeight);		// let the other function do the work!
	}

	class Square : public graphicObject
	{
	...
	};

	Square::setAspectRatio(float newRatio) 
	{
	//- no-op for square, aspect ration initialized at 1.0
	}


There is more than one way to skin a cat, and height and aspect
ratio are entirely adequate to define both rectangle and square,
and you have no embarassing setSize(dim1,dim2) function hanging
around with no function.  setHeight() (perhaps generalize to
setSize() and inheirit from graphicObject parent...?)  does what
it should in all cases.  No artificial "it sets the width when
it shouldn't" to argue about.   :)


Basically if we have such a big problem with member functions 
during inheritance, perhaps you don't have the right member
functions defined  :) :)

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"There are no problems, only opportunities!"
"What we have here is an insurmountable opportunity..."
Newsgroups: comp.lang.c++
From: murali@saifr00.cfsat.honeywell.com (R. Muralidhar)
Subject: Re: Debugging output
Organization: Honeywell Air Transport Systems Division
Date: Thu, 5 Nov 92 18:59:29 GMT


In <Bx9369.3zL@cs.uiuc.edu> pjl@cs.uiuc.edu (Paul Lucas) writes:

>In <spuler.720931050@coral> spuler@coral.cs.jcu.edu.au (David Spuler) writes:

>>I was wondering whether anyone has any suggestions as to how to use the neat
>>operator << to produce debugging output in a way that it can be removed
>>easily from production code.  The obvious method is:

>>#ifdef DEBUG
>>   cerr << .....
>>#endif

>>but I'd like to avoid the #ifdef -#endif lines.

>*****>	Why?  In a "final" version, you don't want debugging code in the
>	object file.

I, too, have felt a similar need like David Spuler. For one, those #ifdef -
#endif lines interfere with neatly indented code, are unsightly, and make
the code less readable. (I don't discount their usefulness, don't get me
wrong.)

>>I've been trying to declare my own "dbg" streams by inheriting it
>>from the standard "ostream" class and redefining the << operators.

>	[stream that has flag whether to print elided]

>*****>	This is overkill; the same thing can be achieved without
>	inventing another class:

>	#ifdef DEBUG
>	#	define	CDEBUG	if ( debug ) cerr
>	#else
>	#	define	CDEBUG	//
>	#endif

>	CDEBUG << "here\n";

This method will work only if all the information to be 'output' appears in
one source line. What if I had to do (for readability purposes):

        CDEBUG << "here is senetence one.\n"
               << "here is sentence two.\n";

The technique Paul Lucas suggests wouldn't work, but David's would.

Muralidhar Rajappa                    murali@saifr00@cfsat.honeywell.com
Honeywell Commercial Flight Systems Group
Phoenix, AZ 
-- 
                 _
  /|/), , ;_ _  // .
(/  /(_<_/ '(_(_X_<_
murali@saifr00.cfsat.honeywell.com
From: yngvi@rhi.hi.is (Yngvi Sigurjonsson)
Newsgroups: comp.lang.c++
Subject: Pointer to constructors||class?
Date: 10 Nov 92 17:31:34 GMT



How can I get a pointer to constructor?? I would like too be able to
have a pointer to either a class or class constructor. I had intended to
use constructor pointers in a drawing program in such a way that mouse
down would do:

ObjPointer= new ConsPointer(x,y)

and then i could use virtual functions described for Object to work with
derived objects.

I imagine I could define wrapper functions, and pointers too those to
call to the constructors but I really dont want to.

Thanks in advance for any advice or pointers :).





-- 
 /| Yngvi Thor Sigurjonsson         |\ |\ ______________________/|
| | Fljotasel 17                    | || |   yngvi@rhi.hi.is   | |
| | Reykjavik Iceland               | || |_____________________| |
 \|_________________________________|/ |/_______________________\|
Newsgroups: comp.lang.c++
From: mcgrant@leland.Stanford.EDU (Michael Grant)
Subject: typeof operator?
Followup-To: comp.lang.c++
Summary: Good thing for templates to have
Keywords: typeof templates
Organization: Information Systems Laboratory, Stanford University
Date: Tue, 10 Nov 92 09:21:48 GMT

Has anyone in the C++ committee considered inclusion of a typeof()
operator into standard C++? It would certainly make for some very
interesting templates.

The typeof() operator exists in GNU g++, but I'm not sure it can
be used in the following manner. I would certainly hope it could.

Consider:

template<class T>
class Foo {
   T num;
   typeof(abs(T)) len;
   ...
}

Now, if 'double abs(double)' were defined in-scope, Foo<double> would yield

class Foo<double> {
    double num;
    double len;
...
}

But, if 'double abs(complex)' were defined in-scope, Foo<complex> would
yield

class Foo<complex> {
    complex num;
    double len;
...
}

Isn't that great? For readability's sake when writing member functions,
it would make sense to do something like

template <class T>
class Foo {
    typedef typeof(abs(T)) absType;
    complex num;
    absType len;
...
}

That way, inside member functions I can use Foo<T>::absType to refer to
the type of that variable. And, in more complicated situations, it seems
convenient for the template class to automatically track the changing
output types of the functions it uses.

Any comments? Of course, this can be MANUALLY simulated with things like

template <class T,class absT>
class Foo {
    T num;
    absT len;
}

but it seems that this is a natural extension to parametrized types.

Michael C. Grant
mcgrant@isl.stanford.edu

From: karen@hpfcbig.SDE.HP.COM (Karen Sturgeon)
Date: Wed, 11 Nov 1992 22:00:34 GMT
Subject: SoftBench Insight
Organization: HP SESD, Fort Collins, CO
Newsgroups: comp.lang.c++

Greetings SoftBench Insight Receivers:

We hope you are enjoying the premier issue of HP's SoftBench Insights
quarterly newsletter.  For comments or suggestions, please use this
corrected email address:

       softbench_insights@fc.sde.hp.com

Thank you,
Denise Scruggs
Hewlett-Packard
Managing Editor
(303) 229-6773
Newsgroups: comp.lang.c++