HDTenEightyP/NetNews huggingface dataset:
From: f254@cs.utexas.edu (Fall Class Account)
Newsgroups: comp.lang.c++
Subject: Help! Problem with Protogen (BC++ 3.1)
Date: 31 Dec 1992 21:59:54 -0600
Organization: U Texas Dept of Computer Sciences, Austin TX
Distribution: world
NNTP-Posting-Host: nada.cs.utexas.edu

I have been having trouble making the .prj generated by ProtoGen using
Borland C++ 3.1.  (It compiles ok but I get a lot of linker errors for
undefined symbols in making).  I thought the .prj files ProtoGen created
were ready to go for making, etc...  Or, am I supposed to add some .lib
to the .prj? 

If anyone has any experience/ideas on this, please post them here!

Thank you very much in advance.
From: banana@panix.com (Walter Polkosnik)
Newsgroups: comp.lang.c++
Subject: C++ Vectors
Date: 26 Dec 92 21:11:19 GMT
Organization: PANIX Public Access Unix, NYC

Is there a class somewhere lying around that handles vectors in the sense of
physics? Or a class that does the 4 vectors of relativity. This would be a
pretty useful thing for me to have. I've been trying to write one myself, but
I'm new to C++ and my compiler doesn't seem to recognise my overloading of
operators for the vector class I made. An ftp site would be nice.

Thanks.


-- 
Walter Polkosnik                 
Physics Department         banana@panix.com        
Queens College, CUNY       {cmcl2,apple}!panix!banana
Xref: sparky comp.lang.c++:18330 comp.object:4641
From: dwr@cci632.cci.com (Donald W. Rouse II)
Subject: Re: register variables in inline functions
Organization: [Computer Consoles, Inc., Rochester, NY
Date: Tue, 22 Dec 1992 20:55:31 GMT

In article <1992Dec15.192533.26033@vedge.com> hendrik@vedge.com (Hendrik Boom) writes:
>dwr@cci632.cci.com (Donald W. Rouse II) writes:
>: In article <1992Dec10.003109.25441@bilver.uucp> dandrews@bilver.uucp (Dave Andrews) writes:
>: >In article <1992Dec9.011428.11178@aplcen.apl.jhu.edu> ded@aplcen (nod sivad) writes:
>: >My understanding is that both "register" and "inline" may be ignored
>: >by your compiler.  They are only hints.
>: >
>: MY understanding is that "inline" may be replaced with "static",
>: but it may not be ignored.
>
>In 
>class foo{
>	int i;
>	inline int bar(){ return i;}
>	};
>inline cannot be replaced with static.

I forgot that you can explicitly declare member functions inline.
(In your example, "inline" is implied.)
I was thinking about non-member functions.
Non-member functions declared as "inline"
may be treated as "static" by the compiler
(scopewise, it _must_ be treated as "static").
The compiler may not simply ignore "inline" in that case,
since the function name would then have global scope.
If by ``"inline" may be ignored'' you meant that
the compiler does not actually have to put the
function body inline where it is invoked,
I agree with you.
Newsgroups: comp.lang.c++
From: ghawkins@unix1.tcd.ie (George C. Hawkins)
Subject: Not supposed to use static variables in member fns?
Organization: Trinity College, Dublin
Date: Thu, 31 Dec 1992 21:54:56 GMT


If a member function wants to remember a value between calls to it
then it must store that value in a varaible visible to all member
functions. Is this right? I was doing:

class Foo {
	void bar;
}

void Foo::bar()
{
	static int remember;

	// etc.
}

But was rather upset to find that all instances of Foo shared the
same 'remember'. I generally use g++ but I ran the above through
cfront and the way it produces the C code you can see this must be
true. I find this quite surprising, does C++ save you from using
global variables at one level by allowing you to pack things up
into objects only to force you into using variables that are visible
to all the members within an object.

Yours,


George.

--
george lives at:
___________________________________________________________________________
|   ghawkins@unix1.tcd.ie (mostly)  |   ghawkins@vax1.tcd.ie (sometimes)  |
---------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: girod@node_262d6.kiloapo.ts.tele.nokia.fi (Marc Girod)
Subject: Implementation of MI
Reply-To: marc.girod@ntc.nokia.com
Organization: kpd
Distribution: comp
Date: Thu, 31 Dec 1992 07:16:27 GMT

Hi netters!

In his book: 'C++ Programming Style', Tom Cargill suggests to test
your compiler with the following example (Listing 9.14 p 219)

-mi.C-----------------------------------------------------------
#include <iostream.h>

class Top {
    int x;
  public:
	Top();
	Top(const Top&);
    Top& operator=(const Top&);
};

Top::Top(): x(0) {
	cout << "\tTop::Top() this=" << this << "\n";
}

Top::Top(const Top& t): x(t.x) {
	cout << "\tTop::Top(const Top&) this=" << this << "\n";
}

Top& Top::operator=(const Top& rhs) {
	cout << "\tTop::operator=() this=" << this << "\n";
	if (this != &rhs)
		x = rhs.x;
	return *this;
}

class Left: public virtual Top {
	int y;
};

class Right: public virtual Top {
	int z;
};

class Bottom: public Left, public Right {
};

main() {
	cout << "Bottom first;\n";
	Bottom first;
	cout << "Bottom copy = first; \n";
	Bottom copy = first;
	cout << "copy = first;\n";
	copy = first;
	return 0;
}
-mi.C-end----------------------------------------------------------

Well, compiled under HP-UX with CC v3.0, I get the following output:

> mi
Bottom first;
	Top::Top() this=0x68fad210
Bottom copy = first; 
	Top::Top(const Top&) this=0x68fad234
copy = first;
	Top::operator=() this=0x68fad234
	Top::operator=() this=0x68fad234
>

...where as the author expected, Top::operator= is erroneously called
twice.

With g++ v2.3.3, both under HP-UX and SunOs, I get:

> mi
Bottom first;
	Top::Top() this=0x68fad210
Bottom copy = first; 
	Top::Top() this=0x68fad228
	Top::Top(const Top&) this=0x68fad228
copy = first;
	Top::operator=() this=0x68fad228
>

...where this problem doesn't appear..., but why is the Top
constructor called?

Happy New Year!
--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+
Newsgroups: comp.lang.c++
From: mbb@litwin.com (Mark Beyleveld)
Subject: testing for null pointer
Organization: Litwin Process Automation
Date: Mon, 28 Dec 1992 18:19:16 GMT

Assuming I declare

int* aPointer = 0;

is it valid to write

if (aPointer) {...}

or must I write

if (aPointer != 0) {...}

Also, are the rules for pointers to member functions the same?

---------------------------------------------------------------------
Mark Beyleveld
Litwin Process Automation
mbb@dynsim1.litwin.com				
-- 
---------------------------------------------------------------------
Mark Beyleveld
Litwin Process Automation
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: IS C++ a language for the "average programmer"
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 29 Dec 1992 00:10:31 GMT

In article <24498@alice.att.com> ark@alice.UUCP () writes:
>
>Now, you might argue that computers implement integers
>but don't truly imnplement reals -- but indeed they don't
>truly implement integers either.

	But with appropriate software they can implement
a subrange of integers as big as you can afford to buy the RAM for :-)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: daveg@synaptics.com (Dave Gillespie)
Newsgroups: comp.lang.c++
Subject: Re: Sizeof and Virtual functions
Date: 25 Dec 92 03:57:57 GMT
Organization: Synaptics, Inc., San Jose, CA
In-reply-to: mccauleyba@vax1.bham.ac.uk's message of 24 Dec 92 13:21:21 GMT

In article <1992Dec24.132121.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:

>> Isn't there a better way to implement virtual functions ? 
> No. The only other way would be to include the type information in the pointer
> itself so all pointers to objects of classes with virtual functions would
> become bigger. This would also mean that if a pointer were converted to void*
> and back it would loose it's type information. (I'm not sure if a compiler
> with this property would be conforming but it would certainly be unpopular).

Oh, surely you're not saying there is *no possible* other way to
implement virtual functions than this.

Consider:  Suppose you divided your memory space into pages, say of
size 1K.  Arrange so that a given page only contains objects of a
single given class (with virtual functions).  Make a table that maps
from page numbers onto virtual function tables.  If objects are small
enough so that many can fit on a single page, the virtual overhead is
essentially removed.  And in particular, the overhead is moved out of
the object itself, so we've removed the effect on the value of `sizeof'.

(Now, this ignores the issue of stack allocation of objects, or
inclusion of objects as members of other objects.  It would take
a lot of work to iron out all the details, but my point is, it's
*possible* to implement virtual functions in a totally different
way if that's what you really need.)

> Another solution would be to adjust the action of the `sizeof' and `(void*)'
> operators to refer to the object excluding its type indicator but
> this would break any code that used `malloc'.

It would break all kinds of things, in fact.

>> Isn't the current implementation a clever hack at best ?
> Possibly but the only alternative would be a clumsy hack.

Or something better that nobody's thought of, yet.

> Almost any use of void* and sizeof is implementation dependant, they are
> really part of C and C++ programmers should avoid them whenever possible.  

An excellent point.  The `new' operator was a fine innovation in C++,
even aside from its necessity when constructors are involved.  It
removes the one place in C where `sizeof' was needed in everyday
programs.

								-- Dave
--
Dave Gillespie
  daveg@synaptics.com, uunet!synaptx!daveg
  or: daveg@csvax.cs.caltech.edu
Newsgroups: comp.lang.c++
From: girod@tele.nokia.fi (Marc Girod)
Subject: New try: Access to private constructor for building a private static member
Reply-To: marc.girod@ntc.nokia.com
Organization: kpd
Distribution: comp
Date: Wed, 23 Dec 1992 06:19:20 GMT

Hi net world!

I got only one answer to this posting, a week ago (the subject was:
Initialization of private static members), telling me that the code in
my example works under xlC (RS6000 C++).

But nobody answered about whether it SHOULD work or not...

------------------------------------------------------------
// stinit.C

class A {
  private:
    A();
    static A a;
};

A A::a; //HP CC v 3.0: error: global scope cannot access A::A(): private  member (1298)
        //
        //GNU C++ version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
        //stinit.C: In function `void  _GLOBAL_$I$_1A$a ()':
        //stinit.C:5: constructor `A::A ()' is private
        //stinit.C:7: in base initialization for class `A'

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

The ARM states p 180 that 'Static members obey the usual member access
rules except that they can be initialized (in file scope)'.

This allows a private static member to be initialized, as long as the
constructor for its class is public.

Are my compilers correct in refusing me the access to private
constructors, to build a private static member?

Sorry if this has already been dealt with...

Best Regards!
...And incidentally, Merry Christmas!
--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: "type safety" deemed essential
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Tue, 22 Dec 1992 12:44:33 +0000

In article <448@genie.UUCP> roger@genie.UUCP (Roger H. Scott) writes:
> In article <rmartin.724430168@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
> >For any significant industrial application, I think strong typing is
> >utterly essential.  It is just too easy to create horrible run time
> >errors without type safety.  
> 
> This sounds like theory rather than practice speaking.  Let's hear from the
> (net) C++ user community: who has written a non-trivial commercial C++ 
> application *without* making significant use of either type casting [(T *)]
> or run-time type checking [Bar *bar_p = foo_p->asBar();]?  

Does my Text Mode User Interface Toolkit count ?

I DID use downcasting, but only as an efficiency hack in templated 
Collections, and all hidden from the caller in the Collection template.

I also used a construct VObject *v = editControl->inheritingVObject();
However, this was NOT type-safe downcasting, but used in the following 
inheritance DAG ...

   VObject       EditControl
     |              |
     +------+-------+
            |
       Some mixin class (e.g. TextEdit)

to enable some function taking a Collection of EditControls to display 
them on the screen (which requires them to be VObjects).

The Toolkit is currently approx 16,000 lines of code.

-- 
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.
From: detlefs@src.dec.com (Dave Detlefs)
Newsgroups: comp.lang.c++
Subject: Re: Special-purpose-heap-managers - references, FTP?
Date: 29 Dec 92 18:45:36 GMT
Organization: DEC Systems Research Center


I regard the proposition that special-purpose heap managers are "much
faster" than *all* general purpose ones as quite unproven.  It is
certainly true that there exist bad general purpose allocators, and
that special purpose allocators are much faster than these.  But this
does not imply that there can't be a really good general-purpose
allocator whose performance approaches the performance of writing a
special-purpose allocator for each class in your program.  In fact, I
believe that some variation on the Quickfit algorithm [1] fits the
bill.  If you want to look at some very interesting empirical studies
of allocator performance, I strongly recommend some papers by Ben Zorn
and Dirk Grunwald at the University of Colorado [2], [3].

The bottom line being that rather than mess around with custom
allocators in each program you write, it's possible that you can
solve the problem pretty once-and-for-all by getting a different
implementation of malloc on your system.

Dave
--------------------------------------------------
[1] Weinstock, C.B. and Wulf, W. A. Quickfit: An efficient algorithm
for heap storage allocation.  ACM SIGPLAN Notices 23(10): 141-144,
October 1988.

[2] Grunwald, D. and Zorn, B.  Custo-Malloc: Efficient Synthesized
Memory Allocators.  Technical Report CU-CS-602-92, Departement of
Computer Science, University of Colorado at Boulder, Boulder, CO, July
1992.

[3] Zorn, B.  The Measured Cost of Conservative Garbage Collection.
Technical Report CU-CS-573-92, Departement of Computer Science,
University of Colorado at Boulder, Boulder, CO, July 1992.
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Standard library functions and macros
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 2 Jan 1993 15:34:04 GMT

76336.3114@CompuServe.COM (Kevin Dean) writes:

>In an article date Dec. 31, Jim Adcock (jimad@microsoft.com) says:
>
>>"Reserved" in the same sense that ANSI-C reserved them -- that is if you
>>#include the corresponding ANSI-C standard header, then the function
>>names in that standard header become reserved. 
>
>In what sense do they become reserved?  I see no problem with reserving
>::fcnName() but I have difficulty accepting the idea that Class::fcnName()
>is reserved as well.

They become reserved as an identifier. Class::fcnName() is reserved because
fcnName() may be a macro. (Someone please correct me if my terminology is
not quite correct here).

>>If this is not acceptible, then simply don't include that standard header
>>file.
>
>All well and good but I've seen some compilers (Microsoft's among them)
>that, with certain optimizations turned on, reserve the function name
>anyway even though its corresponding header has not been included.  (I
>don't know if this applies to MSC 7.0 since I haven't played with it yet
>but it was certainly the case with 6.0).

When the header file is not included, they are still reserved, but only
as identifiers with external linkage. This means that Class::fcnName() is
OK, as is
	static fcnName() { ... }
or
	static int fcnName;
but not any of the following:
	fcnName() { ... }
	extern fcnName() { ... }
	int fcnName;

-- 
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: tandon@reef.cis.ufl.edu (Mridul Tandon)
Newsgroups: comp.lang.c++
Subject: RCS (Revision Control System)
Date: 27 Dec 92 16:27:15 GMT
Distribution: usa
Organization: University of Florida


I am interested in getting RCS (revision control system?) for my Sun
Workstation for managing C/C++ code. Can anyone suggest from where I can
download RCS source/binaries? Thanks.

Mridul Tandon.
Newsgroups: comp.lang.c++
From: 76336.3114@CompuServe.COM (Kevin Dean)
Subject: How to turn PC speaker off
Date: 21 Dec 92 18:55:34 GMT

C.S. Chang (cschang@umd5.umd.edu) writes:

>Is there any way to turn the PC speaker off so that there will be no
>beeps if a certain function call failed. 

class PowerCase {
  friend class ScrewDriver;
  friend class Pliers;

  Screws _screws[6];
  Speaker _speaker;
  // ... other private items here.
  
  void open();
  void close();

  public:

  void powerOn();
  void powerOff(); 
  };

class Screwdriver {
  // ...

  void undo(Screw & s);

  public:

  void openPowerCase(PowerCase & pc) {
  for (int i = 0; i < 6; i++)
    undo(pc._screws[i]);
  pc.open();
  }
  };

class Pliers {
  void cut(Wire & w);
  public:

  void disableSpeaker(PowerCase & pc) {
  cut(pc._speaker._wire);
  }
  };

main() {
PowerCase pc;
ScrewDriver sd;
Pliers p;

sd.openPowerCase(pc);
p.disableSpeaker(pc);

return (0); 
}

That should do it, I think.


Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Intersting Data Structure
Organization: Rational
Date: Wed, 23 Dec 1992 17:03:17 GMT

reznick@acf3.nyu.edu (Daniel Reznick) writes:

>Can anyone suggest a feasable Data Structure/Class Hierarchy to
>implement a Rubik's Cube?

Off the cuff, try this:

There are Cubies, which represent single cubes.  Two varieties:
CornerCubies and MiddleCubies.  Create Edges which contain pointer to
three Cubies.  Sides which contain pointers to four edges.  And a cube
which contains the six sides.

Sides can be rotated.  When they are rotated, they obtain the adjacent
sides from the cube.  The sides participate in a rotation of the
edges.  When an edge is rotated, it gets the adjacent edges from its
containing side and then rotates the cubies through the edges.  

THus, the cubies act as particles which move through the fixed
structure of edges, sides and the cube.  


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Newsgroups: comp.lang.c++
From: cleeland@cs.tulane.edu (Chris Cleeland)
Subject: Lex-compatible grammar for C++?
Nntp-Posting-Host-[nntpd-17525]: sinbad
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Distribution: usa
Date: Tue, 29 Dec 1992 21:55:41 GMT


Does anybody know where I might find a lex-compatible grammar
for C++?

Short, simple...Thanks!
-cj
-- 
----------------------------------------------------------------------
Chris Cleeland			"If your heart ain't in it,
cleeland@cs.tulane.edu		 then get your other part out."
Newsgroups: comp.lang.c++
From: dschieb@muse.cv.nrao.edu (Darrell Schiebel)
Subject: Re: template disappointments ... (suggesti
Organization: National Radio Astronomy Observatory
Date: Wed, 30 Dec 1992 18:57:56 GMT

In article <1992Dec30.165154.25081@nrao.edu> cflatter@nrao.edu (Chris Flatters) writes:
>
>Newsgroups: comp.lang.c++
>From: cflatter@nrao.edu (Chris Flatters)
>Organization: NRAO
>Lines: 47
>
>In article 92Dec29191250@gomez.stanford.edu, mcgrant@gomez.stanford.edu (Michael C. Grant) writes:
>>
>>In article <1992Dec29.204431.13413@nrao.edu>
>>cflatter@nrao.edu (Chris Flatters) writes:
>>   In article 92Dec29133556@muse.cv.nrao.edu,
>>   dschieb@muse.cv.nrao.edu (Darrell Schiebel) writes:
>>   >		class typeinfo {};
>>   >		template<class t> class typeinfo : public typeinfo {};
>>Yeah, that's a bummer. I see no reason why typeinfo and typeinfo<T>
>>can't be distinguished by any reasonable compiler.
	[explanation deleted]
>In principle it is possible to envision a template name space that is separate
>from the class name space but this would require the decision of whether an
>identifier is a class name or a template name to be made with some awareness
>of the context in which it appears.  This would rule out the use of LR(k)
                                                                     ^^^^^
>parsers (such as those generated by yacc) since syntactic elements are not
>recognized until all of their components have been scanned.  This is a fairly
>hefty price to pay.

	Although the Sun yacc man page says it "executes an LR(1) parsing 
	algorithm". The hard copy docs state that it accepts LALR(1) grammars,
	which is typical of most YACC implementations (A true LR parser with
	an arbitrary number of lookahead tokens...I wish).

	Since one cannot have an argumentless template, I don't see any great
	problem. Although, certainly it must be simpler to require that all
	class and template name be distinct.

>because it is forbidden by the language definition

	And this is the point which makes this whole discussion moot.


						Darrell Schiebel