HDTenEightyP/NetNews huggingface dataset:
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: Garbage Collection for C++
Date: Sat, 29 Aug 1992 19:00:09 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

tmb@idiap.ch writes:
|In article <1992Aug29.054113.917@frumious.uucp> pat@frumious.uucp (Patrick Smith) writes:
|   Actually, I don't think adding GC to C++ would solve the problem
|   of when to destroy temporaries.
|
|   GC could help with cases such as this:
|
|      String s, t;
|      const char* p = (const char*) (s + t);
|      // ... do something with p
|
|If GC were added to the C++ language, this would still not work.
|You would need to write something like:
|
|	String s,t;
|	const char *p = (const char *)new String(s+t);

What I had in mind was that one would write the String class so that
the actual character array was stored in garbage collected memory.
The String destructor would not release this memory; that would be
left for the garbage collection mechanism to do.  In that case, I
would expect the code I gave to work correctly.

Note that I did not say that GC would solve the problem itself; I just
said that it would help with the solution.


|If you wanted to do something like this frequently, you might be able
|to define a class HeapString that eliminates the need for an explicit
|call to "new".

By this do you mean something along the lines of my suggestion above?


|   but I don't see how it would help with this:
|
|      ofstream("some_file") << "Hello, " << "world!\n";
|
|This code is wrong, and it would continue to be wrong in the presence
|of GC.

It's wrong because of the current rules for destruction of temporaries.
Changing those rules _might_ make this work as the programmer
expected.  Just adding GC would not.  That was my point.
I take it you agree.

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Newsgroups: comp.lang.c++
From: ralph@cs.stanford.edu (Ralph Melton)
Subject: Templates, const member functions, and g++
Summary: When I try to use const member functions in class templates, g++ complains
Originator: ralph@Xenon.Stanford.EDU
Keywords: templates, const, g++
Organization: CS Department, Stanford University, California, USA
Date: 31 Aug 92 20:45:11 GMT

The following program, abstracted from larger work, makes g++ 2.2.2 complain
"test.C:9:'template for method `bar' doesn't match any in class 'foo<2,3>'".

I need the operator int() to be a constant member function.  Removing
both instances of the word 'const' lets g++ compile this correctly,
but that gives me other problems in the rest of my program.

I don't completely understand the ramifications of templates and of
the const keyword.  I would appreciate it if someone would tell me
either a) "this is the correct procedure for declaring a constant
member of a template class, and you should file a bug report for
g++.", or b) "No, the way you declare a constant member function of a
template class is this."

Thanks in advance,

Ralph Melton


//--- cut here
#include <ostream.h>

template <int lb, int ub>
class foo
{
  int f;
public:
  operator int() const;
};  // line 9.


template <int lb, int ub>
foo<lb,ub>::operator int() const
{
  return f;
}

main()
{
  foo<2,3> the_foo;
  cout << int(the_foo);
}
// end of file.



-- 
Ralph Melton			ralph@cs.stanford.edu
"Then ye shall know the truth, and the truth shall make you free."
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: Templates, classes, and enumeration types
Summary: yes, it's a BC++ 3.x bug wrt nested types
Date: 27 Aug 92 18:47:12 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <1992Aug26.071212.3003@ennews.eas.asu.edu> nwatson@enuxha.eas.asu.edu (Nathan F. Watson) writes:
>[This works with BC++ 3.1:]
>   template <class T> class A
>   {
>      public:
>         enum Aenum { ... };
>         void Afunc(Aenum v) { ... }
>   }
>
>But no combination I have tried so far works outside the class definition.
>The best I can come up with is:
>
>   template <class T> void A<T>::Afunc(A<T>::Aenum v) { ... }
>
>How should I do this?  Is this a BC++3.1 bug?

Yes it's a BC++ bug since 3.0 (which I reported in Dec.91!).  The only
thing I'm not sure of is whether the "A<T>::" qualifier is required in
the parameter list (but it certainly shouldn't hurt).  If Aenum were
the return type, then a qualifier probably would be required, but I
think once it hits "A<T>::funcname" it's in the scope of "A<T>".
Anyone have a definitive answer?

Anyway, BC++ 3.x gets very confused by nested type names (typedefs,
nested classes, enums) when used outside the template class definition
or when used by derived classes.  I don't know of any workaround other
than defining the function inside, using the "real" type for typedefs,
or moving the type definition outside the class (make Aenum global).

I send all the bugs I find to bugs@borland.com (just reports, no reply
or tech. support) and to the TC++/BC++ mailing list (to subsribe,
email "subscribe tcplus-l Jane Doe" to listserv@ucf1vm.cc.ucf.edu).
E-mail me if you want a copy of my 3.0 or 3.1 bug reports.

Jamshid Afshar
jamshid@emx.utexas.edu
From: asher@qtp.ufl.edu (Robert L. Asher)
Newsgroups: comp.lang.c++
Subject: BC++ 3.1 and 386 code generation
Date: 28 Aug 92 16:31:40 GMT
Organization: Quantum Theory Project, University of Florida


Recently a friend of mine purchased the BC++ 3.1 upgrade and I thought I might
be interested as well.  But I had some doubts and wanted to know about the
speed improvements and wheather 386/486 code generation had been added.  He
indicated that it had and so did the blurb from Borland I got via e-mail.  So I
had some programs which are fairly cpu intensive.  We compiled them and made
some tests.  3.1 does not seem to make 386 code for me.  I compiled using
bcc -Ot -3 -f287 code.cpp
and the execution file then ran slower than the 3.0 version of the code
compiled with the same options except a -2 used.  This was suspicous in itself.
Then I tried running the code on a 286 machine and it did.  What's going on
here?  Did we miss something?

Thanks for any help / info.
Robert

-- 
Robert L. Asher          | 
Department of Chemistry  | 
University of Florida    | 
asher@qtp.ufl.edu        |
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: destruction of temporaries
Date: Wed, 02 Sep 1992 22:57:57 GMT
Organization: Security APL, Inc.

In article <23585@alice.att.com> ark@alice.UUCP () writes:
>In article <1992Aug28.221841.149034@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:
>
>> I don't claim to have a complete solution to the problem.  However, for the
>> specific case   c ? a+b : a   where a+b creates a temporary, I would be
>> tempted (as a compiler writer) to always return a temporary: a+b if c is
>> true, and a copy of a otherwise.  This solves the problem of not knowing
>> whether a temporary has been created.
>
>I'm afraid it doesn't solve the problem.  For example, suppose `a' is of type
>const char*, `b' is of type String, and String has one of those problematic
>conversions to const char*.  Now, let's modify your example a tiny bit and
>look at c?(const char*)(a+b):a.
>
>This expression always returns a value of type const char*, but that's not
>where the problem likes: the problem is in the temporary of type String
>yielded by the subexpression a+b.  The value of (const char*)(a+b) is valid
>only so long as that temporary stays around, so any games you play with
>the const char* values themselves won't affect that.

The problem in this case is the (const char *) conversion, not the ?:
expression.  You would have essentially the same problem with only the
conversion.  Remember, I didn't claim to be solving the whole problem, just
?:.

I consider a "conversion" (or any other function) which returns a pointer to
an internally-allocated object to be suspect, anyhow; except in the case
where the object returned is of a class with its own memory management.  (On
the other hand, I don't off hand have any good alternative for the cases
where you want to use it.)
From: vrm@hawksnest.cerc.wvu.wvnet.edu (Vasile R. Montan)
Newsgroups: comp.lang.c++
Subject: I need an Expression Object
Date: 31 Aug 92 14:36:21 GMT
Organization: Concurrent Engineering Research Center

Is there a publicly available implementation of an Expression object?
One that can parse an expression and can be evaluated based on values
for its variables. I am not picky about the BNF but would prefer a
standard infix expression syntax.  I also would like for it to handle
logical expressions.

Thanks,
-- Vasile
From: anstey@sun.soe.clarkson.edu (Charles Anstey)
Newsgroups: comp.lang.c++
Subject: GCC2.2 doesn't inline template class functions. Normal?
Date: 26 Aug 92 06:42:02 GMT
Article-I.D.: sunspot.ANSTEY.92Aug26014202
Distribution: comp.lang.c++
Organization: Clarkson University, Potsdam NY

While playing around with GCC2.2, I noticed that it does not inline
template class member functions.  Is this typical of all compilers for
reasons I do not know?  GCC2.2 will inline member functions of a
non-template class.

The examples was quite simple.
template <class PT>
class S {
private:
  PT length;
public:
  S (int size):length(size) {};
  PT size () { return (length);};
};

S.size() is not inlined.  If I remove the template PT and change it to 'int'
then it is inlined.

Anyone know why?

Thanks in advance.
-Charles Anstey
Newsgroups: comp.lang.c++
From: cnhasan@casbah.acns.nwu.edu (Nirmal Hasan)
Subject: Bug in Turbo Debugger? 
Keywords: BC++ 2.0, Turbo Debugger, BUG?
Organization: Northwestern University, Evanston, Illinois, USA
Date: Fri, 4 Sep 1992 20:25:16 GMT

I am using BC++ 2.0 to develop a discreet event simulator. I have run into
a weird problem with the Turbo Debugger. I have a couple of data structures
as follows: 

class foo_rec
{
	:
	:
foo_rec *next;
	:
	:
}

struct foo_list
{
foo_rec *List;
	:
	:
}

In the code I have

	while (something_or_other)
	{
	  foo_rec *temp = foo_list.List;      // Line 1

	  // Now search the linked list for a record

	 if (!temp) Error(REC_NOT_FOUND) 
	  // Error() is my error reporting function. Exits on error

	 //Continue processing the rec found

	}

If I step through the line marked "Line 1", temp contains junk and the
program either exits with error if I was lucky enough to hit a NULL pointer
somewhere, or goes into the wild blue yonder while searching the linked
list. But the original linked list remains intact though (I checked that
using the watch and inspector windows).

But none of this happens if I just let the program run. The program works
fine. If I have a break point set up on "Line 1", but continue execution
*without* stepping throught that line, things are fine. If I setup a
breakpoint before "Line 1" and another after "Line 1" and run, no problems.
The problems occur only when I use the "step" facility. And only on this
particular line. I have the same statement elsewhere in the program and
have the same problems.

I apologise for that rambling description, but I wasted 4 days in trying to
debug my program before I realized that the bug was in the debugger, and I
am very pissed!

Has something similar happened to anybody else? Is it really a bug in the
debugger or is it something to do with the code itself?  

Nirmal "Very upset" Hasan
Newsgroups: comp.lang.c++
From: esimon@wd.estec.nl (Erik Simonsen)
Subject: Re: C++ FAQ and Style Guides
Reply-To: esimon@sdeserver.estec.esa.nl
Organization: ESA/ESTEC
Date:  4 Sep 92 10:55:58 GMT

Indication of a FTP site for C++ FAQ would be very much appreciated.
Thanks,

Erik
--
Erik Simonsen          ESA/ESTEC WDP          
Postbus 299            NL-2200 AG Noordwijk   
Phone: +31 1719 83133  Fax: +31 1719 84295
E-mail: esimon@sdeserver.estec.esa.nl
From: roth@ordin.cs.wisc.edu (Bill Roth)
Newsgroups: comp.lang.c++
Subject: Books
Date: 25 Aug 92 21:44:23 GMT
Organization: U of Wisconsin Madison - Computer Sciences


Which book is better, Lippman's or Bjarne's, and why?

email your replies.
--

-------------------------------------------------------------------
Bill Roth, University of Wisconsin Computer Sciences Dept.
Internet: roth@cs.wisc.edu. BITNET: ROTH@WISCPSL. HEPNET: PSL::ROTH
Newsgroups: comp.lang.c++
From: bakowskr@wm-mercer.ca (Ron Bakowski)
Subject: indent for C++
Organization: William M. Mercer Limited, Toronto, Ontario
Date: Thu, 27 Aug 1992 19:57:39 GMT
Keywords: indent, cb, format

	Concerning the indent-C++ program I read about recently, I tried to
	ftp it from the host listed in the message but mailserv reports that
	I have illegal characters in the hostname.  Can someone help me out?

	The host, path and file name I copied (not necessarily correctly) from
	the aforementioned message was:
	
	ftp.th-darmstadt.de:/pub/programming/languages/c++/tools/ 
	indent-C++.6.5.tar.Z

	Thanks in advance (pardon my newness to usenet) 

	Ron B.  (direct tel:(416) 868 7688)
		bakowskr@wm-mercer.ca
Newsgroups: comp.lang.c++
From: holiday@bnr.ca (Matthew Holiday)
Subject: Re: Garbage Collection for C++
Reply-To: holiday@bnr.ca
Organization: Bell-Northern Research, Richardson, TX
Date: Mon, 31 Aug 1992 15:20:16 GMT

In article <23580@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
|> 
|> 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.
|> 

One of the things that makes GC attractive is the need to reclaim memory that
might be leaked during exception handling.  Imagine that a function allocates
an array with new [], and then an exception transfers control to a scope which
isn't prepared to delete that array.  Unless there is strong coupling between
exception handlers and try blocks (i.e., every potential handler for a exception
knows about the places the exception may originate, and the need for store
reclamation), there will be memory leaks resulting from exceptions.  One way
to deal with this is for every try block to have a catch block for every
exception type, in which all cleanup takes place, and then re-throws the
exception to a handler which can actually act on the exception type.  Its not
particularly elegant, but perhaps would work.

Any ideas?

-- 
Matt Holiday                                      #include <std/disclaimer>
holiday@bnr.ca
BNR Richardson, TX
From: preney@cs.uwindsor.ca (Paul Preney)
Newsgroups: comp.lang.c++
Subject: Re: Tiny proposal for named loops.
Date: 26 Aug 1992 17:18:38 GMT
Organization: University of Windsor, Ontario, Canada


I have noticed this discussion about the use of break, continue, goto, etc. in C/C++ programming. I must say that I actually *prefer* to use structured programming techniques, especially in complicated code. My reasons for this are simple... Whenever I write a program for someone else or myself, I, of course, wrote it to do the desired task. Once, I finished it, I archived it and left it sit somewhere on some floppy disk until it was needed again. Now, if I did not adhere to structured programming conventi



ons, I would not even remember how exactly I used my returns, breaks, continues, and gotos and therefore, I could get myself into some trouble adding code to a program; i.e. a function with more than 1 return statement and adding code to it after the first return statement which should have been added also before every return statement. Surely, a function such as:

int g(int a, int b) {
	if (a < b)
		return 1;
	else
		return 0;
}

is trivial but I think it is a much better practice to use:

int g(int a, int b) {
	return (a < b) ? 1 : 0;
}

since, you now are treating the function g as a function that has a place of entry and a place of exit. This makes code very clean especially in complicated functions and in simple/complicated long functions. If I did not adhere to such practices then I would have difficulty adding new code or modifying old code in my *own* program, let alone anyone else's.

I feel that people should be consistent in programming... very consistent especially if the program is going to sit for a period of time when nobody is going to be modifying it. Conforming to structured practices allows one to more conclusively *prove* his/her program correct since there is ONLY 1 RETURN statement in the function and ALL of the code leads to that *CONCLUSION* or return statement. Thus, I could much more easily say that the second function of g() is correct than that of the first one where 



I would have to check each and every return statement and all paths that lead to it. God help you if you have nested loops, if/else's and switch's in one function! :-)

Now, I have not been programming too long, since grade 9 and now I am in 2nd year university, BUT that does not mean in any way that I do not know what I am doing in C, C++, PostScript, NeWS, FORTRAN, BASIC, 80x86 Assembler, etc. BUT I HATE messy programming (for even which I am at fault) because it is very hard to "come bcak to" after a long time and it is also hard to catch those small weenie-little bugs that cause your program to not work properly.

Paul Preney
"The Machine"
University Of Windsor
preney@server.uwindsor.ca
From: rjf@thunder.Berkeley.EDU (Russell Fleming)
Newsgroups: comp.lang.c++
Subject: Re: Pointer to member function as parameter
Keywords: pointer, member function
Date: 2 Sep 92 19:05:41 GMT

In article <Btv0xr.A6H@watcgl.uwaterloo.ca>, bhickey@bambam.uwaterloo.ca
(Bruce Hickey) writes:
> 
> 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. 
>
> 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
> 
> }
> 

There is nothing wrong with your declaration of a pointer to the member
function.  The problem lies with your use of the pointer.  All
non-static member functions have an implied "this" argument which is
used to access the data associated with the object.  When you use a
ptr-to-mem-fcn to invoke the function, you must also provide the object
which the function is to act upon (ie. (this->*f)(2)).  Two solutions to
your problem are available.  The first elimintates the need for a
pointer.  Simply modify your code as follows:

void freefunc (mine& m)
{
	cerr << "calling func\n";
	m.func (2);
}

int main ()
{
	mine test;
	freefunc (test);
}

Alternatively, since the member function you are using does not (as
shown) rely on any data from the object,
you could re-write your code to use a pointer function as follows:

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

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

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

int main ()
{
	mine test;
	double (*pf)(int) = &mine::func;
	freefunc (pf);
}

=================================================================
Rusty Fleming, Software Consultant @ Tandem Computers Inc.
email: rjf@mpd.tandem.com            Austin, Texas
voice: (512) 244 - 8390              USA
Newsgroups: comp.lang.c++
From: sullivan@teal.csn.org (Steve Sullivan)
Subject: beginner's question ...
Organization: Colorado SuperNet, Inc.
Distribution: na
Date: Mon, 31 Aug 1992 03:24:52 GMT


Here's a beginner's question ... when I compile the following
file with gcc 2.2.2 on Sunos 4.1.1, I get:
   > g++ -c testd.cc
   testd.cc: In function `int  main ()':
   testd.cc:9: template for method `print' doesn't match any in class `QI<int>'

Yet it looks ok to me.  Where am I going wrong???
Any help would be much appreciated.
Many thanks -

Steve Sullivan
sullivan@mathcom.com

=========== cut here =============
template <class T>
class QI {
public:
  QI(); 
  void print() const;
private:
  T item;
  QI *next;
  };		// this is line 9



template <class T>
QI<T>::QI() {}


template <class T>
void QI<T>::print() const {};


main () {
   QI<int> alpha();
   }
=========== cut here =============
Newsgroups: comp.lang.c++
From: patton@phy.uab.edu (David Patton)
Subject: Re: C++ FAQ and Style Guides
Reply-To: patton@phy.uab.edu
Organization: University of Alabama at Birmingham
Date: Fri, 4 Sep 1992 15:51:12 GMT


try ftp at sun.soe.clarkson.edu in /pub/C++
From: matt@physics16.berkeley.edu (Matt Austern)
Newsgroups: comp.lang.c++
Subject: Re: Novice Questions
Date: 25 Aug 92 19:30:32
Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
Distribution: usa
	<1992Aug26.001150.8237@sunb10.cs.uiuc.edu>
Reply-To: matt@physics.berkeley.edu
NNTP-Posting-Host: physics16.berkeley.edu
In-reply-to: pjl@sparc2.cs.uiuc.edu's message of Wed, 26 Aug 1992 00:11:50 GMT

In article <1992Aug26.001150.8237@sunb10.cs.uiuc.edu> pjl@sparc2.cs.uiuc.edu (Paul Lucas) writes:

> >syntax?  I'm writing a simple program that does different types of string
> >reversing and thought that I should call a function with a string, and then
> >return that string reversed in different ways.
> 
> *****>	Array names (almost) always decay into a pointer to the first
> 	element, so _that's_ what you return--a pointer.

Yes and no.  This answer is correct, but, depending on what the
original user wanted, not necessarily useful.  My impression was that
he wanted to treat arrays (including strings, which, in C, are just
arrays of characters) as first-class objects.  Pointer manipulation is
useful, but it isn't the same thing at all.

(And one problem with returning a pointer to an array instead of
returning an array is just that a pointer has to point to something!
As people have already observed in the thread on garbage collection,
this means that when a function returns a pointer, part of the
interface of that function must be an explicit protocol on who
allocates and deallocates that storage.)

For example: if arrays were first-class objects, then, if A is an
array, and foo() was a function which returns an array, you could
write 
		A = foo().  
Of course, this isn't possible with the built-in C types; that is, if
A is declared as "double A[NUM_ELTS]", and foo is declared as "double
*foo()", then this code is illegal.

Fortunately, this is only half of the story.  I have carefully written
"C" up until now instead of "C++", because there is a better way in
C++: you can declare your own types, e.g., Array, or String, and you
can treat these types as first-class data types---you can use the
assignment operator for objects of type Array or String, and you can
return them from functions.  

The only down side of this is that you have to define Array and String
yourself, or pick them up from some class library; there isn't yet a
Standard Class Library that is defined along with the C++ language.  
--
Matthew Austern                   Just keep yelling until you attract a
(510) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
matt@physics.berkeley.edu         solutions, become a part of the problem!