HDTenEightyP/NetNews huggingface dataset:
From: dsf@cray.com (Dan Frankowski)
Subject: Re: destruction of temporaries
Organization: Cray Research, Inc.
Date: 21 Aug 92 17:17:56 CDT

In article <4095@seti.UUCP> Daniel R. Edelson <daniel.edelson@inria.fr> writes:

>In article <TMB.92Aug20142610@arolla.idiap.ch>, tmb@arolla.idiap.ch
 (Thomas M. Breuel) writes:

>|> In article <23487@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

>A previous poster mentioned quality of implementation.
>I couldn't agree more. Scientific computation is a problem 
>for C++ operator overloading. Are we even certain that destroying
>temporaries immediately makes C++ suitable for scientific
>computation? At the the Usenix C++ conference advanced topics
>workshop, we saw a presentation by a person from Boeing (I'm sorry,
>my material is at home and I don't remember his name) who pointed
>out some of the difficulties with scientific computations. One problem
>is using the chaining capability of a cray.
>
>Assume you have a matrix expression like 
>	D =  A * B + C;
>Assume further that the compiler figures out how to vectorize
>the multiplication. The next step is to chain the multiplication
>to the addition. But this is very difficult because the functions
>that implement the overloaded operators hide the fact that the loops
>chain.

I don't know how destroying temporaries any sooner or later would make
it possible to chain such operations.  As I posted earlier, the
problem is that it is expanded into

D.operator=(A.operator*(B.operator+(C)))

and no part of the program expresses the fact that both addition and
multiplication are taking place at the same time.

In the style of the matrix package newmat (by Dr. R. B. Davies), the
solution would be to make operator+ return an AddedMatrix, and make
operator* with an AddedMatrix return an AddMultMatrix:

AddMultMatrix GeneralMatrix::operator*(AddedMatrix& am);

Finally, structure the program such that when the AddMultMatrix is
actually evaluated, there is a procedure that implements addition
and multiplication in one (chained) loop.

IMHO, the catch is "when the AddMultMatrix is actually evaluated"--
this means that all code using a general matrix must at one time or
another explicitly invoke an Evaluate() function, which seems contrary
to the spirit of C++.  Not that I know of a better way.  :-)

>The point is, scientific computing is difficult. What are the
>ramifications of dictating that temporaries get destroyed
>very quickly. Does that suffice to make C++ acceptable in
>numerical computing? Does that, on the other hand, make C++
>a more difficult language for the general user?

If that was the point you were making, I agree.  I was just noting
that I don't see the relation between chaining and garbage collection.

>Daniel.Edelson@inria.fr

DISCLAIMER: This ain't official Cray business.
-- 
Dan Frankowski            Dan.Frankowski@cray.com     (612) 683-5099
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Distribution: world
Subject: Re: using (...) question
X-Mailer: cppnews $Revision: 1.14 $
Organization: Trumphurst Ltd.
Date: Wed, 19 Aug 1992 16:04:32 +0000


In article <1992Aug17.170733.17470@taumet.com> steve@taumet.com (Steve Clamage) writes:

> >In <J3mkPB8w165w@toz.buffalo.ny.us> cyberman@toz.buffalo.ny.us (Cyberman) writes:
> 
> >>I know printf is prototyped as
> >>int printf(char *,...);
> >>I would like to know how from within the function to access the 
> >>remaing parameters!
> 
> The usual C implementations of <varargs.h> are not usable in C++, as
> the macros result in illegal C++ code.
> 
> The Standard C header file <stdarg.h> serves the same purpose and is
> generally available with C++ implementations.  The ANSI/ISO C++
> committee has voted to make the Standard C header <stdarg.h> part of C++.
> 
> If at all possible, you should use <stdarg.h> rather than <varargs.h>.
> See any good Standard C text for information on the use of these macros.
Correct. However, beware if you have a C++ -> C translator, and you are 
using certain flavours of Unix (at least one HP compiler to my knowledge),
because there are bugs in the stdargs implementation.

Of course, you should still use stdargs, and you should complain to your 
Unix vendor if the compiler is broken. I only mention it to save hours 
searching for a non-existent bug in your code, to hassle HP to fix their C
compiler, and to show off my knowledge of obscure C compiler trivia :-)
---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
Newsgroups: comp.lang.c++
Subject: Help : Compression Algorithms
From: ebolog@elaine.ee.und.ac.za (EDWIN BOLOGNA : THIRD)
Date: 20 Aug 92 13:01:38 +0200
Organization: Electronic Eng., Univ. Natal, Durban, South Africa


Does anyone out there happen to have PAS, C, or ASM source code to decode
and code LZH, or other good compression formats.

Any information at all on any of these formats will be greatly appreciated.

        Desperate fellow programmer (And very Greatful for any information)

                E.B. (EBOLOG@ELAINE.EE.UND.AC.ZA)

PS : Please be kind hearted and Assist !
From: brazile@soir.bbn.com (Robert Brazile)
Newsgroups: comp.lang.c++
Subject: Re: Return value for the constructors.
Date: 20 Aug 92 22:00:44 GMT
	<1992Aug19.175852.38459@watson.ibm.com>
	<1992Aug19.231926.28218@sunb10.cs.uiuc.edu>
	<2273@devnull.mpd.tandem.com> <matt.714318343@centerline.com>
	<1992Aug20.170524.3452@sunb10.cs.uiuc.edu>
	<matt.714332315@centerline.com>
Distribution: usa
Organization: Bolt Beranek and Newman, Cambridge, Mass.
NNTP-Posting-Host: soir.bbn.com
In-reply-to: matt@centerline.com's message of 20 Aug 92 17:38:35 GMT

In article <matt.714332315@centerline.com> matt@centerline.com (Matt Landau) writes:
   [Also, having worked on a large software system that used exceptions as
   a primary means of error reporting and recovery, I'm not convinced that 
   it's the panacea some people seem to think it will be.  Dealing with
   exceptions correctly in large systems rapidly becomes tedious and error
   prone itself.]

Having worked on the large software system to which Matt refers, I can
verify what he says. In particular, reuse becomes tricky in that the
piece of code you steal^H^H^H^H^Hreuse (or just call from a library)
may surprise you - even if the exceptions it throws are documented and
you've covered them, code upon which it depends might throw exceptions that
it doesn't handle for you. If they're uncommon enough, you might not
find out for a long time. Which means you pass that problem on to any
code that calls your new routine.

That shouldn't happen in well-designed code, I hear you cry. Well,
that's true, but in a large and/or complex system it WILL happen.

Having exceptions is no worse than the current situation (trying to do
everything by returning NULL pointers, or [shudder] global error
codes) and is actually preferable because it's more flexible and helps
with signalling errors in (hopefully simple) constructors. I just want
to point out that it's not a panacea - it's doesn't even make things
particularly easier.

Robert Brazile
Bolt Beranek and Newman
--
Robert Brazile					brazile@bbn.com
Bolt Beranek and Newman Inc.			+1 (617) 873-2403
Cambridge, Massachusetts
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Garbage Collection for C++
Date: 20 Aug 92 21:37:20 GMT
Organization: Microsoft Corporation

In article <DAVEG.92Aug17224359@synaptx.synaptics.com> daveg@synaptics.com (Dave Gillespie) writes:
|In article <1992Aug18.021453.24394@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
|>|> Now, it turns out that in some cases, GC is actually "guaranteed" to
|>|> be faster, in the sense that it can combine very low-cost allocation
|>|> with no overhead deallocation (that is, 0 machine cycles per word).
|
|Well, now, this sounds like the same logic people use to ruin themselves
|with credit cards...  Remember, you still wind up paying (for deallocation),
|just later instead of right away.  But the convenience of paying later,
|and the efficiency of paying in chunks, is a big win.

In generation schemes, both long-lived and short-lived objects have
allocation and deallocations costs that are very very small -- IE "0"
There are significant allocation and deallocation costs only for object
that fall in between these two extremes -- objects that live to be middle
aged.  And the cost of these objects is not really the cost of allocating
or deallocating them, but rather the cost of keeping them young.

Indirectly, one could argue its the deaths of the short-lived objects that
define the lifetime of a generation, and thus indirectly the short-lived 
objects share a portion of the blame for the costs of the medium-lived
objects.  Still, "0" allocation and deallocation costs for the "typical"
object is a fair description of the behavior one sees in practice --
its only the "atypical" objects that cost you anything significant.

Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Dumb questions about Borland C++
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 19 Aug 1992 17:43:31 GMT

In article <1992Aug18.000414.15202@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <1992Aug13.152405.16170@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>|	No. Its only a 16 bit machine. And the 386 still
>|runs 16 bit operating systems.
>
>Recent Intel PC chips such as the 386/486 can run in many different memory
>model modes, including 16 bit flat, 16:16 segmented, 32 flat, and 16:32 
>segmented.  The last mode, for example, gives the programmer 16,000 distinct
>4 Gigabyte address spaces.  Most PC operating systems have historically
>used the 16 bit flat and 16:16 segmented modes.  NT is an example that
>uses a 32-bit flat programming model [like most recent Unix machines]
>I'm not aware of any operating systems that currently exposes the 16:32 
>programming mode.
>
>But, the point is is that its the historical operating systems that are
>the restriction, not the chips themselves.  Blame the Intel chips for having
>a shortage of registers, or blame them for being CISC,...., but don't blame them
>for being "16 bits" -- because they aren't.
>


	Of course. I mean that while we have hardware that can do
nice things, only very recently has there been any software with
>16 capability (namely OS/2). Excepting of course 386 Unix systems.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: vinoski@apollo.hp.com (Stephen Vinoski)
Subject: Re: template static data members
Date: Wed, 19 Aug 1992 14:54:23 GMT
Organization: Hewlett-Packard Corporation, Chelmsford, MA

In article <4086@seti.UUCP> Daniel R. Edelson <edelson@sor.inria.fr> writes:
>In article <Bt5FDH.DFK@apollo.hp.com>, vinoski@apollo.hp.com (Stephen Vinoski) writes:
>|> 
>|> 	template<class T> Simple LessSimple<T>::s;
>|> 
><problem and explanation omitted>
>|> 
>|> Unfortunately, in the example case
>|> above, ``s'' cannot be explicitly initialized, and the problem cannot
>|> be solved without changing the declaration of Simple so such
>|> initialization is allowed (if possible).
>|> 
>|> -steve
>
>Can't it be initialized with a temporary which the compiler
>may or may not optimize away?
>
>	template<class T> Simple LessSimple<T>::s = Simple();
>
>(Not that this makes the bug much less annoying.)

Yes, this works.  I had tried this a couple months ago when I first
ran into this problem, but I must have done something wrong because it
didn't work. :-(

Regardless of my error, the real problem underlying all of this is
that the compiler cannot tell a legal program containing an
uninitialized definition for each static data member from an illegal
program containing only declarations, no definitions, for each static
data member, since in both cases a bss symbol is created.  It never
used to matter until templates and automatic instantiation came along.

Thanks for making me go back and try this again, Dan, and also thanks
for embarrassing me in public. :-) You should already know that I am
perfectly capable of doing that without anyone's help. :-)

-steve

-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
From: Oliver.Otto@ossi.fido.de (Oliver Otto)
Newsgroups: comp.lang.c++
Subject: Unix commands from C++
Date: 9 Aug 92 20:47:32 GMT
Article-I.D.: fast.713567392.F00001



Hello All!

is there a way to tell my C++ proggi (compiled with GNU) to open a shell
and to run another program and than to return to the main C++ prog???

Oliver

#! rnews 900
Newsgroups: comp.lang.c++
From: ohrd!twriter@cs.toronto.edu (Timothy Writer)
Subject: Help: Looking for documentation on iostream library.
Keywords: iostream
Organization: "Ontario Hydro - Research Division"
Date: Tue, 18 Aug 92 03:44:48 GMT

I recently compiled gcc-2.2.2 and libg++-2.2 for my workstation,
replacing g++-1.40.3 and libg++-1.39.0.  I understand that the
(io)stream library has changed substantially to conform to the proposed
ANSI standard.  Unfortunately the documentation for libg++-2.2 assumes
the user has adequate documentation for iostreams.  As I have already
spent a small fortune on C++ books which predate the (new) iostream
library, I am reluctant to purchase another.  Is there a
book/paper/report which fully documents only the iostream library?
Where can I get one?  Is there anything available via anonymous ftp?

Thanks for your help.

Tim

-- 
Tim Writer			     phone:  (416) 231-4111 ext. 6990
Ontario Hydro Research Division	     fax:    (416) 237-9285
Toronto, Ontario		     e-mail: cs.toronto.edu!ohrd!twriter
CANADA					     cs.utoronto.ca!ohrd!twriter
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: run-time type checking, freezing, and thawing
Keywords: DAG RTTI
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 13 Aug 1992 08:05:04 GMT

dan@BofA.com (Dan Brockman) writes:

>What is a DAG ?  What is a RTTI ?

A DAG is a Directed Acyclic Graph.
RTTI stands for Run-Time Type Information.

(Of course, having read this, you just as likely none the wiser :-)

-- 
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!
Newsgroups: comp.lang.c++
From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Is C++ "for the rest of us" ?
Organization: netmbx, Berlin, Germany
Date: Mon, 17 Aug 1992 10:47:40 GMT

I have been talking to managers who are very nervous about
moving to C++.  It seems to have a reputation for being
difficult to master, and those of us who program in C++
are sometimes considered Gurus.

C++ certainly helps structure large projects, and after
making the switch I have absolutely no desire to go back
to C.  But it does require a new way of thinking, and it
has some rather obscure aspects...

What guidelines would you give to a manager who is trying
to decide whether to use C++ for an new project?  Would you
suggest that a team with average programmers move to C++ ?
Should a programming team attempt a C++ project if they do
not have any C++ gurus to fall back on?


Jonathan

=======================================================================

Jonathan Robie		jrobie@netmbx.UUCP
Arnold-Zweig-Str. 44	jrobie@netmbx.in-berlin.de
O-1100 Berlin		
Deutschland		Phone:  +37 (2) 472 04 19  (Home, East Berlin)
				+49 (30) 342 30 66 (Work, West Berlin)



-- 
Jonathan

===========================================================================

Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: constructor call during initialization of same class
Organization: TauMetric Corporation
Date: Sun, 23 Aug 1992 15:45:30 GMT

casadei@verona.mit.edu (Stefano Casadei) writes:

>Is it possible to define a class constructor which invokes another
>constructor of the same class during the initialization phase (i.e. between
>the : and the body) ? If not, why is such a simple feature not implemented
>in the language ?

A constructor turns raw storage or an object of some type into the
constructor's object type.  You may invoke a constructor to create
an object from inside a constructor:
	class foo { ... foo(); foo(int); }
	foo *fp;
	foo::foo()
	{
	    foo f(1);	// create another foo 'f' inside the constructor
	    fp = new foo(2);	// create another foo on the heap
	}
Of course, the local foo 'f' created inside foo::foo() is destroyed when
foo::foo() exits.

I am guessing that you want to share some code by having several
constructors call a "basic" constructor.  You can't do that with
a construcutor.  You can write an initialization function which all
constructors call.  This is equivalent to what I think you want:
	class foo {
	public:
	    foo();
	    foo(int);
	    foo(char*);
	private:
	    init();
	}
	foo::foo() { ... init(); ... }
	foo::foo(int i) { ... init(); ... }
	foo::foo(char* p) { ... init(); ... }
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Temporary variables and unnamed objects
Keywords: Constructors,temporary,unnamed
Organization: :
Date: Sun, 16 Aug 1992 08:03:34 GMT

In article <BszD04.7Ao@world.std.com>, pkturner@world.std.com (Prescott K Turner) writes:

> > Finally, the ARM says that the constructor is not true a callable function
> > which has no return type, yet cfront allows:
> > 
> >   Object(3).doSomething()
> > 
> > which implies that constructors *DO* return values (i.e., the object being
> > constructed,) and that it returns an lvalue.
 
> Here, you've made the common error of mistaking Object(3) for a function
> call, when it's actually an explicit conversion (ARM 5.2.3).

This is true, but perhaps not quite complete.  If the constructor took
several arguments, you could still use it:

		x += Complex( alpha, ( alpha + 1 ) / beta );

Thus expression are permitted beyond what conversions alone allow.

I somewhere saw this construct called a `value builder' and I like
the term.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: kent@world.std.com (kent c leonard)
Subject: looking for ftp site for djg c++
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 12 Aug 1992 22:06:02 GMT

Like the subject says, I'm looking for the DOS c++ compiler.

Please email kent@world.std.com

thanks,
kent
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Is C++ "for the rest of us" ?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 17 Aug 1992 12:46:22 GMT

In article <1355EN@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
>I have been talking to managers who are very nervous about
>moving to C++.  It seems to have a reputation for being
>difficult to master, and those of us who program in C++
>are sometimes considered Gurus.
>
>What guidelines would you give to a manager who is trying
>to decide whether to use C++ for an new project?  Would you
>suggest that a team with average programmers move to C++ ?
>Should a programming team attempt a C++ project if they do
>not have any C++ gurus to fall back on?
>
	The principal issue is the quality of the compiler, surely.
After all, you can write C in C++ quite happily. C compatibility
is C++ biggest advantage (and biggest disadvantage).

	I still write lots of 'C' programs, they just happen
to have built in strings, lists, extensible arrays and other
things you always wanted in C. Thats why its C, ++ :-)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: rogers@eagle (Bill Rogers)
Newsgroups: comp.lang.c++
Subject: RE:Help? TV stream...DAMN!
Date: 19 Aug 92 20:13:43 GMT
Article-I.D.: news.Bt8yuw.E40
Organization: Sangamon State University
X-Newsreader: Tin 1.1 PL4

My newreader and emacs are fighting each other. Sorry bout that above.

Let's start again.

How do I check to see if a stream created object was actually creted without
error? Here is the constructor that seems to work just fine, I can't
tell the caller what happen without using a global, something I'd rather not.


TFieldCollection::TFieldCollection( char *filename ):
				TCollection (streamableInit ) {
    if(filename == NULL) return;
    ifpstream in( filename );
    if (in) {
	// This is cool, but I could use some error checking here also.
	in >> *this;
	in.close();
    } else { // Damn no file found!
	messageBoxRect (TRect(10,10,50,19),mfOKButton,
		"Damn! file: %s not opened.",filename );
    }  /* if (in) */
}

I call this like:
	 TFieldCollection *fc = new TFieldCollection("somefile.ext");
but:
	if(fc) //doesn't seem to work

TIA,
Bill
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<> Bill Rogers, Assistant Director for Academic Computing Services          <>
<>              Sangamon State University, HSB-115                          <>
<>              Springfield, Il 62794-9243     fax:217-786-7188             <>  
<> Internet:rogers@eagle.sangamon.edu        voice:217-786-7352(Mon.->Thur.)<>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Newsgroups: comp.lang.c++