HDTenEightyP/NetNews huggingface dataset:
From: qincao@cs.uh.edu (Qin Cao)
Subject: classes referenced each in their declaration
Organization: University of Houston
Distribution: na
Date: Tue, 21 Jul 1992 17:44:45 GMT

   I am implementing an interface with C++. I need to declare several classes
which are referenced each other in their defination. If I used pointer, then
it works fine, but I realy want to use dot notation to refer the class member,
instead of "->" notation when using pointer. Unfortunately without using
pointer, the C++ compiler does not buy that, it gave a error message: 
"incomplete field". The following fragments are examples to demonstrate my
problem.

#include <iostream.h>

class X;
class Y;

class X {
  int a;
  Y b;          // if I put "Y *b;" here, it works fine 
};

class Y {
 int c;
 X d;
};
 
main()
{
} 

Then if I compile the above code, a error message returned,says"imcomplete
type of filed b" for class defination of X. I knew that if I changed the
declaration of field b to "Y *b", it works fine. But I do want use dot
notation to refer its member, instead of pointer notation. So my question
is that is that possible to declare classes defination which are referenced
each other without using pointer in the class definations in C++.

Any suggestion or hint solution is appreciated. Thanks in advanced.
 


Newsgroups: comp.lang.c++
From: ssimmons@convex.com (Steve Simmons)
Subject: >>>>>>Naming collision of X11 Object and NIH Object class
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Date: Fri, 24 Jul 1992 12:57:14 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.


This should be a frequently asked question ;-.

Just jacket the X11 include files with defines and undefs


// To avoid namespace collisions between NIH and X:

#define Object XObject
#define String XString


#include <X11/cursorfont.h>        /* For various pointer fonts */
#include <X11/Xatom.h>

// Namespace collisions avoided.

#undef Object
#undef String


Thank you. 


					Steve Simmons
From: jwer@benson.az.stratus.com (justin werner)
Newsgroups: comp.lang.c++
Subject: compilers for i386/SVR4?
Date: 21 Jul 92 17:21:17 GMT
Reply-To: jwer@benson.az.stratus.com

I'm looking at two C++ compilers for i386 + ATT SVR4:
Computer Innovations & Liant/LPI.

1.	If you have had experience with one or both
	of these compilers, could you relate your
	problems/flames/plus-points/etc. to me?  Either
	e-mail or post would be fine.

2.	If you have suggestions for other compilers
	(other than g++), please let me know.

Again, my platform will be an i386 w/ATT SVR4


Thanks in advance,
justin werner

____________________________________________________
justin werner    jwer@benson.az.stratus.com     NeXT

"Death... by katunga!" - anonymous
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Cost of compiler
Organization: TauMetric Corporation
Date: Fri, 24 Jul 1992 15:47:24 GMT

brendan.woithe@f820.n680.z3.fido.zeta.org.au (Brendan Woithe) writes:

>I'm just wondering how much people pay for C++ compilers. I've heard them
>costing up to 1200 big ones, with toolboxes. Is that about average???

>And anyone in AMERICA - How much do you guys get it for
>   (in Australia everything is expensive)

Prices range over two orders of magnitude, from around $100 to over
$10000 for a single user.  It depends on the features of the C++ system,
the computer, and the O/S.  I don't know what kind of average would be
helpful under these circumstances.

But if a "big one" is in the range of $0.10 to $10, then 1200 sounds
about average. :-)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: gsbg9079@uxa.cso.uiuc.edu (G. Scott Braley)
Subject: Re: Looking for Adam Blum
Organization: University of Illinois at Urbana
Distribution: usa
Date: Fri, 31 Jul 1992 18:52:04 GMT

dshaker@qualix.com (Doug Shaker) writes:


>I am looking for an email address for
>Adam Blum, the author of "Neural Networks
>Software in C++".  Any help would be appreciated.

> - Doug Shaker

As it just so happens, I was about to post this note myself.  I am also
interested in an E-mail address for him.  Can anyone help?


			-Scott
			(217)356-1712
			gsbg9079@uxa.cso.uiuc.edu


-- 
*****************************************************************************
*  F.B.I.B.M.--The most feared merger  *  gsbg9079@uxa.cso.uiuc.edu         *
*****************************************************************************
From: dsf@cray.com
Newsgroups: comp.lang.c++
Date: 17 Jul 92 18:22 MDT
Subject: Re: NIH library gone?
Nf-ID: #R:1992Jul15.121149.22974@hemlock.c:-1438125699:1992Jul17.092228.4538@hemlock.cr:1098240733:001:1682
Nf-From: cray.com!dsf    Jul 17 18:22:00 1992


In article <1992Jul15.121149.22974@hemlock.cray.com> dsf@cray.com (Dan Frankowski) writes:
>I have the National Institute of Health Class Library (NIHCL) version 3.0
>and I would like to obtain 3.10, especially the documentation.
>
>The C++ FAQ (thanks Marshall Cline!) says that the NIHCL may be
>obtained via anonymous ftp from [128.231.128.251] (ns.nih.gov).  I
>have tried several times over the last couple of weeks and been
>refused anonymous ftp.  It was always during business hours.
>
> (other questions deleted)

I received an email reply that was probably the output of "archie
nihcl", which is what I should have done.  Duh.  For those of you who
don't know, archie servers are databases of anonymous ftp listings
that respond to queries.  Often your system will have a command
"archie" to query a server, just like "webster" queries a Webster
dictionary server.

Many of the listings seem to be at alw.nih.gov (128.231.128.7) in /pub
or mirrors of it, such as citi.umich.edu (141.211.128.16) in
/afs/alw.nih.gov/dcrt/kgorlen/(several directories here).

I ended up getting the documentation for 3.10 from psuvax1.cs.psu.edu
(130.203.1.6) in /pub/src/C++, but I still haven't found the source
for 3.10.

The moral of the story: Use archie!

Dan

--------------------------------------------------
Here is a partial listing of what is out there:

nihcl-2.204a.tar.Z
MartinNihcl3-100.tar.Z
MartinNihcl3-101.tar.Z
nihcl-3.0-dec1.0-diffs.Z
nihcl-3.0-sun2.1-diffs.tar
nihcl-3.0-sun2.1.tar.Z
nihcl-3.0.tar.Z
nihcl-info-3.10.tar.Z
nihcl.tar.Z
nihcl.dos
NIHCL
NIHCL.info
NIHCL.texinfo
nihcl.ps
nihcl.dvi
nihcl

-- 
Dan Frankowski            dsf@teak.cray.com     (612) 683-5099

Newsgroups: comp.lang.c++
From: mittle@watson.ibm.com (Josh Mittleman)
Subject: Re: inlining a virtual function.
Date: Thu, 23 Jul 1992 19:59:45 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center
Keywords: inline virtual

> class A {
>   virtual int f() { return 1; }
> };

> "x.c", line 1: warning: virtual function  A::f() cannot be inlined

> My question is why CANT we inline a virtual function?

An inline function does not have an address, because it does not generate a
function call.  Instead, it is expanded at compile time (sort of like a
macro).  A virtual function has to have an address, which will be stored in
the virtual function table, and must always be accessed through a function
call. 

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
From: maxtal@extro.ucc.su.OZ.AU
Newsgroups: comp.lang.c++
Date: 17 Jul 92 20:48 MDT
Subject: Re: Member function pointers, (Base::*)
Nf-ID: #R:1992Jul16.151946.1@ssrl01.slac.s:507495057:1992Jul17.164853.29520@ucc.su.oz:2107714212:001:1805
Nf-From: extro.ucc.su.OZ.AU!maxtal    Jul 17 20:48:00 1992


In article <1992Jul16.151946.1@ssrl01.slac.stanford.edu> tcox@ssrl01.slac.stanford.edu writes:
>
>I have formed the belief that by careful coding techniques, one can avoid
>the use of explicit casts on C++ code, except where interface into other
>language modules is concerned (in this case, the Motif/Xt toolkit).

	Good.
>
>However, there is one stubbon problem which I cannot for the life of me see
>an elegant solution for, so I am posting this in the hope that someone can
>enlighten me.
>
>Now, as Motif programmers will know, PushButton callbacks, and indeed
>pretty much all callbacks within Motif, end up calling a "C" routine with
>the following declaration:-
>
>		actionRoutine( Widget, XtPointer clientData, XtPointer)
>
>The first arg is the widget wherefrom the callback originated, the second
>is any (equiv to void*) user provided pointer, and the third is the
>address of an Xevent structure which further defines the operation.


	Unless I misunderstand :

Provide ONE only callback routine in your entire progam.

	actionRoutine(Widget W, void *object, XtPointer X)
	{
		WidgetObject* w=object;
		w->execute(W,X);
	}


Where:
	class WidgetObject { 
	public: 
		virtual execute(Widget,XtPointer)=0;
	};


To define the behaviour, derive a class from WidgetObject.
You must supply the object somehow to Motiff to
call you back with.


[PS: I'm not a Motif or even X user, I use Windows. The above
type of solution is what I do there. It might need tuning.
But the key is ONE only callback (of each type in Windows).]


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: jvb@cray.com (Jeff Boyd)
Newsgroups: comp.lang.c++
Subject: c++ performance codes
Date: 28 Jul 92 18:15:28 GMT
Organization: Cray Research, Inc.

Does anyone know of any good c++ codes that could be used
for performance analysis?
From: Tazzzzz.Is.Sexy@UM.CC.UMICH.EDU
Newsgroups: comp.lang.c++
Subject: Tazzzzz Is Sexy
Date: 22 Jul 92 06:00:38 GMT


 
Tazzzzz Is Sexy!
From: wright@epx.cis.umn.edu (Mark Wright)
Newsgroups: comp.lang.c++
Subject: Bizarre Borland stream bug
Date: 30 Jul 92 18:53:27 GMT
Organization: University of Minnesota

OK, now this is REALLY silly. I'm compiling the following program
under Borland C++ v3.1.  All it does is read in a file with the format
given below.  It looks like borland's stream class DOESN'T LIKE THE
NUMBER NINE!!!  Am I doing something weird, is this the compiler, or
should I call in an exorcist...
 
 
#include<iostream.h>
#include<fstream.h>
 
struct PointRecord {
  int pointno;
  double x;
  double y;
};
 
 
void main( int argc, char *argv[] )
{
  PointRecord point;
  ifstream inFile( argv[1], ios::in );
 
  for (;;) {
    if (!(inFile >> point.pointno))
      break;
    if (!(inFile >> point.x))
      break;
    if (!(inFile >> point.y))
      break;
 
 
    cout << point.pointno << ": "
         << point.x       << ", "
         << point.y       << endl;
  }
}
 
 
/*
FILE 1:
0001    111111.1111     111111.1111
0009    222222.2222     222222.2222
 
PROGRAM OUTPUT:
1: 111111.1111, 111111.1111
0: 9, 222222.2222
 
 
FILE 2:
0009    222222.2222     222222.2222
0001    111111.1111     111111.1111
 
PROGRAM OUTPUT:
0: 9, 222222.2222
25614: 0.2222, 1
-19961: 0.1111, 111111.1111
*/
 
 
 
Mark Wright
wright@epx.cis.umn.edu
Newsgroups: comp.lang.c++
From: mittle@watson.ibm.com (Josh Mittleman)
Subject: Re: const on pass by value
Date: Fri, 24 Jul 1992 17:23:25 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

In article <1992Jul24.151010.11969@PacBell.COM>, pjcondi@lepton (Paul
Condie) writes:

> Should pass by value arguments be declared as "const" for
> good coding style?  Or is that nit picking?

A blanket convention makes no sense.

For scalar arguments, it doesn't really matter: The user can see that the
argument is passed by value, so he doesn't care whether or not it is const.
If you find it convenient, make it a const.

For struct or class arguments, it may make a difference, and it is
important to tell the user whether you will change the argument or not.
Use const appropriately.

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
Newsgroups: comp.lang.c++
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: New C++ type: boole
Organization: Texas Instruments Inc
Date: Mon, 27 Jul 1992 13:52:43 GMT

In <9220914.11530@mulga.cs.mu.OZ.AU> fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

>The following is actually from Deviasse Robert N <a228devi@cdf.toronto.edu>.
>I am posting it for him, since he does not have write access to the net.
>Disclaimer: if you don't like it, blame him! :-)

>	Fergus.

>========================== PROPOSAL FOLLOWS =============================

>Actually there is a general way of adding a boole type without breaking any
>C++ code. Every DOS compiler I've used (and a few UNIX ones) already give
>warning for code such as "if (ch=getchar()) /*...*/;". Such warnings could
>easiliy be made manditory in the standard, or the standard could reserve
>a pragma that does this type of checking, though the implementation may
>choose not to implement it. 

NO!  Do *NOT* make this warning mandatory.  Some of us prefer to write
code like this on purpose.  Accidently using '=' where I meant '=='
has never been a problem for me, and I find 'if (x=f(z))' to be a much
more concise statement of what I want (if f(z) returns a zero or null
pointer, do the body of the if; whatever happens, assign the returned
value to z) than having to parenthesize and then add an explicit
comparison to 0 for the 'if'.

This is one warning that I always turn off in PC compilers.  Pure
annoyance. 

>I think that most people would like to have a boolean type in C++, although
>most people have resigned themselves to thinking that boolean types
>cannot easily be added to C++.

The only 'advantage' I can see to a 'real' boolean type is if you can
guarantee me that it will only take up one bit and the compiler is
bright enough to store them all off in some bit array someplace to
save space.  Otherwise, I guess I fail to see any pressing need for
this.

I think there are a lot better ideas than this to expend effort on
(things like real subrange types, for example, which would allow
'bool' to be implemented as a subrange from 0..1, for folks who really
feel like the need bool).

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.c++,comp.lang.c
From: anderson@dseg.ti.com (John Anderson)
Subject: PC Based C Compiler targeted to Mips R3000
Organization: TI-DSEG Spring Creek
Reply-To: anderson@dseg.ti.com
Date: Thu, 30 Jul 1992 22:03:41 GMT


Does anyone know of a C or C+++ compiler that runs on a PC but produces object code
for a MipsCo R3000 Risc processor?

If so, please send me the name and address.

Thanks

John Anderson

Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Distribution: world
Subject: inherited:: proposal (Was: Renew?)
X-Mailer: cppnews $Revision: 1.10 $
Organization: Trumphurst Ltd.
Date: Fri, 31 Jul 1992 10:47:49 +0000


In article <1992Jul28.184049.24609@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> 	Hope Bjarne doesnt mind me posting this.
..
> From bs@research.att.com Tue May 19 04:13:57 1992
..
> This paper proposes the extension of C++   with the  keyword
> inherited,  a  qualified-class-name used to denote an inher-
> ited class member.  The advantages are a clearer inheritance
> relationship  and  increased programming safety.  The imple-
> mentation cost is small, and the consequences  for  existing
> code minor.
..
> We will
> never know if  this  proposal  would  have  passed,  though,
> because  at  this  point  in the discussion, Michael Tiemann
> walked in and muttered something like ``but  we  don't  need
> that extension; we can write code like that already.''  When
> the murmur of ``but of course  we  can't!''  had  died  down
> Michael showed us how:
> 9     class foreman : public employee {
>          typedef employee inherited;
>          // ...
>          void print();
>      };
> 99     class manager : public foreman {
>          typedef foreman inherited;
>          // ...
>          void print();
>      };
> 99     void manager::print()
>      {
>          inherited::print();
>          // ...
>      }
> What we hadn't  noticed  was
> that  the  re-introduction  of  nested  classes into C++ had
> opened the possibility of controlling the scope and  resolu-
> tion of type names exactly like other names.
I found this example very illuminating (not surprising, considering its 
source :-). I might well start using "inherited" typedefs in my user
interface toolkit (although I might call it "base" or "super" instead of
"inherited" - comments anyone ?). 

I would be interested to learn about other proposals which have been 
rejected, particularly those for which the main reason for rejection was 
that existing language features made the proposal unnecessary. I feel I 
could broaden the scope of my C++ knowledge considerably this way.

Is there anywhere where I could obtain access to such information ?
---
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 connected with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
From: head@dorsai.com
Newsgroups: comp.lang.c++
Date: 18 Jul 92 00:26 MDT
Subject: Re: C++ for VAX/VMS
Nf-ID: #R:daily-planet.concordia.ca:4542:1992Jul17.202648.18621@dorsai.co:1671847644:001:980
Nf-From: dorsai.com!head    Jul 18 00:26:00 1992


henry2@sunlite.concordia.ca (Henry Polley) writes:
: 
: Does anyone know of a c++ compiler for the vax/vms environment?
: I am looking for something that is commercial preferably.
: 

I'm not sure of a commercial product, but the Free Software Foundation offers
the GNU C++ compiler.  You can find it, and a lot of other wonderful things
on the DECUS tapes (thanks R.S.).

GNU software is not commerical (in fact, just the opposite).  I have found
it to be excellent.  I have had a problem with GNU C++ streams, however.
I'm getting an unresolved linker error on a symbol that is clearly the
munged name for stream operator<<.  I checked the VMS library distributed
with GNU C++, and I did find a symbol that matches almost exactly -- it's
off by a single character ("$" v. "_" I think).  Anyway, I'm pretty sure
I didn't install and build things correctly, and that is the cause of the
linker problem.  (If anyone can clue me in to how to resolve it, I'd be
most appreciative.)


Newsgroups: comp.lang.c++
From: zoo@cygnus.com (david d 'zoo' zuhn)
Subject: Re: C++ for VAX/VMS
X-Md4-Signature: 2f5abba9ddf5052e56b311349a863b41
Organization: Cygnus Support -- +1 415 322 3816
Date: Wed, 22 Jul 1992 23:43:13 GMT
Followup-To: gnu.misc.discuss


[ note Followup-To; as this isn't appropriate for comp.lang.c++ ]

   From: head@dorsai.com

   GNU software is not commerical (in fact, just the opposite).  I have found
   it to be excellent.  

I will take exception to the first statement.  GNU software can very
easily be commercial software (Cygnus and Crynwr and other attest to
this fact).  It just happens to be under terms that are quite unlike
most other commercial software: you can share it.

And the reason for the second statement above (which I agree with) is
the fact that since it *can* be shared, improvements *are* shared,
from user to user and user to developer.  

Many commercial software houses use GNU software.  Many hardware
vendors are shipping gcc with their operating systems.   


  david d 'zoo' zuhn |  
    cygnus support   |  "Man made it, man can fix it."
    zoo@cygnus.com   |  		-- anonymous biker in South Dakota

Newsgroups: comp.lang.c++
From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Organization: netmbx, Berlin, Germany
Date: Wed, 29 Jul 1992 07:48:19 GMT

chip@tct.com (Chip Salzenberg) writes:

>But once you've frozen a C++ object into a dead array of bytes, it's
>no longer a C++ object, so the C++ type system is no longer operative.

>So RTTI and persistence are only marginally related subjects.

RTTI is needed to properly freeze a C++ object into a "dead array of
bytes" and to turn a "dead array of bytes" into a C++ object.  It is
also needed to follow references among objects in RAM.

Unfortunately, the proposed standard will not provide enough info to
do this, according to Mat Mol.  He referred to a second standard for
extended type information that might have enough infor but which he
suggests might not make it into the standard.  I am trying to get my
hands on these proposals, but it may take a few weeks...

RTTI and persistence are related enough that all of the major C++
database systems use precompilers to get at it.  Since a precompiler
requires real programming effort I don't think we would do that if
it weren't needed...



Jonathan

===========================================================================

Jonathan Robie		jrobie@netmbx.UUCP
Arnold-Zweig-Str. 44	jrobie@netmbx.in-berlin.de
O-1100 Berlin		
Deutschland		Phone:  +37 (2) 472 04 19  (Home, East Berlin)
				+49 (30) 342 30 66 (Work, West Berlin)


-- 
Jonathan

===========================================================================
From: jld2@ns1.cc.lehigh.edu (J. Lynch Davis)
Newsgroups: comp.lang.c++
Subject: Makefile Problems with BC 2.0
Date: 31 Jul 92 19:08:22 GMT
Organization: Lehigh University

I am compiling the files with bcc -c fname1 fname2 but when I try to link the
files, I am getting a no stack error, and it usually doesn't find my stdlib
routines.  I am not using any parameters when I try to link

Thanks,
Lynch

jld2@lehigh.edu
Newsgroups: comp.lang.c++
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: strdup() Was: Re: Renew?
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia
Date: Fri, 31 Jul 1992 17:07:04 GMT

hansen@pegasus.att.com (Tony L. Hansen) wrote:
> >    #include <string.h>
> >    char *nstrdup(const char *s)
> >    {
> >	if (!s) s = "";
> >	char *ret = new char[strlen(s) + 1];
> >	if (ret) strcpy(ret, s);
> >	return ret;
> >    }
> 

I wrote:
> Elegant answer but has a little problem.
> 
> char* ptr = nstrdup(0); // ptr = ""; not allocated by new
> delete [] ptr;		// error
> 
> Therefore, I suggest the following change.
> 
> if (!s) return 0;

Tony Hansen corrected me in a private mail. Thanks.
I incorrectly copied his nstrdup and that is why
I got that error.

I copied
	if (!s) return "";
instead of
	if (!s) s = "";

In the latter case, nstrdup correctly returns newed
memory and hence, delete [] ptr will work.

Sorry for the confusion.

-Sekar
Newsgroups: comp.lang.c++