HDTenEightyP/NetNews huggingface dataset:
From: mat@uunet.uu.net!mole-end
Subject: Re: Renew?
Summary: Proposals to x3j16/WG21
Organization: :
Date: Mon, 27 Jul 1992 07:22:23 GMT

In article <1992Jul25.151227.8156@hemlock.cray.com>, de@cray.com (Duane Eitzen) writes:

> On the topic of submitting a proposal: how does one do this? How
> much time should one expect to spend doing it? What percentage of
> external proposals are successful?

Several of the big C++/OO magazines published an article last year by
Bjarne Stroustrup on just this topic.  The spirit was `Please don't, but
if you insist on doing it, here's what you must do to have a ghost of a
chance.'

There's a lot of work involved, including analysis of how the proposal
would interact with other stuff.  C++ is sufficiently rich (like Ben&Jerry's
ice cream!) that this is a non-trivial task and should be undertaken by
several people, preferably with experience in compilers and language
semantics.  (Actually, more like a `whole calamari' flavor of B&J's, if
you get my drift.)

What percentage are `successful'?  If you mean `what percentage are
accepted more or less in the form in which they were submitted?' maybe
one in twelve.  If you mean `What percentage influence the language?'
the number might be a little higher.  (Of course, the season isn't over
yet, so the percentages aren't complete.)

Proposals by people who've worked in the guts of C++ are more likely to
address the issues squarely, and probably have a much better chance than
a proposal written by J. Random User.  (I've seen some simple ones that
I thought worthy, but that never saw the light of day.)  Proposals made
by representatives of large user groups (e.g. an SQL standards body)
have a better chance of commanding attention, but not necessarily a
better chance of acceptance.

My opinion on this one is that it is a non-starter.  You CAN'T just go
moving stuff around in C++; it really is tied to the Object model of
programming and the referential attributes that represent relationships
have to be maintained (i.e. you can't tolerate dangling pointers).  To
make this work, you have to think through not only C++ and its semantics,
but the nature of OO programming and how OO maps into C++.  It's job
somewhere between Huge and Fu'Cryin'OutLoud Huge.  You are trying to
shoehorn a brontosaurus into a Habitrail(tm, probably) and it just won't
go.

realloc() as it stands in C is nice because you MAY be able to expand
an array in place.  But C++ tends to work free store harder, and it's
less likely, given N. Random Storage Manager, that you'll reap the
benefit.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Newsgroups: comp.lang.c++
Subject: Re: C++ Return Types
Date: 21 Jul 92 21:54:53 GMT
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia

kramasamy@vax1.umkc.edu writes:
>ark@alice.att.com (Andrew Koenig) writes:
>> 	bitmap operator| (const bitmap& x, const bitmap& y)
>> 	{
>> 		bitmap result;
>> 
>> 		// build up the result in `result', then...
>> 
>> 		return result;
>> 	}
>
> Consider the bitmap to be of the following class definition
>
> class bitmap
> {
> 	char *ptr ;
> 	public :
> 		bitmap()
> 		{
> 			ptr = new char[10] ;
> 		} ;
> 		~bitmap()
> 		{
> 			delete [] ptr ;
> 		} ;
> } ;
>
> If we adopt the second solution for the above class definition we run
>into problems of deallocating 'ptr' thro' destructor and the calling routine will
>get a garbage bitmap. How can we return for such cases?

The solution, in this case, is a proper copy constructor.
That is, you need

bitmap::bitmap(const bitmap& b)
	: ptr(new char[10])
{
	strcpy(ptr, b.ptr);
}

-Sekar
Newsgroups: comp.lang.c++
Subject: Re: Covariant Types in Derived Classes
Distribution: world
Organization: Trumphurst Ltd.
Date: Fri, 24 Jul 1992 19:22:08 +0000

I am one of those who view RTTI with suspicion. I have no objection to its 
inclusion in the language, but I hope it doesn't encourage a rash of 
Smalltalk programming, or the absolutely horrible switch(typeof(thing)) !

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

> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> 
> >>If I want a generic print function that can handle all types as though they
> >>were basic types, then this print function must know the location and type
> >>of each member, and also the name if the function is to be particularly
> >>useful.
> 
> >	Such a utility function would be useful for debugging only.
> >Yes, to do it you would need RTTI.
> 
> Not so.  A report generator might start by showing me the default
> printout for an object.  I can grab fields with my mouse and move
> them around or delete them.
> 
> A user interface tool might allow me to do something similar by providing
> me with a default, editable window.
> 
The report generator and the user interface tool does not _require_ RTTI. 
The objects to be displayed/reported on should return a Collection of field 
specifiers from a virtual function. These field specifiers can then be 
placed on a menu for user selection and placement. The field specifier 
will contain virtual functions to format, display, validate and set the 
value of each field. A generic user interface object can then be 
constructed to use these methods for displaying and/or editing the field.

In any case, how does RTTI help ? You have a tool which will allow the 
user to create an input screen for any arbitrary object. How will knowing 
the class of the object to be displayed help ? What you really need to 
know is how to display/edit each property of an object of that class.

A debugger does, of course, require RTTI. At least one C++ debugger 
actually uses RTTI info placed in the executable by the compiler to 
identify the dynamic type of objects. However, this information IS NOT 
ACCESSABLE TO THE PROGRAMMER.

The only use I can see for RTTI is downcasting. The only places where I 
have found it expedient to do downcasting are in efficient implementations
of Collection templates. I also feel very uncomfortable about it, as I 
know my Collections are not really safe - I should fix this by making my 
base collection class publicly read-only (by making all the non-const 
members protected), but I haven't yet.

I haven't properly got to grips with mixins yet, but I have a glimmer of 
understanding that suggests that they might be used to solve many of the 
other problems which tempt you to use downcasting.
---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
Newsgroups: comp.lang.c++,comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 21 Jul 1992 16:26:59 GMT

In article <1992Jul20.215058.1216@cadsun.corp.mot.com> shang@corp.mot.com writes:
>Secondly, we both  
>agree that it is necessary to allow rediscovery of a type. 

	In general C++ programming I do not agree that it is
necessary to recover arbitrary type information. That is because,
quite simply, you CANNOT use it.

>What I disagree is  
>the argument that the design of heterogeneous collection is fundamentally  
>wrong, which, of cause, is not your statement.

	I think I should clarify here: I am arguing against
DOWNCASTING. 

	I am not against collections of objects all derived
from a common base provided you access them via the base.
That is the vey point of inheritance, after all.
In this case the objects are all of the same type:
it is homogeneous at the level it is accessed and
heterogeneous at the actual object level, but the actual
object level is not accessible.

	I am not against collections of objects of completely
unrelated types provided the types are drawn from a finite
and statically known set. In this case there is a 'type' which
is the finite union of those types, so again, the collection
is really homogeneous wrt that type.

	I am not against the two above combined either.

	I am against using, in general programming,
DOWNCASTING or run-time type information to defeat the type system.

	I agree that in Debuggers and other such programs
these facilities are essential, indeed, you need much more
than a mere safe downcast or run-time type code. In a debugger,
for example, you need in effect run-time access
to the complete declaration and definintion of each class in
the whole program!

	C++ does NOT have facilities at present to do this.
I am NOT against adding them. But I would be against using these
facilities in the general programming context for which C++
was intended and where such mechanism are *dangerous*.

	Clearly, for example, a debugger which allows you
to modify instances of a class breaks encapsulation!
It breaks almost every principle you can think of. 
It is meant to: you use the debugger when a more important
thing is already broken : your program :-)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: michael@xon.co.uk (Michael J Marshall)
Newsgroups: comp.lang.c++
Subject: Re: template argument as base class
Date: 24 Jul 92 10:39:44 GMT
Organization: X-ON Software - London, England
X-Newsreader: Tin 1.1 PL4

stefan@mpi-sb.mpg.de (Stefan Naeher) writes:
: 
: Does anyone know a workaround for the following problem.
: ...
: A possible application is the implementation of data types with implementation 
: parameters, e.g., dictionary<skiplist>, dictionary<red_black_tree>, ....

Perhaps try something like:

template <class T> class container
{
private:
	T data;
public:
	....
};

This should give you the implementation control you are seeking. I can see
interfacing issues being a problem - you will need to ensure that the
interfaces to the classes used as T in the template are similar (if not
identical) or you're going to have trouble.

FYI, Borland's 3.x C++ products have a class library with template
implementations that do what you want. If you want me to post some details
on the net, e-mail me, and I'll post an article on how they go about it.
Warning: it's NOT trivial!

My 2p worth

Michael

= Michael John Marshall - michael@xon.co.uk = B0ftg+k-s(+)h-r-
=   X-ON Software - 21 Great Tower St, London EC3R 5AQ ENGLAND
=   H 071 281 7056 - W 071 522 0088
= Last night I played poker with a deck of Tarot cards -
= I got a full house and four people died - Steven Wright
Newsgroups: comp.lang.c++
From: elston%boot.decnet@edwards-tems.af.mil (Mark Elston, NSI Inc., Edwards AFB CA)
Newsgroups: comp.lang.c++
Subject: GCC on VMS Systems
Date: 29 Jul 92 23:36:26 GMT
Organization: T&E Mission Simulator - Edwards AFB, CA

Thanks to those who responded to my request for information on the availability
of GCC for VMS.  I downloaded the port on MANGO.RSMAS.MIAMI.EDU and, after a
brief run-in with the KITINSTAL.COM file got the system up and running (sortof).
(Special thanks to Mats Bergstrvm).

Now I just need the privs to put the shareable libraries in sys$common....

BTW, (I have yet to wade through all the info files) is there anyway to force
the compiler to look in GNU_CC:[INCLUDE] for GCC and 
GNU_CC:[INCLUDE],GNU_CC:[GXX_INCLUDE] for GCC/PLUS without having to state
it explicitely on the command line each time I do a compile?

Thanks again for all the help.

Mark.


-------------------------------------------------
Mark Elston
elston@edwards-tems.af.mil
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: virtual madness - problem with virtual base class
Organization: TauMetric Corporation
Date: Mon, 27 Jul 1992 18:28:58 GMT

mat@uunet.uu.net!mole-end writes:

>Casting of pointers in C is pure `bitblt.'  In C++, it can imply conversion.

Actually, casting of pointers in C can also involve conversion.  To
take a homely example, casting a near to a far pointer (or the reverse)
on Intel architectures certainly involves conversion, since they are
not the same size.  There are machines where pointers to some types
(especially char*) are different sizes, or have different formats, than
pointers to other types.

For these reasons, the C Standard is careful to say that casting
among different pointers is not guaranteed to work, and that a
conversion is in general involved.  The result of a cast is a value,
not an lvalue.  (Some compilers allow casts to be treated as lvalues
under some poorly-defined circumstances.)  This characterization of
pointer casts was not an invention of the ANSI C committee, by the
way, but appears in K&R1.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: chew@hplchew.hpl.hp.com (Chee Chew)
Newsgroups: comp.lang.c++
Subject: Re: HELP with overloading binary operator...
Date: 28 Jul 92 19:11:58 GMT
Reply-To: web@athena.MIT.EDU
Organization: Hewlett-Packard Laboratories
To: smneyln@ariel.lerc.nasa.gov

In article <28JUL199210114546@ariel.lerc.nasa.gov>,
smneyln@ariel.lerc.nasa.gov (Michael Neylon) writes:
|>I have the following class...
|>
|>classs ARRAYBASE {
|>private: float matrix[MAXSIZE][MAXSIZE];
|>public: int xsize, ysize;
|>	ARRAYBASE(int x, int y) {xsize=x+1;ysize=y+!;};
|>// put + get handlers
|>// overloaded operator= which is fine
|>// Inverse() function, taken from _Num. Rec. in C_
|>	ARRAYBASE ARRAYBASE::operator*(ARRAYBASE array1, ARRAYBASE array2)
|>	{
|>		//fill the array using matrix multiplication
|>		//fill in matrix[][] and xsize, and ysize vars
|>		return *this;
|>	};
|>};
|>

since your * is  a non-static member function, it takes one argument
(your array2).  Array1 will be
the "this".

a function overloading * will take two arguments if it is a static
member, or a non member function.

-Chee
Newsgroups: comp.lang.c++,comp.std.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: Language extensions for run-time type identification
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Tue, 21 Jul 92 14:31:31 GMT

In article <14ft2uINNjh4@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe  
Buck) writes:
> * the virtual impossibility of designing a more general solution that does
>   not break compatibility with C structs (a requirement that may be
>   meaningless to theoretical folks but that is nevertheless vital).
>   This constraint forbids adding any data to the object of any kind.
>
The object code does not necessarily include any code about the type  
information. Encoding vtable references into object code is a particular way  
applied by the current C++ implementation. For a complete solution to run time  
type check, this technique must be changed. I've mentioned several times, the  
"tagged pointer" technique is the proper way to achieve this goal. Only those  
polymorphic pointers need to be tagged (not all pointers). The tagged pointer  
is not an overhead since it already eliminates the necessity to tag an object. 
 
> * the fact that it is trivial to force any class for which run-time type
>   identification is needed to have a virtual function table (simply add
>   a virtual destructor).
>
Adding something virtual just for the purpose that has nothing to do with it?

> In most implementations of classes with virtual functions, each object
> already has, in effect, a type-ID: the pointer to the virtual function
> table.  This is a natural hook on which to hang run time type checking.
>
The pointer to vtable can not work as a type-ID for a language with multiple  
inheritance. An object of particular class derived from multiple bases may  
contain serveral different vtable references. Different base pointers to the  
same object may use different vtable pointers.
 
> I could also argue the other way: for a debugger, it isn't enough to
> identify all class objects.  I also need to be able to identify the
> types of any int, double, pointer, or reference variables.  There's no
> inherent reason why being able to identify all classes, but no other
> variable types, is a more natural or useful division that just being
> able to identify objects that have virtual functions.
> 
I fully agree with you when you argue the other way. In fact, it is possible  
and practicable to identify any types and classes, no panelty on object codes,  
especially for those objects of conventional C types. The only panelty is an  
additinal integer (used as internal type identifier) for each type or class.  
But we can benefit a lot: integrating conventional C types into class hierarchy  
without additional overhead, explicit run time type check to prevent all the  
type error at compile time, type-safe cast, to solve problem with "sizeof"  
operator, problem with pointer increasement and decreasement, problems with  
covariant type in derived classes, and many many other interesting things. 

David Shang
Newsgroups: comp.lang.c++
From: iwirawan@tartarus.uwa.edu.au (Indra Wirawan)
Subject: Re: Borland C++ Programming for Windows
Organization: University of Western Australia
Date: Sat, 25 Jul 1992 20:26:58 GMT

em@jyu.fi (Erkki Mattila) writes:

>I would like to know a good (i.e. quick) mail order source for the following
>book:

>	"Borland C++ Programming for Windows" 
>	by Peter Norton and Paul Yao, Bantam Books 1992. 

>I inquired about it at a local book store and they told me that the delivery 
>would take 3 months. And that's way too long for me. So, could anyone either
>buy the book for me and send it to me (I would, of course, pay all your costs)
>or recommend a good mail order company?

>I would also appreciate it if you could list other good books on Windows
>programming with C++ or, possibly, send me a copy of a relevant book review.

>Regards,

>Erkki Mattila

>internet: em@jyu.fi
>address: Aarnipolku 2 B 3
>	 SF-40600 JYVASKYLA
>	 FINLAND
>-- 
>*****************************************************
>** Erkki Mattila, University of Jyv{skyl{, Finland **
>** Internet: em@jyu.fi  Telephone: +358 41 621 169 **
>*****************************************************

 I purchased a book "Developing Windows Applications With Borland C++ 3"
 written by James W. McCord which is published by SAMS publishing co.
 After I read it, I found this book is very good for beginner who eagerly
 wants to get started in Windows programming world. I paid AUD$61.95
after three months later I found the price already increased to AUD$80 !
 If you want more depth treatments why not you opt to Charles Petzold's
book on windows programming. His new book covering Windows 3.1 is
coming soon.

Cheers

 Indra

-------------------------------------------------------------------------
Indra Wirawan
The University of Western Australia
Nedlands, W.A. 6009
e-mail: iwirawan@tartarus.uwa.edu.au
        wirawa_i@kultarr.cs.uwa.oz.au

               "For things we have to learn before we can do them.
                We learn by doing."
                                    Aristotle
------------------------------------------------------------------------


Newsgroups: comp.lang.c++
From: dpg@extro.ucc.su.OZ.AU (D P Gilbert)
Subject: Re: Language extensions for run-time type identification
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Sat, 25 Jul 1992 00:06:46 GMT

mat@uunet.uu.net!mole-end writes:

[Some nested stuff removed.]

>There's another group of classes for which polymorphic behavior makes
>little sense: those that are used to implement or provide data structures
>(lists, trees, etc.)

I agree with the general thrust of your argument but I think I know at
least one exception to the above generalisation. A base class supporting
nodes in a multi-way tree may like to order its children by some criteria
supplied by its derived classes (i.e. a "virtual int compare(Node &)"
method). Also I'd like to be able to recursively clear down the tree
via the base class pointers. This requires virtual destructors in
order to work.
>-- 
> (This man's opinions are his own.)
> From mole-end				Mark Terribile

> uunet!mole-end!mat, Somewhere in Matawan, NJ
Doug Gilbert
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Help W/ Generics in C++
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 21 Jul 1992 15:27:23 GMT

In article <1992Jul20.132106.1@vmsb.is.csupomona.edu> cvadrsvk@vmsb.is.csupomona.edu writes:
>
>
>I am new to C++.  I have programmed in C for about 5 years and now want to 
>use features of C++.  I have also programmed in Ada to a limited extent.
>In Ada generic packages may be created.  Can someone assist me in describing 
>how this is implemented in C++.  The application I am working on is the
>implementation of a B+Tree System.  I would like to be able to hand a 
>"generic" object the data structure for the records along with the operator to
>compare the structure and have the internals of the file system completly
>hidden.
>

	Pretend you writing a class to make a B+Tree of T objects.
Now just put

template<class T>

on the line before the class declaration.
You also need to add <T> in various places to make it work.


-- 
;----------------------------------------------------------------------
        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: ted@aps1.spa.umn.edu (Ted Stockwell)
Subject: NIH question
Organization: Univ. of Minnesota Astronomy Dept., APS Lab
Distribution: comp
Date: Thu, 23 Jul 1992 16:07:04 GMT

Has anyone had any experience using the NIH class library with 
Solbourne's OI toolkit (X windows)?  Any pitfalls?

Is there a mailing list for NIH issues?
--
"It's not the bullet that kills you, it's the hole."  -- Laurie Anderson
Ted Stockwell, ted@aps1.spa.umn.edu, estockwe@phi.com
Xref: sparky comp.lang.c++:11698 comp.editors:1840
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.c++,comp.editors
Subject: Re: Undoing, Emacs and unlimited files ... summery.
Date: 28 Jul 92 16:49:59 GMT
	<NMOUAWAD.92Jul27131847@math.waterloo.edu>
Followup-To: comp.lang.c++
Organization: Department of Computer Science, University of Manchester
In-reply-to: nmouawad@waterloo.edu's message of 27 Jul 92 17:18:47 GMT

In article <NMOUAWAD.92Jul27131847@math.waterloo.edu> nmouawad@waterloo.edu (Naji Mouawad) writes:

   As far as "total undo" is concerned, I did not get any detailed
   answer. It seems that this has to do with "logging". A technique for
   keeping a log file of all the events that took place while the file
   was edited. Apparently there is a lot of activity going-on within the
   data-base community in order to find good ways for implementing the
   logging technique.

A while ago I posted a little survey of different editors and in
amongst them was "sam" by Rob Pike.  This does "logging" as mentioned
above.  "sam" can undo _any_ operation except reading/writing a file.

The editor is described in Software Practice and Experience, around
1989 I think.  I'm sorry I don't have the full reference as I don't
have a copy of the message anymore.  Maybe somebody else can supply it.
If anybody does have a copy of my article, could you also send it to
me I don't have the orgininal anymore :-(

bevan