HDTenEightyP/NetNews huggingface dataset:
From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Re: run-time type checking, freezing, and thawing
Organization: netmbx, Berlin, Germany
Date: Wed, 12 Aug 1992 13:43:05 GMT

jimad@microsoft.com (Jim Adcock) writes:

>In article <2A827DFD.6D68@tct.com> chip@tct.com (Chip Salzenberg) writes:
>|Therefore, EVEN IF the C++ standard includes RTTI, object storage will
>|STILL require preprocessors and all that loathsome junk that you claim
>|will be unnecessary once RTTI becomes available.

>An alternative to loathsome preprocessors is to use loathsome postprocessors
>instead and grovel over the debugging information emitted in the .objs.
>This makes your postprocessors dependent on the .obj format emitted, but
>still this should be an easier task.

We could take that even one step further, and grovel over debugging info
placed in the .EXEs.  In fact, we could develop a general purpose library
for accessing this information.  And we could standardize this for all
vendors.  We have now rederived the concept of extended run time type
information....

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

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

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: Mon, 17 Aug 1992 12:38:52 GMT

In article <1992Aug17.074855.24336@ericsson.se> jonas@beppe.ericsson.se writes:
>In article 23166@ucc.su.OZ.AU, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>> In article <1992Aug15.005542.3104@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
>> >
>> >Reference counting suffers serious drawbacks:
>> >
>> >1. It can't handle cyclic data structures
>> >
>> >2. It is one of the most inefficient forms of garbage collection known to man.
>> >
>> >The main reason I'm pushing for true garbage collection is that I consider
>> >reference counting (which I already have) to be an unacceptably poor solution.
>> 
>> 	Mm. Reference counting used to implement 'write on demand' in
>> copy contructors is supposedly inefficient. But this is not at all
>> the same as reference counting for garbage collection. In copy contructors,
>> you have to check the reference count before each write operation,
>> and if its not 1, clone off a copy of the object. Thats slow.
>> 
>> 	But for GC you only have to increment the reference count
>> when you take the address of the object to form a GC pointer,
>> decrement it when the pointer is destroyed, and destroy the 
>> object when the count goes to 0. That doesn't seem to be so slow
>> to me: please correct me if I'm wrong.
>
>Wouldn't even a GC scheme have to create a copy of the object if the pointer was
>used for non-const operations on the object? The advantage with implementing
>GC pointers as separate constructs is that the programmer can decide when he
>wants stucture sharing and whe he does not.
>
	GC pointers ought to behave like ordinary ones. When you
copy a pointer you share the 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: harris@hprnd.rose.hp.com (Mike Harris)
Newsgroups: comp.lang.c++
Subject: USL Components on Sun ???
Date: 18 Aug 92 16:21:12 GMT
Organization: HP Roseville Networks Division

I am trying to find out if the USL component library is shipped with the
Sun C++ compiler and if so, what version of the Sun C++ compiler.

Any info would be appreciated.  Please e-mail any responses.

Thanks,

Mike
harris@hprnd.rose.hp.com
Newsgroups: comp.lang.c++,comp.lang.c
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: PL/1 ==> C/C++, arrays
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 13 Aug 1992 08:00:10 GMT

In article <1992Aug10.174059.18557@bnrmtl.bnr.ca> lew@bnr.ca (Pierre LEWis) writes:
>(I'm indirectly involved in following, but find it quite fascinating)
>
>A group here has tens of thousands lines of PL/1 code that they are
>considering porting to C or C++.  Characteristic of this code is that it
>makes heavy use of PL/1 arrays and all related language features.  For
>example:
>
>When I first met this problem, my first reaction was that C++ would be great
>for such a challenge, and much better than C.  One would simply define an
>appropriate Pl1Array class to support all (most) needed features.  But it
>certainly wouldn't be trivial as shown by some of the above example.  And
>after a bit more thought, I'm somewhat less convinced.
>
>QUESTION:  is anyone aware of such a class?  Other comments?  What about PL/1
>to C or C++ conversion aids?  Maybe that's an FAQ, but I found nothing.
>
>Sorry if I made some of you wince at the mention of PL/1 (esp. in such a
>group),
>
	Most of te PL/1 stuff can be done in C++, and better, but you
will need to use different techniques sometimes.

	The biggest headache will not be arrays IMHO, but nasty
LITTLE things, namely the automatic conversions of numeric types.

	The array cross section facility is only a special case
of the DEFINED mechanism, which C++ can emulate quite nicely.
You will find that sometimes you'll have to expand a PL/1
expression ito a loop, or an indexed goto into a switch.

	All do-able...by hand. I doubt an automatic converter
could work very well, although for some bits of code it might
help a bit.

	I think you would be up for a major re-write.
This might be faster than a slavish conversion.

-- 
;----------------------------------------------------------------------
        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++,comp.std.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Proposal: Operator <-
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Fri, 21 Aug 92 19:41:34 GMT


To provide a transparent generic object pointer (reference), we need a 
new operator <- to clear the side effect caused by operator ->. 
Consider the following example:

template <class RefType, class ObjectType>
class REF
{    RefType ref;
   public:
     ObjectType * open ()
          { return (ObjectType*) ref.open(); };
     void close () { ref.close(); };

     ObjectType * operator-> () { return open(); };
     ObjectType * operator<- () { return close(); };
     ObjectType   operator*()   { return *open(); };
     REF<RefType,ObjectType> operator++ ()
        { return REF<RefType,ObjectType> rf ={ ref.next(); };
     ...
};

The operator <- is always called implicitly by the compiler:

     When operator-> followed by a lvalue, operator<- is called 
     after the assignment, otherwise, operator<- is called 
     immediately after the member is read.

For example:

     REF<PersistentRef, Circle> circle_ref;
     position = circle_ref->position;

Operator-> will call PersistentRef's "open" to read the circle object 
stored in a persistent storage, and the operator <- will be called 
after the object is read into the memory.

The default operator <- for standard pointer is equivalent an empty 
operation.

Without built-in operator <-, the programmer must close the object 
storage explicitly:

	position = circle_ref->position; circle_ref.close();

If position is a member function:

	position = circle_ref->position();

you must call close at the end of the function. This may cause another 
problem: position() can not be called by other member functions within 
the object, otherwise the open/close operations will be unbalenced.

If operator<- is provided by the language, then we can write programs 
independent to any particular memory management protocol. For example, 
we can write dynamic data linking structures like trees, chains, rings 
that can run both in standard alloc/free memory and in MS Windows heap 
without changing the source.

David Shang
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 21 Aug 92 22:02:19 GMT

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:


|The question is: what should be the default. I don't think that
|mandatory late destruction solves anything, because if you start
|relying on the persistence of temporaries in expressions, the next
|step is that you'll get confused about why they don't hang around for
|the whole block.

Agreed.  In my opinion, we should not even have to think about
temporaries.  The compiler should quietly use them in foolproof
situations, and quickly destroy them.  In any situation where a
pointer or reference to a temporary is being taken, the compiler
should complain.  I would not be at all adverse to having the compiler
treat the taking of the address or reference of a temporary as an
error.

--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: jdc@naucse.cse.nau.edu (John Campbell)
Newsgroups: comp.lang.c++
Subject: SunOS conflicts with g++
Keywords: size_t, ptrdiff_t, flock
Date: 17 Aug 92 23:06:07 GMT
Organization: Northern Arizona University, Flagstaff AZ


Help,

I'm using g++ on a Sparc (SunOS 4.1.2) and find myself with three
compile errors that I wonder about fixing:  
       1) conflicting types for `size_t':
       2) conflicting types for `ptrdiff_t'
       3) warning: `flock' was declared `extern' and later `static'

It appears each of these is a conflict between files in g++-include and
 /usr/include/sys:

   1) conflicting types for `size_t':
      /usr/include/sys/stdtypes.h:typedef	int		size_t;
      /usr/local/lib/g++-include/stddef.h:typedef unsigned long   size_t;

   2) conflicting types for `ptrdiff_t'
      /usr/include/sys/stdtypes.h:typedef int		ptrdiff_t;
      /usr/local/lib/g++-include/stddef.h:typedef long int	    ptrdiff_t;

   3) warning: `flock' was declared `extern' and later `static'
     /usr/include/sys/fcntlcom.h:struct flock {
     /usr/local/lib/g++-include/std.h:int       flock(int, int);

Anyone have an "expert" opinion about what to do with these?  (I
assume I want to change the g++-include files, but wonder if that's
really safe?)  War stories?  Gotcha's I might find further down the
line as I mix g++ with SunOS 4.1.2?

Also, I wouldn't expect this particular question to be in the
FAQ, but I'm new to this group.  Would someone tell me where the
FAQ is kept?
-- 
	John Campbell               jdc@naucse.cse.nau.edu
                                    JDC@NAUVAX.UCC.NAU.EDU
From: Benjamin.Tse@f550.n635.z3.fidonet.org (Benjamin Tse)
Sender: acsnet@csource.oz.au
Newsgroups: comp.lang.c++
Subject: Best C++ compilier for Ibm
Date: Wed, 12 Aug 1992 17:19:01 +1000

Hi, just about to get into C++ programming and wondered which compiler was the
 best for the Ibm.

I've seen the Borland C++ 3.1 and its Turbo C++ and wondered what the
 difference was. I have little experience in C programming although I have been
 using Pascal and BASIC (when desperate). I need a starting point for using C
 in *both* Dos and Windows - any suggestions ?

Also, what's this Application Frameworks thing that can be bought with Borland
 C++ ?

Info sought,
Benjamin

 * Origin: Empire BBS +61(3)592-5662 (3 lines) (3:635/550)

Newsgroups: comp.lang.c++
From: matthew@ntl02.decnet.nokia.fi (Matthew Faupel)
Subject: C++ 3.0 and exceptions
Organization: Nokia Telecommunications, Cambridge, UK
Date: Wed, 19 Aug 1992 10:57:59 GMT

Could anyone please confirm or deny the fact that exceptions as described in
Bjarne Stroustrup's 2nd edition of the C++ Programming Language are *not*
supported by v3.0 of the language?

Follow-up question: If they are not supported, when will they be?


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 *---
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: auto T&
Date: 20 Aug 92 13:06:34 GMT
Article-I.D.: alice.23494
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Aug19.234913.622@tfs.com> eric@tfs.com (Eric Smith) writes:

> Much recent discussion about destruction of temporaries suggests a
> better way to solve the whole problem, and to allow returning references
> to temporaries from functions.

> auto String& stringfunction(const String& input)
> {
>    // Calculate/create a new temporary or named automatic String
>    // and return a reference to it.
> }

> The "auto" in the function return value type tells the compiler to allocate
> the space for that automatic in the stack frame of the caller, instead of
> the stack frame of the called function.

What's wrong with this?

	String stringfunction(const String& input)
	{
	   // Calculate/create a new temporary or named automatic String
	   // and return a copy of it.
	}

A smart compiler will allocate space for the result in the stack frame of the
caller, instead of the stack frame of the called function.  A number of
C++ implementations already do this.

This technique has the advantage of being easy to understand and
getting the right answer from all existing C++ implementations.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: Return value for the constructors.
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Thu, 20 Aug 1992 17:02:39 GMT

In <1992Aug20.122656.15072@aruba.uucp> philc@ruby.aruba.UUCP (Phil Calvin) writes:

>In article <H575V1E@netmbx.netmbx.de>, jrobie@netmbx.netmbx.de (Jonathan Robie) writes:

>|> But note this example from the ARM, page 62:
>|> 
>|> 	complex* p = new complex(i++);
>|> 	if (p == 0)  // allocation failed!
>|> 
>|> On page 61 he also states that initialization will only be done if the
>|> return from the new is nonzero.
>|> 
>|> So I think that it is safe to check the pointer to see if it is zero.

>Isn't a more secure method provided by implementing a _new_handler function
>that deals with allocation failures??

>That way, such pointer checks are unnecessary..

	Yes....but.  All the _new_handler knows is that somebody ran out
	of memory somewhere.  It knows nothing about the object that was
	trying to be constructed at the time; hence, it may only be able
	to do "dumb" or "panic" actions.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: hons@rkw-risc.cs.up.ac.za (Honneurs Studente)
Subject: C++ vs PASCAL
Date: 18 Aug 92 02:23:47 GMT
Organization: University of Pretoria, South Africa
Keywords: C++ PASCAL

Can anyone give me an unemotional opinion on what seems to be a ridiculously
emotional issue regarding the desireability of using an Obj Oriented Pascal
as opposed to C++. Do either of the two have any significant
advantages over the other and if so what are they. If the two compilers in 
question where turbo pascal for windows and BC++3.1 for win which would be
the best choice and why? I'm not a windows programmer but am considering
getting involved in ms windows. How well do pacal and windows co-exist 
as opposed to C/C++ and windows. 
Any opinions on the matter will be appreciated.

Please E-Mail replies to 9180486@cs.up.ac.za

THANX
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Is C++ "for the rest of us" ?
Date: 20 Aug 92 01:54:58 GMT

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?  Would you
|suggest that a team with average programmers move to C++ ?
|Should a programming team attempt a C++ project if they do
|not have any C++ gurus to fall back on?

First, learn as much as you can about the technology and the industry.
Jumping into OOT in ignorance is a sure way to create a disaster.  

Select a small project (6 man months to 2 man years max).

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.  

Document the successes and failures of the team, and then go on to
select a new project and train more engineers and managers.

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

C++ is hard to learn.  OOD is perhaps even harder.  The conceptual
barrier between C/SA/SD and C++/OOA/OOD is very high.  It takes a long
time, and a lot of training and experience to cross that barrier.  Any
organization which is contemplating the switch from C to C++ or SA/SD
to OOA/OOD would be wise to move slowly, and enlist the help of the
experts. 

--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Is C++ "for the rest of us" ?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 21 Aug 1992 02:03:33 GMT

In article <k9!nz8l.nagle@netcom.com> nagle@netcom.com (John Nagle) writes:
>       I'd recommend learning Smalltalk before C++, even if you never intend
>to write anything in Smalltalk.  Smalltalk offers object-oriented programming
>with safety, at some cost in performance.  

	You're kidding right? About safety? Smalltalk is
type-safe in vacuuo :-)

>In Smalltalk, one can actually
>see what this OOP thing is all about and what it buys you.  Then one can
>learn to deal with the compromises made in C++ to bolt OOP onto C without
>adding garbage collection.  If you learn C++ first, the clunky features
>of the language obscure the object-oriented concept.

	Perhaps you should learn C++ first to see what static
type safety buys you. Then you might consider why C++ compromises
heavily in favour of security. Of course GC is an exception to this IMHO.

>
>       I'd avoid any C++ without templates for new work.  You really
>need a generic capability to make OOP work, and hokey schemes with
>macros and heavy use of "(void *)" bypass most of the type checking
>while not making it clear where it has been bypassed.

	Yes, but I dont see the connection between genericty
and polymorphism, on the contrary I thought they were totally
different mechanisms.
>
>       I suppose we all have to go to C++, but after two years with the
>language, I wish something better were available.
>
>					John Nagle
	We all agree here surely :-)


-- 
;----------------------------------------------------------------------
        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++
Subject: Help : SVGA, VGA drivers
From: ebolog@elaine.ee.und.ac.za (EDWIN BOLOGNA : THIRD)
Date: 20 Aug 92 13:08:12 +0200
Organization: Electronic Eng., Univ. Natal, Durban, South Africa


Does anyone out there happen to have PAS, C, or ASM source code to decode
drivers (.DRV) formats so that I can use them in my programs (To access
different video cards).

Any information at all on any of these formats will be greatly appreciated.

        Desperate fellow programmer (And very Greatful for any information)

                E.B. (EBOLOG@ELAINE.EE.UND.AC.ZA)

PS : Please be kind hearted and Assist !
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Downcasting (was: Re: run-time type checking)
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 14 Aug 1992 05:03:50 GMT

jbn@lulea.trab.se (Johan Bengtsson) 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 { //....
		virtual operator Derived1*() { return 0; }
		virtual operator Derived2*() { return 0; }
>:	};
>:Now what does this do? Well, it preserved th open/closed principle
>:and encapsulation and the explicit interfaces principle.
>
>What if someone using your classes decides to add a Derived3 class
>to which downcasting should be possible?  He must modifiy your
>class Base, for which he may not have source code.

Yes, but that would be a change to the interface!

The whole point is that the ability to downcast a Base to a derived class
SHOULD be part of the interface. If you want to change the interface, then
of course you are going to need to modify the source code - this does not
violate the open/closed principle.

Also lattanzi@wsl.dec.com (Len Lattanzi) writes:

>Biggest drawback is that Base must know about every derived class and
>provide a virtual type conversion. But it is a usable poor-man's RTTI.

Again, this is not a drawback but rather a deliberate design decision.

If I pass you a Base*, I expect that you will only be able to modify it
using the Base interface. Thus if you want to be able to modify it using
the Derived interface, then the conversion from Base* to Derived* should
be an explicit part of the Base interface.

The real drawback is the amount of typing required. This can be reduced
with macros if desired.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Xref: sparky comp.lang.c++:12774 comp.std.c++:1108
From: jane@mullian.ee.mu.OZ.AU (jane lynette cosham)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: How do I forward declare a nested class?
Date: 23 Aug 92 14:22:35 GMT
Organization: Computer Science, University of Melbourne, Australia

This is something I keep coming up to and can never figure out the
syntax for.

How do you forward declare a nested class?

eg if I have a class A and 2 classes nested within A (say B & C), and
functions in both B and C take pointers to the other (ie C needs A::B*
and B needs A::C*) - how do I do this?

BTW I am using both BC 3.0 and MSC 7.0 and can't figure this out for
either.  I can't find any reference to this in manuals for either
compiler or in the ARM.


Thanks to all

Jane
Newsgroups: comp.lang.c++