HDTenEightyP/NetNews huggingface dataset:
From: nicholas@iti.gov.sg (Nicholas Tan)
Subject: pointer to constant object violation
Originator: nicholas@helios.iti.gov.sg
Organization: Information Technology Institute, National Computer Board, S'pore
Date: Sat, 15 Aug 1992 05:39:26 GMT


I have come across something that puzzles me.  My test program below has a class
String which has a member function that returns a pointer to a constant string.
However, if I use a typedef rather than a #define for STR, different behaviour is
observed.  Using a typedef, I can compile, link, and run using Borland C++ 3.0,
g++ 2.2.2, and Sun CC 2.?.  The result is that the 4th character is modified to
a 'Z'.  If I use a #define, g++ 2.2.2 gives a warning, "assignment of read-only
location", and produces an executable that behaves as previously.  However, both
Sun CC 2.? and Borland C++ 3.0 produces an error during compilation.

I thought a typedef was just a synonym for another type, it does not introduce
a new type.  Also, does a compiler need to see a '*' character in order to flag
pointer to constant object violation?  Can someone tell me whether what
happens is or is not correct C++?

Thanks.


--------------------------------------------------------------------------


#include <iostream.h>
#include <string.h>


typedef char*		STR;
//#define STR		char*


class String
{
	private:
		STR str;

	public:
		String(STR = "");
		const STR value() const;
};


String::String(STR str)
{
	unsigned int len = strlen(str);
	this->str = new char[len+1];
	strcpy(this->str, str);
}


const STR String::value() const
{
	return this->str;
}


int main(int, char* [])
{
	String s1("Hello World");
	cout << s1.value() << "\n";
	(s1.value())[3] = 'Z';
	cout << s1.value() << "\n";

	return 0;
}
Newsgroups: comp.lang.c++
From: myerse@spot.Colorado.EDU (MYERS ETHELLA ANN)
Subject: C++ compilers for Unix
Followup-To: comp.lang.c++
Organization: University of Colorado, Boulder
Date: Thu, 20 Aug 1992 17:54:23 GMT

   I am looking for a C++ compiler for my Sun.  I checked out the
FAQ, but it's a little skimpy on compiler info. I've been told that
while the price is right for GNU C++, it is too much of a headache to
install and maintain.  I've been looking into Glockenspiel and Saber/
ObjectCenter, and Sun C++.  Does anyone have any experience with or
info about these compilers?

  I am just looking for a compiler and a debugger.  I don't need
and probably don't want a work bench or developer's environment.

Thanks,
-Ann
   
****************************************************************************
Ethella Ann Myers          E-mail: eam9e@paleosun.ngdc.noaa.gov
Phone: (303) 497-6467
****************************************************************************
Paraphrased from "Global Village News" from Nickelodeon:
The Government just announced today the creation of the Neutron Bomb II.
Similar to the Neutron Bomb, the Neutron Bomb II not only kills people
and leaves buildings standing, but also does a little light housekeeping.
****************************************************************************
    "Some people say that I must be a horrible person, but that's not
     true.  I have the heart of a young boy -- in a jar on my desk."
                                        -- Steven King, 3/8/90
***************************************************************************
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Downcasting (was: Re: run-time type checking)
Date: 18 Aug 92 18:02:01 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: In article <4823@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
: >: >maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: >: >:
: >: >:	class Base { //....
: >: 		virtual operator Derived1*() { return 0; }
: >: 		virtual operator Derived2*() { return 0; }
: >: >:	};
[...]
: >	I agree that unrestricted typecasting provides the ability to
: >	cleanly extend the interface of a base class, into the interface
: >	of any derived class.  Although I admit that in a way this does
: >	break the "closedness" of the Base class interface, I don't think
: >	it does so in a "bad" way.
: 
: 	This is the issue. You might be right, but I'm not convinced.
: In a statically secure system, I argue that it is important to access
: an object only by its explicitly declared accessible interface.

****	I think _that_ is the issue.  I'd say a system can be statically
	secure, even if it does (undeclared) runtime-checked down-casts
	(that is, if the program only does the down-casts when possible).
	I think we agree on the need to sometimes do controlled downcasts.

	I also admit that when you see a need for a downcast, you should
	ask yourself why you have lost track of the type of the object,
	and change the code to avoid it, if possible.  Downcasting is a
	last resort.  Yes, I use GOTOs too (in the form of break/continue
	statements).

	You may argue that the system is easier to _maintain_ by making the
	possible down-casts visible in the base class, and I would agree.

: >
: >	The importance is that in neither case do you have to
: >	intervene with the source or compiled code of the base
: >	class to do what you want.  This is considered good
: >	for behaviour (overriding virtuals), so why not also
: >	for interfaces (unrestricted but safe downcasting)?
: 
: 	It is sound for virtuals because they are declared!

****	But not in the base class!  You can't find out which
	derived classes override a virtual by inspecting the
	base class.

: >	A base class intended for future inheritance (even by
: >	other programmers) should support overriding behaviour
: >	using virtual member functions, and should support
: >	interface extension by runtime-checked, safe downcasting.
: >
: >	This lessens the risk that future users without access to the
: >	source code will get stuck when deriving from the base class.
: 
: The point of polymorphism is that
: your should not rely on derived class behaviour in routines
: given a base object, and you shouldn't need to.

****	But you do, since any derived class may have an
	incorrect implementation of a virtual method.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| jbn@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490              |
--------------------------------------------------------------------------
From: stevep@ims.com (Steve Poulsen)
Subject: Re: Looking for C++ Guidelines/Standards
Organization: Integrated Measurement Systems, Inc.
Date: Thu, 20 Aug 1992 15:08:05 GMT

In article <1992Aug19.163002.10065@access.usask.ca>, long@skorpio.usask.ca (Sed's Warren Long) writes:
|> There is a good book called "C Programming Guidelines" by        
|> Thomas Plum which describes style and standards when 
|> programming in C.
|> Is there something similar for C++ ?

I will assume you are familiar with "The C++ Programming Language, Second Ed."
by Stroustrup.  Check out "C++ Programming Style" by Tom Cargill.  It's part
of the Addison-Wesley Professional Computing Series.

-Steve-

--
Steve Poulsen, Integrated Measurement Systems, Inc.  Beaverton, OR  USA
Voice: 503-626-7117   Fax: 503-644-6969   Fidonet: 1:105/31.6
INTERNET: stevep@ims.com   Compuserve: [70262,3115]
From: groo@chsdip.wisdom.bubble.org (Bill Squier)
Newsgroups: comp.lang.c++
Subject: Re: Finding runtime Null ptr assignments
Date: 11 Aug 92 18:41:42 GMT
Organization: Dragonsoft Development
X-Newsreader: Arn V1.00 beta rel2

In article <BsJI3x.Lqp@news.cso.uiuc.edu>, Scott Brown writes:

> Using Borland's 3.0 compiler I have been getting a 
> null pointer assignment error at run-time with a program
> I'm working on.  Any hints as to how I might find out
> why this is? [...]

The easiest way to track down NULL pointer assignments in
Turbo Debugger (and any debugger that supports memory-watch
breakpoints) is to set a break point that watches location 0 as a
long.  As soon as one of those bytes is changed, the debugger will
position you on the statement that caused the problem.

With TD, the appropriate command is in the _W_atch menu (I believe).

----------------------------------------------------------------------
"Stimpy, sometimes your wealth of ignorance astounds me." -ren hoek
Bill Squier (groo@chsdip.wisdom.bubble.org) MetaMail capable
From: rogers@eagle (Bill Rogers)
Newsgroups: comp.lang.c++
Subject: Help? TV streamable obj creation
Date: 19 Aug 92 19:56:48 GMT
Article-I.D.: news.Bt8y2q.DtJ
Organization: Sangamon State University
X-Newsreader: Tin 1.1 PL4



--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<> Bill Rogers, Assistant Director for Academic Computing Services          <>
<>              Sangamon State University, HSB-115                          <>
<>              Springfield, Il 62794-9243     fax:217-786-7188             <>  
<> Internet:rogers@eagle.sangamon.edu        voice:217-786-7352(Mon.->Thur.)<>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Garbage Collection for C++
Organization: :
Date: Fri, 21 Aug 1992 08:28:40 GMT

In article <DAVEG.92Aug20043156@synaptx.synaptics.com>, daveg@synaptics.com (Dave Gillespie) writes:
> In article <1992Aug19.180252.12942@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
 
> >>   Is there really so much harm in allowing the C++ runtime
> >>   system to delete the object in that circumstance?
> 
> > You've answered your own question in the negative.  If the destructor
> > has an effect on the program's output, and it is accidentally called
> > by the GC instead of by its proper deletion, the program's output will
> > depend on the exact properties of the GC system and ...
 
> Sorry, I didn't make myself clear.  I realize that allowing GC to call
> a destructor would add one more case where destructors with side effects
> could surprise the C++ programmer.  My question was, is that potential
> for surprise enough to kill the idea of garbage collection in C++?
 
> My answer is no, it just means C++ programmers who use garbage collection
> have to be a little careful about what they put in their destructors.

`A little careful about what they put in their destructors.'
(Picture this said with dripping, oozing sarcasm.)

If you look at where OOA and OOD are going, and what they are talking
about, you may observe that they talk about things called `relationships.'
These relationships have something called `cardinality,' and they describe
what does and does not exist--and in the better models, when.

To model these OOA and OOD things in OOP (as we should) we have to control
what does and does not exist--or we have to fake it by introducing an
indirect representation of Object existance.

I've neither seen nor heard a proposal for a workable, maintainable,
practical, economical way of representing Object existance--other than
object existance.  (Note the difference in capitalization, please.)

It is this that underlies almost all of the problems with databases
and persistance.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: boehm@parc.xerox.com (Hans Boehm)
Subject: Re: Garbage Collection for C++
Organization: Xerox PARC
Date: 21 Aug 92 15:22:26 GMT

jimad@microsoft.com (Jim Adcock) writes:
>In generation schemes, both long-lived and short-lived objects have
>allocation and deallocations costs that are very very small -- IE "0"
>There are significant allocation and deallocation costs only for object
>that fall in between these two extremes -- objects that live to be middle
>aged.  And the cost of these objects is not really the cost of allocating
>or deallocating them, but rather the cost of keeping them young.

Could you clarify your accounting for long-lived objects here?  Are you
assuming that you know at allocation time that the object will be
permanent?  Otherwise it must be copied at least once out of the youngest
generation.  That's certainly nonzero cost.  Furthermore, it will probably
be copied (or traced) several more times as the result of full collections.
(If I don't know that all my objects are essentially permanent, and I
see my heap growing, I presumably have to initiate full collections
occasionally.)  In addition to this, I need some way of tracking
pointer stores into the old object.  I would claim that all of this adds
up to significantly more than malloc/free time for the object.

Generational (esp. copying) collectors win dramatically on short-lived
objects, provided you have some efficient way of tracking stores
into old objects.  Fortunately most objects fall into this category
for most programs.

(Ben Zorn has some measurements that substantiate this for some
interesting C programs.  It is clearly the case for all known
Lisp and Smalltalk implementations.)

A generational copying collector is probably the worst possible choice if
all your program allocates are large long-lived bitmaps  (and indeed
generational copying collectors usually treat such things as a special
case).

Hans-J. Boehm
(boehm@parc.xerox.com)
Newsgroups: comp.lang.c++,comp.std.c++
From: dan@BofA.com (Dan Brockman)
Subject: Re: run-time type checking, freezing, and thawing
Organization: Bank of America, Capital Products, RMTG #5906
Date: Wed, 19 Aug 92 01:25:44 GMT

In article <l7u53jINN17a@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
>Assertions of Turing equivalence are not very interesting.  Stopwatch
>benchmarks of program speed and programmer speed are where it is at.
>Do what makes you more productive.

Any good empirical evidence available regarding the productivity 
of C++ versus, say, C ?  In practical commercial environments?

-- 
 ------------------------------------------------------
 Daniel Brockman                       tel 415-953-0406, fax 415-622-2892
 Bank of America, Dept 5906, 555 Calif St
 San Francisco 94104 USA              email uunet!odinba!dan dan@BofA.COM
From: victor@watson.ibm.com (Victor Miller)
Newsgroups: comp.lang.c++
Subject: intelligent generation of template instances
Date: 19 Aug 92 20:33:24 GMT
Reply-To: victor@watson.ibm.com
Organization: IBM, T.J. Watson Research Center
Disclaimer: This posting represents the poster's views, not necessarily those of IBM

Suppose that I have a template class (taken from the FAQ):

	 template<class T>
	 class Vec {
	   int  xlen;
	   T*   xdata;
	   int  check(int i) const;
	 public:
	   int len() const {
	     return xlen;
	   }
	   const T&  operator[](int i) const {
	     return xdata[check(i)];
	   }
	   T&  operator[](int i) {
	     return xdata[check(i)];
	   }
	   Vec(int L=10) :
	   xlen(L),
	   xdata(new T[L]) {
	     /*verify*/
	   }
	   ~Vec() {
	     delete [] xdata;
	   }
	 };

If I have the actual definintion of check in a separate file.  It
appears that I need to manually instantiate each instance that I use.
Is there any sort of hack which would allow automatic generation of
all such instances after looking at the results of compilations?

For instance after a lot of programs use the Vec class, it would be
nice if a post-processor could determine that the instances (for
example) of Vec<int>, Vec<float> and Vec<char *> where used, and
compile them (sounds like a job for a makefile)?  Does anyone know of
such a program (say on Unix)?


--
		Victor S. Miller
		Bitnet: VICTOR at WATSON
		Internet: victor@watson.ibm.com
		IBM, TJ Watson Research Center
		"Great artists steal; lesser artists borrow" Igor Stravinsky
From: ajb@winton.uucp (Arthur J. Butler)
Newsgroups: comp.lang.c++
Subject: Re: Allocating arrays larger than 64K with new?
Date: 13 Aug 92 14:26:41 GMT
Organization: Worcester Polytechnic Institute, MA

In article <f94m37_.feustel@netcom.com> feustel@netcom.com (David Feustel) writes:
>The following program compiles and links successfully with the ZTC
>-mx option. Running the program crashes the system. The program was
>linked and run under Flashtek's x32 dos extender.
>
>==============
>
>#include <stdio.h>
>
>#define AS 3000000
>
>long * getspace(unsigned int amount)
>{	long * a;
>	printf("malloc %d ",amount);
>	if(a=(long *) malloc(sizeof(long)*amount))
>	{	printf("succeeded\n");
>
>	else
>
>	{	printf("failed\n");
>
>	}
>
>	return a;
>
>}
>
>	
>
> 
>
>void main(int argc,char **argv)
>
>{	long i,imax=AS;
>
>	double sum=0;
>
>	long *a, *b, *c;
>
>	printf("Hello, World\n");
>
>	for(i=0;i<argc;++i)
>
>	{	printf("%s\n",argv[i]);
>
>	}
>
>	a=getspace(AS);
>
>	b=getspace(AS);
>
>	c=getspace(AS);
>
>	if (a==0|b==0|c==0) exit(-1);
>
>	for(i=0;i<imax;++i)
>
>	{	
>
>		a[i]=i*i;
>
>		b[i]=i;
>
>		c[i]=i*i*i;
>
>		sum+=a[i]+b[i]+c[i];
>
>	}
>
>	free(a); free(b); free(c);
>
>	printf("sum: %e\n",sum);
>
>	exit(0);
>
>}
>
>
>-- 
>Dave Feustel N9MYI <feustel@netcom.com>
>---
>Given Civil Seizure, from the DEA's point of view, winning the War on
>Drugs would be killing the Goose that lays golden eggs.


I just compiled this using Zortech and linking with x32v.lib.  I
compiled it both as a C program and as a C++ program (minor note: i had to
include stdlib.h).  I sucessfully ran it on my 486 with 8 meg of
memory and about 80 meg of free disk space.  You are allocating three
chunks of 12 Mbytes each.

I believe your problem is that you compiled the program in small
memory model and not X memory model.  It will link with x32 and not
complain at all.  I did that by mistake and indeed running the program
halted the system.

arthur (ajb@winton.wpi.edu)
From: Bharathi@Cedar.Buffalo.Edu
Newsgroups: comp.lang.c++
Subject: Can someone post the FAQ on c++
Date: 20 Aug 92 21:11:28 GMT
Reply-To: Bharathi@Cedar.Buffalo.Edu
Organization: CEDAR Research Group / Dept. of Comp.Sc. SUNY - Buffalo
Originator: bharathi@sheliak.cs.buffalo.edu


Is there a ftp-site for the FAQ?  Thanks..

Chandra
Newsgroups: comp.lang.c++,comp.object,comp.databases
From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Re: A POET Tutorial
Organization: netmbx, Berlin, Germany
Date: Thu, 13 Aug 1992 07:28:44 GMT
Keywords: OODBMS, C++, POET

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

>I have a couple of questions regarding Jonathan Robie's posting:

>----------------------------------------------------------------------

>>    main ()
>>    {
>>      PtBase    objbase;
>>    
>>      objbase.Connect ("LOCAL");    // Connect to the server
>>      objbase.Open ("test");        // Open the database
>>
>>      Person    *man = new Person(objbase);
>>      man->Store();
>>    
>>      objbase.Close();    
>>      objbase.DisConnect();
>>      delete man;
>>    }

>Why aren't Close() and DisConnect() automatically called by the
>destructor?

Each of these returns error codes which the programmer might want
to test and respond to.

>----------------------------------------------------------------------

>>    PersonAllSet*    allPersons = new PersonAllSet("objbase");
>>    Person*    thisPerson;
>>
>>    allPersons->Seek(0, PtSTART);
>>    while (allPersons->Seek (1, PtCURRENT) == 0)
>>    {
>>    allPersons->Get(thisPerson);
>>    thisPerson->DoSomething();
>>    allPersons->Unget(thisPerson); // deletes the object if nobody 
>>                                  // else is using it.
>>    }
>>    delete allPersons;
>>
>>[...]
>>Note that we call Unget() when we are done with the object.  Every 
>>object you read takes up memory, so you should get into this habit.

>Again, weren't destructors invented so that we wouldn't have to rely
>on programmers habits?

What destructors are you talking about?  The destructor for allPersons
is not a good candidate, since it may sit around for a long time
creating objects that you really don't want to keep in memory until
the set is deleted, and using this destructor would make us keep
track of all loaded objects in the allPersons set.

The destructor for the object is also not a great candidate since
it depends on programmer's habits just as much as the Unget() and
has different semantics.


>Also, is there any particular reason why allPersons is dynamically
>allocated in this example? Wouldn't it be simpler and more efficient
>to just use a local (automatic) variable?

No particular reason...it all depends on how you are using it.


Jonathan

=======================================================================

Jonathan Robie		jrobie@netmbx.UUCP
Arnold-Zweig-Str. 44	jrobie@netmbx.in-berlin.de
O-1100 Berlin		
Deutschland		Phone:  +37 (2) 472 04 19  (Home, East Berlin)
				+49 (30) 342 30 66 (Work, West Berlin)


-- 
Jonathan

===========================================================================
From: twbrown@PE-Nelson.COM (Tom W. Brown)
Newsgroups: comp.lang.c++
Subject: Re: Dumb questions about Borland C++
Date: 13 Aug 92 22:57:54 GMT
Organization: PE-Nelson

In article <1992Aug13.152405.16170@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> In article <q!3m8wf.sjk@netcom.com> sjk@netcom.com (Shel Kaphan) writes:
|> >I've been trying to port some programs written for a Unix C compiler
|> >to Borland C/C++, and have a few questions:
|> >
|> >- How do you add an assembly language file to a project in the Windows
|> >IDE ("Integrated Development Environment")?  I tried to do the obvious
|> >thing, and it claims to have successfully "compiled" the assembly
|> >files, but it turns out it didn't do anything.
|> 
|> 	Just add the file to the project. Must have .ASM extension.
|> Never tried it but it should work. Otherwise you can configure
|> the project to specifically invole the assembler.

No, the Windows hosted IDE (BCW.EXE) is still brain-dead in version 3.1 and
doesn't have the Transfer Options capability of the DOS hosted version.  Only
.C (.CPP) and .RC files can be compiled.  You can, however, put the .OBJ's
in the project as long as you assemble them separately.


|> >
|> >- Is there a way to view the 386 registers in the debugger?  I mean
|> >those registers not already present in the 286 and 8086.
|> 
|> 	No because they are not used.

Yes you can, sort of...  bring up the Register window (View|Registers) or 
activate the register subwindow of the CPU view (View|CPU) and press CTRL-R to
toggle between 32 and 16 bit views of the registers.  In 32 bit mode the
additional segment registers FS and GS are displayed.  Note, however, that
you do not get a view of any of the real funky control registers like the
GDTR, LDTR, etc.


|> >
|> >- Isn't there some way to tell it that you want "int" and "unsigned int"
|> >to be 32 bits?   (just wishful thinking).
|> 
|> 	#define long int :-)

:-O
    you mean, #define int long, right ;-)

|> 
|> >
|> >- Is there no memory model on the PC in which the stack can occupy
|> >more than 64K bytes?  (more wishful thinking, I know ... don't flame me.) 
|> >Don't ask why I care.
|> 
|> 	No. Its only a 16 bit machine. And the 386 still
|> runs 16 bit operating systems.

Wait for NT and then wait for Borland to release their compiler support for
it (better get a deck of cards or something while you're waiting :-)


----------------------------------------------------------------------------
Tom Brown               |  "Strange women, laying in ponds, distributing
PE Nelson Systems       |   swords is no basis for a system of government."
twbrown@pe-nelson.com   |                    Monty Python and the Holy Grail
----------------------------------------------------------------------------
Newsgroups: comp.lang.c++