HDTenEightyP/NetNews huggingface dataset:
From: pete@borland.com (Pete Becker)
Subject: Re: Death of Borland C++ Compiler
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Fri, 18 Dec 1992 17:19:04 GMT

In article <chaolin.88@fcit-m1.fcit.monash.edu.au> chaolin@fcit-m1.fcit.monash.edu.au (CHAOLIN CHANG) writes:
>
>I was a loyal Borland C++ compiler user.  I love the IDE environment 
>(though I only use it for creating the project file) and various tools 
>bundled.  But as my programs are becoming complex (using pointer, pointer 
>to pointer, pointer to pointer to pointer and farmalloc extensively), 
>Borland compiler begins to fall over.  One of my colleagues is also 
>suffering for the same experience when he tried to push the Borland compiler 
>to its limits.
>
>I had pulled all my hair out.  If the program is run within the debuger line 
>by line, it works fine.  But as soon as I let go, it hung my PC.  
>
>I recompile the same source code in Zortech.  It WORKS. 
>
>I wonder if anyone else has the same experiences with me?
>

	It is not at all uncommon for buggy programs to appear to work when
compiled with one compiler and to fail with another compiler.  It often means
that the two compilers lay the data out differently, so writing through a
bad pointer happens to be harmless with one compiler and fatal with another.
	I have rarely seen problems of the type described here that can
actually be blamed on the compiler.  Which isn't to say that it can't be a
compiler bug, but that it requires much more investigation.
	-- Pete


Newsgroups: comp.lang.c++
From: pete@borland.com (Pete Becker)
Subject: Re: Matrix Addition  Was Re: Complex Addition.
Originator: pete@genghis.borland.com
Keywords: operator, memory leak
Organization: Borland International
Date: Thu, 17 Dec 1992 18:43:48 GMT

In article <36223@sophia.inria.fr> gchow@hawai.inria.fr (Gloria Chow) writes:
>
>How about if the structure is a bit more complex, especially one with
>dynamically allocated memory.  I tried the following (I appologize if it's
>syntactically incorrect, I no longer have the version which I actually tried.
>This one is just from memory):
>
>class MATRIX
>{
>protected:
>    double      **entry;
>    int         nrows, ncols;
>public:
>    MATRIX( int num_rows, int num_cols );
>    MATRIX& operator=( const MATRIX& equivalent );
>    MATRIX& operator+( const MATRIX& addend );
>};
>

	Add a copy constructor.  If you don't supply one, the compiler will
provide one for you, and it often won't do what you want it to do.  In
general, there are three member functions that should probably all be present
if any one of them is: assignment operator, copy constructor, and destructor.
	-- Pete


Newsgroups: comp.lang.c++
From: twriter@rd.hydro.on.ca (Timothy Writer)
Subject: Re: Survey: File Extension
Reply-To: twriter@rd.hydro.on.ca
Organization: "Ontario Hydro - Research Division"
Date: Mon, 14 Dec 92 21:10:10 GMT

warsaw@nlm.nih.gov (Barry A. Warsaw) writes:


>Should the .h file extension matter?  Do compilers supporting
>pre-compiled headers need to know the extension for header files?
>Just wondering 'cause we use .cc and .hh

Is there a good reason for having separate extensions for C and C++
header files?  Why not share header files between C and C++ like so:

	#ifdef __cplusplus
		// C++ interface
	extern "C" {
	#else
		// C interface
	#endif
	#ifdef __cplusplus
	}
	#endif

One situation where I have found it useful to have separate extensions
is for editors which choose a mode based on the extension.  However, I
get around this with GNU emacs using file local variables e.g.

	// Local Variables:
	// mode: c++
	// End:

Tim

-- 
Tim Writer			     phone:  (416) 231-4111 ext. 6990
Ontario Hydro Research Division	     fax:    (416) 237-9285
Toronto, Ontario		     e-mail: twriter@rd.hydro.on.ca
CANADA
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: register variables in inline functions
Organization: TauMetric Corporation
Date: Wed, 16 Dec 1992 18:36:27 GMT

hendrik@vedge.com (Hendrik Boom) writes:

>dwr@cci632.cci.com (Donald W. Rouse II) writes:
>: In article <1992Dec10.003109.25441@bilver.uucp> dandrews@bilver.uucp (Dave Andrews) writes:
>: >>
>: >My understanding is that both "register" and "inline" may be ignored
>: >by your compiler.  They are only hints.
>: 
>: MY understanding is that "inline" may be replaced with "static",
>: but it may not be ignored.

>In 
>class foo{
>	int i;
>	inline int bar(){ return i;}
>	};
>inline cannot be replaced with static.

Can we please cut through the crap here?

Inline non-member functions have all the semantics of non-member static
functions.  Inline member functions don't have the semantics of static
member functions.  No one is talking about macro-replacement of 'inline'
with 'static'.

It is unfortunate (you might choose a stronger word) that both the
keyword and the explanatory term "static" are overloaded with several
unrelated meanings in C and C++.  It results in confusion in
discussions like these.

Think of non-member "inline" functions as being declared "static".

For member and non-member functions, "inline" is a request to the
compiler that they be implemented more efficiently.  You may or may
not have your request fulfilled.  In particular, they might be
expanded inline, but result in less efficient code when used
indescriminately.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Public access to private data member
Organization: University of Illinois at Urbana-Champaign
Date: Fri, 11 Dec 1992 18:17:24 GMT

In <28575.9212111556@louis.ecs.soton.ac.uk> Stuart Maclean <S.D.Maclean@ecs.soton.ac.uk> writes:

>Hi all, I'm new to C++ and am wading through Lippman's Primer. I am
>puzzled by a certain example. The basis of my query is easily seen
>with some code. Apologies if this is a FAQ.

>// a Screen Class declaration.

>class Screen
>{
>  short height;
>  short width;
>  char *cursor;
>  char *screen;

>public 
>  ......
>  void copy ( Screen& );
>}

>now, the copy function is implemented thus:

>void Screen::copy( Screen& s )
>{
>  delete screen;
>  height = s.height;
>  width = s.width;

>  blah blah blah
>}

>My question is;
>  Why are the data members s.height and s.width accessible to copy,
>  even though both height and width are declared private. Is
>  it just because s happens to be of the same class as the target
>  object ??

*****>	Yes.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: srheintze@happy.colorado.edu
Subject: Re: Death of Borland C++ Compiler
Organization: University of Colorado, Boulder
Date: 18 Dec 92 10:22:19 MDT

In article <chaolin.88@fcit-m1.fcit.monash.edu.au>,
chaolin@fcit-m1.fcit.monash.edu.au (CHAOLIN CHANG) writes: >  >  
> I wonder if anyone else has the same experiences with me? 
>

I had the opposite experience:  my programs would not work in Zortech v2.1 so I
switched to Borland v2.0 and I have not used Zortech since.  I was rather
discouraged to hear that other people were still observing that Zortech was
poor on QA and user support.

Your experience is encouraging however, maybe I'll take semantec up on that $120
offer for their C++ compiler after all.

I think there is a lot of merit to owning several compilers  -- not than any
are superior to others (although this will certainly be true) -- but because
they are all different.

			Sieg 
Newsgroups: comp.lang.c++
From: twriter@rd.hydro.on.ca (Timothy Writer)
Subject: Re: Survey: File Extension
Reply-To: twriter@rd.hydro.on.ca
Organization: "Ontario Hydro - Research Division"
Date: Mon, 14 Dec 92 20:57:33 GMT

warsaw@nlm.nih.gov (Barry A. Warsaw) writes:


>More important is consistancy within your project and compilers/tools
>ought to be configurable to use just about any extension: .cc .cxx
>.cpp .C whatever...

Good point.  I'm writing some code which must be portatble between
MS-DOS with MSC C/C++ 7.0 and IRIX (Silicon Graphics) with GNU
g++-2.2.2.  The only common extension is .cxx.  Why is standardizing on
a file extension important?  Aren't there more serious standardization
issues?  Its trivial for compiler vendors to support all the popular
extensions so why not do that and forget it?

Just my $0.02.
Tim

-- 
Tim Writer			     phone:  (416) 231-4111 ext. 6990
Ontario Hydro Research Division	     fax:    (416) 237-9285
Toronto, Ontario		     e-mail: twriter@rd.hydro.on.ca
CANADA
Newsgroups: comp.lang.c++
From: euamts@eua.ericsson.se (Mats Henricson)
Subject: Re: Special-purpose-heap-managers - references
Reply-To: euamts@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Fri, 18 Dec 1992 12:09:48 GMT

In article 11510@daimi.aau.dk, sabroe@daimi.aau.dk (Morten Sabroe Mortensen) writes:
#Could anyone, -who have tried-, tell, what kind of experiences they have with 
#special-purpose-heap-managers like 'Pool', in what kind of program, with what 
#kind of result/speed-up? 

We did a test of several class libraries, of which one was using a Pool class.
In one test (putting and removing integers from a Set class) the Pool-based
solution was ~20 times faster. That was the extreme case. In another test the
gain was "only" 2.3 times.

BUT REMEMBER: all this performance difference is NOT because of a Pool class.
The libraries differed in many other respects, which affected performance.

And then again: size and performance isn't everything...

Mats Henricson
Ellemtel
Stockholm
Sweden

Newsgroups: comp.lang.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: What is this CFRONT 3.0 warning message trying to tell me?
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Thu, 17 Dec 1992 20:59:11 GMT

In <1992Dec15.183649.20994@delfin.com> mr@delfin.com (Mark Rosenberg) writes:

>I'm porting a large application from a CFRONT 2.1-based compiler (Sun) to
>a CFRONT 3.0-based compiler (Solbourne). The following warning message
>has me somewhat mystified:

>"main.cc", line 31: warning: temporary used for non-const Thing& argument; no changes will be propagated to actual argument (anachronism)

>I've boiled the offending code down to:

>#include <string.h>
>#include <malloc.h>
>#include <stdio.h>
>class Thing
>{
>   public:

>   char *str;
>   Thing(){ str = (char *)0; };
>   Thing(char *s){str=strdup(s);};
>   Thing &operator = ( Thing & rhs  );
>};

*****>	Because this   ^^^^^^^^^^^^^ isn't const.

			Thing const &rhs

>Thing &
>Thing::operator = ( Thing & rhs )
>{
>   if( this->str )free( this->str );
>   strcpy( this->str, rhs.str );
>   return *this;
>}

>Thing getThing()
>{
>   Thing t("a thing");
>   return t;
>}

>main()
>{
>   Thing t1("");
>   t1 = getThing();             // warning
>   printf("value: %s\n", t1.str );

>   Thing t2 = getThing();       // no warning
>   printf("value: %s\n", t2.str );
>}

>When this program is run you get the expectable result:

>value: a thing
>value: a thing

>I realize that getThing should really return a reference and that using

*****>	No it shouldn't; your program will die a horrible death if it does.
	Thou shalt not return a reference to a local variable.

>stdio is really bad style but I don't understand why the first call to
>getThing generates a warning but the second doesn't.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Xref: sparky comp.lang.c++:17842 comp.lang.c:18234 comp.programming:3311
From: gibian@talent.ljo.dec.com (Marc S. Gibian)
Newsgroups: comp.lang.c++,comp.lang.c,comp.programming
Subject: Re: How to make 3/0=INFINITY?
Keywords: INFINITY, ADT
Date: 11 Dec 92 22:41:44 GMT
Reply-To: gibian@ljohub.enet.dec.com
Followup-To: comp.lang.c++
Organization: Digital Equipment Corporation


Many moons ago, when I was a math wiz, I did indeed spend a section of
a mathematics class on theory of infinity.  At the time it was fun, looking
back it reminds me a lot of the current work in area of chaos theory.

But, this is comp.programming, so why not answer the initial question:

"How can I program so that 3 divided by 0 results in infinity?"

The hardware types have pointed to the IEEE standard for floating point
computations.  Thats nice, but once again this is comp.programming, so
here's a software solution:

Use a language supporting operator overloading and data hidding, c++ and
ADA come to mind first, and define your own data type ... how about
infinite.  The data structure would contain:

   real_value - a floating point number when values are not infinite

   infinite_value - an enumeration of values... based on my math
                    experience, it would be:
                     (negative-infinity, real, positive-infinity)

The function definitions are left as an exercise (as I have to beat the
blizzard home ;-)
--
Marc S. Gibian			email: gibian@talent.ljo.dec.com
Principal Software Engineer	phone: (508) 486-6598
Digital Equipment Corporation	fax:   (508) 486-6648  or (508) 486-6100
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Survey: File Extension
Date: 17 Dec 92 20:57:32 GMT
Organization: Microsoft Corporation

Perhaps its time to switch to a more productive discussion, such as
the relative merits of various styles of braces and indentation ? ;-)
From: gisli@hamilton.eecs.umich.edu (Gisli Ottarsson)
Newsgroups: comp.lang.c++
Subject: Complex data types in C++   Novice question.
Date: 15 Dec 92 17:58:57 GMT
Reply-To: gisli@liapunov.eecs.umich.edu
Followup-To: gisli@engin.umich.edu
Distribution: usa
Organization: University of Michigan EECS Dept., Ann Arbor, MI




Hi!

I use C for scientific computations and am thoroughly frustrated
by the lack of a complex data type.  So far I have been using a
structure with a real and imaginary part wihch is fine until I
need to do computations where even simple addition requires a 
subroutine call.

Here is my question.  Does C++ in some way allow the redefinition of 
+ - * /, and so on, to account for complex numbers.

Please understand that I have never even seen C++ code and that this
is merely wishful thinking.  

Please respond by mail since I do not follow this newsgroup.  

--


..............................................................................
							Gisli Ottarsson
   Delenda est Carthago.         			University of Michigan
							gisli@engin.umich.edu
From: je@unix.brighton.ac.uk (John English)
Newsgroups: comp.lang.c++
Subject: Re: Need help implementic data structures of generic objects
Date: 17 Dec 92 10:43:57 GMT
Organization: University of Brighton, UK

cshaver@informix.com (Craig Shaver) writes:
: It is obvious to me that you have a virtual function in the base class for 
: all functions that you need to use when dealing with 'Objects'.
: 
: If you use a function on a class that is only restricted to a certain
: sub-tree of your inheritance structure, then you know what you are using,
: ergo, you should have used that type instead of 'Object'.

Yes, but then you end up migrating a lot of the functionality of your
hierarchy into class Object, in much the same way as widely-used data
structures end up being global in C.

: IMHO, if you do not use inheritance, you are not doing OOP.  If you do
: not care, then you are just using C++ as a variation on C with no real
: benefit.

Not use inheritance? who said dat? Just don't follow the Smalltalk model,
use multiple inheritance instead of an omnipresent Object class.

: If I offended anyone that is just tough.

Don't give it another thought :-)
-- 
-------------------------------------------------------------------------------
John English			| Fudd's first law of opposition:
Dept. of Computing		|    If you push something hard enough, it
University of Brighton		|    *will* fall over.
E-mail: je@unix.brighton.ac.uk	| Testlicle's deviant to Fudd's law:
Fax:    0273 642405		|    What goes in, must come out.
-------------------------------------------------------------------------------
From: gchow@hawai.inria.fr (Gloria Chow)
Newsgroups: comp.lang.c++
Subject: Matrix Addition  Was Re: Complex Addition.
Keywords: operator, memory leak
Date: 13 Dec 92 16:33:47 GMT
Organization: INRIA, Sophia-Antipolis (Fr)

In article <1992Dec11.232954.7071@borland.com>, pete@borland.com (Pete Becker) writes:
|> In article <1992Dec11.170849.18525@rs6000.bham.ac.uk> pickerig@eee.bham.ac.uk (Guy Pickering) writes:
|> >In ARM, the code for the `+` operator for the complex class is given as:
|> >
|> >inline complex operator+(complex a, complex b)
|> >{
|> >  return complex(a.re+b.re,a.im+b.im)
|> >}
|> >
|> >In general, can I create an instance of a class in a member function and
|> >return the object? Doesn't the complex object go out of scope?
|> >
|> 
|> 	Yes, it does.  But that's not the end of the inquiry.
|> 
|> 	int add( int a, int b )
|> 	{
|> 	return a+b;
|> 	}
|> 
|> 	Here, too, the temporary goes out of scope, but the compiler knows how
|> to deal with that.  Same thing for an object of a user-defined type.
|> 

How about if the structure is a bit more complex, especially one with
dynamically allocated memory.  I tried the following (I appologize if it's
syntactically incorrect, I no longer have the version which I actually tried.
This one is just from memory):

class MATRIX
{
protected:
    double      **entry;
    int         nrows, ncols;
public:
    MATRIX( int num_rows, int num_cols );
    MATRIX& operator=( const MATRIX& equivalent );
    MATRIX& operator+( const MATRIX& addend );
};

MATRIX::MATRIX(int num_rows, int num_cols )
{
register int    i;

    nrows = num_rows;
    ncols = num_cols;

    entry = new double *[ nrows ];
    for( i=0 ; i<nrows; i++ )
        entry[i] = new double[ ncols ];
}

MATRIX& MATRIX::operator=( const MATRIX& equivalent )
{
register int    i;

    for( i=0; i<nrows; i++)
        memcpy( (void*)entry[i], 
                (void*)equivalent.entry[i],
                sizeof( double ) * ncols);

    return *this;
}

MATRIX& MATRIX::operator+( const MATRIX& addend )
{
register int    i,j;
MATRIX          sum(nrows, ncols);

    for( i=0 ; i<nrows ; i++ )
        for ( j=0 ; j<ncols ; j++ )
            sum.entry[i][j] = entry[i][j] + addend.entry[i][j];

    return sum;
}


Okay, the problem is when I tried to use the "+" operator as follows:

    matrix_c = matrix_a + matrix_b;

the "+" operation works and sum contains the proper matrix, that is until
"+" finishes and goes out of scope.  The "return" statement makes a temporary
copy of sum (ie. the values of its nrows, ncols, and the pointer entry), and
then proceed to destroy sum automatically.  So, now the entry pointer of this
temporary is no longer pointing to a valid block of memory!!   

Is this really what happened?  I am new to C++, I am not sure my interpretation
is correct.  But all I can tell is that this simple addition and assignment 
sequence DOESN'T work, and I don't know how to get around it.  HELP!!

gloria
Newsgroups: comp.lang.c++
From: timp@extro.ucc.su.OZ.AU (Tim Posney)
Subject: Re: Need help implementic data structures of generic objects
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Wed, 16 Dec 1992 05:36:07 GMT

cshaver@informix.com (Craig Shaver) writes:

[Stuff deleted]

>It is obvious to me that you have a virtual function in the base class for 
>all functions that you need to use when dealing with 'Objects'.

This is a really poor,
At the time you declare Object you need to come up with all the
functions that an Object will support else you cannot write generic
code, and worst will have to rebuild anything that refereces Object.
Or you will have to downcast Object * things to derived classes.
It is bad form to 'downcast objects',
	i.e. ptr = (Derived_From_Oject *) Object_ptr.
	since you then lose type checking at compile time.


The obvious solution is to use Templates, it is precisely for this type
of problem that they were developed. They are compile check safe
and do not require extra code.

>If you use a function on a class that is only restricted to a certain
>sub-tree of your inheritance structure, then you know what you are using,
					  ********************************
Surely in the OOP world we can write code that will work correctly even
if the user does not know what he is doing. This is the whole point.
	>ergo, you should have used that type instead of 'Object'.
Surely one can write generic container classes that will work on
Objects today, and Mooses tomorrow, without re-coding (even of headers)
and without re-compiling.

>Please; in all of the above, correct me if I have been technically
>wrong, and then explain your philisophical counter point to the
>use of inheritance.

I agree that inheritance is great but do not use the languague features
incorrectly. Smalltalk and C++ are DIFFERENT, they approach the same
problems differently. What is a good solution in Smalltalk (Object etc)
is a bad solution in C++. It is possible to write completely generic
container classes using templates, and that is the 'correct' solution
for C++


tim posney


Newsgroups: comp.lang.c++
From: pauljo@microsoft.com (Paul Johns)
Subject: Re: register variables in inline functions
Date: 16 Dec 92 21:32:25 GMT
Organization: Microsoft

In article <1992Dec15.192533.26033@vedge.com> hendrik@vedge.com wrote:
> dwr@cci632.cci.com (Donald W. Rouse II) writes:

...

> : >My understanding is that both "register" and "inline" may be ignored
> : >by your compiler.  They are only hints.
> : >

...

> : 
> : MY understanding is that "inline" may be replaced with "static",
> : but it may not be ignored.
> 
> In 
> class foo{
> 	int i;
> 	inline int bar(){ return i;}
> 	};
> inline cannot be replaced with static.
> -- 

...

"Inline" and "static" are different concepts (and that's why
they're different keywords).  So I wouldn't expect one to
"replace" another, even with reduced functionality.

But they are similar in that when used at file scope (outside 
of a function), they both imply internal linkage (the 
identifier declared at file scope with inline or static is 
visible throughout the source file but NOT outside of the source 
file).

This is where the "confusion" is coming from.

// Paul Johns
Newsgroups: comp.lang.c++
From: mg@atomic (Michael Golan)
Subject: Re: Just what is so great about streams?
Organization: Princeton University, Dept. of Computer Science
Date: 15 Dec 92 02:10:43 GMT

jamshid@ut-emx.uucp (Jamshid Afshar) writes:

>In article <mg.723017110@elan> mg@elan (Michael Golan) writes:
>>murison@cfa.harvard.edu (Marc A. Murison) writes:
>>>I found that I liked the
>>>iostream i/o mainly because it relieved me of the tedium of (1) having
>>>to remember format codes, 
>>
>>I'd go for memorizing %8.3f anyday, rathar than ios:: ... (what is it, I
>>still don't remember - fixed(3) precision(8) ?) ...

>And what does %g mean as opposed to %f and %e? 
Well, 'e' for funny output with 'e' numbers... 'f' for 'f'ixed, 'g' for 
'g'eneral format, right? :-)

I think people say printf() formats are harder because the documentation is so
terse. Just provide as many pages on printf as you do on manipulators, and
include the most commnon examples, and you are fine.
Most of the people who complain really need just:
    %Id %Io %Ix   %N.Mf  %N.Mg %N.Me  and %X.Ys %-X.Ys
I is number of digits
N.M is total-space.digits after the demical point
- for strings left adjust
X is minimum chars to print, spaces are padded as needed
Y is maximum chars to print, as if outs[Y] was '\0' when you output 'outs'

Try to write the docs for the equivalent iostream!!
I tried to get %8.3f, the most common format (IMO), under iostream. I
couldnt find it in two C++ manuals (and I read the docs wrong, too,
thinking precision was number of digits after the dec pt.)


 Michael Golan
 mg@princeton.edu





Newsgroups: comp.lang.c++
From: mf024@randr.com ( Mei Fu	)
Subject: Information about CALICO
Organization: Reynolds+Reynolds, Dayton, Ohio
Date: Wed, 16 Dec 1992 15:08:12 GMT


Hi, 

I'm looking for information about CALICO which is a new C-based, object-
oriented programming language developed by AT&T.  Can anyone give me any
information of this product?


Thanks


Mei
----
E-mail: mf024@windy.randr.com

Newsgroups: comp.lang.c++