HDTenEightyP/NetNews huggingface dataset:
From: ssimmons@convex.com (Steve Simmons)
Subject: >>>>>>>>  Is it possible to use 'delete this' ?
Date: Tue, 29 Dec 1992 13:46:41 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.


> The problem I had with Bob's first reply was that he didn't answer the
> question: is "delete this" legal.
>
> I would also like to know the answer. It seems to work on all the compilers
> I have access to and I understand that Bjarne uses it. So I guess it is legal,
> but it would be nice to have a reference - or is it something the standards
> committee should explicitly include in the standard.
>
> I think Bob's reply would have been much more helpful if it had started out
> with "yes", "no", or "not clear".
>
> Then it would be appropriate to give a warning. Incidentally, is the warning
> about is causing difficulty to some compilers just a "gut feeling" or are
> there specific examples?
>
> Bob's warning about "delete this" seems to apply to any use of "delete" by
> an entity that didn't do the corresponding "new". Otherwise there is always
> the risk that the "delete" will be applied to something not created by
> "new". Is this another safe programming rule?

On page 66 of the ARM, there is an example of why you would want the 
"delete this" capability.  Therefore, it is probably legal.  However, 
the standard does also say that you must be careful not to delete 
a pointer that is not allocated by new.  The resulting behavior is 
undefined (maybe nothing or maybe core dump). 

Thank you. 

					Steve Simmons
From: byrne@cps.msu.edu (Eric J. Byrne)
Newsgroups: comp.lang.c++
Subject: What is a good C++ book?
Date: 29 Dec 92 22:04:51 GMT
Organization: Michigan State University
NNTP-Posting-Host: slate.cps.msu.edu



 Sorry, if this is a FAQ, but I don't follow this group.  I'm looking for
 a good book on C++.  I'm have lots of C experience, but have not used
 an object oriented language before.  If you have used a book and felt
 it was informative and well put together on this subject, please let
 me know the title and author.

  Thanks
   E. Byrne
Newsgroups: comp.lang.c++
From: "John F. Isner" <wk01696@worldlink.com>
Subject: Re: USL C++ Standard Components - A bug?
Organization: Nomura Research Institute
Date: Thu, 24 Dec 1992 03:00:50 GMT
X-Mailer: WORLDLink (3.11)

>DATE:   Sun, 13 Dec 1992 19:51:20 GMT
>FROM:   Andrew Gideon <andrew@tagsys.com>
>
>I have just started working with the USL/C++ Standard
>Components for a new client.  Already, I may have found
>a very serious problem.  I hope that I'm wrong.
>
>I have been working with the Rogue Wave tools.h++ product for 
>quite a while.  One of the first things that I did was
>construct deep collections from the RW shallow collections.
>It was nice to see that USL had already thought of this
>(USL calls deep collections "object collections" and shallow
>collections "pointer collections" - some people still publish
>implementation {8^).
>
>But in my first set of experiments, I immediately noticed
>that something was wrong with the deep sets in USL.  
>
>When insert()ing objects into a deep set, the copy
>constructor is used to create new instances.  The object
>passed in the insert() method is still owned by the caller
>of insert() - the new copy is held by the set.
>
>But when a deep set is destructed, the contained objects are 
>NOT destructed.  Further, objects that are remove()ed are also 
>not destructed.
>
>I could find no way (w/o unsafe casts) to get around this.  
>(And even with unsafe casts, I doubt that it would work)
>
>This seems like a memory leak.  Am I missing something?
>Help, please?
>
>	Andrew Gideon

USL Sets and Set_of_p's (pointer sets) are quite different,
not only in implementation, but in semantics.  A Set_of_p
is implemented using a data structure optimized to support
set operations on void*'s.  The generic wrapper around this
data structure it is merely for type safety, and generates 
no code.  The elements of a Set_of_p are T*'s.  Memory 
management for the T's pointed to by the Set_of_p is the
responsibility of the client.  This is stated quite clearly
USL's documentation.

USL's Sets and Bags, on the other hand, are containers for 
objects.  As you correctly state, objects inserted into them
are copied using T(const T&).  However the copies ARE fully
managed by the container.  For example, the implementation 
uses a hashing scheme with collision lists;  removing an 
object from a Set is implemented by finding and deleting 
the list node containing the object. when the node is deleted, 
~T() is invoked.  Destroying the Set destroys all the lists,
hence all the nodes, hence all the objects they contain.

I have been using the USL Standard Components for several
years, both inside AT&T and in my current job.  To the best
of my knowedge, they are free of memory leaks.  

John Isner
Newsgroups: comp.lang.c++
From: bucjet@uxa.ecn.bgu.edu (Jeffrey Terrell)
Subject: Converting EXE files back to C source code
Organization: Educational Computing Network
Date: Sun, 27 Dec 1992 20:48:44 GMT

I was looking through some of my old disks and I came across some old C
programs I wrote 2 or 3 years ago.  I notice that some of the C source
codes were there also some EXE files.  I saw some EXE files that didn't
have any source code paired with it.  I was wondering if it was possible
to convert those EXE files back to it orginal source code?  Some of
those programs I written was quite interesting.  


Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Should char arrays be deleted with delete[]?
Date: 23 Dec 92 21:50:18 GMT
Organization: Microsoft Corporation
Keywords: C++

In article <1992Dec18.161338.28124@promis.com> fogel@promis.com (Richard Fogel) writes:
|Should char strings allocated as follows:
|
|char *str = new char[10];
|
|later be deleted by:
|
|delete []str   OR    delete str  ?

One rule applies to objects of any type:

Foo* fooArray = new Foo[10];
delete [] fooArray;

Foo* pFoo = new Foo;
delete pFoo;

Base* pBase = new Foo; 	//assuming Base a public base class of Foo
delete pBase;		//AND that Base has a virtual destructor declared

Base* baseArray = new Foo[10];	//WRONG!
delete [] baseArray;			//likewise wrong!

While if you follow other rules your code might accidentally 
work sometimes on some implementations, then again, it might not.
From: darcys@fraser.sfu.ca (Darcy Smith)
Newsgroups: comp.lang.c++
Subject: Re: Newbie Wants Advice on C-Programming
Date: 3 Jan 93 18:56:14 GMT
Organization: Simon Fraser University, Burnaby, B.C., Canada (sortof)


From newsserver.sfu.ca!cs.ubc.ca!destroyer!gatech!swrinde!zaphod.mps.ohio-state.edu!cs.utexas.edu!uunet!pipex!bnr.co.uk!uknet!mcsun!sun4nl!and!jos Sun Jan  3 09:27:40 PST 1993
Article: 34226 of comp.lang.c
Xref: newsserver.sfu.ca comp.lang.c++:27833 comp.lang.c:34226
From: kristfin@rhi.hi.is (Kristjan Thor Finnsson)
Newsgroups: comp.lang.c++
Subject: Borland C++ 3.1 makefile for Newmat
Summary: c++
Keywords: newmat
Date: 26 Dec 92 06:28:42 GMT


Has anyone made a makefile for the latest version of Newmat for bcc 3.1?
I'm not used to makefiles and don't know how to make one for this pack.

Any help would be nice.
All the best and merry Xmas

-- 
-----------------------------------------------------------------
 Kristjan ,,Stjani'' r Finnsson.   Netfang: kristfin@rhi.hi.is 
 Strpfrpinemi vip Haskla Mslands.    Smmi: 673507  
-----------------------------------------------------------------
Newsgroups: comp.lang.c++
Subject: Re: Is it possible to use 'delete this' ?
From: robertd@kauri.vuw.ac.nz (Robert Davies)
Date: Wed, 23 Dec 1992 21:25:04 GMT
Organization: Victoria University of Wellington

rmartin@thor.Rational.COM (Bob Martin) writes:
>bernd@bwhwob.escape.de (Bernd Wiegmann) writes:
>
>>Hi,
>
>>Is it possible to use 'delete this' as the last statement in a
>>method of a class ?
>
>In general, "delete this" is a bad idea.
> .........

This is the standard argument - but I suspect it is not necessarily the 
correct one.

My matrix package newmat06 uses "delete this" in a number of places and this
is one statement that does not seem to have been a problem.

Newmat06 (with some minor amendments) runs OK on Borland 3.1, Gnu 2.2.2,
(not sure about 2.3.2) AT&T 2.2, 3.0, Microsoft (7.0), and mostly on
Zortech so most vendors don't seem to be having a problem. (Gnu 2.3.2 and
Microsoft won't delete this from a constant member function, but that seems
very sensible).

This is in contrast with things like multiple inheritance
and templates that I would be very reluctant to use in a portable package
at the present time.

I agree that "delete this" could be very confusing in a function likely to
be used by others (or oneself, sometime in the future), but for a function
that is only for internal use by one's package, probably declared private 
and properly documented, there doesn't seem to be a problem.

The danger with the statements that "delete this" is not a good idea is 
that the compiler writers or standards committee will listen and a very
useful construct (in some situations) will be lost.

Robert


From: defaria@hpcuhe.cup.hp.com (Andy DeFaria)
Date: Mon, 28 Dec 1992 08:47:24 GMT
Subject: Problem with BC++ 3.0 TLINK and missing symbols
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.lang.c++

I have been receiving errors from Borland C++ 3.0 of the form:


Linker Error: Undefined symbol foo<int>::foobar() in module BAR.C

given the following files:

FOO.H:
------
template <class TYPE>
class foo {
   private:
      int i;
   public:
      void foobar (void);
};

FOO.C:
------
#include "foo.h"

template <class TYPE>
void foo<TYPE>::foobar (void) {
  i++;
} // foobar

BAR.C:
------
#include "foo.h"

void main (void) {
   foo<int> x;

   x.foobar ();
} // main

These example is a chopped down version of the real one that I had originally
had had problems with.  Notice that there is no need for a template anymore as
TYPE is not really used.  I am using Borland C++ 3.0 and in the IDE I create a
project file that has both FOO.C and BAR.C.  Every thing compiles but fails to
link with the above message.  Why?
Newsgroups: comp.lang.c++
From: stefan@mpi-sb.mpg.de (Stefan Naeher)
Newsgroups: comp.lang.c++
Subject: A Template Question
Date: 22 Dec 92 11:39:58 GMT
Reply-To: stefan@mpi-sb.mpg.de
Organization: Max-Planck Institut fuer Informatik


Is it allowed to use a template class name  for a class member ?
Cfront3.0.1 seems to handle this case not correctly.

The following piece of code is compiled without any error message

   template <class T>  class A { };

   struct B
   {
     int A;

    };


however, if I change the type of B::A to int* cfront says   
"error:  A needs template instantiation arguments".

What is the correct behaviour?


-------------------------------------------------------------------------------
Stefan N"aher                                      e-mail: stefan@mpi-sb.mpg.de
Max-Planck-Institut f"ur Informatik                phone:  +49 681 302 5420
Im Stadtwald                                       fax:    +49 681 302 5401
6600 Saarbr"ucken
Germany
-------------------------------------------------------------------------------


Newsgroups: comp.lang.c++
From: euamts@eua.ericsson.se (Mats Henricson)
Subject: Re: How to read a string with space
Reply-To: euamts@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Wed, 23 Dec 1992 15:02:00 GMT

In article 1h9qmnINNlss@manuel.anu.edu.au, cxd653@huxley.anu.edu.au (Chunping Ding) writes:
#
#Could anyone tell me how to read a string with space? Thank you.
#
#I wrote a progam as following:
#
##include<iostream.h>
#
#main()
#{
#  char name[20];
#  cout<< "Enter a name ...";
#  cin >> name;
#  cout << "The name you entered is "<<name<<'\n';
#}
#
#When I run this program and answer the prompt:
#Enter a name ...
#with:
#Ding Chunping
#I got an output from the computer:
#The name you entered is Ding
#
#The computer ignores the part of the string, Chunping, after the space.
#How can I solve the problem?

You can fix this by using the getline function:

main()
{
   char name[20];
   cout << "Enter a name ...";
   cin.getline( name, 20 );
   cout << "The name you entered is " << name << endl;
}

The function getline for istream is declared like this in the file iostream.h:
    istream&    getline(char* b, int lim, char delim='\n');

Input is tricky...

Mats Henricson
Ellemtel
Stockholm
Sweden

Newsgroups: comp.lang.c++
From: empath@ais.org (Tim Triemstra)
Subject: Re: 32bit Zortech Pointers
Organization: UMCC
Date: Fri, 1 Jan 1993 09:09:32 GMT

> 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?

Sorry about the not-so-clear wording on the INT calls, I meant INTeger
calls.  I'm not dealing with any real mode TSRs, or even any external code
to speak of.  The entire program encapsulates only 2 small files that could
easily just be one.

The code goes something like this:

unsigned char *buffer;
//malloc the buffer I believe
InitVoice(buffer);

My pointer logic is real bad at 4am but that is the gist of it.  In the
32bit mode, I get static - but the proper amount of static which mean that
the interrupt is being called and killed correctly, but not given the proper
data - hence the concept of improper pointer holding in 32bit modes with
interrupts.  I'm going to do alot more combing through the code to make SURE
that there isn't any 4byte integer calls where on 2 bytes are expected, but
I've done days of that and I'm pretty sure that is safe.  I was just curious
if you had to protect pointers that were to be handled by both interrupt
and non-interrupt code.  I have alot of 6510 ASM experience with interrupts
but the knowledge of interrupts ends at a theoretical level with 80xxx 
processors.

Thanks again guys.  Joe - I sent this code a while back UUENCODED to
you att proto com, so if this interests you and you would "like" to get
it working go fer it.  It's just gonna be GNU distrubuted when done anyhow.

Tim
Empath@Ais.Org

Newsgroups: comp.lang.c++
From: empath@ais.org (Tim Triemstra)
Subject: 32bit Zortech Pointers
Organization: UMCC
Date: Thu, 31 Dec 1992 03:53:01 GMT

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
(using the quick-and-dirty command line) and produce a "working" .exe file.
However, where it is supposed to play a VOC file of ??? bytes, it comes out
playing ??? bytes - but the wrong bytes!  I know the interrupts are working
as you can time the routines when they work (and play something like "HELLOW
STRANGER" outta the SB Speaker) and the garbage and they are equal because
the length of the sample is controled in a standard 2byte short.  However,
I get garbage for that period of time. I also know it is working simply
because the entire thing is handed via interrupts and wouldn't work at all
if it wasn't kicking in.

My assumtion is that since the data for the VOC is stored in a pointer of
unsigned char's in both versions, that the pointer is somehow not protected
enough for the interrupt handler.  So, any ideas on how to get this working?
I thought I may need to use one of the DOS extenders pointer making
functions, but none of them really seem aplicable.

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

Tim.

Newsgroups: comp.lang.c++
From: bear@kestrel.fsl.noaa.gov (Bear Giles)
Subject: Re: Intersting Data Structure
Organization: Forecast Systems Labs, NOAA, Boulder, CO USA
Date: Wed, 30 Dec 1992 18:34:52 GMT

>reznick@acf3.nyu.edu (Daniel Reznick) writes:
>
>>Can anyone suggest a feasable Data Structure/Class Hierarchy to
>>implement a Rubik's Cube?

What about a list of the rotations?  Each node would contain two
pieces of information: the face (GREEN, WHITE, YELLOW, etc) and the
rotation (1 to 3).  If necessary, you could fit this information into 5 bits!

Solving the cube would be easy -- follow the list backwards and 
reverse each rotation.

Finding the representation of an existing cube would be more complex, but
not as much as you might expect.  You would need an auxillary representation
of the goal states (e.g., move subcube 4 into position 17; I think that
uniquely identifies the goals but I'm not certain) and use the techniques
developed for exchanging subcubes to satisfy all of the goals.  (I've seen
a list of these rotations in "how-to-solve-it" books for the cube).

This will create a fairly long list of rotations, but shouldn't be too hard
to implement.  Then run this list of rotations through a filter which
optimizes moves.  For instance,

  GREEN 2
  RED 2
  GREEN 1

could be replaced with

  GREEN 3
  RED 2

provided GREEN and RED are on opposite sides of the cube.  Obviously, if this
was 

  GREEN 2
  RED 2
  GREEN 2

you could drop _both_ GREEN rotations since that has no net effect.

Of course, you can also reduce the list by optimizing your solution of the
goal states -- you may be able to 'kill two birds with one stone' in many
cases.


Bear Giles
bear@fsl.noaa.gov
From: rjf@seiko.mpd.tandem.com (Russell Fleming)
Newsgroups: comp.lang.c++
Subject: Re: Simulate "Pointer to char" by an array
Date: 30 Dec 92 19:53:47 GMT

In article <1992Dec30.172241.11378@dcs.warwick.ac.uk>,
cmchan@dcs.warwick.ac.uk (C M Chan) writes:
>  
> How can I simulate "pointer to char" by an array in a class whose size
will be \
> delayed to be
> defined at run time?
>  
> For example, [... DELETED ...]

If I understand your question correctly, you can add a char* operator to
the class which will return the type of pointer you are looking for. 
For example:

class X {
private:
	char str[...];
public:
	X(void);
	~X(void);
	operator char* (void) { return str; }
};

main ()
{
	X x;
	char s[...];
	strcpy (s, (char *) x);
}

=================================================================
Rusty Fleming, Software Consultant @ Tandem Computers Inc.
email: rjf@mpd.tandem.com            Austin, Texas
voice: (512) 244 - 8390              USA
Newsgroups: comp.lang.c++
From: samk@microsoft.com (Sam Kho)
Subject: Re: Access non-static data members in Motif callback functions.
Date: 23 Dec 92 23:23:05 GMT
Organization: Microsoft Corporation
Distribution: global

In article <1992Dec21.144344.21100@asl.dl.nec.com> jng@aslslc71.asl.dl.nec.com (James Ng) writes:
>
>We use X11/R4 and Motif 1.1 for our GUI development. Our C++ compiler is
>Object Center C++ (formerly called Saber C++). When we try to use a
>non-static member function as a callback, sometimes nonstatic data members
>get corrupted inside the callback function. Static data members seem to
>maintain their integrity. Does anyone have similar experience or even
>solution to solve the above problem? Any suggestion will be appreciated.
>Suggestion can be mailed to jng@asl.dl.nec.com or posted if you prefer.
>
>James Ng

static data members r like global variables.  "this" is irrelevant.  non-
static data members r like fields in a struct, where "this" is the pointer
to the struct.  in a non-static member function, "this" is assumed to be
the first hidden parameter, i.e.:

	class myclass
	{
	public:
		void nonstatic	(int x);
	};

is like:

	void myclass_nonstatic(myclass *this, int x);

now when Xt calls the callback, the first argument passed is the widget.
my guess is u'r using the widget as "this"!  i'm surprised u'r even able
to get non-corrupted values (probably that offset in the widget just happens
to have the right value).

to verify, cast this into a widget inside the non-static member function,
and do something with it (e.g. if it's a callback to a PushButton, change
the label).

  - sam -

Newsgroups: comp.lang.c++
From: giangd@gocart.eng.hou.compaq.com (Giang Dao)
Subject: class forward ref. in C++
Organization: Compaq Computer Corporation
Date: Thu, 31 Dec 1992 20:13:40 GMT

Dear C++ gurus,
I have the following question :

class A
  {
   ...
   B * bptr;
   ...
  }

class B
  {
   ...
   A * aptr;
   ...
  }

The C++ compiler doesnot allow this since B is not defined
yet in class A definition and B can not be defined first
since A is not defined yet. I can use void * instead and
overcast the type but this is really inconvenient. Worse,
 I have members in A and B that have same names.
This would result in no compilation errors if I typecast the
wrong class. Any work-around without using void * and declare
different member's names in A and B. I use the MS C++ compiler.
Could some body try it on BC++ ? 
Theoretical this should be possible since aptr and bptr are
just address holders and not depending on the structture of
A or B.
Thanks,
Newsgroups: comp.lang.c++
From: tongb@woods.ulowell.edu
Subject: Piping and return code
Organization: University of Lowell
Date: Thu, 31 Dec 1992 00:00:28 GMT

 
Hello,
 
      Does any one know how to put redirect output and get return code in C ?
 
      I am having a small problem to solve but searching through all
the C books I cannot find any information mention how to make redirect
and get a return code within a C program.
      The problem is my C program will run an external DOS program
which accept only input from standart input.  (The Novell LOGIN.EXE file).
This can be done by using piping at DOS prompt.
In turn, I have to be able to obtain the return code from the LOGIN
program.  I had tried several approaches but none of them solved the
problem.
 
1.  Use the EXEC or SPAWN function
    Using these functions I was not be able to pass the password to the
program.  However I will be able to obtained the return code form
LOGIN program.
 
2.  Use the SYSTEM function
 
    E.g.  system("command.com /c echo password|login server/username");
 
    By using this function I was able to pass the password to the
LOGIN program with piping but the program will return zero if the program
executed sucessfully, the return code from the LOGIN.EXE was lost.
 
    Another requirement is this C program should not display any
output to console.
 
Is there any solution ?  Please help!
 
Binh Tong   (tongb@woods.ulowell.edu).
 
 














Newsgroups: comp.lang.c++
From: aaa@hpuerca.atl.hp.com (Simon Fowler)
Subject: Re: Bug in BC/C++ 2.0 ?
Date: Thu, 24 Dec 1992 15:41:45 GMT
Organization: Hewlett-Packard Company, Atlanta GA
Keywords: bugs

In article <1992Dec23.202206.29576@microsoft.com>, pauljo@microsoft.com (Paul Johns) writes:
> What's happening here is that the rules in C++ changed
> AFTER the Borland 2.0 compiler was written.
> 
> In the old (before AT&T 2.1, I believe) days, you had
> to specify the size of the array you were deleting.
> And you had to get it right.  The old Borland compiler
> is compatible with this old rule.

As is the Zortech compiler for OS/2 1.3.

> 1.  Upgrade your compiler to one that's AT&T 2.1-compliant.
> 	I think you should consider Microsoft C++, but I
> 	work for Microsoft and own Microsoft stock, so I
> 	have a clear bias.  :)

Not much alternative for OS/2 1.3

> 2.  Put the size in the delete.  This is upwards-compatible:
> 	it's ignored in AT&T 2.1 and 3.0.  This can be a little
> 	bit of a pain, but it's probably cheaper than upgrading.

Not ignored in IBMC++

simon