HDTenEightyP/NetNews huggingface dataset:
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: HELP: mixing const and non const function
Date: 22 Jul 92 00:14:47 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Jul21.182115.1@cuavax.dnet.cua.edu> 48ganelin@cuavax.dnet.cua.edu writes:
> I want to declare a function to be constant though it
> uses a nonconstant function.
> (Of course it is an error for usual situation, but see example)

The example code is
class foo {
    int vector [10] ;
public:
    int& operator () (int at)  { return vector[at] ; }
};

class foo2
{
   foo f ;
   int median (void) const { return f(5); }  // const violation
};

You can get the effect you want by changing foo to

class foo {
    int vector [10] ;
public:
    int& operator () (int at)  { return vector[at] ; }
    const int& operator () (int at) const { return vector[at] ;}
};

foo2 will now use the const version in its median function.



--
Joe Buck	jbuck@ohm.berkeley.edu
From: cok@sunshine.Kodak.COM (David Cok)
Newsgroups: comp.lang.c++
Subject: Re: ztc 3.0 bug Ternary operator & chars
Date: 25 Jul 92 02:57:46 GMT
Article-I.D.: kodak.1992Jul25.025746.13323
Organization: Eastman Kodak Co., Rochester, NY

In article <1992Jul21.162222.9895@taumet.com> steve@taumet.com (Steve Clamage) writes:
>It really is a bug.  The code in question looked like this:
>
>	cout << (expr) ? '1' : '2';
>
>
>This means that "1" or "2" should be printed, not "49" or "50".
>-- 
>
>Steve Clamage, TauMetric Corp, steve@taumet.com
>Vice Chair, ANSI C++ Committee, X3J16

Watch it!  << binds more tightly than ?: so the above is parenthesized as

	(cout << (expr)) ? '1' : '2';

which isn't what you wanted.

David Cok
cok@Kodak.COM
Newsgroups: comp.lang.c++,comp.std.c++
From: wmm@world.std.com (William M Miller)
Subject: Re: Language extensions for run-time type identification
Organization: Software Emancipation Technology, Inc.
Date: Sat, 25 Jul 1992 17:08:05 GMT

I'd like to make a short comment about the rationale for providing
RTTI only for classes with virtual functions -- even though I
suggested what I considered to be a practical way of providing RTTI
for classes without virtual functions (not tagged pointers, BTW), I
can understand the reasoning for restricting RTTI.  It's not just
convenience in piggybacking onto existing technology, although that is
an attractive aspect of the current proposal.  The real question is
when RTTI is likely to be used.

Consider this: dynamic typing is only required when you've "lost" the
exact type of the object to which an expression refers.  In all other
cases, the static type of the expression is sufficient, and the
compiler can just provide a direct reference to the typeinfo if the
program requests type information.

There are only two ways to "lose" the exact type in C++ (apart from
explicit casting to an unrelated type, for instance): conversion of a
pointer/reference to a derived class into a pointer/reference to a
base class, and conversion to void*.  Doing something about the latter
is either very expensive or requires breaking compatibility with C
void* pointers (tagged pointers), so realistically we are talking
about a requirement for RTTI that *only* has to deal with the results
of derived-to-base conversions.

The question, then, is under what circumstances do such conversions
occur?  The premise of the current proposal is that you don't *do*
such conversions unless you have provided for polymorphic behavior,
i.e., virtual functions.  Inheritance for factoring and sharing of
representation and code is fine, but in such applications you
typically don't rely on derived-to-base conversions.

The challenge, then, for those who view RTTI-via-vtable as
insufficient is to provide *concrete* counterexamples to this
assumption: applications where derived-to-base casting does occur
without the need for virtual functions and for which RTTI would
nevertheless be useful.  Are there such applications?

-- William M. Miller, wmm@world.std.com
Newsgroups: comp.lang.c++
From: eb@ascent.com (Ed Barton)
Subject: Re: suggestions for global constructors
In-reply-to: maxtal@extro.ucc.su.OZ.AU's message of Tue, 21 Jul 1992 16:32:23 GMT
Date: 27 Jul 92 10:36:09
	<1992Jul21.163223.25728@ucc.su.OZ.AU>
Organization: Ascent Technology, Inc., Cambridge Massachusetts

In article <1992Jul21.163223.25728@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

   >>Has anyone come up with any good ways of ensuring that static variables
   >>are instantiated before they are used?

	   They wont, ever. Because it can't be done. It is equivalent
   to the halting problem.

I'm afraid I find this position rather silly.  I presume you are
saying that the compiler or linker would need to decide whether 

	if (f()) g(var);

would actually call g() or not, and of course it can't tell that.  But
I can't believe that we're stuck with a choice between (a) solving the
halting problem, or (b) having a language in which nonlocal variables
of class type are unusable.

    My copy of ARM says that the initialization of nonlocal static
objects in a translation unit is done before the first use of any
function or object defined in that translation unit.  Perhaps my copy
is too old, and for all I know the new ARM might say that you can't
usefully have nonlocal variables of class type.  I understand how it
can be problematic to implement this, and I wouldn't be surprised if
none of the compiler vendors have it right.  But just the same, I
don't think it's impossible.  What I would expect to happen is the
following:

	Find all inter-module references, where a function in module A
	  uses a function or variable in module B.
	Use a topological sort or something to determine an order for
	  running the constructors that is consistent with the order of
	  the inter-module references.
	If no consistent order is possible, produce an error or warning
	  at link time.

In other words, I would expect to get an error when the compiler can't
find a way to satisfy the ordering requirement.  I would not expect
the compiler to solve the halting problem.

    Informally, I would probably regard a solution to the ordering
problem as adequate if it allows me to put classes that have static
data members in a library, and to have the library's static data
members properly initialized before the application's initializations.
Note that there can be dependencies between different library classes,
and that I can't tell when writing the library which modules of the
library will be used by an application.

	   The best solution is to make sure there are no interdependencies.
   One way to do this is to avoid global variables of external linkage.
   They have very limited use anyhow.

IMO this is not a solution.  The same problem arises with static data
members in a class.  It even arises with global variables that are not
of external linkage (i.e., static variables), because the
initializations for another file may call a function in the first file
which references a static variable in the first file.  I can't agree
that static data members of class type are of very limited use.




Newsgroups: comp.lang.c++,comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Language extensions for run-time type identification
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 25 Jul 1992 18:40:58 GMT

In article <1992Jul25.072522.4316@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
>In article <1992Jul24.142452.756@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>> In article <1992Jul23.183041.147@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
> 
>> 	But I would make that argument backwards.
> 
>> 	One often wants het. aggregates of unrelated types.
>> 	Actually, these are aggregates of the *same* type,
>> namely, the union of the unrelated types.
>
>No, they are aggregates of objects which share some common property
>represented by some base type.

	No wait, I said we often want aggregates of *unrelated* types.
You cant change that on meb and say they have a common base!

	Example: aggregates of numbers, some float, some int.
	There's no common base here.

	Example: baskets of fruit. No common base desired.
	(the baskets are just for eating, the fruits have no
	properties of interest)
>
>A union of three types, related or unrelated, is not any of those types.
>It is something else.

	Yes, it is the union of the types. Which is a type.
> 
>> 	On the otherhand, polymorphism is the mechanism by which
>> the derived type NEED NOT BE KNOWN. Indeed, if we are to preserve
>> the open/closed principle, MUST NOT BE KNOWN.
>
>Not so, since the current RTTI proposal would not look past private
>derivation.

	I think you are confused here (but it might be me :-)

	Private derivation hides the BASE class.
	A reference to a base class hides the derived class.
	THAT is requires by the open/closed principle,
the derived class --- JUST LIKE THE PRIVATE part of the
base class --- is IMPLEMENTATION DETAIL and MUST BE HIDDEN
for the SAME REASONS.
>
>> 	So you (well, X3) is considering using RTTI in
>> precisely the case it is not needed, and not supplying it
>> when it actually could be useful :-)
>
>You are offering a type system error (union of A, B, and C as either
>an A or a B or a C) instead of using the type system to support the
>commonality deliberately programmed into the types.

	But you want the type system not to support the commonality
(which it already does--thats called polymorphism )
but to support the non-common bits.
>
>(Anyone got a good intro to either classical or modern category theory?
>And I don't mean the mathematical muddle on morphisms ...)

	Tis not a muddle: tis a superb theory (the mathematical one).

>-- 
> (This man's opinions are his own.)
> From mole-end				Mark Terribile
>
> uunet!mole-end!mat, Somewhere in Matawan, NJ


-- 
;----------------------------------------------------------------------
        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: mat@mole-end
Subject: Re: Speed, Correctness, Availability, and the Real World
Organization: :
Date: Tue, 21 Jul 1992 13:41:43 GMT

In article <1992Jul21.011256.1404@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> In article <1992Jul18.214750.12347@mole-end> mat@mole-end writes:
> |I beg to differ.  What _does_ seem to happen is that if you don't participate
> |in the live discussions, you don't appreciate how much analysis is needed,
> |or the problems of communicating with others present.  
 
> On the contrary, I haven't been there, yet I DO appreciate the problems.
 
> |If you haven't seen
> |it happen, you just can't provide what's needed.  (So I testify, having been
> |there.)
 
> As one WG member told me, "tough nuggets."  I can't be there, so this is
> besides the point.  If committee members cannot communicate what's needed,
> then they certainly cannot communicate what is required of C++ programmers
> and C++ compiler implementors via a written document called a "standard."
> If it is impossible for them to communicate via written form, such as by
> letters or by email, then the issue of this written document called 
> the "standard" is moot.

Ok.  Let's try some things on for size.  (I'm taking some text out of
order here.)

> If some "analysis" of operator.() remains to be done, then how come neither
> you nor any other committee member is willing to identify for me EXACTLY
> WHAT issues remain to be addressed?  I submit on the contrary, if neither
> you nor any other committee member is willing to identify to me EXACTLY
> WHAT issues remain to be addressed, then there ARE NO such other issues
> that remain unaddressed.

First, take some of Coplien's examples (or your own) and show how they
would look if your version of  operator.()  is implemented.  Interlard
the before and after in the paper.  Give consideration to interactions
with other things (e.g. overloading and function signatures) because
people _will_ want to use them together in expressions.

Second, gather up the miscellaneous issues that we've been kicking around
on this newsgroup and incorporate them into the right places in the
proposal.  Then let's you and me and a few others get together by email
and work the proposal over end-to-end.
 
> BUT, I HAVE BEEN asking WG committee members of these "other" proposals
> you mention for about the last year, and none have been willing to
> send me a copy of these "other" proposals.  HOW can I address these
> "phantom" proposals if no one will show them to me?

Let's get together on e-mail about these.  You'd be surprised what can
be done on a small-circulation mailing list.  We have until very late
fall; that's enough time if we start now.

> Then send me a copy of these alternative proposals, and I will write
> up such a comparison from my point of view.  Even if you disagree with
> my "analysis" I will take at least some of the burden off of you and
> the other committee members.

Right now, none of them has much favor.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: dougm@titan.cs.rice.edu (Doug Moore)
Subject: Re: New C++ type: boole
Organization: Rice University Computer Science, Houston, Texas
Date: Mon, 27 Jul 1992 02:03:16 GMT

It has been suggested in one piece of mail that my response to Mr.
Henderson's criticisms were "antagonizing", and in another piece of
private mail that I accused him of lying.

It was my intent to attack Mr. Henderson's arguments, which I found
wanting, and not Mr. Henderson himself.  I respect his, or anyone's,
right to disagree on matters of taste.  But I felt that all of his
arguments were matters of taste, not "holes" in a proposal.

I certainly did not mean to accuse Mr. Henderson of lying.  I can only
assume that the correspondent refers to that point at which I suggest
that, while Mr. Henderson says he finds the proposal flawed, he really
just prefers not to have a boolean type.  I did not mean to accuse Mr.
Henderson of duplicity in this.  I meant only that the "flaws" he
presented were more in the nature of stylistic objections, most of
which could be applied to any proposal for a boolean type.  I'm sure
he honestly considered his list to be a list of flaws.

So, I apologize to Mr. Henderson, and to the net, for appearing to
call him a liar.

I still disagree with him.  I'll try to disagree more carefully in the
future.

Doug Moore
(dougm@cs.rice.edu)

This program posts news to thousands of machines throughout the entire
civilized world.  Your message will cost the net hundreds if not
thousands of dollars to send everywhere.  You will offend hundreds of
people you don't even know.  Please be sure you know what you are
doing.
Newsgroups: comp.lang.c++
From: mat@uunet.uu.net!mole-end
Subject: Re: Covariant Types in Derived Classes
Summary: Extended Type Info, NOT RTTI
Organization: :
Date: Sun, 26 Jul 1992 02:57:56 GMT

In article <712030928snx@trmphrst.demon.co.uk>, nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
 
> 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.

RTTI doesn't provide enough information for this; a second facility that
may or may not happen, called Extended Type Information, will be needed.
ETI is very desirable to support persistance, OODBMs, Remote Object Dispatch,
etc.  Whether it can be done at acceptible cost has yet to be determined.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++,comp.editors,comp.compilers
From: xorian@solomon.technet.sg (Xorian Technologies)
Subject: Re: Looking for editors and parsers for C++
Reply-To: xorian@solomon.technet.sg (Xorian Technologies)
Organization: National University of Singapore
Date: Mon, 27 Jul 1992 01:43:18 GMT
Keywords: C++, parse

Jan Skarvall write :-

: I am also interested in parsers and parser generators for C++ for the same
: reasons.

Our parser generator LADE is able to generate a C++ parser with 0
shift-reduce and 0 reduce-reduce conflicts.  We are also in the process of
writing a C++ parser which will be ready soon.

: We are currently using C++ 2.1.

As far as the parser is concerned there is little difference between 2.1
and 3.0, since template and exception handling has more impact on the code
generation part.

: [Jim Roskind's yacc C++ parser is available in the compilers archives, but
: I'm not sure that'd much help for building an editor. -John]

The problem with Roskind's grammar is that in order to resolve the many
significant ambiguities in C++, Roskind "macro expanded" the productions
involved. While he resolved most of the conflicts, he created monster of a
grammar which bears little resemblance to the specification and is
extremely difficult to use in practice. Based on our own experience and
that of our clients, we strongly recommend against the Roskind grammar for
anything more than simple syntactic checking.

KG Loh
Xorian Technologies Pte Ltd
389A Balestier Road
Singapore 1232
Republic of Singapore
Tel: (65) 255-7151
Fax: (65) 253-7709
email: xorian@solomon.technet.sg
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: garry@alice.att.com (garry hodgson)
Newsgroups: comp.lang.c++
Subject: C++ headers --> Man pages?
Keywords: looking for a tool (genman?)
Date: 21 Jul 92 20:47:22 GMT
Article-I.D.: alice.23265
Organization: AT&T Bell Laboratories, Murray Hill NJ


Sorry 'bout this if it's a FAQ, but here goes.  I vaguely
recall old discussions about a tool or tools to produce
man pages from C++ header files.  Where might I find such a beast?

thanks,

Garry Hodgson

-- 
Garry Hodgson			A slow winter day
AT&T Bell Labs			A night like forever
garry@alice.att.com		Sink like a stone
att!alice!garry			Float like a feather
Newsgroups: comp.lang.c++
From: balasubr@bellahs.com (Balasubramanian RD)
Subject: proceedings of c++ conferences
Organization: Bell Atlantic Healthcare Systems
Distribution: usa
Date: Wed, 29 Jul 1992 00:49:24 GMT

Does any know if the "c++ at work" conference publishes its proceedings? 
I'll appreciate any information on how I can get hold of them (assuming
they do publish.) Thanks.
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c++
Subject: Re: How to avoid calling destructor twice after fork()?
Date: 29 Jul 1992 20:41:59 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Jul29.180655.4716@cis.ohio-state.edu> gyu@cis.ohio-state.edu (george yu) writes:
>I am using fork() system call in my C++ program. The problem is that each
>calling of fork() creates a copy of calling process. The problem is any
>instances created and not destroyed before fork() calling will be 
>destroyed twice.

For most purposes, this should be OK.  Each process has its own copy of the
object, so if the destructor is used to deallocate space it's necessary to
do so in each process.

But if the destructor communicates with external entities, I can see how
this would be incorrect.

I don't think you can prevent the destructor from being called.  However,
you can have the destructor skip the parts that shouldn't be done twice.
After forking, you can set a member in the object that indicates whether
it's the parent or child's copy, and the destructor can look at this member
to decide how to behave.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.c++
Subject: Re: C++ Return Types
From: kramasamy@vax1.umkc.edu
Date: Tue, 21 Jul 1992 17:23:54 GMT
Organization: University of Missouri - Kansas City

In article <23240@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
> In article <1992Jul19.152207.1@cstp.umkc.edu> pkailasam@cstp.umkc.edu writes:
> 
>> 	bitmap &bitmap::operator |(const bitmap &bm)
>> 	{
>> 		bitmap *bm1 = new bitmap ;
>> 		
>> 		// Do the necessary operations in the bitmap pointer bm1
>> 
>> 		return *bm1 ;
>> 	}   
> 
> Thereby allocating a bitmap every time the function is called
> and never freeing it.  How about the obvious approach:
> 
> 	bitmap operator| (const bitmap& x, const bitmap& y)
> 	{
> 		bitmap result;
> 
> 		// build up the result in `result', then...
> 
> 		return result;
> 	}
> -- 
> 				--Andrew Koenig
> 				  ark@europa.att.com

	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?


-karthik

karthik@vax1.umkc.edu


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: Mon, 27 Jul 92 17:36:14 GMT

In article <1992Jul26.014223.6153@uunet.uu.net!mole-end>  
mat@uunet.uu.net!mole-end writes:
> 
> How about this:
> 
> 	Derivation is only useful when used properly with virtualization.

I disagree. Without virtualization, derivation is still useful in code reuse.  
Virtualizaton only makes derivation more powerful in express polymorphism.

> 	Virtualization is only meaningful in the context of derivation.

I disagree. Virtualization actually is a kind of specialization. In addition to  
virtual functions, we can also have vitual types and virtual constants.  
Therefore, virtualization is actually a kind of parameterization. If we design  
class structure in this way: a class can be parameterized with a type, a  
constant, and a function, then, virtualization is still meaningful and useful  
without derivation.

> 	Only derivation can make use of RTTI.

I disagree. Derivation needs RTTI does not mean that only derivation needs  
RTTI. Parameterization needs RTTI too (of cause, it is not the C++ template).

>   therefore
> 	RTTI is only useful in the presence of virtualization.
> 

Since I agree to none of the assumptions, I cannot agree to the conclusion  
either.


David Shang
Newsgroups: comp.lang.c++