HDTenEightyP/NetNews huggingface dataset:
From: erc@netcom.com (Eric Smith)
Subject: Re: template disappointments ... (suggestions?)
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Thu, 31 Dec 1992 15:01:38 GMT

In article <1992Dec30.173230.22878@taumet.com> steve@taumet.com (Steve Clamage) writes:
>In a template instantiation, the 'int' argument might be any expression,
>including one containing right shifts.  If you try to allow what appears
>to be a right shift to be two closing ">" instead, you wind up with
>nondeterministic lexing/parsing, ambiguous grammars, or context-sensitive

How is >> different from > in that respect?  a>b is a perfectly valid
int expression.
Newsgroups: comp.lang.c++
From: priceje@cs.aston.ac.uk (Jason Price)
Subject: Request: Templates & Matrix classes
Reply-To: priceje@cs.aston.ac.uk
Organization: Aston University (Comp Sci)
Date: Tue, 22 Dec 1992 11:23:48 GMT

(Saw a memo here by Mitch Dernis (below) to which this is specifically addressed, but any information or help would be very useful.  Many thanks)\

> 
> In article 4904@news.cs.brandeis.edu, dernis@binah.cc.brandeis.edu () writes:
> >Hi,
> >  This is a fairly simple template question, I hope.
> >I have written a template class, which has been tested and
> >appears to work (mostly at least).  Now I tried to use and I 
> >have found a problem.
> >
> >The class is a matrix class, and works with all numerical types
> >(I have only tested the two that I need - but presumably).
> >
> >Now I want to declare a function which returns a complex Matrix.
> >
> >So I wrote,
> >
> >Matrix<complex> function();
> >
> >But I discovered a problem immediately, that this interprets this
> >as instance of Matrix<complex>, not a function declaration.  It now
> >occurs to me that indeed that is exactly what I have written, and
> >it rightfully complains that I left out the arguments.
> >
> >Does this mean at that I have to template this function too, and do 
> >something like:
> >
> >template <class T>
> >void function(Matrix<T>& ref_to_value);
> >
> >Is there a way I can write a function that will return a complex
> >instance of my matrix class without writing the function as a template.
> >The above my be acceptable, even better as it does not generate a 
> >temporary, but still. . .
> >
> >Thanks,
> >Mitch Dernis
> 
> 
> 
> 


There's a group of research students here at Aston University who are trying to write C++ matrix classes for use in Neural Networks applications.  Do you have any examples of code you have written for operations on matrix classes that we might be able to use?

Also, we haven't yet used templates to pass in items of any type to our matrix classes and we do not at present have a c++ compiler to support this.

Could you supply details of compilers for SUN systems which meet the requirements of passing any type into a class?  (our systems administrator asked me to mention compilers for Solaris 2.1)

Many thanks,

Jason Price.
Neural Computing Research Group
Computer Science & Applied Mathematics
Aston University, U.K.

email: priceje@cs.aston.ac.uk


Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Operator "new" - how to catch array-allocation?
Date: 18 Dec 92 19:23:07 GMT
Organization: Microsoft Corporation

In article <1992Dec17.131239.8036@daimi.aau.dk> sabroe@daimi.aau.dk (Morten Sabroe Mortensen) writes:
|The reason I raised this in the first place is, I'm about to build my own
|special-purpose-heap-manager, -the way I would like it to work, is to attach
|"something" to a given class, and then the result should be, that all dynamic
|allocation involving that class should be managed - the way you allocate
|should be independent of how heap-management is controlled - controlled by
|the normal general-purpose manager or a special-purpose manager!
|As I see it, -now-, I can't get this independency - except when allocating 
|single instances of the used class! Right?

You can do it now -- you just can't do it by overloading the standard syntax,
because "today"s compilers follow the rule that allocating new arrays
uses the global allocator, and thus is not an issue under class control.

As examples of approaches you could use today that don't use standard
syntax, consider the following:

You could provide a static member function to allocate your arrays:

	Foo* arrayOfFoo = Foo::NewArray(1000);

where NewArray could, for instance, be implemented using malloc and then
the objects of the array init'ed using placement operator new on each element.

Note then you need to provide a compatible method for deleting your arrays:

	Foo::DeleteArray(arrayOfFoo);

or:

	DeleteArray(arrayOfFoo);

or something.

An alternate [even more hack IMHO] approach you see people using occasionally
is to overload operator new using "placement" syntax:

	Foo* arrayOfFoo = new (1000) Foo;

where inside of this "placement" you know the size of the object, you
know how many objects -- you just don't necessarily know what Ctors should
be invoked on each element, since Foo could be derived from, meaning
that this overloaded new would need to be reimplemented in each deriving
class.  Also, given that this new looks to the compiler like an allocator
for one element, the compiler will automagically init the first element
of the array, so one had better not do that inside the placement new.
One still has the issue then how to deallocate this thing....as you
might guess I don't recommend this approach.

Newsgroups: comp.lang.c++
From: dshaker@qualix.com (Doug Shaker)
Subject: Re: IS C++ a language for the "average pro
Reply-To: dshaker@qualix.com
Organization: QUALiX Group, Inc.
Date: Thu, 24 Dec 1992 17:09:29 GMT

In article 19600@fcom.cc.utah.edu, val@news.ccutah.edu (Val Kartchner) writes:
>rmartin@thor.Rational.COM (Bob Martin) writes:
>: sam4628@zeus.tamu.edu writes:
>: |In article <rmartin.724431509@thor>, rmartin@thor.Rational.COM (Bob Martin) writes...
>: |..
>: |> 
>: |>This is not a new idea.  Calculus is more complex than algebra.  Yet,
>: |>once learned, it alows a whole new ream of concepts to be conveniently
>: |>expressed.  
>: 
>: |Yes, but does OO _really_ allow you to tackle a more complex problem?
>: |Or does it just allow you a new "notation" which is conveniently adapted
>: |to the more complex type of problems?  
>: 
 
Arghh...  Why would you think that new notations are irrelevant to the type
of problem that you can solve?  It may be that notations are equivalent in
some simple sense, e.g. Turing machine equivalent, but that doesn't mean that
they make no difference to the humans using them.

Example 1: Abandon all traditional color names and, using only wavelength ranges,
phrase a compliment to your [wife|husband|whoever] that you think the color
of their clothing nicely compliments their hair color.  Make it persuasive enough
that they feel flattered.

Example 2: Build an X-window Motif-look-and-feel project management tool that 
with a drag-and-drop PERT chart interface, using only assembly language and get it
to market on the four major Unix platforms within 18 months.

Example 3: Explain the concept of a molar solution without using the terms atom,
proton, electron, molecule, or the names for any other atomic or subatomic particles.

Notation is NOT some trivial notion to be tossed off as surface only.  It is
a language we construct that ENABLES complex thoughts.

 - Doug Shaker
	voice:	415/572-0200
	fax:	415/572-1300
	email:	dshaker@qualix.com
	mail:	Qualix Group
		1900 S. Norfolk St., #224
		San Mateo, CA 94403
From: wlee@sales.GBA.NYU.EDU (Wai-Shing Lee)
Newsgroups: comp.lang.c++
Subject: Is calling a function to assign a value to a static global legal?
Date: 31 Dec 92 06:16:55 GMT
Organization: NYU


   I want to initialize a static global at run-time but I don't want to
have to have a programmer using my modules to have to call some init() funciton
at the begining of thier main().

I can get this to compile under Borland C++ 3.1, but only if it is compiled as
C++, it doesn't like it if it is compiled as plain Borland C.

extern "C"
{
#include <alloc.h>
}

static int *pointer ;
static int initialized=findvideomemory() ;

static int makepointer(void)
{
	pointer=(int*)calloc(10, sizeof(char)) ;
}

The variable "initialized" is junk, but I could just as easily return a value
from makepointer(), but I have more stuff going on in makepointer() than
appears here.

I've traced it and sure enough makepointer() is called and pointer is assigned
a value before main() even starts.  Is the portable, legal.  I didn't look
to hard in my C++ book, but there weren't any obvious answers.  Is this
C++, C or something I should stay away from?

Thanks
Date: Saturday, 2 January 1993 20:24:14 EST
X-Mailer: TMail version 1.14R
From: "Tim Triemstra" <empath@ais.org>
Organization: Empath Software
Subject: Creating Streams
Newsgroups: comp.lang.c++
Distribution: world

I am interested in writing functions very similar to COUT and CIN for use
within a GUI.  Essentially, I want the functions to the exactly like
COUT and CIN, except I want whatever information COUT or CIN would be
piping in or out to first get piped into another function.

For instance, to say COUT << "Hello\n"  I would like COUT to put the
hello as a parameter to a function called GUI_COUT or something of that
sort.  GUI_COUT would of course have to be overloaded to take strings and
int's and whatnot - but that's not a big deal.  GUI_COUT would, of course,
use the graphical font functions to output the string or number or whatnot
onto the screen.  It would also, once complete, also keep track of the
graphical cursor and control word-wrap and all kinds of other neat things.

So, how could I do this?  I assume you could just look into the source for
the file IO and look to change some of this stuff so I could create a
stream similar to ofstream and ifstream and create an object of that
stream.  However, as I am new to C++ and its details I'd love some info on
it.  Thanks in advance.

Tim

-------------------------------------------------------
| When the end comes, there will be two men standing: |
|   Me, and the guy I gotta kill.   - Gosh I'm EVIL   |
------ Tim Triemstra ------------- empath@ais.org -----
Newsgroups: comp.lang.c++
From: suresh@papaya.iss.nus.sg (Suresh Thennarangam - Research Scholar)
Subject: Re: Can't I initialize a dynamically allocated object in its constructor
Reply-To: suresh@iss.nus.sg (Suresh Thennarangam - Research Scholar)
Organization: Institute of Systems Science, NUS, Singapore
Date: Mon, 28 Dec 1992 03:15:32 GMT

In article <1992Dec27.200209.19143@news2.cis.umn.edu> hansen@myria.cs.umn.edu (David Hansen) writes:
>In article <1992Dec22.114251.6663@nuscc.nus.sg>, suresh@papaya.iss.nus.sg (Suresh Thennarangam - Research Scholar) writes:
>[... most of included code deleted ...]
>|> > 
>|> > Vector Vector::operator+ (Vector& a){
>|> >    if (getsize() != a.getsize()){
>|> >       printf("operator '+':Vectors are not of the same size.\n");
>|> >       exit(0);
>|> >    }
>|> >    Vector retVect(getsize()) ;
>|> >    for (int i = 0 ; i < a.getsize() ; i++){
>|> >       retVect.item[i] = item[i] + a.item[i] ;
>|> >    }
>|> >    return retVect ;
>|> > }
>|> > 
>|> My point:
>|> 
>|> retVect used above is a automatic variable that will go out of scope
>|> as soon as the function Vector::operator+() is exited and it's 
>|> destructor will be called which will deallocate the memory
>|> that was allocated by the constructor. Although the returned
>|> Vector object is a copy and will have a valid item pointer, it will 
>|> be pointing to deallocated data.
>
>Ummm, I don't think so.  True, retVect is automatic and will be destroyed when
>it leaves scope.  However, at least on _my_ system (CenterLine ObjectCenter),
>the copy constructor is called _before_ retVect is destroyed.  The copy is
>valid.  I would hope this is the way it is supposed to work...
>
>What you describe is the problem that existed _before_ the copy constructor
>was added.  Since none was defined, the compiler generated one which simply
>performed a memberwise initialization of the copy.  Since one of the members
>is a pointer to some memory which is then deallocated before the copy is used,
>we have the classic "dangling pointer."  The copy constructor allocates its
>own memory for the pointer, which is then freed when the temporary is destroyed.
>
>Or is there something else I'm missing?

I think you are right. I tried it out with my cfront2.1  on SUN4 and it does 
work. I omitted to realize that the copy constructor would be called before
the automatic variable retVect went out of scope and that is really the way
it should work. 

Regards,


      __                  
     (_   / /  o_   o  o |_
     __)/(_( __) (_(_ /_)| )_



Newsgroups: comp.lang.c++
From: joe@proto.com (Joe Huffman)
Subject: Re: 32bit Zortech Pointers
Organization: FlashTek, Inc.
Date: Thu, 31 Dec 1992 20:35:31 GMT

empath@ais.org (Tim Triemstra) writes:

>I've worked long and hard converting some SoundBlaster code from MicroSoft C
>to Zortech C++ support (added BC++ along the way as well.)  However, the
>one catch I have come accross seems to be related to the pointers.

>I already converted all the INT calls to reflect 2bytes in the 32bit mode to
>ensure compatibility (I can optimize later.)  So, since it works under the
>Zortech 16bit modes it SHOULD work under the 32bit model.  It does compile

>I am using Zortech C++ 3.04 with FlashTek's X32-VM (very similar to the
>standard DOSX.)

A side note -- X-32VM is just a newer version of DOSX with virtual memory,
TSR support, memory mapped files, and support for Watcom.  The base extender
is exactly the same.

I don't understand what INT calls you converted...  One thing to be careful
of is that if you are trying to pass data to a real mode TSR of some sort, 
then you need to put the data in a real mode buffer... could this be part
of your problem?

-- 
netcom!proto!joe
joe@proto.com
Newsgroups: comp.lang.c++
From: ege@max.fiu.edu (Dr. Raimund K. Ege)
Subject: Re: More Gnu C++ fun
Organization: Florida International University, Miami
Date: Wed, 30 Dec 1992 21:30:26 GMT

In article <1992Dec30.195714.9824@adimail.uucp>, tel@adimail.uucp (Terry Monks) writes:
|> This minimal program
|> 
|> 
|> class node 
|> {
|> public:
|>   static int level;
|>   
|>   node(){};
|> };

	int node::level;
|> 
|> main()
|> {
|>   node::level=1;
|> }
|> 
|> Any clues?

once you add the line "int node::level;", then g++ will compile and link.
There is a paragraph in the g++ FAQ that mentions the details why this is
needed.

-- 
Raimund K. Ege                             School of Computer Science
                                             Florida Int'l University
ege@scs.fiu.edu           (305) 348-3381              University Park
ege@servax.bitnet     FAX (305) 348-3549              Miami, FL 33199
Newsgroups: comp.lang.c++
From: pauljo@microsoft.com (Paul Johns)
Subject: Re: Flattening (Was: Complexity in the eyes...V2.0)
Date: 22 Dec 92 23:53:23 GMT
Organization: Microsoft Corp.
Distribution: usa

Compilers whose vendors provide a good class browser are a much
better solution--a good browser will show you all the information
you need without changing the semantics of the class.

// Paul Johns
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Make a deep copy!
Summary: Deep .vs. Shallow: the Shallow and the Deep of it ...
Organization: :
Distribution: usa
Date: Sun, 27 Dec 1992 02:40:00 GMT

In article <1992Dec23.210224.566@microsoft.com>, pauljo@microsoft.com (Paul Johns) writes:

> Specifically, you need a copy constructor which
> copies the data pointed to by the pointer in the
> object.  (You should copy both the actual data
> and the array of pointers--I think you missed
> copying the array of pointers in your assignment
> operator.)
 
> Also, read a good C++ text for other pointers.

It seems to me that the whole question of Deep .vs. Shallow copy is
misdirected.  A program is--or should be--a model of something.  A
model is an abstraction expressed in a representation.  That a copy
is deep or shallow describes a technique of representation.  It is
pointless to discuss it without reference to the thing represented.

Deep copy is necessary when you must copy not only one object (small `o'
object) but also objects related to it.  It may be that you must copy
all objects related to it; it may be that you must copy only some objects
related to it.  To know what must be copied, you must understand the
existential relationships in which the object participates, both their
meaning and their requisite cardinality.

And when you understand the issue on that level, Deep and Shallow become
just two possibilities of many--but the correct possibility reveals itself
so that you don't have to go asking the question.
-- 
 (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++,comp.sys.unisys
From: daw@vivanet.com (David A. Wolf)
Subject: Re: C++ on Unisys U6000?
Organization: VIVATRON Corporation 
Date: Wed, 23 Dec 1992 04:22:19 GMT

In article <BzB8B7.4B3@unccsun.uncc.edu> pfschell@unccsun.uncc.edu (Patrick F Schell) writes:
>I hate this sort of posting too, so I'll keep this short.
>
>If you know of a C++ implementation available on the U6000, please
>send mail at this address.  Unisys apparently doesn't provide one
>or even provide references; CenterLine doesn't support this platform,
>but info on other such environments is also welcome.
>
>Thanks.
>
>Really Jim Perry, but you can think of me as Pat Schell for now...

It may be drastic but the Unisys 6000 series is SCO Certified and
you could run SCO O/S and Development system which comes with C++.
Probably not the answer you're looking for...

- good luck.


David A. Wolf                               Toll: 716-272-0820
VIVATRON Corporation                        Free: 800-836-UNIX
Rochester, New York, USA                     Fax: 716-272-7627
SCO Advanced Product Center                email: daw@vivanet.com
*******************************************************************

Newsgroups: comp.lang.c++
From: nagle@netcom.com (John Nagle)
Subject: Re: Not supposed to use static variables in member fns?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 1 Jan 1993 04:23:07 GMT

ghawkins@unix1.tcd.ie (George C. Hawkins) writes:
>If a member function wants to remember a value between calls to it
>then it must store that value in a varaible (sic) visible to all member
>functions. Is this right? I was doing:
>class Foo {
>	void bar;
>}
>void Foo::bar()
>{
>	static int remember;
>}
>But was rather upset to find that all instances of Foo shared the
>same 'remember'. 
      That's what C++ is supposed to do.

      You've been taking this "object" stuff too seriously.  There isn't
a separate copy of each "method" for each object instance.  Even
though class function declarations appear intermixed with the field
declarations inside a class declaration, they aren't really fields.
Class instances are really just structures, with the fields declared in
the class declaration and those of its parents, plus a type field used
to properly dispatch calls to virtual functions.

>I find this quite surprising, does C++ save you from using
>global variables at one level by allowing you to pack things up
>into objects only to force you into using variables that are visible
>to all the members within an object.

      That's about right.  You can't hide things as much as some people
would like.  The way C++ uses include files for class declarations limits
the amount of hiding possible.   Note that private fields have to appear
in the include file used by users of the class, even though the users
can't access them.  This is an even worse visibility problem, and forces
unnecessary recompilations of class users when the implementation of a class 
changes.

					John Nagle

>Yours,


>George.

>--
>george lives at:
>___________________________________________________________________________
>|   ghawkins@unix1.tcd.ie (mostly)  |   ghawkins@vax1.tcd.ie (sometimes)  |
>---------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Not supposed to use static variables in member fns?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 1 Jan 1993 15:38:55 GMT

In article <ghawkins.725838896@unix1.tcd.ie> ghawkins@unix1.tcd.ie (George C. Hawkins) writes:
>
>If a member function wants to remember a value between calls to it
>then it must store that value in a varaible visible to all member
>functions. Is this right? I was doing:
>
>true. I find this quite surprising, does C++ save you from using
>global variables at one level by allowing you to pack things up
>into objects only to force you into using variables that are visible
>to all the members within an object.
>
	Yes, more or less: the problem of global data
is not solved, just reduced by division.

	You can solve your problem with several techniques,
one being to make the function a member of yet another class,
and put a pointer to it in the original object:

// Originally

	class X { int dontcare; int private_to_f; 
		f(){  ... private_to_f .. }
		g(){ .. private_to_f .. } // WOOPS
	};

// fixed

	class X { int dontcare; Y* y;
		g(){ cant access 'private_to_f'}
		f(){y->f();}
	};

	class Y {int private_to_f; 
		public: f(){ .. private_to_f .. } };

// Ugly, requires pointer :-(
// easier to 'trust' the other members

-- 
;----------------------------------------------------------------------
        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: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: IS C++ a language for the "average programmer"
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 28 Dec 1992 14:53:47 GMT

In article <1992Dec28.053645.17136@nuscc.nus.sg> tim@iss.nus.sg (Tim Poston) writes:
>Anybody who thinks they can prove that every complex polynomial
>has at least one root without using analysis
>(the study of the kind of proofs that apply to calculus),
>see me after class.
>

	But this is silly, since R is constructed by analysis.
Given R, and the fact that every positive real has a root in R, 
and every polyn of odd degree over R has a zero in R, 
the Fundamental Theorem of *Algebra* (all polyns over C can be reduced
to linear factors) follows by algebra.

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