HDTenEightyP/NetNews huggingface dataset:
From: martin@ucs.ubc.ca (Marilyn Martin)
Subject: where can I find cfront?
Organization: University of B.C., Network Management Centre
Date: Wed, 26 Aug 1992 20:25:01 GMT

I am in urgent need of cfront.  Can anybody please point to a
public domain or commercial product?  Thanks for your help.

=============================================================================
        Marilyn Martin
        Network Management Centre            e-mail:     martin@netcom.ubc.ca
        6356 Agricultural Road               voice mail: 604-822-4127
        University of British Columbia       fax mail:   604-822-5520
        Vancouver, B.C.  Canada  V6T 1Z2
From: hilgert@troja.informatik.uni-dortmund.de (Thomas Hilgert)
Newsgroups: comp.lang.c++
Subject: Help on: MSC 7.0 + Codebase C++
Date: 2 Sep 1992 10:11:46 GMT
Organization: CS Department, Dortmund University, Germany
Distribution: world
NNTP-Posting-Host: troja
Keywords: Help, codebase, MSC 7.0

Hi, all i want to know is who has build a codebase application with
the C++ interface and the Microsoft C ++ compiler. 

Please answer by email
-- 


*----------------------------------------------------------------------*
| Thomas Hilgert          | hilgert@hades.informatik.uni-dortmund.de   |
|                         |                                        ___ |
| Universitaet Dortmund   |                                       //// |
| FB Informatik           |                                  UNI DO//  |
|     STL                 |                                 ___ ////   |
| Postfach 500 500        | Tel.: +49 231 755 2597          \*\\///    |
| D-4600 Dortmund 50      | Fax.: +49 231 755 2047           \\\\/     |
*----------------------------------------------------------------------*
Newsgroups: comp.lang.c++
From: cparker@centerline.com (Charles Parker)
Subject: Re: bizarre error and help wanted on running TDebugger for Windows
Reply-To: cparker@centerline.com
Organization: CenterLine Software
Date: Wed, 26 Aug 1992 22:01:45 GMT

In article 5326@unixhub.SLAC.Stanford.EDU, mothra@unixhub.SLAC.Stanford.EDU (Rand Phillip Pendleton) writes:
>Well I have just had one of the strangest errors..  The only change I made 
>to my file from last
>night to tonight is changing the message in a SendMessage from
>WM_PAINT to WM_FIRST + WM_PAINT, and now my Borland C++ OWL program
>bombs with a "floating point error, square root of a negative number."

regarding the WM_FIRST + WM_PAINT addition, I cannot see any situation
when it would be appropriate to send such a message. WM_FIRST is used
by OWL to distinguish WM_* messages from WM_COMMAND messages. By adding
WM_FIRST to WM_PAINT, you create an entirely new message which may have dire
consequences.
---
---------------------------------------------------------
                                       cyberspace
momma, don't let yer children grow up to be ^ cowboys ...
---------------------------------------------------------

Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Problem with CC 3.0
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 1 Sep 1992 06:04:31 GMT

moharil@cs.iastate.edu (Vinay Arvind Moharil) writes:

>Hi Netters!
>I am new to the world of C++. I am trying to use the CC 3.0 for Sun SPARC.
>Here is the code in C and C++. The code in C can be compiled with the C 
>compiler happily without any problems. However when I try to compile the
>C++ code using CC 3.0 I get lot of errors in the files like sys/stat.h,
>X11/Intrinsic.h. I did the extern "C" ... part because some one suggested that
>as a solution to get rid of the syntax errors (in the X11/Intrinsic.h file) I 
>was facing. In my opinion, The CC 3.0 should compile the #include portion as a 
>C code and should not give errors as is the case with the C compiler.

[C code omitted]

>main(argc,argv)
>int argc;
>char *argv[];
>{
>extern "C" {
>#include <X11/Intrinsic.h>
>#include <stdio.h>
>}
>typedef char *String1;
>String1 xyz;
>printf("Hi!\n");
>}

Header files should only be #included at file scope, ie. not within
a function. You need to move the #include statements to before the
start of main().

You should also define main() using a prototype - the old K&R style
of function definition is obsolete. Try the following:

	extern "C" {
	#include <X11/Intrinsic.h>
	#include <stdio.h>
	}

	typedef char *String1;

	int main(int argc, char *argv[])
	{
		String1 xyz;
		printf("Hi!\n");
		return 0;
	}

-- 
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: keith@msmri.med.ubc.ca
Newsgroups: comp.lang.c++
Subject: Re: Numerical Recipes in C++?  NOT!!
Date: 1 Sep 92 21:52:30 GMT
Organization: University of British Columbia, Vancouver, B.C., Canada


There are no plans for a C++ version of Numerical Recipes.

A professor I know was talking to William Press, the first author of
Numerical Recipes in C, yesterday.  He asked Press about the C++ version
and the reply was that there are no plans for one.  But there are
plans for a new version of Numerical Recipes in C for later this year.
I am unsure what will be "new" about the new version.

If you are looking for C++ numerical code take a look at the file
c/free-c on research.att.com (login the ftp as netlib not anonymous).
It it contains pointer to numerical C++ software some of it adapted 
from Numerical Recipes.  With time, I am sure more code will be adapted.

I hope this helps.

Keith S Cover
Physics, UBC
Vancouver, B.C.
Canada
keith@msmri.med.ubc.ca
From: hendrik@vedge.UUCP (Hendrik Boom)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 26 Aug 92 13:42:47 GMT
Organization: Visual Edge Software, St. Laurent, Quebec

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
: 
: Under either rule, expressions can already be rewritten to obtain the
: desired lifetime. For example:
: 
: 	X result = x.a().b().c().d();
: 
: Language: early destruction, Wanted: late destruction:
: 
: 	X a = x.a();
: 	X b = a.b();
: 	X c = b.c();
: 	X result = c.d();
: 
: Language: late destruction, Wanted: early destruction:
: 
: 	X a = x.a();
: 	X b = a.b();
: 	destroy(a);
: 	X c = b.c();
: 	destroy(b);
: 	X result = c.d();
: 	destroy(c);
: 
What is 'destroy'? Some language feature I don't know about that
isn't in the ARM syntax?  Or a user-defined member funtion that has
no control over the calling of the actual destructors of members
of a, b, and c?

: The question is: what should be the default. I don't think that
: mandatory late destruction solves anything, because if you start
: relying on the persistence of temporaries in expressions, the next
: step is that you'll get confused about why they don't hang around for
: the whole block.

And you have to worry about a destroy function that can't actually
destroy very much.
: 
: 					Thomas.
-- 
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work:	hendrik@vedge.com,  iros1!vedge!hendrik
at home:	uunet!altitude!ozrout!topoi!hendrik
From: m-ag7953@HAPPY.CS.NYU.EDU (Andrew Gideon)
Newsgroups: comp.lang.c++
Subject: nested enum problem
Keywords: nested enum anachronism scope
Date: 2 Sep 92 15:04:57 GMT
Organization: New York University



I believe that I have seen this problem some time back on this
group, but I'm not certain, and I don't recall the answer anyway.

I have a class with an enclosed enumeration.  To force proper
scoping of the enumeration (I use the same enumeration name
elsewhere), I also have a "dummy" global enumeration of the 
same name.

The class which contains the enumeration has a non-inline
function that returns a value of the enumeration type.  When
compiling this line, I get the error:

	warning: nested DBResultCodes  as return type for non-inline member function, use  DBQuery::DBResultCodes   DBQuery::nextResults(){} in definition (ana
chronism)

The problem is that I have already done so!  The declaration of
that member function is:


  DBQuery::DBResultCodes nextResults();


So why am I getting this warning?  How can I shut it up?

At the end of this message is a small (but complete) example that
recreates this warning.

I am using Sun's 2.1 C++ Compiler.  I would appreciate any and all
responses.  Please reply by email, and I'll post the solutions
(if any {8^(  ).

Thanks very much...

	Andrew Gideon
	m-ag7953@happy.cs.nyu.edu



------------------------------ Example Follows ------------------------------

#include  <iostream.h>

enum  Values {Fake};

class Domain1
  {
  public:
    enum Values {One = 1, Two = 2};
    Domain1::Values f();
  };

class Domain2
  {
  public:
    enum Values {Two = 1, One = 2};
    Domain2::Values g();
  };

main()
  {
  }
Newsgroups: comp.lang.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: Garbage Collection for C++
Date: Sat, 29 Aug 1992 05:41:13 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

daveg@synaptics.com (Dave Gillespie) writes:
|Every third posting in the destruction-of-temporaries thread
|in this group ends with "if only we had GC so we could solve this
|problem once and for all..."

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

but I don't see how it would help with this:

   ofstream("some_file") << "Hello, " << "world!\n";

Well, there is one way.  One could require that all temporaries be
allocated and destroyed by the garbage collection mechanism.
There are at least two problems with this:

1) The destructors for the temporaries are run arbitrarily late,
   if indeed they are ever run (this depends on the rules GC is
   subject to).  In the above example, the programmer probably
   wanted the ofstream destructor to be run fairly soon.

2) Some (most? almost all?) applications would run more slowly if
   temporaries were allocated from a garbage-collected heap instead
   of from the stack.

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: destruction of temporaries
Date: 25 Aug 92 17:57:51 GMT
Organization: Microsoft Corporation

In article <MATT.92Aug19170229@physics16.berkeley.edu> matt@physics.berkeley.edu writes:
|Unfortunately, it really isn't at all clear to me that garbage
|collection and C++ can be made to go together very well.  Naively, it
|seems to me that high-quality garbage collection would be a bigger
|change to the language than high-quality exception handling.

Implementation-wise they amount to about the same thing -- the hard part
is changing a compiler's knowledge of the stack so that it is known at
runtime when what objects where on the stack are alive or not.
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Destruction of temporaries
Date: 2 Sep 92 14:52:45 GMT

adk@Warren.MENTORG.COM (Ajay Kamdar) writes:

|In article <rmartin.715356168@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
|>adk@Warren.MENTORG.COM (Ajay Kamdar) writes:
|>

|  - example where implicit conversion of a temporary to char* is ok deleted -

|>|I wouldn't want the compiler to issue warnings in such a case, irrespective
|>|of whether operator char*() was called on a temporary or not.
|>
|>Then, you should cajole your compiler vender into supplying you with a
|>compiler which provides you with the type of #pragma control that lets
|>you supress the warnings on a function by function basis.

|[...] But if it is a language standard that you are advocating, then
|depending upon pragmas (which are implementation dependent by
|definition) to silence warnings from code which is perfectly ok seems
|inappropriate to me. If the standard specifies the generation of
|warnings, it had better make sure that it enables the compilers to
|generate warnings only for the problematic cases and not for good
|code.

|Warning about conversion of a temporary to pointer or reference is a nice
|goal to shoot for, but that needs the language to be enhanced to enable
|the compilers to do a good job of it. 

Unfortunately, in the absence of a foolproof mechanisms for deletion
of temporaries, the warnings are the only defence you have against the
creation of long lived pointers or references to dead temporaries...
Ugly as spurious warnings are, silent errors are much worse.  (IMHO).



--
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: pat@frumious.uucp (Patrick Smith)
Subject: Re: Destruction of temporaries
Date: Sat, 29 Aug 1992 18:40:25 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

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.

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Xref: sparky comp.lang.c++:13124 gnu.g++.help:1171
From: schiebel@cs.wvu.wvnet.edu (Darrell Schiebel)
Newsgroups: comp.lang.c++,gnu.g++.help
Subject: Explicit Calls to Destructors (SunCC=ok, gcc=not)
Keywords: destructors
Date: 31 Aug 92 12:46:44 GMT
Followup-To: comp.lang.c++
Organization: WVU Statistics and Computer Science
To: gnu-gcc-announce@uunet.uu.net


	In the Sun (SC1.0 w/ cfront 2.1 (I think)), an explicit call
	to a class' destructor from within a one of the class' member
	functions works:

	void Tess::cleanup(Bool abort) {
	  Tess::~Tess();
        }

	However, in gcc-2.2.2 this does not work, and gives the error:

test.cc: In method `void  Tess::cleanup (enum Bool)':
test.cc:28: destructor specification error

	Other nonworking variations:

	this->~Tess();			AND
	(*this).~Tess();		WITH THE ERROR MESSAGE:

test.cc: In method `void  Tess::cleanup (enum Bool)':
test.cc:30: address of `this' not available

	and finally:

	~Tess();			WITH:

test.cc: In method `void  Tess::cleanup (enum Bool)':
test.cc:30: invalid functional cast

	Is there some way to get around this in gcc? Its exactly what
	I want to do; I don't want to force users of my class to call
	parent ``cleanup'' functions, in children. Explicit calls to
	destructors is permitted, ARM p.278, sec 12.4.

						
						thanks,
						Darrell Schiebel
						(schiebel@a.cs.wvu.wvnet.edu)
From: swillden@news.ccutah.edu (Shawn Willden)
Newsgroups: comp.lang.c++
Subject: BC++ templates broken
Date: 29 Aug 92 21:25:48 GMT
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3

Hi all,

	I have discovered a problem with BC++'s templates.  Given code like
this:

	template<class T> class A1;
	template<class T> class A2;
	
	template<class T> class A { A1* a; A2* b; };
	template<class T> class A1 : public A<T> {};
	template<class T> class A2 : public A<T> {};

	main() {A1<int> myA1;}

the compiler chokes, complaining that it cannot expand A2<int> because A<int>
is not yet defined.  Apparently, the expansion of A1<int> causes the expansion
of A<int> which in turn causes the expansion of A2<int> (due to the declaration
of A's member b) but it *can't* expand A2<int> because A<int> hasn't been
expanded yet.  Unfortunately, I have to do this.  As I see it, these are my
options:

	1)	'untemplate' these classes, make them deal with 
		void*'s instead of T*'s and do lots of icky casts.
		I *can* do this because these classes are only used
		internally by another class, which is a template and
		could insure type-safety.
	2)	Make A::a and A::b A*'s and provide lots of forwarding
		functions and do lots of fugly downcasting.
	3)	Make the compiler swallow the above code somehow.
	4)	Redesign the class that uses these three (several
		hundred lines of code, none of it mine and all of 
		it ugly - this option does *not* appeal to me.)
	5)	Get a job as a garbage man so I can just chuck 
		people's trash instead of having to fix it :-)

Obviously, option 3 is what I really want.  Any ideas?
	
--
Shawn Willden
swillden@icarus.weber.edu
Newsgroups: comp.lang.c++
From: J.March@lut.ac.uk
Subject: Re: Differences between versions of C++ ?
Reply-To: J.March@lut.ac.uk (Jon March)
Organization: Loughborough University, UK.
Date: Thu, 27 Aug 92 11:56:21 GMT

>What is the difference between different versions of C++ ?
>

A full answer is in the FAQ (Q126, Q127)

A short answer was:

*VERY* roughly speaking, these are the major features:
 * 2.0 includes multiple/virtual inheritance and pure virtual functions.
 * 2.1 includes semi-nested classes and `delete [] ptr_to_array'.
 * 3.0 includes fully-nested classes, templates and `i++' vs `++i'.
 *?4.0? will include exceptions.

from to Dan Frankowski.

Jon March
From: davidm@consilium.com (David S. Masterson)
Newsgroups: comp.lang.c++
Subject: Re: Callbacks - C++ needs an extension?
Date: 31 Aug 92 17:56:39 GMT
	<1992Aug29.161356.16729@genghis.borland.com> <1893@acf5.NYU.EDU>
Distribution: comp
Organization: Consilium Inc., Mountain View, California
In-reply-to: checker@acf5.NYU.EDU's message of 29 Aug 92 19:26:35 GMT
X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]

>>>>> On 29 Aug 92 19:26:35 GMT, checker@acf5.NYU.EDU (checker) said:

> There is a simple way of doing blind callbacks in a typesafe manner using an
> intermediary class and a pure virtual function:

> class callback
> {
> public:
> 	virtual void CallBack( void ) = 0;
> };

> This is the interface class.  An object that needs to call another
> object back takes a reference to one of these:

> class button
> {
> public:
> 	button( callback &CalledWhenPushed, etc. );
> };

[...]

> That's it.  button knows absolutely nothing about who it is calling.  The
> method uses the virtual call mechanism so it is completely type safe.  There
> is no run time switching on message types, etc, and the method is easily
> extended using templates and/or nested classes.

> This technique is a typical use of the abstract interface/concrete
> implementation idea.  All of the grungy details are in the derived class, so
> the folks using the base don't have to know about them.

Interesting technique, but I have a few questions:

1.  Could you make this work in the case of windowing systems that treat
callbacks as C functions?  Would it be a double callback (ie. callback to a C
function that then calls the appropriate callback object)?

2.  How does the windowing system pass data to the callback?  With buttons,
for instance, all that needs to be known is the action (buttonPush).  With
text widgets, though, the program will want to get at the data that is
provided in the event.  Do this technique advocate a "push" model (the window
system sends data to the program) or a "pull" model (the program asks for the
available data)?

3.  Given a windowing system based on C, its likely that the information
coming from the windowing system will not be C++ object oriented (ie. it won't
follow a C++ inheritance model).  How do you convert?
--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
davidm@consilium.com				Mtn. View, CA  94043
====================================================================
"Creative minds always have been known to survive any kind of bad training."
-- Anna Freud

Well, sometimes, anyway.
-- Mark Brader, utzoo!sq!msb
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 28 Aug 92 23:24:37 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: hendrik@vedge.UUCP's message of 27 Aug 92 18:33:04 GMT

In article <28623@vedge.UUCP> hendrik@vedge.UUCP (Hendrik Boom) writes:

   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?

Please do not confuse GC finalization with C++ destructors. The two
concepts are very different. Finalization routines should be written
specifically for the purpose of finalization; it would be wrong for
the GC to call the destructor for finalization.

Most finalization routines are really error handlers. They detect that
some object that should have been destroyed explicitly (e.g., a file
descriptor, a window) somehow got lost; they can fix the problem (to
allow your buggy program to continue running) and send out a bug
report. But you should (almost) never rely on finalization to destroy
such objects for you as a matter of course.

So, finalization is really something that most users won't have to
deal with, and the usual finalization routine will be very simple and
straightforward. Because they are used rarely and not for very
complicated things, the finalization hooks do not need to be very
"user friendly" and might impose some restrictions on what you can do
(just like you can't call "new" from the "new_handler").

Yes, finalization (in particular, in a conservative GC) is
non-trivial; Boehm posted a reference to a paper about finalization in
a conservative GC maybe this week.  You may want to look it up.

					Thomas.
From: pete@genghis.borland.com (Pete Becker)
Newsgroups: comp.lang.c++
Subject: Re: BC 3.1 TV Running slow ?
Date: 27 Aug 92 19:08:31 GMT
Article-I.D.: genghis.1992Aug27.190831.4681
Organization: Borland International
Originator: pete@genghis.borland.com

In article <1992Aug27.073530.9986@info.ucl.ac.be> vijghen@fynu3.fynu.ucl.ac.be (Philippe Vijghen) writes:
>
>I had the same problem with a Turbo Vision application and BC++ 3.0
>compiler. I looked around for a long time and I found that the source
>of the problem is the memory allocation mechanism: it uses a kind of
>"safe pool" and a lot of verifications; this certainbly provide advantages
>but the main result is a important reduction of the speed inside the
>routines using dynamic memory allocation (I was doing some symbolic
>computation to implement a fuzzy logic controller).
>
>I think that Borland should put an option in his library: speed/security
>for the mem. alloc., don't you?
>

	Actually, the problem is that the TV library as shipped was built with
the debugging code left in.  If you recompile NEW.CPP with the switch -DNDEBUG
all the debugging code will go away, and things will be much faster.
From: holland@dutiws.tudelft.nl (Gerhard den Hollander)
Newsgroups: comp.lang.c++
Subject: LONG class wanted
Date: 1 Sep 92 11:01:59 GMT
Organization: Delft University of Technology

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 )

iThis class should be able to do the following
Operator+(Long Long)
Operator-(Long, Long)
Operator*(Long, Long)
Operator<<(Ostream, Long)
Operator>>(Istream, Long)
and a lot of type casts.

Has anyone allready made this,
if so can someone mail me info abvout how to tackle this thing
(or even better mail me the source code ;))