HDTenEightyP/NetNews huggingface dataset:
From: andy@federation.gatech.edu (Andy Register)
Newsgroups: comp.lang.c++
Subject: Re: Using delete with arrays - help please!
Date: 16 Nov 92 14:29:14 GMT
Organization: CERL-EE, Georgia Institue of Technology

When I experiment with this kind of thing, I use
the function

unsigned long coreleft()

from the alloc.h file.

I can call coreleft, new, delete, coreleft and if the
results of the two coreleft calls are not the same
then somewhere memory did not get free'd up.  Admittidly
not very sophisticated but it seems to work for me.

Try it with the char * example you cited and see what happens.
Also try it with you example and you will see why the [] is
required in the delete.

Any other strategies?

Toodles
Andy
Newsgroups: comp.lang.c++
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Template classes and overloaded binary operators on differing types
Date: 20 Nov 92 17:35:58
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: sb@next.neuro.emory.edu's message of 19 Nov 1992 18:38:44 GMT

     Can someone please comment on the following problem and suggest the
   "best" way to solve it.

      Say I have a template class that implements a VECTOR type and binary
    operators like addition and subtraction. All of the binary operators are  
   currently implemented as template friend functions which accept two  
   vectors of the same type. For example, I have this :


     VECTOR<int> ivec1(3),ivec2(3),ivec3(3);  // 3 is vector size

     ivec3 = ivec1 + ivec2;   

     My question is, how can I extend this so that I can add vectors of  
   differing types ?  e.g.,

	   VECTOR<int> ivec1(3);
	   VECTOR<double> dvec1(3),dvec2(3);

	   dvec2 = ivec1 + dvec1;

    What is a good way to implement this ?

There are several methods:

	(1) define a conversion operator:

	template <class T>
	struct VECTOR {
		...
		operator VECTOR<int> { ... }
		operator VECTOR<double> { ... }
		...
	};

	(2) write an explicit conversion function (can be a template
	function for convenience):

	template <class T>
	VECTOR<double> as_double_VECTOR(VECTOR<T> &v) {
		...
	};

	(3) overload operator+:

	VECTOR<double> operator+(VECTOR<int> &v1,VECTOR<double> &v2) {...}

	(4) overload operator+ with a template:

	template <class X,class Y>
	VECTOR<X> operator+(VECTOR<X> &v1,VECTOR<Y> &v2) {...}

Personally, I'd use (and I have used) (2). Method (1) doesn't work
with GNU C++. Method (3) is usually considered the "most efficient",
but in terms of runtime, the difference is usually insignificant; the
main difference is that it requires less space than conversion
methods, but it requires a whole lot more code. Method (4) may look
appealing, but the return type is wrong (sometimes you want VECTOR<X>,
sometimes VECTOR<Y>), and there is no way of fixing this in C++.

				Thomas.

Xref: sparky comp.lang.c++:16748 misc.jobs.misc:7863
From: mark@whizbang.wariat.org (Mark W. Schumann)
Newsgroups: comp.lang.c++,misc.jobs.misc
Followup-To: misc.jobs.misc
Subject: New Employee Test 
Distribution: world
Date: Mon, 23 Nov 92 01:16:21 GMT
Organization: The Software Sweatshop, Cleveland, Ohio USA


In article <1992Nov22.010912.10552@en.ecn.purdue.edu>
krauskop@en.ecn.purdue.edu writes:

  > (Warren Vonroeschlaub) writes:
  > >  I thought I would mention that, at least it in New York, it is 
  > >  illegal to give
  > >a test to prospective employees before hiring them.
  > >
  > >  We got into alot of trouble at the contracting firm when 
  > >we tested prospective
  > >employees to make sure they really knew how to use AutoCad.  A few weeks later  > >we found one of the people who was turned down (to be exact he knew squat,
  > >regardless of what his resume said) complained to one of the government
  > >agencies.
  > >
  > 
  > Heh.  That should be a piece of cake to get around.  Just pay them $5.00
  > (for their time) as a contract employee to take the test.  Note that I 
  > do not have a company in New York nor do I know about any loopholes in
  > this law, but it does seem to solve the problem.

I don't doubt Warren's story, but my bogometer just hit TILT.  I know
New York is a weird state, but I just have a hard time believing they
have a blanket ban on pre-employment skill tests.  Is there any more
to this story?

Followups to misc.jobs.misc, please!

--
Mark W. Schumann/3111 Mapledale Avenue/Cleveland, Ohio 44109-2447 USA
Domain: mark@whizbang.wariat.org                      CIS: 73750,3527
"We're not nuts or anything; I mean *I'm* not nuts." <whizbang!judy>
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Multiple Header Files Problem
Organization: Rational
Date: Fri, 20 Nov 1992 18:10:08 GMT

dgil@pa.reuter.COM (Dave Gillett) writes:

|     It's pretty hard to get into this fix except by making heavy use of
|inline methods.  Dare I suggest that anyone who regards this as a "very
|serious" problem is *probably* inlining too much? 

excessive inline-ing is one of the most common flaws made by novice
users of C++.  The tempatation to inline is strong, and the
disadvantages are not obvious.  This attitude can lead a development
team into a very nasty situation involving long convoluted dependency
cycles.  It is not always easy to figure out how to break them.

As a basic rule of thumb, functions which access the members of other
classes should not be inlined.  If this rule is followed consistently,
then inlining will never cause a dependency cycle.

The other source of dependency cycles that you mentioned was
"containment by value".  i.e.

	class A
	{
	  public:
	    B itsB;
	};

	class B
	{
	  public:
	    A itsA;
	};

This can be broken by containing one or both members by reference.
(i.e. use pointers or references instead of values).  Such a practice
also brings the benefit that the contained object can be polymorphic.
Objects contained by value cannot be polymorpic, but objects contained
by reference can.

Thus, another rule of thumb is: "where possible, contain by
reference."
--
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++
Newsgroups: comp.lang.c++,comp.std.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Proposal - enhancement for switch statement.
Date: Fri, 20 Nov 1992 19:50:59 GMT
Organization: University of Birmingham

In article <1992Nov19.163944.19935@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> In article <1992Nov16.213015.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
>>Now (as promised) why ranges would be unnecessary (following the "if you
>>can do it with a class then don't extend the language" rule ;-) )
>>
>>template <class T> class Range {
>>  T top,bottom; 
>>public:
>>  Range(t,b) : top(t),bottom(b) {} 
>>  int operator==(T t) { return bottom <= t && top >= t; }
>>}
>>template <class T> inline operator == (T& t,Range<T>& r) {return r == t;}
>>
>>switch (i) {
>>  case Range<char>('0','9') : case '-' : {/*...*/} break;
>>}
> 
> 	This is illegal. 
> 	The 'argument' of a case must be a constant expression.
> 	switch is a primitive operation, the compiler must be able to
> 	check for duplicate cases.
> 

Of course it's illegal! I do wish people would pay attension to the
subject of the thread. What is being to discussed is the merit of
allowing the switch command to accept an argument of any type and
resolve cases using the appropriate == operator. Since there's no
such thing as a compile-time class object constant this implies that
the case clause would have to be able to take an expression if
this proposal were accepted. It would also mean that switch was not
a primative operation (unless it happened to obey C rules in which
case it would optimize back to a primative operation). The ability for
the compiler to detect duplicate cases would also be lost when varaible
expressions where use in case clauses (or when the == operator was not
inline). The complier does not _need_ to be able to detect duplicate
cases if its not trying to make a jump table and it couldn't in these
cases anyhow.

The range issue was introduced as an amendment and I was demonstrating
that it was redundant given the implications of the original proposal.

IMHO...

On balance the extension of switch to operate on any class is probably
unecessary and the extension to case to take ranges is therefore a 
good idea. 

Removing the need for break between case clauses is a bad idea
- the need to avoid fallthrough is better handled by a complier warning.

Adding a new syntax (or worse still token) to the language should not
be done lightly.
-- 
    \\   ( )    No Bullshit!     |  Email: B.A.McCauley@bham.ac.uk   
 .  _\\__[oo        from         |  Voice: +44 21 471 3789 (home)
.__/  \\ /\@    /~)  /~[   /\/[  |    Fax: +44 21 625 2175 (work)
.  l___\\      /~~) /~~[  /   [  |  Snail: 197 Harborne Lane,
 # ll  l\\    ~~~~ ~   ~ ~    ~  |         Birmingham, B29 6SS, UK
###LL  LL\\   (Brian McCauley)   |   ICBM: 52.5N 1.9W
Newsgroups: comp.lang.c++,comp.std.c++
From: xjzhu@math.uwaterloo.ca (Xiaojun Zhu)
Subject: Recursive Template? Are you sure?
Keywords: template, factorial
Organization: University of Waterloo
Date: Mon, 23 Nov 1992 17:58:45 GMT

Hi, there:

While everybody is so hot on the topic about "Recursive template",
I can't seem to make the following code compile under AT&T C++ V3.0.

Can comeone enlight me about this? (or maybe the original creator of 
this piece of code) It seems to me that you have to instantiate every
class which gets involed in. For example, in this case, you have to 
instantiate class Factorial<1>, class Factorial<2>, ..., class
Factorial<5>, but if this is the case, what's the so good about
this recursive template? I don't get the point.

*********Code Segment follows************

#include <iostream.h>

template<int n> class Factorial
{
public:
	int eval() { return n*Factorial<n-1>.eval(); }
};

class Factorial<0>
{
public:
	int eval() { return 1; }
};

int main()
{
	Factorial<6> f6;
	cout << f6.eval() << endl;
	return 0;
}
********** Code Segment Ends **********


--------------------------------------------------------------
   A template version of signature class is under repair.
Symptom: It dies without a warning if I use certain class 
         as an argument.
         
                                       xjzhu@math.uwaterloo.ca
--------------------------------------------------------------
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Confusion on :: and protected (Simple?)
Organization: Rational
Distribution: na
Date: Fri, 20 Nov 1992 15:51:09 GMT

mike@sdd.comsat.com (Mike Stennett) writes:

|I tried to compile with both DEC's cxx 1.0 and GNU's g++ 2.2.2 but got 
|the following errors:

|[39] cxx test.C
|test.C:24: error: In this statement, "foo::print" is not accessible.
|Compilation terminated with errors.
|[40] g++ test.C
|test.C: In function `int  static joe::something (int)':
|test.C:24: method `int  static foo::print (int)' is protected


|class foo 
|{
|protected:
|	static int print(const int y) { cout << y << endl; return 1;}
|};

|class  joe : public foo
|{
|public:
|   static int something(int z);
|};

|int joe::something(int z)
|{
|    foo::print(5);
     ^^^^^^^^^^^^^^^    This is the line with the error.
|}

ARM 11.5 (p253) says that member functions of derived classes can only
access protected members of base classes "through a pointer to,
reference to, or object of the derived class (or any class derived
from that class). 

However, you can do this:

    this->foo::print(5); 

This is allowable since you are accessing foo::print through a pointer
to a joe (this).  Wierd huh?

E&S try to justify this in the last paragraph of page 254.  

--
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++
Newsgroups: comp.lang.c++
From: kanze@us-es.sel.de (James Kanze)
Subject: Re: question on REFERENCES
Organization: SEL
	<1992Nov17.141055.19557@relay.nswc.navy.mil>
Date: 18 Nov 92 17:08:43

In article <1992Nov17.141055.19557@relay.nswc.navy.mil>
kestes@nswc-wo.nswc.navy.mil (Kent Estes) writes:

|> I am working on a function that references objects via id.  Upon finding
|> an object, it returns a reference to that object.  My question is :
|> if the object is not found, what is the best way to handle this.  If 
|> I were returning pointers to objects, all I would have to do is
|> return NULL.

Two possibilities:

Add the element being looked up to the set of objects, with a default
value, and return this.  This is a good solution for associative
arrays, for example, where the operator[] never fails.

Or treat such a reference as an error, and do your error handling
thing.  Exceptions would be nice here, but while we're waiting, I
generally use a call back function.  Note, however, that if the
call-back function returns to where it was called from, you'd better
have something to return anyway.  (A static value would do the trick.
The important thing is that the user is supposed to do something in
the call-back function so that he won't use the reference later
anyway.)

To give a concrete example, from my assocative array class:

	class AssocArray
	{
	public :
		DataType&	operator[]( const KeyType& ) ;
		const DataType&	operator[]( const KeyType& ) const ;
		int		contains( const KeyType& ) const ;
	} ;

The first operator[] uses the first solution.  The second operator[],
which will be used on constant objects, uses the second solution, with
a default call-back function which aborts the program with an error
message.  The contains function is there so that the user can find out
whether the key is present *before* creating it (in a non-const
object) or calling the call-back function (in a const object).
--
James Kanze			GABI Software, Sarl.
email: kanze@us-es.sel.de	8 rue du Faisan
				67000 Strasbourg
				France
From: skip@taygeta.oc.nps.navy.mil (Skip Carter)
Newsgroups: comp.lang.c++
Subject: Re: Just what is so great about streams?
Date: 18 Nov 92 23:26:35 GMT
Reply-To: skip@taygeta.oc.nps.navy.mil (Skip Carter)

In article <1992Nov18.134551.5782@bcrka451.bnr.ca>, sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
|> In article <6994@taurus.cs.nps.navy.mil> skip@taygeta.oc.nps.navy.mil (Skip Carter) writes:
|> >
| >>         ...............
|> 
|> [class TimeStamp]
|> >         friend ostream& operator<<(ostream& os, const TimeStamp& t);
|> >};
|> >
|> >class Comment : public ostrstream                   // write a comment to a file, with user defined start and end
|> >{                                                                             //  comment sequences
|> >
|> >	Now the TimeStamp class can write a comment WITH NO CHANGES MADE TO
|> >	THE TIMESTAMP CLASS.
|> >
|> >	Comment fout(...);
|> >
|> >	fout << TimeStamp();
|> >
|> >
|> >	In fact, TimeStamp can properly write to any class that is ultimately derived from ostream.
|> >
|> 
|> What about     fout << t << t << endl;   
|> The wrong operator<<() will be called for the second output unless you provide
|> the appropriate friend function for TimeStamp, no?
|> 

	There is no problem at all with      fout << t1<< t2 << endl;
	Since  the evaluation order is:
	first,
		fout << t1;	

	which returns a reference to fout which  is then used in the operation,

		(reference to fout) << t2;

	which again returns a reference to fout, which finally gets the    endl


-- 
 Everett (Skip) Carter             Phone:  408-646-3318 FAX: 408-646-2712
 Naval Postgraduate School         INTERNET: skip@taygeta.oc.nps.navy.mil
 Dept. of Oceanography, Code OC/CR  UUCP:     ...!uunet!taygeta!skip
 Monterey, CA. 93943               TELEMAIL: s.carter/omnet
Newsgroups: comp.lang.c++
From: etxmtsb@solsta.ericsson.se (Mats Bengtsson  TX/DK )
Subject: Re: how to initilize an array inside of a class??
Organization: Ericsson
Date: Mon, 16 Nov 1992 11:24:22 GMT

jimad@microsoft.com (Jim Adcock) writes:

.....

>#include <iostreams.h>

>typedef int* intptr;

>class IArray
>{
>public:
>	int arr[8];
>	void print() ;
>	operator intptr() { return arr; }
>};

>void IArray::print() 
>{ for (int i=0; i<8; ++i) cout << arr[i] << ' '; cout << '\n'; }

>const IArray odds = {1, 3, 5, 7, 9, 11, 13, 15};

>class X
>{
>public:
>	IArray i;
>	void print() { i.print(); }
>	X() : i(odds) {}
>};

Why isn't is possible to write
	X() : I({1,3,5,7,9,11,13,15}) {}
I think that would be an obvious solution. The same syntax should also
be suitable for other aggregates (that is, classes with no constructors,
no private or protected members a.s.o.). 


>main()
>{
>	X x;
>	X y;
>	x.print();
>	x.i[1] = 9999;
>	x.print();
>	y.print();

>	return 0;
>}


  /Mats Bengtsson

Newsgroups: cvnet.c++,comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Finding memory leaks
Keywords: OOP,memory leaks
Organization: TauMetric Corporation
Date: Mon, 23 Nov 1992 21:04:18 GMT

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

>steve@taumet.com (Steve Clamage) writes:

>>mpk9172@ultb.isc.rit.edu (M.P. Kirby) writes:
>>
>>>In C I used to use a memory leak finder that would help me find
>>>my memory leaks.  I basically created a #define for malloc that redefined
>>>it ...

>>>I would like to do the same kind of thing in C++...

>>You do NOT want to replace "new" with a macro.  "new" is
>>a keyword which causes constructors to be called, and memory to be
>>allocated via the function "operator new()".  If you replace the "new"
>>keyword with a macro, you destroy the semantics of most programs.

>Unfortunately, we DO want to replace "new" with a macro, so that we can
>get __LINE__ and __FILE__. Redefining operator new() is not sufficient, because
>__LINE__ inside operator new() refers to the line where operator new() was
>redefined, not the line where new was invoked. ...

>The only way that I can see of solving the problem is to write a preprocessor
>which properly parses the source code, and then does the desired replacements.
>I don't see how it could be done using just the simple textual substitution
>provided by the C preprocessor.

If you don't mind modifying the source code, you can use placement syntax.
For example, instead of
        T* p = new T;
you would use
        T* p = new (__FILE__, __LINE__) T;
The result would be a call to
        operator new(size_t size, char* file, int line)
which would be your specialized allocation function.

You could use a macro to make this less tedious:
	#define my_new(x)	new (__FILE__, __LINE__) x
	...
	T* p = my_new(T);
 
Then write your own operator delete.  You have to be aware that there may
be calls to ordinary operator new from the library or other code.  Your
operator delete has to be able to cope with both, since there can be
only one (global) operator delete in the system.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: dhsong@camel.erg.sri.com (Song Dong-ho)
Subject: Andrew Koenig's C++ Class Lib. 
Keywords: c++ library
Reply-To: dhsong@camel.erg.sri.com (Song Dong-ho)
Organization: ETRI, SRI International
Date: Wed, 18 Nov 92 19:40:17 GMT

Does anyone out there know any ftp site for Andrew Koenig's C++ class
library which implemented most of Smalltalk Classes ?

Thank in advance.
Dongho

Dongho Song,
EK345, SRI International, 
333 Ravenswood Ave., 
Menlo Park, CA 94025

dhsong@erg.sri.com
voice)(415)859-4169
Newsgroups: comp.lang.c++
From: head@dorsai.com (Howard Pinsley)
Subject: Using DLL's w/BC++
Organization: The Dorsai Embassy +1.718.729.5018
X-Newsreader: Tin 1.1 PL4
Date: Wed, 18 Nov 1992 18:28:03 GMT

I have an application that I originally linked against the static versions of 
the C RTL, Borland's Classlib and OWL.  Since my .exe size is approaching 1MB, I
thought it would be a good time to use the DLL's for these three libraries.

I'm having trouble doing it.  I first selected the dynamic library options in
the IDE's linker options dialog.  This gave me a lot of errors.  I then realized
that the documentation does indicate that I should define both _RTLDLL and 
_CLASSDLL (with single, NOT double underscores).  This eliminated the previous
linker errors.  However, now I'm getting "type mismatch in redeclaraion" 
compiler errors.

I believe it has something to do with the fact that I am not using the 
_CLASSTYPE macro anywhere (I'm not sure where it should be used).  When I define
a new class, I typically do the following:

_CLASSDEF(TMyClass)

class TMyClass : public TWindow {
};

Should _CLASSTYPE be inserted between class and TMyClass?  I am confused.  Can
someone enlighten me?  Thanks.
-- 

Howard Pinsley                                             Voice: (212) 836-8322
head@dorsai.com                                              Fax: (212) 836-8689

Newsgroups: comp.lang.c++
From: beery@gecko.cis.ohio-state.edu (brian david beery)
Subject: Thanks for the info
Organization: The Ohio State University Dept. of Computer and Info. Science
Date: Tue, 17 Nov 1992 06:16:53 GMT

   I would like to thank everyone who responded to my question about pointers
and class objects.  Basically, I needed to parenthesize the reference as 
follows:
   (*o).value=0;
or:
   o->value=0;
   Thanks again to everyone who responded!
                                    -Brian Beery


















Newsgroups: comp.lang.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Help with nested class and constructor
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Thu, 19 Nov 1992 17:19:20 GMT

In <Bxyxrv.EJ3@news.cso.uiuc.edu> macg9505@uxa.cso.uiuc.edu (Michael Alan Corn) writes:


>I could use a little help on nested classes:
>      I would like to include one of Borlands Array classes in another class,
>in the private data section, but since the constructor requires an int to
>initialize the class, I'm not sure how or where to give it the value:

>class foo {
>      private:
>      Array myarray(10); ///this doesn't work, the compiler chokes


*****>	foo::foo() : myarray(10) {/*...*/}

	Look up mem-initializer in the C++ you have.

>so I've tried this, which seems to work

>class foo {
>      private:
>      void *myarray;

*****>	Why void*?  How about Array*?  Of course, if you do the first 
	thing above, you needn't do anything else.

	[remainder elided]
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: rescorla@rtnmr.chem.yale.edu (Eric Rescorla)
Subject: Re: New Employee Test
Organization: Rescorla for himself.
Date: Thu, 19 Nov 1992 01:05:34 GMT

In article <1992Nov19.002724.13837@en.ecn.purdue.edu> krauskop@en.ecn.purdue.edu (Curtis D Krauskopf) writes:
>Suggestions that a quicksort or other algorithm be used (especially
>since quicksort is a standard library function) get many bonus points.
>If the candidate asks, they can have full access to the company library
>of C books.  (I don't believe in closed-book tests, especially on-the-job).
I know that this is nitpicking, but....
I don't believe that in fact quicksort is a standard library function.
You should not be fooled by the fact that the standard library function
is called qsort(). K&RII certainly doesn't specify that the algorithm
used to do the sort will in fact be quicksort. It could, for instance,
be heapsort, as far as I can tell. 

Also, I'd note that you specified that the guy should create a bubble
sort. One might believe that you had a specific reason why you wanted
that. I certainly wouldn't tell someone who was writing code for me
that I wanted a bubble sort unless that's what I actually wanted.

-Ekr


-- 
-------------------------------------------------------------------------------
Eric Rescorla, DoD#431 (Nighthawk S)              rescorla@rtnmr.chem.yale.edu
Former chemist now CM400 mechanic                 ekr@eitech.com(preferred)
                "Meet the new boss, same as the old boss."
Newsgroups: comp.lang.c++