HDTenEightyP/NetNews huggingface dataset:
From: niklas@appli.se (Niklas Hallqvist)
Newsgroups: comp.lang.c++,comp.object,comp.databases
Subject: Re: A POET Tutorial
Keywords: OODBMS, C++, POET
Date: 14 Aug 92 07:44:36 GMT
Followup-To: comp.lang.c++
Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN

jrobie@netmbx.netmbx.de (Jonathan Robie) writes:

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

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

>>>      objbase.Close();    
>>>      objbase.DisConnect();

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

It's true that you should provide means for a user to intercept errors
but making resource deallocation explicit just for this may introduce
errors instead.  The programmer might easily forget such a deallocation.
Studies have shown that almost all non-trivial programs developped without
a debugging malloc leaks memory, so it's not an uncommon error.  How should
it be done then?  Well, one way is to do what Bjarne did with "new",
introduce an error_handler pointer which the user can direct to his own code,
another will be: use exceptions.  But beware... the latter can really
surprise you in destructor contexts like these.  I'd go for the error_handler
to start with.

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

I think he was thinking of an auxiliary resource allocator object.
Something along the lines:

class PersonMapper {
  PersonAllSet* s;
  Person* p;
public:
  PersonMapper(PersonAllSet* a_s, Person* a_p) : s(a_s), p(a_p)
    { s->Get(p); }
  ~PersonMapper()
    { s->UnGet(p); }
};

Then the loop may look like:

while (allPersons->Seek (1, PtCURRENT) == 0)
{
  PersonMapper pmap(allPersons, thisPerson);
  thisPerson->DoSomething();
}

Comments?

Niklas
-- 
Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!seunet!appli!niklas
From: dag@control.lth.se (Dag Bruck)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 19 Aug 92 11:18:36 GMT
Organization: Department of Automatic Control, Lund, Sweden

In <comp.lang.c++> tmb@idiap.ch writes:
>The properties of temporaries are no different (and no worse) than the
>properties of automatic variables: pointers to them become invalid
>when the object disappears.

I think there is a major difference.  The programmer controls the
scope of automatic variables and hence their lifetime.  Temporaries
are created by the compiler (possibly because of ill-advised
programming techniques) and the programmer has no control over their
lifetime.

The language does not specify under what circumstances temporaries are
created, and I'm willing to accept that, but it should at least
specify their lifetime in expressions that potentially create
temporaries.

Given the deliberations for and against different models [no details
given] I would probably prefer destruction at greatest enclosing
expression, with the additional constraint that temporaries created in
one "arm" of a conditional expression are destroyed at the end of that
conditional expression.

With respect to difficulty of implementation, in particular combined
with exception handling, it would probably pay off to look at existing
implementations (I can think of HP and IBM) before making any judgements.
Newsgroups: comp.lang.c++
From: schnitzi@cs.ucf.edu (Mark Schnitzius)
Subject: Simple inheritance question
Organization: University of Central Florida
Distribution: comp
Date: Tue, 18 Aug 1992 12:39:37 GMT

Is there any way to access the variable 'hold' in
this example with only a pointer to the base class?

class base {};

class derived: public base {
	int hold;
};

main ()
{
	derived d;
	base *p;

	p = &d;

	cout << p->hold;  //DOESN'T WORK!
}

-----
Mark Schnitzius
schnitzi@eola.cs.ucf.edu
Univ. of Central Florida
Organization: Johannes Kepler University Linz - Computing Center
Date: Monday, 17 Aug 1992 14:12:40 CDT
From: <K3006E7@ALIJKU11.BITNET>
Newsgroups: comp.lang.c++
Subject: Que: Double-Precision Complex Arrays

I am new to C++, so please forgive me if these questions are
irritatingly elementary.  But if anyone would offer suggestions
or answers, I would greatly appreciate it!

1) In my program, I have included <complex.h> that comes with
the C++ package.  But when I try to create an array of complex
numbers, the compiler issues an error.  How does one declare a
complex array?

static complex array_name[2][2];

doesn't work, for example.

2) How does one declare double precision complex numbers?  And
double precision complex arrays?  Does one have to fiddle with
the complex.h file itself in order to get double precision?

Any help would be really appreciated.  Thanks, Myron Seto
Newsgroups: comp.lang.c++
From: mendell@turing.toronto.edu (Mark Mendell)
Subject: Re: C++ 3.0 and exceptions
Organization: IBM Toronto Lab
Date: 23 Aug 92 01:54:06 GMT

C++ assumes that any types with the same name are the same type, even across
separate compilation.  Therefore, it is only necessary to match types by name.
THe compiler always knows the name of the objects being thrown, and those being
caught.  It is necessary to do some runtime matching, but only on the names.

-- 
Mark Mendell
IBM Toronto Lab
mendell@torolab6.vnet.ibm.com
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 20 Aug 92 11:53:42 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

ark@alice.att.com (Andrew Koenig) writes:
: 
: Three reasons:
: 
: 	2. Even if you don't want to handle things like the above, you
: 	   would still need flags that correspond to temporaries created
: 	   conditionally, particular in ?: expressions.  These flags
: 	   can potentially impose significant overhead even on people who
: 	   don't care about when the temporaries are destroyed.

As Dag Bruck said in another posting, conditionals could be
given special status, i.e. early destruction always allowed
in conditionals.  Conditionals suck anyway, don't they?

: 
: 	3. I have heard comments from users who really want temporaries
: 	   cleaned up early if possible.  Typically they are using linear
: 	   algrbra packages and write things like this:
: 
: 		Matrix D = A * B * C;
: 	   
: 	   and do not want the intermediate result A * B to hang around
: 	   until the end of the block.

But isn't that a "quality of implementation" issue?

A good compiler should have an option "-Oearly_destroy" to
be used by knowledgeable programmers.  As with some other kinds
of optimizations, this one cannot be guaranteed to be safe for
all code, so must be used with discretion.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| jbn@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490              |
--------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: jkokko@vipunen.hut.fi (Jari Kokko)
Subject: Re: Borland C++ 3.0: Using ifstream
Summary: Thank you
Keywords: Problem was
Reply-To: jkokko@vipunen.hut.fi (Jari Kokko)
Organization: Helsinki University of Technology
Date: Mon, 17 Aug 1992 07:41:10 GMT

jkokko@lesti.hut.fi (Jari Kokko) wrote:
//Any help is welcome, reply by email, I'll post the answers I get when
//I get this to work.

Well, here it is. I got many replys that were of help.
Particularly Anto hit the nail:

//  inFile.open("file.txt");
//  // Linker Error:
//  // Undef'd symbol fstreambase::open(const unsigned char far*,int,int)
                                              ^^^^^^^^ 
Anto: By any chance did you set the option to use unsigned char? If
yes, that may be the problem. Try it with default setting (signed
chars).
When you've been staring at something for hours, you don't notice the
simplest errors. UNSIGNED is the key. I had put on option [X] Unsigned
chars (why, don't ask!), and there isn't a constructor for that in
fstream.h. After taking out the X from there everything was peachy.

Dan points out:
Then , you can't "cout << inFile" (without overloading "<<").  That is
like saying "cout << stdin".  inFile is a stream, and there is no
difference (in handling) between inFile and, say, cout.  You would
have to do this: cout << file.rdbuf();

Thanks for these as well.

//I'm sure this is a problem with some silly option
I could say that again,

-- 
//jkokko // Email: Jari.Kokko@hut.fi \\ (358)(0) 8794431 \\
------------------------------------------------------------
From: rgp@mpd.tandem.com (Ramon Pantin)
Newsgroups: comp.lang.c++
Subject: Re: Return value for the constructors.
Date: 20 Aug 92 05:47:12 GMT
Distribution: usa
Organization: Tandem Computers, Micro-Products Division

In article <1992Aug19.231926.28218@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
>In <1992Aug19.175852.38459@watson.ibm.com> mittle@watson.ibm.com (Josh Mittleman) writes:
>
>>pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
>
>>Sure there is: Overload operator new().  For example, give your class a
>>static status flag.  operator new() sets it to 1, then calls ::new() to
>>allocate the object.  Your constructors make whatever internal checks they
>>need, and set status to 0 if there is a problem.  Then, operator new()
>>returns a pointer to the new object or 0, depending on the success of the
>>process.  From the users point-of-view, it simply looks like a normal call
>>to new().
>
>*****>	Clever...but it's not reentrant.

Paul, that is a moot point given that the object might not always be
created thru new.  All the flag setting/checking by Josh's overloaded
new ends up being ignored for automatic objects (i.e. local variables).
The fact that an object wants to allocate memory thru new for its internal
use doesn't imply that the object itself will always be created thru new.
Similar arguments can be made for arrays of objects allocated thru new
where the overloaded new does not end up being called (if I'm not
mistaken).

I have seen error codes being "returned" (ok, not "return" returned,
but set thru a pointer) by constructors by passing the address of an
integer to the constructor with the subsequent tests of this variable.  
I don't like this alternative very much because the object also
needs to remember in most cases if he is ok or not so that its desctruction
can act accordingly (in which case an "I'm ok" method could be provided
just as easily).

Ramon Pantin
Newsgroups: comp.lang.c++
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: destruction of temporaries
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Fri, 21 Aug 92 15:07:11 GMT

swillden@news.ccutah.edu (Shawn Willden) writes:
: : 
: : >
: : >The properties of temporaries are no different (and no worse) than the
: : >properties of automatic variables: pointers to them become invalid
: : >when the object disappears.

[ Text of accidental post deleted...]

Uh, oops.  Sorry, I never realized how close together the 'p' (post) and 'q' 
(quit) keys are... :-)

: --
: Shawn Willden
: swillden@icarus.weber.edu

--
Shawn Willden
swillden@icarus.weber.edu
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Return value for the constructors.
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 20 Aug 1992 14:26:44 GMT

In article <3462@unisql.UUCP> nandraj@unisql.UUCP (Nandraj Arni) writes:
>
>   Why does C++ not let you have a return value for a constructor?
>Is there any rationale behind this?
>

	The simplest reason is

	Object a=Object(1,2);

where the 'return value' of Object(1,2) could not be syntactically
distingusied from its role returning an object (well, actually,
being an object).

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: T.D.G.Sandford@bradford.ac.uk (TDG SANDFORD)
Newsgroups: comp.lang.c++
Subject: (SUMMARY - no replies!) INDENT for C++ ?
Date: 20 Aug 92 14:12:02 GMT
Organization: University of Bradford, UK
Originator: 90908106@ccw303

In article <1992Aug11.145758.15266@bradford.ac.uk> I wrote:
>Is there a version of the (Unix) indent program which will work on C++
>programs. The versions I've used all work only on std. C, and get upset
>by certain C++ syntax (especially // comments)
>
>I am particularly interested in MSDOS versions, but Unix source would
>probably do (eg GNU).
>
>Reply by e-mail if possible, I will post a summary in about a week's time.
>--
I got no replies, so I guess the answer to my original question was no :-(
---
Thomas Sandford | t.d.g.sandford@bradford.ac.uk
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 20 Aug 92 13:37:43 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

jbn@lulea.trab.se (Silly Me) wrote:
: 
: Conditionals suck anyway, don't they?

I apologize for this stupid remark.  My fingers thought about
the trinary operator (?:), and before my brain was able to stop
them the article had been posted.

Flame me, I deserve it.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| jbn@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490              |
--------------------------------------------------------------------------
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 19 Aug 92 15:00:16 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

jimad@microsoft.com (Jim Adcock) writes:
: In article <46140@sunquest.UUCP> bill@sunquest.UUCP (Bill Raves) writes:
: |For example, Jim Adcock has suggested
: |(<70784@microsoft.UUCP>) "NEVER rely on unnamed temporaries to do
: |anything...", but this would seem to erode the expressiveness of the
: |language: constructs like "foo(x + y)" and "foo()[i]" would no longer
: |be permissible. 
: 
: When an unnamed temporary is assigned to a reference, then the unnamed
: temporary is no longer unnamed.  I believe this should mean that the lifetime
: of the temporary then becomes that of the reference, but its easy to find
: lots of compilers that disagree with this.

I thought the ARM was explicit about binding a reference to a temporary,
that the temporary may not be destroyed until the reference is?

Yes, there it is, on page 268.  This then means that "lots of
compilers" are broken, no?

Neither g++ version 1.40.3 nor Sun C++ 2.1 seems to do this.

Below is a small program that tries to test this, for a simple
case.  Are there compilers that produce output with this program?

//------------------------------------------------------------
#include <stream.h>

class C { public:
   int cookie;
   C() { cookie = 12345; }
   ~C() { cookie = 0; }
   static C temp();
};

C C::temp()
{ C c; return c; }

void f( const C& c )
{ if ( c.cookie != 12345 ) cerr << "The compiler is broken\n"; }

int main() {
   f( C::temp() );  // Sun C++ 2.1 warns here, why?
   const C& cr = C::temp();
   f( cr );
   return 0;
}
//------------------------------------------------------------

Anyone have an idea why Sun C++ 2.1 doesn't like "f( C::temp() );"?
"warning:  initializer for non-const reference not an lvalue (anachronism)"

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| jbn@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490              |
--------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Garbage Collection for C++
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 13 Aug 1992 15:17:49 GMT

In article <3907@starlab.UUCP> mi@starlab.UUCP (Michael Hoennig) writes:
>In article <1992Aug6.014619.2111@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>>GC classes cannot be allocated on the stack or statically,
>>so when one is, it is silently converted to a GC pointer
>>to an object.
>
>>Pointers to GC class objects will be GC pointers.
>>GC pointers are like classes, they have built in destructors and
>>constructors so they can't just disappear.
>
>I think this is a neverending loop. If pointers to GC class objects will be
>GC pointers too, they will be silently converted to a GC pointer (which is
>a pointer to a GC class) and must be silently converted to a GC ...
>
>=> GC class objects must be allocatable on the stack - but the compiler
>must recocnize this.
>
	?? GC objects are allowed only in the GC heap. Pointers
to these a possibly special, but they can be static, auto, or inside
objects on the GC heap, and probably with some loss of security
they could be allowed in objects not on the GC heap.

	GC pointers are like *ordinary* C++ classes, not GC classes.
If GC objects were allowed on the stack, they would have to be
copied when the lexical scope was exited if there were still
existant pointers to them. So why not just allocated them
on the GC heap in the first place?

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: Tagged Pointers
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Mon, 17 Aug 92 17:49:31 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: In article <1992Aug13.173401.14944@fcom.cc.utah.edu> swillden@news.ccutah.edu (Shawn Willden) writes:
: >That's what I understood from your previous posts (TU*!=TP) and I was
: >suggesting that maybe there is a good argument for making this so.
: >What are the arguments against it?
: >
: 
: 	There's not so much an argument against it as a simple fact
: that th're different. The tagged pointer has the tag in the pointer
: (conceptually at least). It is a pointer that can point to one
: of several types.
: 
: 	A tagged union has the tag in the union.  It is an object
: of one of several types.  A pointer to
: a tagged union is an *ordinary* pointer.
: 
: 	Tagged pointers are a special case of tagged unions.
: You can of course have a pointer to a tagged pointer, etc.
: You wouldnt want that to be a tagged pointer would you?
: Or perhaps you would?
 
No, I don't think so.  Not if we want to allow:

	[T1,T2,T3]** foo = new [T1,T2,T3]*[NUM_ELEMS];

(if I understand your syntax).  What I mean is a ordinary pointer 
to an array of tagged pointers.

: 	It all depends on whether tagged pointers are a genuine
: type or not. If it is, all the above things must be distinct.
: If not (I suggested not in my post) then maybe we can make
: a pointer to a tagged union work as if it were a tagged
: pointer. This would homogenise the interface. More work
: for the compiler, less for the programmmer. Less control
: for the programmer too.

Hmmm.  It appears I didn't explain myself very well because that is
precisely what *I* was suggesting.  I suppose the difference lies in
my consideration of TP's and TU's as different types but (as I said)

	1)	*TP yields a TU
	2)	&TU yields a TP

whereas you suggested that they not be actual *types* but that we 
make them work like the above anyway.  Same effect, different words.
Have I got this right?

: 	So the issue is whether a tagged pointer is a proper type
: or just a sort of syntactic sugaring that supports a new 
: mechanism for genericity. My thinking was the latter.

I think your thinking is better :-)  TP couldn't be a proper type
anyway.  If anything, TP would be a *family* of types.
 
: 	Any comments?

Getting back to the question that started this exchange (should we have
tagged references?), I think that they're probably unnecessary for the
case I was presenting (by which I mean that they don't greatly simplify 
anything).  If I have a TP and wish to pass a reference to what it points 
to to a function I can just say:

void foo([T1,T2,T3]& fred)	// fred is a ref to a TU, not a tagged ref.
	{...}

void bar();
	{
	[T1,T2,T3]* barney;
	...
	foo(*barney);		// *barney is a TU, foo gets a ref to it.
	}

at least that is what the programmer may think.  In fact TU and TP are not
types but the syntax of the sugar looks right.  Actually, does it really 
matter whether we call [T1,T2,T3]& a ref to a tagged union or a tagged 
ref?

Shawn Willden
swillden@icarus.weber.edu
From: Aurelius@cup.portal.com (Mark Christian Barnes)
Newsgroups: comp.lang.c++
Subject: Re: struct array question
Date: Sat, 15 Aug 92 00:34:34 PDT
Organization: The Portal System (TM)
Distribution: usa

Hi Dave,

| struct wintype {
| char buf[4000];
| short curx;
| short cury;
| short initialized;
| };
| wintype win[5];

 Unless you are knew at C, you have simply forgotten a thing or two:

struct wintype win[5]; /* this will work */

typedef struct wintype { ... } wintype; /* this makes the old line ok */

			Regards, Aurelius@cup.portal.com