HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.lang.c++
Subject: Re: streams
Date: 17 Oct 92 04:03:05 GMT
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

In article <rmartin.719166192@donner> rmartin@donner.Rational.COM (Bob Martin) writes:
>cshaver@informix.com (Craig Shaver) writes:
>
>>In article <1992Oct13.155518.22845@rs6000.bham.ac.uk> pickerig@dns0.bham.ac.uk (Mr. G. Pickering) writes:
>>>My first reaction is to use FILE functions rather than streams, unless
>>>you have a good reason to use streams. This is just the way I do things,
>>>feel free to flame me for this.
>
>>Praise the lord for a breath of fresh air -- streams are hard to use!
>
>IMHO this statement is too strong.  Streams are different, to be sure;
>but they are not truly hard to use.  

	They are almost IMPOSSIBLE to use for me. There is NO published
documentation worth a grain of salt that I'm aware of. They are NOT
in the ARM, and Borlands doco skips over the harder, more interesting
bits. I dont have the official AT&T libraries so I dont have their
doco. I have the source code, mind you, but it impressed me
as being rather complex.

>Moreover, they have a number of advantages that should not be ignored.  
>
>	They are type safe.  You cannot foul up your stack with
>statements like printf("%d\n", 1.0); or the more malignant scanf form.

	Yes. But using strings has the same advantage.
>
>	They are extensible.  You can create I/O operators for new
>data types.

	You can also convert any new type to a string the same way.
>
>	They are polymorphic.  You can invoke the correct I/O
>operators without knowing the types of the data you are I-ing or O-ing
>(this requires a little preplanning, and some appropriately placed
>virtual functions)

	This is much harder to do with strings, that is, input
is probably done better with streams. 
>
>When I first started using C++, I often fell back on stdio.h, simply
>because I knew it well, and was comfortable with it.  But over time I
>used streams more and more.  Now, I never think about using stdio
>anymore.  Not that stdio is bad, it's just that now I am used to
>streams.
>
>--
>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++


	So tell me: I have a 

	class string { int length; char *s; ...};

and I want to USE it as a stream ( a sort of packaged strstream).
How do I do that?

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c++
Subject: Re: Is pointer in my address space?
Date: 9 Oct 1992 20:41:00 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Oct9.190838.19205@bcrka451.bnr.ca> senior@bcrki69.bnr.ca (Dan Senior) writes:
>Suppose you are writing a utility and want to check that you have 
>been passed valid parameters? Isn't Andrzej practicing safe style? :)

Just because it's in your address space doesn't mean it's correct.  And in
fact, the pointers that point to random data in your address space are the
more dangerous ones; other pointers will at least cause a fault, so the
program will halt immediately rather than possibly producing incorrect
results.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.c++
From: weiyeh@previous.cc.columbia.edu (Wei-Yeh Lee)
Subject: Re: My objects are too big - why?
Organization: Columbia University
Distribution: comp
Date: Fri, 9 Oct 1992 22:17:59 GMT

vinoski@apollo.hp.com (Stephen Vinoski) said:
> 
> > The Base class is empty, but must have a non-zero size (ARM, chapter
> > 9, page 164), so its size is 1.
> 
> Why must an empty class have non-zero size? Speculation around here was  
so
> that:
> 
> 		int foo ;
> 		base bar ;
> 		base bat ;
> 
> 
> would all have unique addresses.
Precisely, If an object did have a zero size, then the next object that  
gets new'ed may be placed at the same address.

/weiyeh
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Save the Bamboo forests		Wei-Yeh Lee          weiyeh@columbia.edu
Columbia University	Academic Information Systems  Unix Systems Group
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Newsgroups: comp.lang.c++
Organization: University of Illinois at Chicago
Date: Tuesday, 13 Oct 1992 12:50:29 CDT
From: <U28165@uicvm.uic.edu>
Newsgroups: comp.lang.c++,comp.lang.c,comp.sys.ibm.pc.soundcard
Subject: Sound Blaster Development LIB

Are there any SB or SB Pro libraries available for c or c++?  If so what
anonymous ftp sites and what files are available?  Any help would be
greatly appreciated.
                               john (fredin@earth.eecs.uic.edu)
                                    (u28165@uicvm.uic.edu)
Newsgroups: comp.lang.c++
From: bytor@grumpy.bellcore.com (Ross Huitt)
Subject: Re: Proposal: Preconditions and PostConditions in C++
Organization: Bellcore
Date: Fri, 9 Oct 92 14:14:59 GMT


If you have a derived class is meant to be a subtype (if it is suppose to be completely type
compatible in all situations with the base class) then you definitly would want to inherit
pre/post-conditions and invariants. This is at least a minimum criteria for type compatibility.
If, on the other hand, a subclass is not meant to be type compatible (if it is inheriting for
implementation instead) then you don't want the burden of the contraints. C++ doesn't have
any way of differentiating different kinds of inheritance nor does Eiffel (I think). I find
myself rarely, if ever, inheriting where the derived class is not intended to be type compatible.
Maybe its just a stylistic quirk, but I never find the need to loosen the constraints of a base
class.

Ross Huitt
bytor@ctt.bellcore.com


In article <1992Oct9.095955.24874@aut.abb.se>, alindbac@aut.abb.se (Anders Lindbck) writes:
|> In article <1992Oct7.185350.8033@walter.bellcore.com> bytor@grumpy.bellcore.com (Ross Huitt) writes:
|> >In article <1992Oct7.125441.10012@aut.abb.se>, alindbac@aut.abb.se (Anders Lindbck) writes:
|> >|> In article <Bvq8tF.J3C@fiu.edu> feathers@serss0 (Michael Feathers) writes:
|> >|> >I advance this idea with some trepidation... (ooh! noo! new language 
|> >|> >feature!) but has anyone considered adding Eiffel-style pre and post 
|> >|> >conditions to C++?
.....
|> 
|> >The major problem that prevents macros from being used is inheritance of conditions.
|> [Example deleted]
|> >Problem:
|> >Base::i(int) has specified a precondition. A user is then free to derive a class and redefine
|> >the method and violate the precondition in a way that is never detected. The user must have
|> >the discipline to copy the precondition down everytime the method is redefined. In Eiffel,
|> >at least, pre-post/conditions and class invariants are inherited. 
|> 
|> But is that really a good thing ?
|> 
|> There is nothing that says that a precondition which is valid in a base 
|> class is a prescondition which must be valid for a derived class. 
|> A base class may have more restrictions than a derived class 
|> (and sometimes vice versa but that's not the issue here). 
|> 
|> So to always inherit the pre- and post-conditions may not be a good thing. 
|> 
|> On the other hand one can always question the fact that one has a derived 
|> class that is more tolerent than a base class; but that's another question. 
|> 
|> >
|> >There are other problems but, IMNSHO, this is the worst of the lot.
|> >
|> >Ross Huitt
|> >bytor@ctt.bellcore.com
Xref: sparky comp.lang.c++:15027 comp.std.c++:1389
From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: NULLing a pointer
Date: 15 Oct 92 18:28:42 GMT
	<1992Oct5.234314.8127@CSD-NewsHost.Stanford.EDU> <Bw35Ev.FKM@csc.liv.ac.uk>
	<WARSAW.92Oct15103415@anthem.nlm.nih.gov>
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.


    me> With delete(void*), I can't even do it.

I should have said, I can't do it with op delete. I have to use some
other method name.  No big deal, I s'pose...
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: Preconditions and PostConditions in C++
Date: 12 Oct 1992 17:09:47 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Oct12.135729.9116@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>What is one real example where private bases give you an advantage over
>including a member object? Every time I've thought about this, it seems
>to me that the private base forces the derived class to use a particular
>implementation---and that is likely to cause difficulties during the
>maintenance phase of a program's life.

Yes, usually the purpose of private derivation is to force the use of a
particular implementation, but this does not have the consequence you
fear, because it hides this fact from users of the class.  For example,
one "standard technique" is to use multiple inheritance, publicly
inheriting from an abstract baseclass that specifies an interface (e.g. an
associative array), and also privately inheriting from a "concrete"
baseclass that provides an implementation (e.g. a hash table, B-tree,
AVL-tree, etc).  This has the benefit that completely different
implementations can be "dropped in" based on what will perform best in a
given application; maintenance becomes easier, not harder.

But yes, private derivation does end up looking a lot like including
the privately inherited object as a member (for example, if private
inheritance were dropped from the language, you could get the same
effect in most cases by including the privately inherited baseclass as
a member of the (no longer) derived class and passing method calls along).
However, there are often some efficiency and space advantages, as well
as coding advantages, to doing it with private inheritance.



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.lang.c++
From: mdk34398@uxa.cso.uiuc.edu (Mike Krupicka)
Subject: streams
Organization: University of Illinois at Urbana
Date: Tue, 13 Oct 1992 14:09:14 GMT

I am writing some code where I would like to be able to read in either from
stdin or from a file. What I want to know is how do you initialize the stream,
and pass it to a common var. I tried something like the following and had
problems because the code was local only to the if statement.

main(){
.
.
if (stdflag)
	ostream& fin = cin;
else
	ofstream& fin("test.in");

Any ideas?

Mike Krupicka
beaker@uiuc.edu
Newsgroups: comp.lang.c++
From: cshaver@informix.com (Craig Shaver)
Newsgroups: comp.lang.c++
Subject: Re: virtual destructors
Date: 13 Oct 92 00:17:54 GMT
Organization: Informix Software, Inc.

In article <1992Oct12.164043.18038@aplcen.apl.jhu.edu> ded@aplcen.apl.jhu.edu (nod sivad) writes:
>
>Thanks to everyone who responded to my problem concerning the need
>to call the destructors of derived objects with a base class 
>pointer.  I said in my message what I really needed was a virtual
>destructor.
>
>The answer to my problem is...declare a virtual destructor.  Duh.
>

C++ is complex enough to be self destructive :)

-- 
Craig Shaver  (cshaver@informix.com for now) (415)390-0654 (415)926-6407
Productivity Group POB 60458 Sunnyvale, CA  94088
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: Preconditions and PostConditions in C++
Summary: public and private bases
Date: 9 Oct 92 19:15:45 GMT
Article-I.D.: alice.23852
Organization: AT&T Bell Laboratories, Murray Hill NJ




bytor@grumpy.bellcore.com (Ross Huitt @ Bellcore) writes

 > If you have a derived class is meant to be a subtype (if it is suppose
 > to be completely type compatible in all situations with the base class)
 > ... on the other hand, a subclass is not meant to be type compatible
 > (if it is inheriting for implementation instead) ... C++ doesn't have
 > any way of differentiating different kinds of inheritance nor does
 > Eiffel (I think).

Actually, C++ does: public derivation implies a subtype relationship,
private derivation doesn't.

 > I find myself rarely, if ever, inheriting where the derived class
 > is not intended to be type compatible.

Public bases are far the most common, but there are cases where private
bases are useful.
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: NIHCL
Keywords: C++ NIHCL
Date: 13 Oct 92 16:53:08 GMT
Article-I.D.: alice.23874
Reply-To: ark@alice.UUCP ()
Distribution: na
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Oct13.104738.9270@cbnewsm.cb.att.com> trix@cbnewsm.cb.att.com (t.roger.kiang) writes:

> If that's true, then what was all that bruhaha when
> NIH try to patent those genetic patterns they found
> in their research.

I have no idea.  What I do know is that the source code for NIHCL
explicitly says that anyone may use it for any purpose.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: Tachen Ni <tcnyyf@caen.engin.umich.edu>
Subject: Q: How to change the byte length of type "double" in g++?
Date: Thu, 08 Oct 92 13:21:23 EDT
Organization: Bioengineering, Univ. of Mich.
X-Useragent: Nuntius v1.1.1d9
X-Xxmessage-Id: <A6F9E5E50501343C@no-name-medsci2.med.umich.edu>
X-Xxdate: Thu, 8 Oct 92 18:19:33 GMT


Recently I found that the default g++ (Version 1.37.1 on Unix
machine) byte length for data type "double" (8 bytes) is not 
enough for my project.  Is there any way that I can change it 
to 12 bytes?  

Reply by e-mail preferably.  Thanks for the help.  


Tachen Ni, Bioengineering Program, Univ. of Mich.
e-mail: tcnyyf@caen.engin.umich.edu
Xref: sparky comp.lang.c++:14967 comp.lang.c:14960 comp.sys.ibm.pc.soundcard:2774
From: atm@bass.bu.edu (Atul Mistry)
Newsgroups: comp.lang.c++,comp.lang.c,comp.sys.ibm.pc.soundcard
Subject: Re: Sound Blaster Development LIB
Date: 14 Oct 92 12:52:59 GMT
Article-I.D.: bu.98595
Reply-To: atm@bass.bu.edu (Atul Mistry)
Followup-To: comp.lang.c++
Organization: Boston University

In article <92287.125029U28165@uicvm.uic.edu> U28165@uicvm.uic.edu writes:
>Are there any SB or SB Pro libraries available for c or c++?  If so what
>anonymous ftp sites and what files are available?  Any help would be
>greatly appreciated.
>                               john (fredin@earth.eecs.uic.edu)
>                                    (u28165@uicvm.uic.edu)
From: checker@acf5.NYU.EDU (checker)
Newsgroups: comp.lang.c++
Subject: Re: Const and Reference
Date: 9 Oct 92 18:45:07 GMT
Organization: New York University

c7821027@csie.nctu.edu.tw (Shih-Hao Liu) writes:
>#include <stdio.h>
>main()
>{
>    char a = '-';
>    const char &b = a;

>    b = '+';
>    printf("%c\n");
>}
>What output should we excepted?

This shouldn't compile, let alone generate output.  Also, you should put
a character in the argument list of printf if you want to print one.

Chris
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: vsprintf vs. incore-formating: philosophy
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 9 Oct 1992 18:14:21 GMT

In article <ric.718471686@updike> ric@updike.sri.com (Richard Steinberger) writes:
>
>	Can anyone provide some advice on whether to use vsprintf() in 
>a C++ program?  This C library function is not overloadable/extensible,
>but it does exactly what I need done with standard data types.  Do people
>generally feel that it is worth the effort to develop a similar 
>function using incore formatting and thus follow "the spirit of C++"?
>	If an extensible vsprintf-like function were available in C++, I
>would probably use it, but I am reluctant to try to write one when
>vsprintf() today is adequate to current needs.  Any thoughts?
>
	Well, everyone else will disagree with me :-) but
I define a string class, then define 

	string aprintf(char*, ...);

which is implemented using vsprintf and som varargs stuff.
All non builtin types T you want to print define a member

	string T::print()const;

or just a conversion to string. Given all that, you can use
strings for incore formatting. Better, you dont need to
worry about overloading << to get output for each class.

(You can define string output instead, once)

Using printf like functions is naughty because its easy to
mismatch the format string and the other arguments.
But at least I understand how it works, I dont have any
specs on the iostream classes (only the source :-)

-- 
;----------------------------------------------------------------------
        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: rick@mel1.geg.mot.com (Rick Rankin)
Subject: Re: Problems compiling libg++-2.1 for RS/6000
Organization: /mel1/u/rick/.organization
Date: 7 Oct 92 14:54:06

In article <1992Oct6.193117.17657@bcrka451.bnr.ca> noye@bcrka378.bnr.ca (Janet Noye) writes:
Path: schbbs!mothost!ftpbox!uunet!mcsun!uknet!stl!bnrgate!bcrka451!bcrka378!noye
   From: noye@bcrka378.bnr.ca (Janet Noye)
   Newsgroups: comp.lang.c++
   Date: 6 Oct 92 19:31:17 GMT
   Sender: 5E00 Corkstown News Server
   Reply-To: noye@bcrka378.bnr.ca (Janet Noye)
   Organization: Bell-Northern Research, Ottawa, Canada
   Lines: 16

   I am having problems building libg++-2.1 on the RS/6000.  When it gets to the 
   String.cc file the assembler gives a list of errors.  I have the patch for
   the RS assembler and was able to build gcc-2.1 and am using gcc to build
   libg++.  I would appreciate any information from people who have run into
   to this problem or have succesfully built gcc 2.x and libg++ 2.x for the
   rs/6000.  I am running AIX 3.2

   Thanks for your help,
   Janet Noye

   -------------------------------------------------------------------------------
   Janet Noye : email : noye@bnr.ca                Bell-Northern Research Ltd.
		phone : (613) 763-5985             P.O. Box 3511, Station C
		fax   : (613) 765-4845             Ottawa, Ontario K1Y 4H7
						   Canada
   -------------------------------------------------------------------------------
 I had the same problem.  Use gcc-2.2.2 and libg++-2.2.  The work fine.

--
==============================================================================
| Rick Rankin				|				     |
| Motorola				| Voice: 602-441-5726		     |
| Government Electronics Group		| Fax: 602-441-2919		     |
| 8220 E. Roosevelt St.			| Internet: rick@mel1.geg.mot.com    |
| Scottsdale, AZ 85252			|				     |
| Mail Drop R4246			|				     |
==============================================================================
Newsgroups: comp.lang.c++
From: ren@function.mps.ohio-state.edu (Liming Ren)
Newsgroups: comp.lang.c++
Subject: Re: GNU C++
Date: 12 Oct 1992 21:43:18 -0400
Organization: Department of Mathematics, The Ohio State University
NNTP-Posting-Host: function.mps.ohio-state.edu


Does anybody know where I can ftp the  GNU c++ manual or the description of GNU c++?
Is there such a site?

Thanks!
From: wilson@mailhost.aa.cad.slb.com (David Wilson)
Newsgroups: comp.lang.c++
Subject: Book on Turbo Vision? (was Re: Turbo Vision's redraw())
Date: 8 Oct 92 13:18:28 GMT
Article-I.D.: aa.1992Oct8.131828.10885
Organization: Schlumberger CAD/CAM; Ann Arbor, Michigan (USA)

In article <13050@biggs> theoretj@Software.Mitel.COM (Jean-Francois Theoret) writes:
>
> ...
>
>I would also need a good Turbo Vision Reference Book (apart from 
>Borland's original...) if it exists.  Thanks in advance.
>

I would like to second that request!  I've heard about the series of articles
in Dr. Dobb's about Turbo Vision, but I've yet to see a specific reference
to any book on the subject.  If you know of one, please tell us about it.
I don't care if it's specific to Pascal or to C++.  Anything would be more
than I've got now.

Dave Wilson
Newsgroups: comp.lang.c++
From: nagle@netcom.com (John Nagle)
Subject: Re: virtual destructors
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 12 Oct 1992 23:55:15 GMT

ded@aplcen.apl.jhu.edu (nod sivad) writes:
>The answer to my problem is...declare a virtual destructor.  Duh.

>Yes, I've RTFM, perused the FAQ, books, magazines, etc.  Did I remember all 
>that stuff?  Obviously not.  My only experience with the virtual keyword
>was with virtual functions, and in that case one is required to name 
>the functions identically.  I had the idea "virtualness" required identical 
>names and thus didn't attempt it with differently named destructors.  Ah, well.

       It's not your fault.  The language is badly designed in this area.
Destructors should always be virtual, and it should be an error (at least
a warning) to declare one that isn't.

					John Nagle

Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: vsprintf vs. incore-formating: philosophy
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 14 Oct 1992 11:37:24 GMT

In article <1992Oct8.161142.2627@taumet.com> steve@taumet.com (Steve Clamage) writes:
>ric@updike.sri.com (Richard Steinberger) writes:
>
>
>>	Can anyone provide some advice on whether to use vsprintf() in 
>>a C++ program?  This C library function is not overloadable/extensible,
>>but it does exactly what I need done with standard data types.  Do people
>>generally feel that it is worth the effort to develop a similar 
>>function using incore formatting and thus follow "the spirit of C++"?
>
>The function is part of the Standard C library, and is thus part of C++.
>In that respect it is perfectly legal.
>
>However, the printf (and scanf) family of functions are inherently
>unsafe: They take variable argument lists, and have unchecked type
>dependencies between the format string and the actual arguments.
>These functions are contrary to the "spirit of C++", which
>involves type safety, among other things.
>
>If you want to use vsprintf, do so.  If you want the advantages of
>C++ type checking and extensibility, don't use it.  You can use
>iostreams to do almost anything you can do with printf/scanf.
>
>In particular, you can use strstreams to get safe in-memory
>formatting.  One concern with sprintf is overflowing the target
>buffer.  This needn't happen with strstreams, apart from the
>type-safety and user-extensibility advantages.
>-- 

	The idea of

	stream << object;

is flawed because it assumes that there is only one way to represent
the object. Using 'inserters' and 'maniulators' etc is a pretty
poor way to fix this. In my opinion the correct way to do this
is have univeral type 'string' then have

	print(stream&,const string&);
or
	ostream::operator<<(const string&);

Now for each type you can have a function like

	string sci(float,int len, int decimals);

which is more or less the method used in Modula.

	Hence

	cout<<sci(3.7,3,1) << str(i,10) << ...;

This looks more like printf. It also has the advantage of
automatically giving you "incore" formatting

	string s=sci(4.5,10,4);

and is easier to understand. The reason that the << mechanism
is so hard to use I think is that it introduces coupling
between the objects and the manipulators. The above method
"encapsulates" the formatting parameters in the call.

(Objects that convert to strings automatically can be printed
directly)

The other advantage is that you can make your
classes 'device independent' by NOT mentioning
iostreams in them.  Instead mention 'string', which
is a 'memory only' system independent class.

Anyhow, there are now *three* advertised methods,
using printf, using iostreams, and using strings :-)
Take your pick.




-- 
;----------------------------------------------------------------------
        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++