HDTenEightyP/NetNews huggingface dataset:
From: ghawkins@unix1.tcd.ie (George C. Hawkins)
Subject: How do I write a typedef to go with my template class?
Summary: See subject line.
Keywords: template generic define
Organization: Trinity College, Dublin
Date: Wed, 26 Aug 1992 19:11:01 GMT


I can use templates for classes but how do I write a typedef to go
with a template class. At the moment I have a horrible solution
using a massive #define. I have a '.h' file, such that if I have
a class X and use the line:

	Callbackdeclare(X);

I get a new class (called Callback<X> if I was using templates).
*And* I also get a typedef to go with it. I think to reimplement
the class to be a template class is no problem, but how do I get
the very handy typedef to go with it. As far as I can see templates
only have "scope" over the class or whatever that follows them. I.e.
I can't do:

	template <class X>
	class Callback {
		...
	}
	typedef void (X::func_ptr)(int);

And even if I could I'd get name clashes for all my typedefs for
Callback class being used with different X types.

So what's the solution? At the moment I have this code to
do things:

#define Callbackdeclare(CLASS)					\
class CLASS;							\
								\
typedef void (CLASS::*name2(CLASS,PMF_CB))( int );		\
								\
class name2(CLASS,Callback) {					\
								\
private:							\
								\
	CLASS* _obj;						\
	name2(CLASS,PMF_CB) _pmf;				\
	...

Fairly ghastly stuff I guess, but it works and solves a really
tricky problem.  (If you haven't come across name2(x,y) before it's
just a concatenation macro, so after cpp has gone through say
'name2(call,back)' it will be replaced by 'callback'.)

So please, please help me develop a clean solution with templates.
Thanks for your time, yours,


George.

--
george lives at:
___________________________________________________________________________
|   ghawkins@unix1.tcd.ie (mostly)  |   ghawkins@vax1.tcd.ie (sometimes)  |
---------------------------------------------------------------------------
From: baden@sys6626.bison.mb.ca (Baden de Bari)
Newsgroups: comp.lang.c++
Subject: Re: Is C++ "for the rest of us" ?
Date: Sun, 23 Aug 92 12:25:43 CST
Organization: system 6626 BBS, Winnipeg MB

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

> In article <k9!nz8l.nagle@netcom.com> nagle@netcom.com (John Nagle) writes:
> >       I'd recommend learning Smalltalk before C++, even if you never intend
> >to write anything in Smalltalk.  Smalltalk offers object-oriented programmin
> >with safety, at some cost in performance.  
> 
> 	You're kidding right? About safety? Smalltalk is
> type-safe in vacuuo :-)
> 
> >In Smalltalk, one can actually
> >see what this OOP thing is all about and what it buys you.  Then one can
> >learn to deal with the compromises made in C++ to bolt OOP onto C without
> >adding garbage collection.  If you learn C++ first, the clunky features
> >of the language obscure the object-oriented concept.
> 
> 	Perhaps you should learn C++ first to see what static
> type safety buys you. Then you might consider why C++ compromises
> heavily in favour of security. Of course GC is an exception to this IMHO.
> 
> >
> >       I'd avoid any C++ without templates for new work.  You really
> >need a generic capability to make OOP work, and hokey schemes with
> >macros and heavy use of "(void *)" bypass most of the type checking
> >while not making it clear where it has been bypassed.
> 
> 	Yes, but I dont see the connection between genericty
> and polymorphism, on the contrary I thought they were totally
> different mechanisms.
> >
> >       I suppose we all have to go to C++, but after two years with the
> >language, I wish something better were available.
> >
> >					John Nagle
> 	We all agree here surely :-)
> 
> 
> -- 
> ;----------------------------------------------------------------------
>         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
> 	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
> ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
 
 
            I'd like someone's views on the advantages of OOD in Prolog, 
versus OOD in Smalltalk.  I was thinking of starting out in TC++, but 
since I'm not well versed in the criptiveness of TC++ I'd like a more 
proffessional opinion on which to use.
 
                >>Baden<<



;--- (Baden de Bari) a user of sys6626, running waffle 1.64
;E-mail: baden@sys6626.bison.mb.ca
;system 6626: 63 point west drive, winnipeg manitoba canada R3T 5G8
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: auto T&
Date: 26 Aug 92 02:11:45 GMT
	<9223817.24813@mulga.cs.mu.OZ.AU> <17dlcaINNafv@early-bird.think.com>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: barmar@think.com's message of 25 Aug 92 15:59:06 GMT

In article <17dlcaINNafv@early-bird.think.com> barmar@think.com (Barry Margolin) writes:

   In article <9223817.24813@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
   >Here again compilers should be smart enough to optimize away the both the
   >unnamed temporary AND the named temporary "retval".
   >I don't know whether the latter optimization is allowed by the ARM
   >(I suspect not), but it SHOULD be.

   It is in limited cases.  Sec. 3.5 of the ARM explicitly says, "nor may an
   automatic named object of a class with a constructor or a destructor with
   side effects be eliminated even if it appears to be unused."  In most
   cases, I suspect compilers won't check for the "with side effects" (if the
   constructor or destructor isn't inline, they generally can't), and some
   compilers may not even check whether the class has a contructor or
   destructor.

Yes, and this rule is unlikely to change. People are using
constructors/destructors not only for memory management but also as a
form of UNWIND-PROTECT (e.g., create a window on block entry and make
sure it gets destroyed on block exit, no matter what).

I think this is in line with the C/C++ philosophy of using a "small"
number of primitives for as many purposes as possible. In C++, classes
are being used for OO programming, as modules, and for cleanup jobs at
the end of blocks. I'm not sure whether this is a good strategy in the
long run.

					Thomas.
Newsgroups: comp.lang.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: destruction of temporaries
Date: Thu, 27 Aug 1992 00:44:34 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

jimad@microsoft.com (Jim Adcock) writes:
|I suggest that something like the following set of rules would in practice
|allow compiler implementations such that all existing conforming
|compiler/program pairs could continue to work:

[ some rules deleted ]

|3) Temporaries must live until after their last access or end of block --
|whichever comes first.

In order for this to work, we would need rules as to what constitutes
an 'access' to a temporary.  What rules would you suggest?
(Personally, I think finding good rules would be a very hard
problem.  But I hope to be pleasantly surprised.)

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Newsgroups: comp.lang.c++
From: lheureux@alysse.fai.ucl.ac.be (Olivier L'Heureux)
Subject: Re: Graph Library ?
Organization: Computer Science Department, Catholic University of Louvain
Date: Mon, 31 Aug 1992 13:25:28 GMT

u8903845@cs.uow.edu.au (Anil Sachdeva) writes:
> Hi I was wondering , If there is any Graph Library Around . 
> Shortest Distance and etc . In C++ or in C .
> 
> Thanks
> 
> u8903845@cs.uow.edu.au

Have a look over "LEDA", from K. Mehlhorn and S. Naher. This C++ library
has graph objects. It was described and reviewed in Dutta's C++ product
list posted in "comp.lang.c++".

LEDA can be ftp'ed from ftp.th-darmstadt.de (130.83.55.75), directory
/pub/programming/languages/C++/c++-products or from ftp.cs.uni-sb.de
(134.96.252.31), directory pub/LEDA.

						Olivier L'Heureux
------------------------------------------------------------------------
Olivier L'Heureux (lheureux@fai.ucl.ac.be)
                    ,                          ,
Laboratoire de Microelectronique de l'Universite Catholique de Louvain
place du Levant, 3   B-1348 Louvain-La-Neuve          Belgium.
Newsgroups: comp.lang.c++
From: hosken@spss.com (Bill Hosken)
Subject: Re: GOTO, was: Tiny proposal for na
Organization: SPSS, Inc.
Date: Thu, 27 Aug 1992 18:10:13 GMT

In article <rmartin.714931485@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:
> hosken@spss.com (Bill Hosken) writes:
> 
> >Clear thinking helps to write good code, gotos whether or not.
> 
> 
> This is sort of like saying:  "I am an expert driver, my clarity of
> driving skills entitles me to ignore certain stop signs, when I know
> (by virtue of my great skill) that there is no cross traffic.
> 
> 
> So we have rules.  These rules protect us average types from the guys
> who think they are "real good drivers".  When some guy blows a stop
> sign, it doesn't matter to me, one whit, if he is the greatest driver
> in the world, I will still applaud the cop who pulls him over.
> 

The rule "avoid goto" does not stop anyone from writing confusing
code.  It probably makes some people think more about the code
they write when seeking alternatives to the goto, but taken alone
it does little good.  

A better rule would be "Be prepared to give a clear and convincing
argument that the code is correct".
From: jh@first.gmd.de (Joerg Heuer)
Newsgroups: comp.lang.c++
Subject: Re: Turbo C++, function prototypes
Date: 1 Sep 92 12:05:48 GMT

zpvy0a@hou.amoco.com (Prasad Yalamanchi WWNV x4269 9.125) writes:

>I am trying to compile a program on Turbo C++, 3.0 . It gives me the following

>error.

>main () , function prototype missing.

>Do i need to put in the 'main' function's prototype. 

>void main();

>was still giving me errors.  Could someone help.

main's correct return type is 'int'. Try it. It's always better to write
the things You mean explicitly. (Though it should work with the implicit
'int'.)

J"org.

--
Joerg Heuer                   | UUCP:     jh@gmdtub.uucp
GMD-FIRST an der TUB          | INTERNET: jh@first.gmd.de
Rudower Chaussee 5, Geb. 13.7 | KOMEX:    heuer@kmx.gmd.dbp.de
D-1199 Berlin Adlershof, FRG  | Tel/Fax:  +49 30 6704 - 5819/5610
Newsgroups: comp.lang.c++
From: glw@ioit.uswc.uswest.com (Glenn Williams)
Subject: Re: Borland C++ 3.1 Buggy any alternatives?
Organization: US WEST Information Technologies
Date: Fri, 4 Sep 1992 19:40:39 GMT

I have been using Borland's C++ since it came out and I have only experianced these kind of problems on my old 286 PC( six years old ), and very rarely indeed. My 386DX has never had any problems like this. In fact since I received 3.1 I have not had my machine hang once( except for user generated stupidity ).

I also own Zortech and I have never been happy with their environment or support. I have never received any notice from them of new product's or updates. Never in 2 years.

I gave up on Microsoft altogether.

glenn williams
US WEST

"Its show time!"
From: kudva@ecn.purdue.edu (Gautham K. Kudva)
Newsgroups: comp.lang.c++
Subject: C++ 3.0 for SPARCs?
Date: 1 Sep 92 15:41:50 GMT
Distribution: usa
Organization: Purdue University Engineering Computer Network

Hi,
	Our research group has recently started using C++.
We do most of our development work on Sun SPARC workstations.
So far we've been going with cfront 2.1, and we'd like to upgrade
to C++ version 3. Our primary reason for upgrading is Template
support. Does anyone have experience with any cfront compliant 
C++ compilers with template support for Suns? In particular how 
about USL C++ 3.0? Any comments or suggestions are greatly 
appreciated. 

Please post or e-mail me at kudva@ecn.purdue.edu. If there's
sufficient interest, I'll summarize.

Thanks much in advance,
Gautham Kudva
Newsgroups: comp.lang.c++
From: dsf@cray.com (Dan Frankowski)
Subject: Re: C++ FAQ and Style Guides
Organization: Cray Research, Inc.
Date: 4 Sep 92 09:26:47 CDT

In article <esimon.715604158@imlab1> esimon@sdeserver.estec.esa.nl writes:
>Indication of a FTP site for C++ FAQ would be very much appreciated.

From the FAQ:

	Availability:	This is available via anonymous ftp
			from: sun.soe.clarkson.edu [128.153.12.3]
			in the file: ~ftp/pub/C++/FAQ

	Without FTP:	You can also get it by sending electronic mail:
			|	To: archive-server@sun.soe.clarkson.edu
			|	Subject: send C++/FAQ
			This will help those who don't have ftp.

	See also:	comp.lang.c's FAQ appears at the beginning of every
			month in that newsgroup, and is maintained by
			Steve Summit (scs@adm.mit.edu).

	Author contact:	Marshall Cline
			Paradigm Shift, Inc
			65 N. Main St. / Norwood NY 13668-1121
			voice:315/353-4585, fax:315/353-6110
			email:cline@sun.soe.clarkson.edu

	Copyright:	Copyright (C), 1991,1992 Marshall P. Cline, Ph.D.


>Thanks,

You're welcome.

>Erik
>E-mail: esimon@sdeserver.estec.esa.nl

DISCLAIMER: This ain't official Cray business.


-- 
Dan Frankowski            Dan.Frankowski@cray.com     (612) 683-5099
From: skip@taygeta.oc.nps.navy.mil (Skip Carter)
Newsgroups: comp.lang.c++
Subject: copy ctor and inheritance
Date: 3 Sep 92 17:41:37 GMT
Reply-To: skip@taygeta.oc.nps.navy.mil (Skip Carter)


	How do I get the copy constructor of a base class to get invoked
	when I use a copy constructor for a base class ?

	In the following example I get the behaviour I want (AT&T 2.1)
	if I leave it up to the compiler to create the copy constructor for B,
	but if I write my own, the copy constructor for the base class A never
	gets invoked.  (It does not matter whether or not I define the copy constructor
	for the base class, A).


#include <iostream.h>

class A
{
	private:
	  int val;
	public:
	  A() : val(0) { cout << "A() invoked\n"; }
	  A(const A& a) { val = a.val; cout << "A(&A) invoked,  val = " << val << '\n'; }
	 ~A() { cout << "A.val = " << val << " going away\n"; }
	  void set_val(const int v) { val = v; }
	  int get_val() const { return val; }
};

class B : public A
{
	private:
	   int vv;
	public:
	  B() : vv(0) { cout << "B() invoked\n"; }

                      // If the constructor below is commented out, A::val is copied
	//    B(const B& b) { vv = b.vv; cout << "B(&B) invoked\n"; }

	 ~B() { cout << "B.val = " << vv << '\t' << get_val() << " going away\n"; }
	  void set_v(const int v) { vv = v; }
	  int get_v() const { return vv; }
};

void main()
{
	A a;

	a.set_val( 3 );

	B b;

	b.set_v( 2 );

	b.set_val( 1 );

	// no surprises here
	cout << "A = " << a.get_val() << endl;
	cout << "B = " << b.get_v() << '\t' << b.get_val() << endl;


	// now for the real test

	B c( b );

	cout << "C = " << c.get_v() << '\t' << c.get_val() << endl;

}


-- 

 Everett (Skip) Carter             Phone:  408-646-3318 FAX: 408-646-2712
 Naval Postgraduate School         INTERNET: skip@taygeta.oc.nps.navy.mil
 Dept. of Oceanography, Code OC/CR  UUCP:     ...!uunet!taygeta!skip
 Monterey, CA. 93943               TELEMAIL: s.carter/omnet
Newsgroups: comp.lang.c++
From: brennan@hal.com (Dave Brennan)
Newsgroups: comp.lang.c++
Subject: What happens if I throw in a terminate function?
Date: 31 Aug 92 23:55:26 GMT
Organization: HaL Computer Systems, Austin, TX
NNTP-Posting-Host: yosemite.hal.com

If I use set_terminate to set up my own terminate function, then throw an
exception in my terminate function what happens?  Is this a legal thing to
do?  ARM doesn't seem to take sides on this issue.  I'm looking at this
from an implementation point of view.  What I need to determine is if the
implementation should allow the throw, or if it should do something nasty
like call abort.  Obviously (at least after you've been thinking about
exceptions all day) it would have to abort once there's nobody left to
catch.

--
Dave Brennan                                      HaL Computer Systems
brennan@hal.com                                         (512) 794-2855

Visit the Emacs Lisp Archive: archive.cis.ohio-state.edu:pub/gnu/emacs
Newsgroups: comp.lang.c++
From: pjl@sparc2.cs.uiuc.edu (Paul Lucas)
Subject: Re: easy reference question
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Wed, 26 Aug 1992 00:32:53 GMT

In <1992Aug24.123549.28952@jho.com> harrison@jho.com (Mark Harrison) writes:

>We have a member function of a class that is used to set a new
>destination for the class.

>class foo {
>	CallManager * caller;
>public:
>	setcaller(CallManager * newcaller) { caller = newcaller; }
>};

>We have also received a suggestion that we convert the pointers
>to references.  At this point I'm a little confused... If I
>declare

>class foo {
>	CallManager& caller;
>public:
>	setcaller(CallManager& newcaller) { caller = newcaller; }
>};

>it seems that when setcaller(x) is called, the actual data object
>will be assigned rather than the address (or reference), which is
>what we want.

****>	That's right; a reference can only be initialized once; note:
	I said _initialized_, not assigned.  After that the object
	referred to is _always_ used, never the reference; a reference
	is an alias for another object.

>Should we say "caller = &newcaller;" ?  Is this an exception to
>the rule "use references instead of pointers whenever possible."?

*****>	I don't know where you got that rule from.
	BTW, your example using the reference is illegal C++; a
	reference _must_ be initialized in all of the classes
	constructors:

		class foo {
			CallManager &caller;
		public:
			foo( ... ) : caller( ... ) { ... }
			// ...
		};
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: lwb@cs.utexas.edu (Lance W. Bledsoe)
Newsgroups: comp.lang.c++
Subject: Re: LONG class wanted
Date: 2 Sep 1992 08:52:47 -0500
Organization: U Texas Dept of Computer Sciences, Austin TX
NNTP-Posting-Host: cs.utexas.edu

In article <2048@dutiws.tudelft.nl> holland@dutiws.tudelft.nl (Gerhard den Hollander) writes:
>I am thinkling of creating a class which can handle arbitrary large numbers
>(wheter integers of reals,
>and I'm thin king of numbers with >100 digits )

Zortec C++ comes with a class similar to this.

-- 
+------------------------------------------------------------------------+
|  Lance W. Bledsoe          lwb@cs.utexas.edu           (512) 258-0112  |
|  "How did the Scarecrow know he didn't have a brain?"                  |
+------------------------------------------------------------------------+
Newsgroups: comp.lang.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Destruction of temporaries
Date: Wed, 02 Sep 1992 23:12:36 GMT
Organization: Security APL, Inc.

In article <1992Sep2.192339.2774@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>In article <1992Sep2.042030.488@frumious.uucp>, pat@frumious.uucp (Patrick Smith) writes:
>Several people have expressed opinions that seem to suggest that
>there are some functions that should be called with temporaries
>and some that shouldn't.  I don't have the same intuition.
>
>In particular, I'm assuming that they would designate that the
>first argument of all my insertors as not usable with temporaries.
>
>   ostream& operator<<(ostream& out, MyType& mytype) ;
>
>But the description of these is clear. They return their first
>argument.  Except that they have a side effect on out they are
>identity functions.

It isn't clear from the prototype.  In other words, there is no way for the
compiler to know it.

I think this is part of a more general problem with functions that return
their arguments in C++.  Consider the problem with the const-ness of the
return results of functions returning an argument.  We have a solution to
this, sort of, but it isn't very good: it involves making an exception to
the type checking.

This isn't an answer; just an attempt to redefine the question.
From: pete@genghis.borland.com (Pete Becker)
Newsgroups: comp.lang.c++
Subject: Re: Turbo C++, function prototypes
Date: 3 Sep 92 21:09:22 GMT
Organization: Borland International
Originator: pete@genghis.borland.com

In article <1992Sep3.171537.14287@taumet.com> steve@taumet.com (Steve Clamage) writes:
>harrison@lclark.edu (Mark Harrison) writes:
>
>>In article <1992Sep2.162728.11201@taumet.com> steve@taumet.com (Steve Clamage) writes:
>>>If you write, for example,
>>>	void main(){ }
>>>The compiler is obligated to diagnose an error in C and C++.
>
>>But still, I have Turbo C/C++ 3.0, and my compiler is NOT obligated to
>>diagnose an error.  I know because I've used 'void main()', and everything
>>compiles & runs just fine.
>

	If you use the -A switch (enforce ANSI requirements) with our compiler,
it will complain about void main() in a C program.
	-- Pete
Newsgroups: comp.lang.c++
From: zougas@me.utoronto.ca (Tom Zougas)
Subject: Re: the 'standard' complex class
Organisation: U of Toronto, Dept. of Mechanical Engineering
Organization: UofT Mechanical Engineering
Date: Thu, 27 Aug 1992 03:13:46 GMT

mcgrant@rascals.stanford.edu (Michael C. Grant) writes:


>I am rather frustrated with the approach that AT&T took with its complex
>class, specifically the decision to make the real and imaginary fields
>private. (GNU's libg++ makes them protected, which is similarly frustrating
>but not quite as much so).

>Because the class does not need to be specially notified when the .re or
>.im fields change, why not make them public? It certainly allows for
>maximum flexibility; it won't break a single function already written
>for complex numbers.

Don't forget that complex numbers could also be represented in polar form.
The point of abstraction is you don't want to know HOW the class is
represented only WHAT is available. Inlining access functions might give
the efficiency you need.

-- 
===========================================================================
Tom Zougas					      zougas@me.utoronto.ca
Engineering Mechanics and Design Laboratory		       416-978-1281
Dept of Mechanical Engineering, University of Toronto,      Toronto, CANADA
From: kevinl@tisdec.tis.tandy.com
Date: 25 Aug 92 08:32 CDT
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Message-ID: <6800007@tisdec.tis.tandy.com>
Nf-ID: #R:thor:714668024:tisdec.tis.tandy.com:6800007:000:819
Nf-From: tisdec.tis.tandy.com!kevinl    Aug 25 08:32:00 1992


	I have to paritally disagree.  Everytime you add a flag variable,
you are doubling the number of states for your program.  The more states,
the more possible paths, and the more paths, the more possible unforseen
errors (if the paths are not anticipated and tested--something that is
very hard to do).
	For experienced programmers, the goto is a legitamite tactic.
There may not be any cases where a goto is absolutly necessary (I've
heard that there are some, but I have yet to see any), but putting
a goto instead of, say, another function call in a path that is called
10,000 times each time the program is run, saves massive amounts of
time.
	I agree that programs are generally easier to understand and
debug when there are no goto statements, but, if well documented
gotos are just another structured technique.

Newsgroups: comp.lang.c++,comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.tools,comp.windows.ms.programmer