HDTenEightyP/NetNews huggingface dataset:
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Multiple representation of an object type
Organization: University of Jyvaskyla, Finland
Date: Fri, 13 Nov 1992 08:31:12 GMT

In article <BxDGKn.4u2@news.orst.edu> gnk@belar.ECE.ORST.EDU (Giri Rangan) writes:
>I am in search of a correct and a very efficient way of implementing
>multiple representations of an object type. Here is an example :
>
>I have a polynomial class. A polynomial can be represented in two ways.
>One is to store the coefficients of each order term and the other way
>is to store the roots of the polynomial. Both the representations are
                 ^^^^^
evidently meaning 'factors'

> ...
>Another point to note is that the two representations are inter
>convertible. As a result, if I change a particular coefficient, then
>the present roots of the polynomial are no longer valid. They will have
>to change too.
> ...

An exactly analogous situation (complex numbers in both Cartesian
and polar representation) happens to be well presented
in Meyer's "Object-Oriented Software Construction", 7.7.4 (p. 136 - 139).
The code is in Eiffel, but you'll get the idea.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.lang.c++
Subject: What is the best way to learn C++?
From: David Garrett <DG1097A@auvm.american.edu>
Date: Mon, 9 Nov 1992 11:54:02 EST
Organization: The American University - University Computing Center

I am an Amer.Univ. Grad. Student (IS) interested in learning C++.  Our school
offers on classes in this language, so I am looking for a class I can take in
the Washington D.C. area.  Does anyone know of a good one?  Is it just easier
to get a book & teach yourself?  If so, what would be a good book to buy?
           ------Any responses would be greatly appreciated.
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: how to initilize an array inside of a class??
Date: 13 Nov 92 10:25:06
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: cooper@plains.NoDak.edu's message of 12 Nov 92 03:46:14 GMT

   int some_ints[3000] = { 1, 6, 34, 3, ... ,0 };

   But my compiler complains about that, saying that I can't initialize
   class members there.

I believe GNU C accepts something like that, but your code would
be unportable.

   The only other way I can think of doing it is
   to do something like:

   Y::Y()
   {
       some_ints[0] = 1;
       some_ints[1] = 6;
       ...
       some_ints[2999] = 0;
   }

   Is this my only other option??

Well, not quite. You could write:

static int some_ints_initial[] = { 1, 6, 34, 3, ..., 0};

Y::Y() {
	copy_ints(some_ints,some_ints_initial,
		  sizeof some_ints_initial/sizeof *some_ints_initial);
}

   Would there be a performance hit doing it that way, I kinda
   think so as the first one is done at compile time, while the other is
   done at run-time, correct??

Automatic variables always need to be initialized at runtime (that's a
property of the machine, not of C).  The version that I gave above
that uses "copy_ints" and "some_ints_initial" is pretty much what the
compiler would generate anyway, and presumably, back in the days when
C still cared about such things, K&R wanted you to be aware of this
cost. In the brave new world of C++ where O(n) copying operations (and
a lot of other stuff) happen behind your back anyway, this attitude is
probably an anachronism.

					Thomas.

Newsgroups: comp.lang.c++
From: eb@ascent.com (Ed Barton)
Subject: Re: Debugging output
In-reply-to: ort@netcom.com's message of 9 Nov 92 11:20:51 GMT
Date: 10 Nov 92 08:19:25
Organization: Ascent Technology, Inc., Cambridge Massachusetts


In article <1992Nov9.112051.21350@netcom.com> ort@netcom.com (David Oertel) writes:

   >> I was wondering whether anyone has any suggestions as to how to use the neat
   >> operator << to produce debugging output in a way that it can be removed
   >> easily from production code.  The obvious method is:

   >> #ifdef DEBUG
      >> cerr << .....
   >> #endif

   >> but I'd like to avoid the #ifdef -#endif lines.

	   I didn't see the truly obvious answer to this post.  That is to
	   put the #ifdef,#endif around the body of an inline function.

Someone please correct me if I'm wrong, but I thought the arguments to
an inline function still had to be evaluated, even if they aren't used
in the body.  So if you write

void debug(ostream& expr) { 
#ifdef DEBUG
  if (debug_flag) expr << endl;
#endif
}

debug(cout << "foo: " << foo);

wouldn't the compiler still have to arrange to do the output anyway as
part of argument evaluation, even when DEBUG is not defined?  I
thought it's not supposed to matter to the result whether a function
is inline or not.

Or maybe I misunderstood the suggestion?


Newsgroups: comp.lang.c++
From: syackey@ccscola.Columbia.NCR.COM (Steve Yackey)
Subject: Re: something nasty
Organization: NCR Corp, E&M-Columbia, Columbia, SC
Date: Wed, 11 Nov 92 14:35:27 GMT

In article <1992Nov9.171715.20728@sierra.com> dkarr@sierra.com (David Karr) writes:
>syackey@ccscola.Columbia.NCR.COM (Steve Yackey) writes:
>: In article <540@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>: >In article <1992Nov1.224626.771@BofA.com> dan@BofA.COM (Dan Brockman) writes:
>: >>
>: >>If you can explain this, please send me email and
>: >>tell me how to fix my code so it runs.
>: >>
>: >>---------------- the big nasty --------------------
>: >>
>: >>
>: >>"Dbasesw.c", line 1842: internal <<AT&T C++ Translator 
>: >>2.1.03 08/31/90>> error: bus error (or something nasty
>: >> like that)
>: >
>: >1) I have seen this (SCO ODT, HCR C++ compiler).  No rhyme or reason
>: >	that we've ever been able to determine.  Sometimes just simple
>: >	syntax errors.
>: >
>: >2) You did't give us the code w/ the problem (which may or may not
>: >	have helped...)
>: >
>: 
>: the magic fix (works here) is to take the entire function, i.e., stuff
>: between the {}, that has the error, line 1842 in this case, yank it out
>: and stick it at the top of the source file.
>: 
>: have no idea what this does, but it has always worked.
>: 
>
>(I have a suspicion we have a problem with our outbound news.  If you
>read news frequently, could you indicate that you saw this note in
>email?)
>
>As I mentioned before, we only get that on the HP compiler, and only
>if we compile with "-g".  I tried moving the function that got the
>error to the "top" of the source file (first function after #include
>section), but it didn't fix the error.  It did change the error
>message, though.
>
>This is the error I get before moving the function:
>
>CC: "/tmp_mnt/sambu/people/dkarr/work/new2dm/ui/CrossSection.cc", line 593: internal error: bus error (or something nasty like that) (3058)
>
>This is what I get after moving the function:
>
>CC: "/tmp_mnt/sambu/people/dkarr/work/new2dm/ui/CrossSection.cc", line 575: internal error: (function: DbgPush::~DbgPush()) Optdriver: Instruction outside a procedure. (6731)
>
>--
>David M. Karr
>Sierra Geophysics, Inc.
>ARPA: dkarr@sierra.com, UUNET: uunet!sgihbtn!dkarr
>Phone: (206) 822-5200 (x343)

I, also, just recently talked with a person at Computer Innovations, a
re-seller of Cfront (we buy a C++ debugger from them, but 'must' buy our
Cfront from an internal supplier - it has the same disease). Anyway, they 
apparently have found the cause of this and cured it in their version. Not
sure whether they have anything for you environment but they are
at 908-542-5920.
From: ort@netcom.com (David Oertel)
Newsgroups: comp.lang.c++
Subject: Re: Debugging output
Summary: RE: debugging output
Date: 9 Nov 92 11:20:51 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)



>> I was wondering whether anyone has any suggestions as to how to use the neat
>> operator << to produce debugging output in a way that it can be removed
>> easily from production code.  The obvious method is:

>> #ifdef DEBUG
   >> cerr << .....
>> #endif

>> but I'd like to avoid the #ifdef -#endif lines.

	I didn't see the truly obvious answer to this post.  That is to
	put the #ifdef,#endif around the body of an inline function.

	ort@netcom.com
-- 
Xref: sparky comp.lang.c++:16043 sci.math.num-analysis:3274
From: coactive@netcom.com (Coactive Aesthetics)
Newsgroups: comp.lang.c++
Subject: Re: Looking for the person  who has compiled ET++3.0....
Date: 12 Nov 92 10:30:53 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
X-Newsreader: Tin 1.1 PL5

Neil Davis (N.Davis@lut.ac.uk) wrote:
: Hi,
: 
: I feel sure that I recently deleted an email from someone
: who may have successfully compiled ET++3.0 with the latest
: GNU C compiler (2.3.1).

I would be very suprised if anyone did this. gcc 2.3.1 has a bug in which it
does not generate code for inline friend functions. Since the MetaDef() 
macro defines three of these functions, and MetaDef is used by almost every
class definition, you'll see hundreds of unresolved symbols.

I am hoping that a patch for this will be posted, or that gcc 2.3.2 comes
out real soon. Otherwise I guess I'll have to go back to 2.2.2.

Otto

--
Otto Lind                  Coactive Aesthetics
otto@coactive.com          P.O. Box 425967, San Francisco, CA 94142
netcom!coactive!otto       voice:(415)626-5152    fax:(415)626-6320
Newsgroups: comp.lang.c++
From: pj@sam.wpd.sgi.com (Paul Jackson)
Subject: Re: templates within templates
Reply-To: pj@sgi.com
Organization: Silicon Graphics, Research & Development
Distribution: comp
Date: Wed, 11 Nov 1992 23:33:55 GMT

In article <ROSENBER.92Nov11235158@aton.abo.fi>, rosenber@aton.abo.fi (Robin Rosenberg INF) writes:
|> I tried using templates like this:
|> 
|>     Ref<Node<T>> obj;
|> 
|> I tried Borland C++ (3.0) and g++ (2.1) and neither accepts the syntax.

Try changing it to:

    Ref<Node<T> > obj;

with a blank between the two consecutive '>' signs,
so that the parser doesn't get confused with the
'>>' right shift operator.

It works for me this way, using a cfront based compiler.

-- 

				I won't rest till it's the best ...
				Software Production Engineer
				Paul Jackson (pj@sgi.com), x1373
Newsgroups: comp.lang.c++
From: tstead@cs.umr.edu (Tim Steadham)
Subject: Source needed
Date: Mon, 9 Nov 1992 18:15:07 GMT
Organization: University of Missouri - Rolla
Originator: tstead@mcs213f.cs.umr.edu

I do not know if this is the right newsroup  to post this article in or not,
but here goes.  I am looking for the following types of codes:
Equation solver, preferably one with LU decomp with max. columnar pivoting
 (but any other will do... :)
Cubic Spline program

I have look in the book, "Numerical Recipes for C", but found that whoever
wrote those codes, was NOT a C programmer.  Anyway, I have Borland C++ ver 3.0
running on a 386/33.  Also, any other numerical solution code.  If you have
got any of the codes out of "Numerical recipes" to work, please tell me how
you did it.  I am very confused.  Thanks in advance :)

Newsgroups: comp.lang.c++
From: robert@slipknot.rain.com (Robert Reed)
Subject: Re: Criticisms Wanted
Reply-To: robert@slipknot.rain.com.UUCP (Robert Reed)
Organization: Home Animation Ltd.
Date: Mon, 9 Nov 1992 20:24:24 GMT

In article <1992Nov8.170309.12301@cc.gatech.edu> brianm@cc.gatech.edu (Brian N. Miller) writes:
|In article <BxDDJy.9GC@slipknot.rain.com> robert@slipknot.rain.com.UUCP (Robert Reed) writes:
|>One criticism I've heard is that the time saved in debugging due to the strong
|>typing is consumed in optimizing.
|
|Strong typing complicates optimization?  I don't think so.  If anything, it
|simplifies it.

Please understand, these are not my criticisms, but complaints I've heard from
others.  And the point was NOT that strong typing complicates optimization, but
that strong typing reduces debug time (by acting as an integrated lint), but
that some of the other language features (like reference initialization versus
copying, operator functions, etc.) provide many ways to hide the way things are
done in the code, and that complicates the process of developing an optimal
program because of the increased complexity and (at least for the novice)
hidden implementation costs.

|>Also, I've seen complaints that tenet of information hiding and code reuse
|>is a myth with C++ because in order to understand a class you intend to
|>reuse, you must study the source code anyway.
|
|That has little to do with C++.  I can't think of any language that
|unambiguously illustrates ADT behaviour in the export interface.

Well, yes, and I suggested a similar example in another language.  But the
point is that C++ has been reputed to be a language that finally makes the
concept of "software components" realizable.  The argument goes that if you
still have to examine the internal workings of component classes to determine
how to best use them, then their value as components has been greatly
diminished.
________________________________________________________________________________
Robert Reed			Home Animation Ltd.		503-656-8414
robert@slipknot.rain.com	5686 First Court, West Linn, OR 97068

I finally went to the eye doctor.  I got contacts but I only need them for
reading.  I got flipups.
--Steve Wright
________________________________________________________________________________
From: yli@acsu.buffalo.edu (Yanhong Li)
Newsgroups: comp.lang.c++
Subject: Bus error
Date: 11 Nov 92 01:04:31 GMT
Organization: State University of New York at Buffalo/Comp Sci

#include <iostream.h>

class T {
 public:
 int i;
 void foo() {cout <<"foooo\n";}
};

void main(){
T *tt[3][5];

tt[2][3]->i=1;
}



-- 
===============================================================================
Yanhong Li                          716-838-6493(h)    645-3198(o)
Dept. of Computer Science                       Good good study                
SUNY at Buffalo, Buffalo, NY14260               Up up every day
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: operator [][]
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 11 Nov 1992 18:20:16 GMT

In article <1992Nov9.114516.29846@alf.uib.no> s026@brems.ii.uib.no (Paal K Holmberg) writes:
>In article <1992Nov9.095352.19114@fmrco.uucp>, pandrews@lovat.fmrco.com (Paul Andrews) writes:
>|> 
>since it os a trouble to get around mutiple []'s , you can always cheat and use a 
>normal function element(int x,int y...) to get a certain element in the matrix or whatever.
>I agree it is not as elgant as the [] approach, but it is easy.
>

	It would be nice if [] could work like (), that is one could
declar

	operator[](int,int,int){ ...}

for example, that is, allow multiple arguments for [] just like ().
This would allow multiple dimensioned matrices as well as providing
a wealth of extra overloadable notations.

It would of course break those programs for which

	a[2,3];

actually meant a[3] using the comma operator, but there surely are not
so many of them ..??

-- 
;----------------------------------------------------------------------
        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++,bnr.lang.c++
From: dechc00@tohi.DMI.USherb.Ca (CHRISTIAN DECHAMPLAIN)
Subject: Re: Criticisms wanted
Organization: Universite de Sherbrooke -- departement de Mathematiques et
	d'Informatique
Date: Fri, 6 Nov 1992 12:26:31 GMT


I think that people that don't want to code in C++ are just afraid.  This is
my opinion.  Just find a good compiler along with good programmers that don't
fear learning a language that just helps them produce better code and you'll
make a better product than with C.  The difficult part is to forget procedural
desing and learn to design object-orientedly.

For the things you have to consider, I don't think the language would make
a difference.  It's the system and the librairies that you use that will
make a difference.  Since you can use C librairies with C++ and that a
system offering C often offers C++ also, the considerations are not the
language.

Your choice depends on your compiler and your programmers.

Consider also that you can mix C and C++.

--
Christian Dechamplain|
(819) 563-8951       |
dechc00@dmi.usherb.ca|
----------------------
Newsgroups: comp.lang.c++
From: eb@ascent.com (Ed Barton)
Subject: Re: pointer to member in MSC 7.0
In-reply-to: tac@rena.world's message of 5 Nov 92 18:38:53 GMT
Date: 9 Nov 92 08:56:34
Organization: Ascent Technology, Inc., Cambridge Massachusetts


[I tried to respond to this via E-mail, but it bounced.]

In article <TAC.92Nov5183853@rena.world> tac@rena.world (Telmo A. Carmo) writes:

   How does one implement a pointer to a member function
   in MSC 7.0 
   I am not able to use pointers to derived class member functions

   here is a small example:
   ----------------------
   class Object;
   //#define mt long (Object::*)()
   class Object {
   public:
	   int get() { return 2234;}
	   long perform(long (Object::*)(),long);
	   //long perform(mt,long);
   };
   //#undef mt

   typedef long (Object::*method)();
   typedef long (Object::*method1)(long);

   class AA : public Object {
   public:
	   long test(long v);
	   void Do(method,long);
   };
   long Object::perform(method m,long v)
   {
	   method1 q = (method1)m;
	   return (this->*q)(v);
   }
   void AA::Do(method m,long v)
   {
	   perform(m,v);
   }
   long AA::test(long v)
   {
	   printf("ld=%ld\n",v); return 0l;
   }
   main()
   {
	   AA ole;

	   method m = (method)&AA::test;
	   /*  ^-- ERROR */
	   ole.Do(m,(long)23);
	   return 0;
   }
   /*
   yy.cpp
   yy.cpp(47) : error C2642: cast to pointer to member must be 
				   from related pointer to member
   */


You are actually attempting to lie to the compiler.  A pointer of type
long (Object::*)() can point to exactly one type of thing: namely, a
member function of Object.  But AA::test is NOT a member function of
Object.  It is a member function of AA.

Look at it this way: If you store something in an (Object::*)()
pointer, then you can invoke the pointer on anything of type Object,
including those that are not also of type AA; but to invoke the
pointer on non-AA objects would lead to disaster.  Consequently, it is
unsafe and violates the language definition to store AA:test into an
(Object::*)() pointer, even in those cases where the compiler may
allow you to do so.  It is not hard to make examples (involving
virtual functions and such) in which your program will crash if you do
this, EVEN IF the argument is actually of type AA.




Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: c++ & c+++
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 12 Nov 1992 11:38:12 GMT

In article <BxGqHw.4IK@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:

>|> The ARM is for language laywers and implementors and focusses on language
>|> details and implementation techniques. Trying to learn C++ from the ARM is
>|> a mistake; it would be like trying to learn English from a dictionary.
>
>Agreed.  What you would miss by not having ARM is the "annotations"
>(which are of technical interest, some historical interest, and at
>times amusing).  No "normal person" trying to learn C++ now needs
>ARM.

	I dont agree. No one in their right mind should attempt to
write C++ without the bible. It is THE reference. I learned C++
by reading the ARM (and a couple of other books as well).
I admit I read it more that once though ... :-)

	Personally, I recommend Meyers Object Oriented Software Construction,
even though it describes Eiffel and not C++, IMHO it is one of the best
books I have read for some time.

-- 
;----------------------------------------------------------------------
        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++
X-Mail-Path: hactar.hanse.de!mcshh.Hanse.DE!Germany.EU.net!cat.uucp!startsn1
From: startsn1@cat.de (Wolfgang Schrecker)
Subject: exchanging object between computers
Date: Fri, 06 Nov 1992 01:02:25 +0200
Newsgroups: comp.lang.c++
X-Gateway: hactar.hanse.de to comp.lang.c++; Fri, 6 Nov 1992 03:59:18 +0100

Well, the idea is to exchange objects between computers of different kind
using XDR for instance. The problem is when packing the elements of an object
via XDR how would I know the different types that make up my object in order
to pack them. I do not want the packing methods in the original classes,
because it should not make a difference for an object if at any time I might
want to send it somewhere.
Any Ideas ??
post to this newsgroup or email to above address or to 'schreckr@cat.de'
Thanks
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Wanted: Example of Contravariance
Organization: Rational
Date: Sat, 7 Nov 1992 01:15:36 GMT

srheintze@happy.colorado.edu writes:

>Can someone please give me a small example of contravariance I can compile and 
>run with Borland C++ v3.1 or Microsoft C++ v7?

>I've seen articles in the Journal of Object Oritned Programming and in the C++
>report but the never show me a small sample of code I can compile.
>I just saw a new term: covariance.  Is it possible to demonstrate this 
>with a short C++program?

>			Thanks,
>					Sieg

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

class B
{
  public:
    virtual B& void f(B&);
};

class D : public B
{
  public:
    virtual D& boid f(B&);
};

Notice that the arguments of the two 'f' functions are the same.  This
is "contravariance", since the argument does not (contra) vary with
the class type.  

However, the return values are "covariant" since they do (co) vary
with the class type.

Although covariant return types have been accepted into the language
definition, I don't think they are accepted by many of the compiler
out ther right now.  Contravariant arguments are mandatory in C++.


--
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++
From: potts@oit.itd.umich.edu (Paul Potts)
Newsgroups: comp.lang.c++
Subject: Re: Criticisms Wanted
Date: 13 Nov 1992 23:05:48 GMT
Organization: Instructional Technology Laboratory, University of Michigan
NNTP-Posting-Host: helen.oit.itd.umich.edu

In article <1992Nov13.060823.1358@BofA.com> dan@BofA.com (Dan Brockman) writes:
>In article <1992Nov11.175117.15325@bcrka451.bnr.ca> sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
>>
>Reading source code is hardly a crime.  He could be trying to fix the damned
>bug his benighted colleague wrote into the program.  He could be trying to 
>find the damned bug.  

If I could get by without doing it, I would certainly prefer it. The
programmers that wrote some of the classes I'm using might have been
making a lot of money, but they sure don't know how to write readable
code. The biggest reasons seem to be:

- this code wasn't really tested - if you actually inherit a class
and use it, it bombs... (i.e., the beta application classes for Turbo
Vision Development Toolkit).

or

- this class is so poorly documented that the programmer who wrote it knows
how to use it and what can be done with it, but no one else can
(i.e., TurboVision itself).



-- 
Politics is crime pursued by other means.              
potts@oit.itd.umich.edu      CI$ 71561,3362 (rarely)