HDTenEightyP/NetNews huggingface dataset:
From: bhickey@bambam.uwaterloo.ca (Bruce Hickey)
Subject: Pointer to member function as parameter
Keywords: pointer, member function
Organization: Computer Graphics Laboratory, University of Waterloo, Ontario, Canada
Date: Mon, 31 Aug 1992 18:05:51 GMT

Hi,

I am attempting to pass a pointer to a member function as an argument to
a function. Neither Stroustrup (2nd Ed) or Lippman (2nd Ed) cover this
subject directly, to my knowledge. 

I am trying to create a pointer to a member function as well as use that 
pointer to call the function. The problem arises when I try to pass this 
pointer as a paramter to a function. There appears to be no reason why this 
is not possible. 

Compiling the attached code I get two errors:

1) "test.cc", line 17: error:  object missing in call through pointer to member function - If this is incorrect how would I call the function?

2) "test.cc", line 28: error: & .*  expression - Since I want to pass a pointer
do I not need its address?

The second piece of code, which works, uses only global functions. The 
extension of this code to include class member functions is unpleasantly 
confusing.

Suggestions regarding the solutions or simply a correct example would be
appreciated.

Thanks,
Bruce Hickey

-------------------- Compiled with AT&T 3.0.1 ------------------------------
#include <iostream.h>

class mine {
public:
    double func( int );
};

double mine::func( int var1 ) 
{ 
    cerr << var1 << "\n"; 
    return 0.1;
}

// This function wants a pointer to a member function.
void freefunc( double (mine::*f)(int) ) 
{ 
    cerr << "calling func\n";
    (*f)(2);			// How do I call the function?
}

int main()
{
mine test;		

double (mine::*pf)(int) = &mine::func;

(test.*pf)(5); 		// Call the member function through pointer

freefunc(test.*pf); 	// Attempt to pass pointer to function

}

-----------------------Working version with only global functions ------------

#include <iostream.h>

double func1( int  var) 
{ 
    cerr << "func 1 " << var << "\n";
    return 0.1;
}

void freefunc1( double (*f)(int) ) 
{ 
    cerr << "calling func1\n";
    f(2);
}

int main()
{
double (*pf1)(int) = func1;

(*pf1)(5);		// Call the function through the pointer
freefunc1(*pf1);	// Pass the pointer to the fuction as a parameter

}

Newsgroups: comp.lang.c++
From: jimmy@namao.ucs.ualberta.ca 
Subject: Constructors in C++
Organization: University of Alberta
Date: Thu, 27 Aug 1992 15:56:52 GMT

Does a constructor with parameters call the default constructor ? I am
a novice, so please do not laugh.
Thanks,
Jimmy

jimmy@namao.ucs.ualberta.ca

--
jimmy@namao.ucs.ualberta.ca
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: External or internal linkage according to ARM?
Organization: TauMetric Corporation
Date: Thu, 3 Sep 1992 17:40:22 GMT

warsaw@nlm.nih.gov (Barry A. Warsaw) writes:

|In the following example, should the symbol Singleton::OnlyOne have
|external linkage or internal linkage?  Cfront 2.1 say external, but
|g++ 2.2.2 gives only internal and the question of which is correct has
|come up.

|class Singleton
|{
|public:
|	static const Singleton& const OnlyOne;
|	...
|};

ARM section 9.4, first paragraph:

"Static members of a global class have external linkage."

Even without this explicit sentence, the semantics of static members
require global linkage.  (There is only one copy shared by all class
instances.)

Local classes cannot have static data members (also in 9.4) for
the same reason: there is no way to to provide a definition of
the static data member.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 26 Aug 92 14:45:40 GMT
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Aug25.182943.9266@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

> These same thoughts could be equally applied to the lifetime of temporaries,
> leading to the conclusion that the lifetimes of temporaries ought to be
> the same as for named objects.

I thought so too (with the restriction that temporaries created in conditional
contexts be destroyed in those contexts) until I noticed the following:

	{
		statement1;
		if (condition) goto label;
		statement2;
	label:	statement3;
	}

If statement2 generates a temporary, it is no longer possible to destroy the
temporary after statement3 without having to remember whether or not the
goto was executed.  That leaves three possibilities, all unpalatable:

	1. Force the implementation to store flags to keep track of control
	   flow in cases like this, or

	2. Say that all temporaries are destroyed at every label, or

	3. Prohibit a goto from crossing a statement that generates a temporary.

Alternative (1) is a real pain for the implementor and in come cases can
incur significant run-time overhead.  Alternative (3) would break lots of
existing code.  That leaves (2).  It turns out, though, that a clear formulation
of the intent of (2) is quite difficult in the presence of break, continue,
and return statements.  Maybe someone out there can find one?
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: mcgrant@rascals.stanford.edu (Michael C. Grant)
Subject: Re: GOTO, was: Tiny proposal for named loops.
Organization: Information Systems Laboratory, Stanford University
	<rmartin.714668024@thor> <2299@devnull.mpd.tandem.com>
	<rmartin.714749390@thor>
Date: 25 Aug 92 21:03:51

In article <rmartin.714749390@thor> rmartin@thor.Rational.COM (Bob Martin) writes:

   Of course, blindly applying rules is silly.  But so is being blind to
   rules.  Break rules when you have a good and justifiable reason to do
   so.  I.e., use gotos in the generated output of a compiler...

   |[Good Programming] has to do with programmers that recognize better
   |and simpler ways of implementing things.  There might be a breed of
   |untrained or inexperienced programmers for which your rules might
   |serve as guidelines until they become real programmers.

   On the contrary, it is the untrained and inexperienced programmers
   that typically feel that rules should be violated.  It is mature and
   seasoned programmers which have learned respect for those rules.

   I am not saying that every seasoned programmer agrees with me that
   'breaks' should be avoided.  I am simply saying that the more years a
   programmer has under his belt, the more he understands the reasons
   behind the rules, and the less often he breaks them.

I don't think it always works that way... It seems that a lot of people
after their initial inexperience become overly (IMHO) dogmatic about
avoiding breaks, continues, etc., and then back off somewhat from that
original overenthusiasm. They then 'settle into' a set of instinctive
guidelines for their effective use that are much less exclusive than
you would like them to be...

I've seen similar 'cleansing' processes when one comes upon recursion
and object-oriented programming for the first time... some tend to
overuse these tools at first, but experience helps them define 

Certainly others have the opposite experience, as you have mentioned,
but your articles have been filled with so much black and white that
I felt it necessary to inject a little grey.

Perhaps this has been mentioned, but anyone interested in a less recent
contribution to this debate might want to check out Donald Knuth's book
_Literate Programming_ which contains a reprint of an article in which he
supports limited use of goto's and similar structures.

Michael C. Grant

Xref: sparky comp.lang.c++:13283 gnu.g++.help:1187 gnu.g++.bug:1425
From: rollins@bart.ee.queensu.ca (Mark Rollins)
Newsgroups: comp.lang.c++,gnu.g++.help,gnu.g++.bug
Subject: (none)
Date: 4 Sep 92 02:00:25 GMT
Followup-To: comp.lang.c++,gnu.g++.help,gnu.g++.bug
Organization: Queen's University, Kingston
To: bug-g++@prep.ai.mit.edu


PROBLEM DELETING A VECTOR OF CLASS OBJECTS
------------------------------------------

Using the syntax of Stroustrup's 1st edition, pg. 162
and g++ version 2.2.2, libg++ version 2.1, and SunOS 4.2.2 I get
correct results but a compiler warning:

   g++ -o bin/junk badmem.cc -lg++ -lm
   badmem.cc: In method `Vector::~Vector ()':
   badmem.cc:9: warning: use of array size with vector delete is anachronistic

If I omit the array size, the Vector does not get de-allocated
properly using the destructor, and all virtual memory gets eaten up
rather quickly. (It's probably just deleting the 1st one in the array).

What is the proper syntax for deleting a vector of class objects ?
Or is there any way to turn off this annoying warning flag ?

-----------------------------------------------------------------
Working version that produces a warning:
-----------------------------------------------------------------
#include <Complex.h>

class Vector {
  int		size;
  Complex	*v;
 public:
  Vector(int s=1) { size = s; v = new Complex[size];};
  ~Vector() { delete [size] v;}
};

void foo(int s)
{
  Vector junk(s);
}

main()
{
  Vector* test;
  for (int i=0;i<100000;i++) 
	foo(1000);
}
-----------------------------------------------------------------
Buggy version that quickly uses up all virtual memory:
  (difference is in the ~Vector() destructor)
-----------------------------------------------------------------

#include <Complex.h>

class Vector {
  int		size;
  Complex	*v;
 public:
  Vector(int s=1) { size = s; v = new Complex[size];};
  ~Vector() { delete v;}
};

void foo(int s)
{
  Vector junk(s);
}

main()
{
  Vector* test;
  for (int i=0;i<100000;i++) 
	foo(1000);
}


-- 

******************************************************************
*  Mark Rollins                |email:                           *
*  Dept. Elec. Eng.            |  rollins@eleceng.ee.queensu.ca  *
*  Queen's University          |                                 *
*  Kingston, Ontario, CANADA   |                                 *	
*  K7L-3N6                     |                                 * 
******************************************************************
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 28 Aug 92 15:40:39 GMT
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <DAVEG.92Aug28004331@synaptx.synaptics.com> daveg@synaptics.com (Dave Gillespie) writes:

> Your description is more dramatic than clear :-), but it brings to
> mind an example where garbage collection could be troublesome in C++.
> Is this what you were thinking of?

>    class D *orphanedThing;
>    class C {
>      D *thing;
>      ~C() { orphanedThing = thing; }
>    };

That is indeed a troublesome case for GC in C++.

I think the right answer, at least for most practical purposes, is to
say that the purpose of garbage collection is to simulate unbounded
memory.  Once an object has become garbage, there is no way to tell
whether that memory is still in use, so the implementation should be
allowed to reclaim it without explicitly destroying the object.
As a programmer, you shouldn't care; you have no way of finding out that
it happened.

Now, of course, there is a problem here: people may well want garbage
collection to be not quite so transparent.  Suppose, for example, that
an object holds some kind of resource, such as a file descriptor.  It
would be nice to release that resource, too, after the object is no
longer visible.

However, I don't think it's right to do this in the garbage collector:
if you have enough physical memory, GC may not occur for a long time.
Imagine, for example, a window system that relies on GC to remove windows
whose associated process has died.  You want those windows to go away
*now*, not after an indeterminate interval.

I have seen one compromise position, though, that might conceivably
be useful for some of these problems: the notion of a `weak pointer.'
A weak pointer points at an object as long as the object is still
around; when the only pointers to an object are weak pointers, the
object is deleted and all the weak pointers are set to zero.  You can
then test the weak pointer at some future time and see that the object
has vanished without the kinds of circularites implied by the earler
example.

Would weak pointers be useful?  I'm still not convinced one way or the other.
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: hendrik@vedge.UUCP (Hendrik Boom)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 27 Aug 92 18:33:04 GMT
Organization: Visual Edge Software, St. Laurent, Quebec

daveg@synaptics.com (Dave Gillespie) writes:
: 
: I did; as far as I can tell, the GC has to call destructors, and it's

One of my nightmares in a Lisp garbage collector is the destructor
from Hell that retrieves otherwise moribund objects and makes them
accessible again.  Do we have to do another garbage collection to see if
objects are really free?  And if they are, do we have to call
the destructor from hell again? and again? and again?and again?
Newsgroups: comp.lang.c++
From: dpb@air54.air54 (David P. Boerschlein)
Subject: Re: Strange behavior with gcc 2.0 (bug?)
Organization: NASA Langley Research Center
	<MCGRANT.92Aug26232210@rascals.stanford.edu>
	<9224017.22289@mulga.cs.mu.OZ.AU>
	<1992Aug27.075945.21285@cco.caltech.edu>
Date: Thu, 27 Aug 1992 14:35:42 GMT



This is an alignment problem.   Try one of the following:

    (*) instead of cout << (long double) i << " " << (long double) i,
        try:
            cout << (long double) i << " ";
            cout << (long double) i ...

    (*) check your compiler switch options for an option that relaxes
        the requirement that a double be aligned on a double-word boundary.


--
   ___
  |    \             .      |
  |     |  __             __|
  |     |  __| \  /  |   /  |
(_|____/  |__|  \/   |   \__|

David Boerschlein
dpb@air16.larc.nasa.gov
MS 130
NASA LaRC
Hampton, VA 23681
Newsgroups: comp.lang.c++
From: Rob.E.Allan@hydro.on.ca (Rob E. Allan)
Subject: calling fortran subroutine from C++ (on suns)
Reply-To: Rob.E.Allan@hydro.on.ca
Organization: Ontario Hydro
Date: Thu, 27 Aug 1992 15:36:16 GMT

I am running sun C++ 2.1 and sun Fortran 1.4 on a sparcstation.
I am trying to call a fortran subroutine from C++. The
linker complains that it can't find the fortran subroutine.
This works fine in C. I call the fortran subroutine junk
by the call < _junk(val1,val2) > and everything works fine.

Thanks for any help.


rob	email:rob.e.allan@hydro.on.ca
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Destruction of temporaries
Date: 31 Aug 92 13:29:29 GMT

pat@frumious.uucp (Patrick Smith) writes:

|rmartin@thor.Rational.COM (Bob Martin) writes:
||String& f(String& x) {return x;}
||
||String a,b;
||char* c = f(a+b);
||
||The above is more of a problem, becuase in order to provide the
||necessary warning, the compiler must warn whenever a reference to a
||temporary is taken.  This would generate warnings even when there was
||no danger.  But that's what warnings are all about.

|My feeling is that if a compiler did this, the meaningful warnings
|would be buried in a landslide of warnings for completely safe cases.
|For example,

|   String operator+(const String& s1, const String& s2);

|   String a, b, c, d;
|   d = a + b + c;

|In evaluating the second sum, the reference s1 is bound to the
|temporary representing a+b.  So the compiler would issue a warning,
|according to your rule.

Ideed.  But I think the warning is still useful.  The difficulty is
that an alias to a temporary can refer to the temporary, long after it
has been destroyed, regardless of which strategy is eventually used to
destroy it.  (With the exception of GC).  Moreover, it is not
realistic to suppose that the compiler can track the usage of such
aliases in order to warn against misuse.  But, the compiler *can* warn
us whenever such aliases are created. 

Such warnings are useful in my opinion, because they point at
potential problem areas.  If there are lots of them produced, there
are lots of potential problem areas to review.

Some compilers may wish to deal with the deluge of warnings by
implementing #pragmas which specifically inhibit warnings about the
creation of aliases as arguments to specific functions.  For example:

 #pragma Supress_Alias_Warning String::operator+(const String&, const String&)

This could prevent the compiler from warning about aliases created
when forming the arguments to functions which are known to be benign.
The above #pragma would eliminate all the warnings from your example,
but would still pass warnings about other aliases.

This exposes the alias problem, and puts responsibility for it square
on the programmer.  It also allows the compiler to destroy temporaries
at the earliest possible moment.

--
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++
From: cory@enigami.mv.com (Cory Kempf)
Newsgroups: comp.lang.c++
Subject: Re: named loops
Date: 26 Aug 92 15:48:41 GMT
Reply-To: cory@enigami.mv.com
Organization: EnigamI, Inc., Nashua, NH
X-Mailer: uAccess - Macintosh Release: 1.6v1


In article <1992Aug24.161012.2835@taumet.com> (comp.lang.c++), steve@taumet.com (Steve Clamage) writes:
>bevan@cs.man.ac.uk (Stephen J Bevan) writes:

>Second (a bit of nit-picking), the current "break" does not require a
>label, whereas "goto" does.  The proposed change adds a label to
>the main code and thus also to the "break".  This seems to me quite
>similar syntactically to the "goto", as shown in the example above.

A major difference is that the proposed change impliments a very highly
rigidly defined implimentation of a goto.  As I pointed out in a pervious
article on the subject, just about ever control structure is a form
of if/goto.  Defining a proposed change as being bad because it is
a form of goto would imply that all loops, switch statements, exception
handling, etc are also likewise bad.

All of these structures are essentually if/goto combinations, with
very rigid rules for how they can be used.  As such, they make the
code cleaner, and easier to read, because we know what the rules are
for a while loop, for example.  Goto's have very few rules.  When
you see a goto in code, you know that execution is jumping somewhere.
Where?

>The difference is the location of the label and whether there is a
>colon following it.  For better diagnostics in the presence of syntax
>errors and for consistency, it could be argued that the loop label
>should have a colon anyway.

Actually, this would be a bad idea.  In a case statement, execution
goes to the code imediately following the colon.  In a goto, execution 
goes to the code imediately following the colon.

With a named loop, upon encountering a continue, execution goes on
to the next cycle, which begins somewhat after the label (especially
in the case of a for loop).  Upon encountering a break, execution
goes to the code after the end of the named loop, nowhere near the
colon.  

Looks pretty inconsistant, to me.

Considering the state of most compiler diagnostics, I really wouldn't
bother using *THAT* as a justification for *ANYTHING*. (except, perhaps,
an *OSHA* standard for compiler diagnostics :-)  )

+C


-------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
cory@enigami.mv.com           ...!decvax!enigami!cory
Annon:	wi.5036@wizvax.methuen.ma.us

"F' cryin' out loud, it's *your* life; shouldn't you at least examine 
your lifestyle values to see if they are really what *you* want."
										--Keith Lim
From: johnrp@well.sf.ca.us (John Panzer)
Newsgroups: comp.lang.c++
Subject: Re: break/continue (was: Re: Tiny proposal for named loops.)
Date: 26 Aug 92 06:12:07 GMT
Organization: Whole Earth 'Lectronic Link

In article <1992Aug26.040955.593@frumious.uucp> uunet.ca!frumious!pat writes:
>rmartin@thor.Rational.COM (Bob Martin) writes:
>
>|No, exceptions do not violate structure (IMHO).  The function which
>|throws an exception never returns!  The calling code preserves its
>|invariants.  The exception is caught by code which expects it, so its
...(deleted)
>An error function that stops your program alters the control flow
>in a nice, simple way.  By contrast, exceptions can have somewhat
>non-intuitive effects.  Consider this function:
>
>   void foo() {
>      char* p = new char[17];
>      doSomething();
>      delete [] p;
>   };
>
>If doSomething() can throw an exception, then foo() has a memory leak!

If doSomething() calls exit(), the program still has a memory leak.
(Usually the memory is reclaimed by the system so you don't notice,
but try it with shared memory sometime...)  On the other hand,
in the presence of exceptions you have at least two ways to plug
the leak:

  void foo() {
    char * p = new char[23];
    try {doSomething();}
    catch(...) {delete p; throw;}
    delete p;
  }

Or, make a "resource acquisition" class:

  template <class T> class HeapArray {
  public:
    HeapArray(size_t NumElems) {Ptr = new T[NumElems];}
    ~HeapArray(void) {delete Ptr;}
    T * Ptr;
  };
  void foo() {
    HeapArray<char> p(5);
    doSomething();
  } // p is destructed whether or not exception is thrown.

John Panzer
johnrp@well.sf.ca.us
Newsgroups: comp.lang.c++
From: bhickey@bambam.uwaterloo.ca (Bruce Hickey)
Subject: Templating pointers
Organization: Computer Graphics Laboratory, University of Waterloo, Ontario, Canada
Date: Wed, 2 Sep 1992 18:17:49 GMT

Hi,

I have a problem converting some simple C++ code to accept templates. I want
to pass a pointer to a templated class to a function. Sadly the templated
functon does not appear to expand its arguments. The "standard C++" code
below works fine. When I attempt to introduce templates I get the error

"test.cc", line 25: error: use of template function freefunc() does not match any of its template definitions
"test.cc", line 25: error: no standard conversion of struct  mine <int >* to mine*
"test.cc", line 25: error: bad argument  2 type for freefunc(): void (mine__pt__2_i::*)(int ) ( void (mine::*)(int ) expected)
3 errors

These error messages make me think that the function freefunc() is not being
instantiated with <int>. Do I have to change something in this code to force
this required template expansion? 

Thanks,
Bruce Hickey

------------------------ Standard C++ code - cfront 3.0.1 -------------------
// Thanks to jamshid@emx.cc.utexas.edu and fjh@munta.cs.mu.OZ.AU for their
// help with pointers to member functions.
#include <iostream.h>


class mine {
public:
    void func( int );
};

void mine::func( int var1 ) 
{  
    cerr << var1 << "\n"; 
}

void freefunc( mine* obj, void (mine::*f)(int) ) 
{ 
    cerr << "calling func\n";
    (obj->*f)(2);
}


int main()
{
mine test;
mine* mineptr = &test;

freefunc(mineptr, &(mine::func));

}

----------------------- Templated C++ code - cfront 3.0.1 -------------------

#include <iostream.h>

template<class T>
class mine {
public:
    void func( int );
};

template<class T> void mine<T>::func( int var1 ) { cerr << var1 << "\n"; }

template<class T>
void freefunc( mine<T>* obj, void (mine<T>::*f)(int) ) 
{ 
    cerr << "calling func\n";
    (obj->*f)(2);
}


int main()
{
mine<int> test;
mine<int>* mineptr = &test;

freefunc(mineptr, &(mine<int>::func));

}

Newsgroups: comp.lang.c++
From: russ@silver.ucs.indiana.edu (Jeff Russ)
Subject: NIHCL 3.0 on DEC System 5900/g++ 2.2 problems
Organization: Indiana University
Date: Fri, 28 Aug 1992 03:49:51 GMT

I'm trying to get NIHCL 3.0 to compile and run with g++ 2.2 on a
DEC System 5900 running Ultrix 4.2.  I can get the stuff to compile
and run but the programs seem to get hung up in the destructor code
after the main program exits.  The only way to kill the program is
with a kill -9.  ANy ideas?

----------------------------------------------------------------------------
Jeff Russ				russ@silver.ucs.indiana.edu
University Computing Services		PHONE: (812) 855-2733
Indiana University, Bloomington, IN     I want to buy old PDP[4-9] systems.
Newsgroups: comp.lang.c++