HDTenEightyP/NetNews huggingface dataset:
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Reference counting for vectors, (Tony Hansen's book).
Date: 15 Aug 92 03:22:08 GMT
	<BRISTER.92Aug14110706@tirade.decwrl.dec.com>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: brister@decwrl.dec.com's message of 14 Aug 92 18:07:06 GMT

In article <BRISTER.92Aug14110706@tirade.decwrl.dec.com> brister@decwrl.dec.com (James Brister) writes:

   On Fri, 14 Aug 1992 16:47:19 GMT, abed@venus.wustl.edu (Abed M. Hammoud) said:
   > I was trying to implement the vector class using the method suggested
   > by tony Hansen. i.e reference counting. the following code is taken
   > from Hansen's book (C++ Answer book). There is some thing that doesn't
   > seems correct.

   What's not correct? The fact that modifying one variable causes the other
   to change? If that's not what you want, then this isn't for you, but in the
   case where you're making multiple copies of the array (as paramaters to a
   function, for example), then this scheme is great.

Using reference counting to get reference semantics on parameter
passing is very confusing indeed (sadly, this bad idea seems to
pervade the C++ literature).

I have found it to be much better to give everything (including
arrays) value semantics and use call-by-reference when I want and mean
call-by-reference (some special hacks are needed for avoiding
redundant copies on return).

Using call-by-reference when you mean it is also more efficient than
having reference counting operate behind the scenes constantly.

If you truly want reference counting semantics, you can easily derive
it from objects with value semantics using a template class.

   [goes on to suggest the use of copy-on-write]

Copy-on-write is not really an option for classes like arrays that
require high-performance updates. You don't want to pay the price for
the memory fetch and conditional branch on each array store.

					Thomas.
Newsgroups: comp.lang.c++
From: bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565)
Subject: Re: Garbage Collection for C++
Originator: bcannard@hppcb36
Date: Sat, 15 Aug 1992 02:56:13 GMT
Organization: Mentor Graphics 
Keywords: 
Followup-To: 


In article <TMB.92Aug14130323@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
|> In article <1992Aug14.021547.15215@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
|> 
|>    In article <DAVEG.92Aug13025629@synaptx.synaptics.com>, daveg@synaptics.com (Dave Gillespie) writes:
|>    |> Couldn't we get away with having a garbage collector that didn't
|>    |> need pointers to be declared `GC'?
|> 
|>    I can't see that this is viable given the basic constraints on C++: among
|>    other things, those who don't want GC shouldn't have to suffer the hits.
|> 
|> What "hits"? In all the cases that I have looked at, the GC overhead
|> has been _smaller_ than the overhead of explicit memory management in
|> C++. Now, maybe my sample of programs is biased, but if you claim that
|> there are "hits", please state either whether you have concrete
|> evidence that there are, or whether your statement is just religious
|> belief. Your vague statements might easily turn into gospel truth.
|> 
|> Based on my experience, I would turn your statement around and say:
|> "those of us who want GC shouldn't have to suffer the inefficiencies
|> of not having it".
|> 
|> 					Thomas.

It's practical experience. A question for you: have you ever used a
custom-made, tailored new/delete (or malloc/free), instead of the ones provided
as standard? I have. I've been inside malloc (it's not a pretty sight :-) ),
worked around it, optimised it, jiggled the numbers, bypassed it, and generally
done everything I could to optimise storage recycling. The difference in
performance (on the right type of application) is startling, and more than the
difference between manual and automatic. I'm willing to talk at greater length
about storage allocation, if people are interested, but I'd rather do it in a
different thread, or off-line.

In a *fair* comparison between an optimised GC and an optimised
manual scheme, the manual scheme will win if the decision of when and what to
delete can be made at compile time. In a situation where the decision can only
be made at run time, the GC will win. This is one reason why I want both
mechanisms.

There are plenty of reasons whey GC is genuinely more efficient than
manual: it allows better-designed data structures, it eliminates the need to
copy data which plagues large systems using manual recycling, and it reduces
development and maintenance costs. But the idea that GC is inherently faster
than manual is bogus.
-- 
bob_cannard@mentorg.com         "Human beings? ... Well, I suppose they are a
                                 form of life, even if they are unspeakable"
Exprssed opinions are not necessarily those of Mentor Graphics Corporation.
Newsgroups: comp.lang.c++
From: matthew@ntl02.decnet.nokia.fi (Matthew Faupel)
Subject: Exceptions and C++ v3.0 Summary
Organization: Nokia Telecommunications, Cambridge, UK
Date: Thu, 20 Aug 1992 14:57:37 GMT

Thanks to all those people who either posted or mailed me directly.  The
answer to the question:
  Are exceptions as detailed in the latest edition of the C++ book by B.S.
  supported by v3.0 of the C++ compiler?
is:
  No.  cfront v3.0 as shipped by USL does not currently support exceptions,
  however v3.0 of HP's compiler (to be shipped sometime in September or
  October) does.

Thanks again,


Matthew
--
---* Amnesiac the Wizard *------------------* matthew@uk.tele.nokia.fi *---
 Opinions expressed here are not those of my company.    | NB. ntl02 is EN
 They're not even my own; I plagiarised the lot of them! | TEE EL ZERO TWO
---* matthew@ntl02.decnet.nokia.fi *------------------* Matthew Faupel *---
Newsgroups: comp.lang.c++
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: Re: destruction of temporaries
Organization: Mentor Graphics Corp. - IC Group
Date: Tue, 18 Aug 1992 20:52:11 GMT

In article <1992Aug17.211508.6634@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>In article <23466@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
>|> This treatment [end of statement] has two significant disadvantages:
>|> 
>|> 	1. If I break a statement up into several, it may
>|> 	   quietly change its meaning.  Thus, for example, if
>|> 	   String::operator const char*() exists, and s and t are
>|> 	   of class String, then
>|> 
>|> 		printf("%s\n", (const char*)(s+t));
>|> 	
>|> 	   might work but
>|> 
>|> 		const char* r = s + t;
>|> 		printf("%s\n", r);
>|> 	   
>|> 	   might not.
>
>And I feel that I should be able to add a { } around an expression
>statement without changing its meaning.  In other words I ought
>to be able to further transform the above to
>
>		const char* r = "" ;
>		if ( 1 ) { r = s+t ; } 
>		printf("%s\n", r) 
>
>
>Even "end of block" (the latest anyone has proposed) makes
>this example undefined.
>

As Andrew Koenig and Jerry Schwarz point out, "end of statement" and
"end of block" treatment of temporaries is not good enough.

The ARM also mentions a "end of function" treatment, but goes on to reject
that too. However, I am not convinced by the ARM's explanation for not
adopting the "end of function" approach. On page 270, the ARM gives the
following example and uses that example to reject this approach:

	const char* f()
	{
		String x("foo");
		String y("bar");
		return x + y;    // still not guaranteed to work
	}

However, note that I can put myself in exactly the same situation even
without any temporaries being involved.
	const char *f()
	{
		String x("foobar");
		return x;	// not guaranteed to work either
	}

So why would the ARM consider the example with a temporary sufficient
reason to reject the "end of function" approach? To me it appears that
the "end of function" approach for temporaries would not cause any more
difficulties or program bugs than those that can already occur even without
temporaries. So why not reconsider that approach?

- Ajay

-- 
I speak for none but myself.

Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
From: landauer@morocco.Eng.Sun.COM (Doug Landauer)
Newsgroups: comp.lang.c++
Subject: Re: Tiny proposal for named loops.
Date: 22 Aug 92 01:01:50 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: morocco

> ||for main_loop (...) {
> ||  // ...
> ||  for inner_loop (...) {
> ||    // ... complex mess of loops ...
> ||          break main_loop;       // somewhere deep inside the loops
        // ... more complex mess of loops ...
      } // end of inner_loop
      // ... more complex mess of loops ...
    } // end of main_loop

Unless you require that the loop name appear on the closing brace as well
as the heading of the loop, this sounds to me like a way to have a goto
whose destination is someplace very far away from the place where the
label name is defined.  Why not just "goto" some carefully-named labels?
Like, say, "continue_main_loop" and "break_main_loop"?

> |State variables are preferable to breaks and continues.
> I disagree.  I generally prefer a multi-level break ...

I gather from this interchange that the mid-70's Structured Programming
pogrom which attempted to eradicate the "goto" is still striking fear into
the fingertips of programmers in the 90's ????

The only language change that I'd suggest is that label names should not
be permitted to be *less* than 14 characters long.  :-)
-- 
Doug Landauer -- landauer@eng.sun.com
SMI[STE]->SunPro::Languages.PE(C++);
Newsgroups: comp.lang.c++
From: jypai@ccnext.csie.nctu.edu.tw
Subject: Is there a FAQ
Reply-To: jypai@ccnext.csie.nctu.edu.tw
Organization: Computer Science & Information Engin., Chiao-Tung U, Taiwan, ROC
Date: Thu, 20 Aug 1992 06:54:25 GMT

I've been here for about one month.
But never saw a FAQ.
I guess there's not one.
Am I right?

--

Yuan
+----------------------------------------------------------+
| Internet Address         : jypai@csie.nctu.edu.tw        |
| NeXT mail GLADLY accepted: jypai@ccnext.csie.nctu.edu.tw |
+----------------------------------------------------------+
Newsgroups: comp.lang.c++
From: staferne@risc.uni-linz.ac.at (Stefan Taferner)
Subject: Re: Is C++ "for the rest of us"
Organization: RISC, J.K. University of Linz, Austria
Date: Tue, 18 Aug 1992 07:29:04 GMT



Hi Jonathan !

My opinion:
If your average team of programmers is already familiar with C, then 
switch to C++. Sure, C++ has some new/strange features, but it should
be no real problem for a C programmer to learn it.
If your team has to learn C *and* C++, it might be very difficult for
them. I've seen this problem two years ago in the team I worked with.
They all were rather average programmers and nobody had any C knowledge.
(mostly PL/1 programmers). It took them some months to really learn C and
C++, and I think it took them about one year to fully understand C++.
Remark: they didn't have time to learn C/C++ all the day. Say they used
C++ for 3 hours a day.

----
Stefan       staferne@risc.uni-linz.ac.at (Stefan Taferner)
             RISC, J.K. University of Linz, Austria
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 20 Aug 92 18:32:23 GMT
	<1992Aug19.180252.12942@mole-end.matawan.nj.us>
	<DAVEG.92Aug20043156@synaptx.synaptics.com>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: daveg@synaptics.com's message of 20 Aug 92 11:31:56 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:

   > 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 the exact sequencing
   > of internal states of the program and of the program's runtime internals'
   > states.  It might work correctly by accident in testing, and fail
   > disastrously in service.

   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.

I think the answer is simpler than that. Delete should continue to
work as it does (including returning memory to the system).

In addition to that, there may be facilities to allow the programmer
to specify finalization of heap objects that are about to be collected
but have not been "deleted". Such a facility would not require any
language changes; something like "gc_set_finalization_hook(void*,void
(*f)(void*))" might do the trick. Some people may prefer to use such a
facility simply to detect memory leaks in existing programs, while
others might want to use it, for example, to release external
resources.

					Thomas.
Newsgroups: comp.lang.c++
From: boehm@parc.xerox.com (Hans Boehm)
Subject: Re: Garbage Collection for C++
Organization: Xerox PARC
Date: 20 Aug 92 16:26:04 GMT

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
>I think the answer is simpler than that. Delete should continue to
>work as it does (including returning memory to the system).

>In addition to that, there may be facilities to allow the programmer
>to specify finalization of heap objects that are about to be collected
>but have not been "deleted". Such a facility would not require any
>language changes; something like "gc_set_finalization_hook(void*,void
>(*f)(void*))" might do the trick. Some people may prefer to use such a
>facility simply to detect memory leaks in existing programs, while
>others might want to use it, for example, to release external
>resources.

Technical point:
There are some important issues related to the order in which
objects get finalized by the collector.  If your program drops both an
IO buffer and a corresponding file descriptor, the IO buffer needs to
get finalized first, so that its contents can still be flushed.
Typically finalization proceeds in topological order.  This means cycles
become a problem.  The new version of our stand-alone collector in

parcftp.xerox.com:~ftp/pub/russell/gc.tar.Z

has one proposed (and still controversial) way of handling this.

(The current version of this collector has some known bugs, which you
you may or may not notice.  It will be replaced by version 2.2 shortly.
The finalization interface is not expected to change.)

Hans-J. Boehm
(boehm@parc.xerox.com)

Newsgroups: comp.lang.c++
From: shirleyk@qualix.com (Shirley Kumamoto)
Subject: C++ graphics libraries
Followup-To: info@qualix.com
Keywords: C++ graphics windows
Reply-To: shirleyk@qualix.com
Organization: QUALiX Group, Inc.
Date: Thu, 13 Aug 1992 19:52:10 GMT

The Qualix group has three commercial packages that you might be
interested in. The first is XV++, which is a C++ class library
providing a c++ API to the XView toolkit.  Applications derive
from XV++ base classes with notification and events handled by
virtual functions.  The second is View.h++ which gives Motif 
programmers a C++ API to the Motif toolkit.  It encapsulates
100% of Motif capability.   OI library is another class library
which emulates either OPENLOOK or Motif and allows one to write
just one application which can be switched at runtime.

If you would like more information on any of these products,
let me know.




Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Is C++ "for the rest of us" ?
Organization: :
Date: Thu, 20 Aug 1992 09:46:53 GMT

In article <rmartin.714275698@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:
> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
 
> |What guidelines would you give to a manager who is trying
> |to decide whether to use C++ for an new project?  ///

>  ...
> Train the engineers in OOD and C++.  Training in OOD is essential, C
> programmers who learn C++ are likely to keep using C-isms and not
> likely to practice any OO.  
 
I'll second that, and for a different reason.

Y'see, if you want to avoid the C'ism, what you need is training in
OO Programming.

But if you want to get the job done on time and with a minimum of
hassle, and get the bennies of OO, then you need OO Design.  And
to make the OO Design sound, you need OO Analysis.

Oh, and you need a clear notion of `Detailing'--my term, by analogy with
the structural and miscelaneous steel industries, for what is commonly
lumped under `Detailed Design'--except that nobody has a definition,
except maybe me.  Look for some of my old posts, here and on comp.object.
(I don't mean that nobody _does_ it; I mean that nobody can _explain_ it.)

Anyhow, I suggest you study a bunch of OO methods, and also study E/R
modelling, and then follow none of them exactly!
-- 
 (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: TSOS@uni-duesseldorf.de (Detlef Lannert)
Subject: Re: Tiny proposal for named loops.
Organization: Universitaetsrechenzentrum, Heinrich-Heine-Universitaet, Duesseldorf
Date: Fri, 21 Aug 1992 11:15:36 GMT

In article <aldavi01.714376080@starbase.spd.louisville.edu> aldavi01@starbase.spd.louisville.edu (Arlie Davis) writes:

>Since the language is still open to improvements, even those which relate to
>the more C-oriented personality of C++, I'd like to suggest the addition
>of named loops.  The syntax would not break any existing code at all.
>An identifier would be placed just after the "for", "while", "do", or even
>"if" keyword.  This keyword could be used just after "break" or "continue",
>to specify exactly which loop to break or continue.
>
>Example: [deleted for bandwidth's sake]
>
>This would eliminate the need for some state variables used with switches,
>which would make code more readable, and more block-oriented.

I like your idea. It could certainly make C[++] code safer
and more legible. There shouldn't be any syntactical problem
with

     if [<id>] (<expression>) <statement>
     switch [<id>] (<expression>) <statement>
     while [<id>] (<expression>) <statement>
     do <statement> while [<id>] (<expression>) ;
     for [<id>] (...;...;...) <statement>

A "break <id>;" statement would be useful for the "switch"
construct as well as for "while", "do...while", and "for",
as would the "continue <id>;" for the repetitive statements.

For the "if", however, there would be no use in assigning
any identification because it does not constitute any blocks
by itself and "continue" or "break" is not applicable.

Talking about blocks: Have there been any discussions about
a possible assignment of identifications to blocks? Something
like

     {<block-id>
        ...
     <block-id>}

instead of just

     {
        ...
     }

could improve the legibility of C[++] programs and help
localize errors. (A compiler error message should be
generated whenever the block-id of the closing } doesn't
match that of the opening {.) Of course this feature would
have to be optional.

I apologize if this suggestion has been discussed before;
otherwise I'd like to hear your comments (and suggestions
with regard to a possible syntax).
--
Detlef Lannert      DC3EK      E-Mail: tsos@rz.uni-duesseldorf.de
"Ab morgen wird gearbeitet."
From: kwassin@cs.vu.nl (Wassink K)
Newsgroups: comp.lang.c++
Subject: Question about Turbo Vision MessageBox
Date: 14 Aug 92 18:13:56 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

Hi,
I'm using Turbo Vision's  messageBox function, but am
wondering if it's possible to change the texts on the buttons;
In the msgbox.h file a class is defined mentioning things
like yesText, cancelText, etc.
Does anybody know how to change them, so I can say
'Yes' and 'No' in other languages as well ?

Koen.
Newsgroups: comp.lang.c++
From: svenning@cc.curtin.edu.au
Subject: Still looking for C libraries!
Organization: Curtin University of Technology
Date: Tue, 18 Aug 1992 07:16:23 GMT

Hello,
      With reference to my plea for any information regarding the whereabouts
of any C/C++ libraries.....well....I'm still looking!
Can anyone please help me with regard to this matter? I urgently require help
for completion of my current software project.

                                          Thanks,
                                                 Todd Venning.
                                          e-mail: svenning@cc.curtin.edu.au




Newsgroups: comp.lang.c++
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: Re: Downcasting (was: Re: run-time type checking)
Keywords: polymorphism, RTTI, downcasts.
Organization: Mentor Graphics Corp. - IC Group
Date: Wed, 12 Aug 1992 21:17:16 GMT

In article <9222518.29381@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>>There are other ways than tagged pointers to make downcasting
>>sound. One might be to declare the derived classes that you want
>>to downcast to in the base class FROM which you want to downcast:
>>
>>	class Base {
>>		....
>>		operator Derived1*() =0;
>>		operator Derived2*() =0;
>>	};
>>
>>or with a special syntax:
>>
>>	 class Base {
>>		..
>>		downcastable Derived1, Derived2;
>>	};
>>
>>Now what does this do? Well, it preserved th open/closed principle
>>and encapsulation and the explicit interfaces principle.
>
>This is a good idea.
>In particular, it seems that this technique much reduces the attraction of
>the current proposal to allow downcasting, because users can achieve virtually
>the same effect themselves - they just have to make the interface explicit.
>

I haven't been following this debate much, so I may be missing the point
here, but it pains me to see people get really excited about this idea.
I don't care what principles this approach obeys, the very fact that it
requires the base class to know about its derived classes and requires the
base class to be modified every time a new derived class is added makes this
approach dead in the water as far as I am concerned. Making the Derived?*
functions pure virtuals in the base class also forces each derived class to
know about its sibling classes. No good. The current proposal to allow
downcasting (I suppose that refers to the proposal by Bjarne Stroustrup and
Dmitry Lenkov) is much superior to this approach. I will take that
approach (provided that proposal gets accepted) any time over this old hack.

Now that I have had my 2 cents on this issue, I relinquish the thread back
to the regulars.

Cheers,

- Ajay

-- 
I speak for none but myself.

Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
Newsgroups: comp.lang.c++
From: lvi@ida.liu.se (Lars Viklund)
Subject: References as class members
Organization: CIS Dept, Univ of Linkoping, Sweden
Distribution: comp
Date: Fri, 14 Aug 1992 14:15:25 GMT


Is the following class declaration legal?

class X {
    X& r;
};

According to ARM it should be OK, but the ObjectCenter 1.1 compiler
and Sun CC 2.1 claims that the reference must have a constructor.
GCC compiles it without complaining.

--
Lars Viklund                                       | Email: lvi@ida.liu.se
Programming Environments Laboratory                | Phone: +46 13282689
Department of Computer and Information Science     | Fax  : +46 13282666
Linkoping University, S-581 83  LINKOPING, SWEDEN  | Telex: 50966 UNILIN S