HDTenEightyP/NetNews huggingface dataset:
From: dyoung@gizmo.wpd.sgi.com (Doug Young)
Subject: Re: C++ and XtAddEventHandler()
Reply-To: dyoung@sgi.com
Organization: Silicon Graphics, Inc.
Date: Mon, 27 Jul 1992 20:00:47 GMT

|> Excerpts from netnews.comp.lang.c++: 20-Jul-92 C++ and
|> XtAddEventHandler() by zhaocuie@iscs.nus.sg 
|> >I'm using C++ to develop a GUI builder based on Motif, Xt, and X11.
|> >Now I'm facing some problems. I need to call an Xt convienent function
|> >        XtAddEventHandler(_w, event_mask, nonmaskable, proc, client_data)
|> >to popup Motif popup menus. I wrote the codes as follows:

|> > 
|> >        void Simple::postItEventHandler(Widget, XtPointer clientData, XtPointer)

|> >It does not work. The compiler said:
|> >        error: bad argument 4 type for XtAddEventHandler(): void (*) (Widget,
|> >        XtPointer, XtPointer) (XtEventHandler expected)


Xt event handlers, after R4, have a fourth argument, Boolean *, which you
are not including, therefore making the type of your function incorrect.
Change your function declaration to:

  void Simple::postItEventHandler(Widget, XtPointer clientData, XtPointer, Boolean *)

and all should be well.

Doug Young
From: thssmdt@iitmax.iit.edu
Newsgroups: comp.lang.c++
Date: 17 Jul 92 22:10 MDT
Subject: X3J16 spec
Nf-ID: #N:1992Jul17.181021.17378@iitmax.ii:1059225064:001:67
Nf-From: iitmax.iit.edu!thssmdt    Jul 17 22:10:00 1992


Can anyone tell me how I can get a copy of the latest X3J16 spec?


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: Wed, 22 Jul 92 15:03:30 GMT

In article <1992Jul21.094204.20100@mole-end> mat@mole-end writes:
> 
> The assumption underlying the decision to include only classes with
> virtual functions is that a class that has no polymorphic behavior
> whatsoever (not even a virtual destructor) cannot be used in any way
> that is both safe and interesting even with the proposed runtime type
> support.  Can you refute this assumption?
> -- 


Yes.

First of all and to be specific to C++, it is the class hierarchy, or  
inheritance and the polymorphic pointers that lead to the necessity of run time  
type checking. It is not the virtual behaviors of a class. We still need run  
time type check even if we disallow any virtual behaviors in C++. Therefore,  
the assumption is laid on the wrong ground. I can only accept this assumption:  
run time type check is not necessary for any argument that is sepcified by a  
sealed class or that is sealed itself. Here "sealed" means "no derived" or  
"cannot be used to derive".

Secondly, the real reason to limit the current proposal to classes only with  
virtual behaviors is not that classes without virtual behaviors are not  
necessary to be run time type checked. The real reason is an  
implementation-dependent issue: classes with virtual functions have vtables  
which can be used to store the run time type info, and it is impossible to  
create a vtable or some equivalent for each class or even the conventional C  
type since this would require each object to carry an overhead, even a simple  
integer or a character. This problem is cuased by the limit of the current C++  
implementation, not by the C++ language itself. We do have a proper  
implementation alternative as applied in other strongly-typed OO langauges that  
can support a complete run time type check. My question is: why should we add  
an imperfect language concept that is limited by the current implementation?

David Shang
From: rpost@cellar.org (hamilton)
Newsgroups: comp.lang.c++
Subject: Borland vs. Microsoft (vs. Zinc)
Date: 19 Jul 92 03:51:52 GMT
Organization: The Cellar BBS and public access system

It seems to me, that the very fact that Zinc has a GUI that permits the
programmer to develop in any interface, indicates that Zinc has the more
superior GUI object.  Currently I am using ObjectWindows.  Unfortunately
Software Engineering requires we take other issues into consideration
besides natural law.  Namely, what is the size of the target base?
Companies developing products will not be interested if you know an
obscure, but better designed, system versus a well know but *kludged*
system.

What can you do?

See you in Pittsburgh...
From: weh@abasin.dr.att.com (William E. Hopkins)
Newsgroups: comp.lang.c++
Subject: Re: reference to C++ assertion macro package?
Keywords: C++, assertions, precondition, postcondition, invariants
Date: 28 Jul 92 23:21:08 GMT
Organization: AT&T Bell Laboratories

In article <1992Jul27.191336.6100@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
|> In article <1992Jul25.152611.18998@taumet.com> steve@taumet.com (Steve Clamage) writes:
|> |maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> |>	Does anyone have details of the proposed assertion
|> |>facility for C++?
|> |
|> |The <assert.h> facility from Standard C is part of C++.  I have not seen
|> |any proposals for anything else.  If in particular you mean something
|> |like the pre- and post-conditions for Eiffel classes, I haven't seen any
|> |discussion of them.
|> 
|> Overloading operator->() allows checking pre-conditions on pointers,
|> Overloading operator.() allows checking pre-conditions on references,
|> [if such were permitted] although neither with the convenience nor completeness
|> provided by Eiffel.

Annotated C++ (a.k.a. A++) appears to provide much of the same capability as
the pre- and post-conditions and invariants in Eiffel (as I mentioned in my
original posting).  A++ defines a notation and provides a preprocessor to
make it happen.

I'm still waiting for a response from a reference librarian on the two A++
references I posted earlier.  Since one of the authors is Doug Lea of
libg++ fame, maybe he knows of other papers on A++ that are more accessible
(I tried the GNU documents that come with Lynx/OS on the off-chance it would
be there...no luck!).

Bill Hopkins
william.e.hopkins@att.com
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: classes referenced each in their declaration
Distribution: world
Organization: Trumphurst Ltd.
Date: Fri, 24 Jul 1992 19:51:13 +0000


In article <1992Jul23.003724.13021@murdoch.acc.Virginia.EDU> gs4t@virginia.edu (Gnanasekaran Swaminathan) writes:
> Thanks for catching the bug. The following is tested
> in GNU C++ and it works.
> 
> class Y;
> 
> class X {
> 	Y&	y;
>     public:
> 	X(const Y& y1): y(y1) {}
> };
Is it permissible to assign a reference to const to a reference to non-
const in GNU C++ ?

I don't think it should be !
---
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
trmphrst.demon.co.uk is NOT connected with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
Newsgroups: comp.lang.c++,comp.std.c++
From: mat@mole-end
Subject: Re: Language extensions for run-time type identification
Organization: :
Date: Wed, 22 Jul 1992 09:17:52 GMT

Just a point of fact:

In article <1992Jul21.143131.6902@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:

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

Not quite true.  Those multiple vtable references in a complete object
all have to point to vtables whose only differences are their `offset
adjustments.'

This area has been studied to death and is being studied right now into
the twilight zone and while some problems remain, this is not one of them.
-- 
 (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: mat@mole-end
Subject: Re: Back from Toronto
Organization: :
Date: Mon, 20 Jul 1992 17:30:16 GMT

In article <1992Jul19.144507.10140@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> In article <1992Jul18.083446.9363@mole-end> mat@mole-end writes:
> >I've just returned from the Toronto meeting of the ANSI/ISO C++ committee,
> >on which I am a paid-up Observer member.  It was an instructive time, to
> >say the least.
> 
> 
> 	Thanks for your report on the meeting. (appertiser)
> 
> 	Now could I impose on you to tell us a little more,
> in your own good time of course, about what was actually
> under consideration? (main course please, we're all banging
> our cutlery :-)

Well, I spend my time with the Extensions WG, so there's a lot I didn't
see.

Let me explain a little bit.  The WGs are expected to report their
activities in brief to the committee(s) as a whole.  But if they are not
ready to recommend a proposal to the committee(s) as a whole, the
report may just be an item on a list, or it may be a brief description
with the request for a straw vote to `get the sense of the committee.'

So most of what I saw related to the Extensions WG.  After prioritizing
the list, we spent most of our time on (a) removing array allocation from
the global operators new and delete, (b) looking at ramifications of ~const
(a proposal which the WG likes a lot, but in a much-slimmed-down version),
and (c) working out the ramifications IN THE USE of type conversions in
the presence of runtime-checked conversions.

Each of these led down all sorts of interesting paths.  Each stands a
fair chance of producing a language improvement; (c) may result in a
major improvement.

Could these three topics really have taken two days in meetings?  Yes.
Around the table were compiler writers from at least three companies,
and representatives of users, of the NCEG, and of the object-extended SQL
communities, as well as Bjarne Stroustrup and an assortment of `cats
and dogs' (including m'self).
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Xref: sparky comp.lang.c++:11824 comp.std.c++:1000
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: Downcasting and mortal sin (was run-time type checking)
Date: 30 Jul 1992 22:51:13 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <2A784613.34A4@tct.com> chip@tct.com (Chip Salzenberg) writes:
>According to shang@corp.mot.com:
>>In article <2A75806A.826A@tct.com> chip@tct.com (Chip Salzenberg) writes:
>>> virtual boolean Animal::can_mate_with(const Animal&);
>>
>>I'm interested in the implementation of your "can_mate_with" in a derived  
>>class. Whould you show me how it is done without RTTI?

[Shang then puts a few other restrictions on him.]

>No, not okay.  I do not program with one hand tied behind my back.
>The complete language is always at my disposal.

OK, let me rephrase shang's challenge (and beat maxtal to the punch):

How can you implement can_mate_with() in such a way that the open/closed
principle is maintained?  This requires that you be able to add new derived
classes without having to modify the base class definition (which may be
shrink-wrapped, so the source is not available for modification).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: kanderso@kleber.ICS.UCI.EDU (Kenneth Anderson)
Subject: Linked list implementation of a stack.
Newsgroups: comp.lang.c++
Date: 21 Jul 92 22:08:26 GMT

Hi,

I am new to programming in C++ and I have yet to find an example of a stack
implemented as a linked list.  Every example that I have found, defines a
stack class which expects an int parameter that denotes the maximum number
of elements allowed on the stack.  They then use an array implementation for
the stack, with the int parameter defining how many elments are in the array.
I, personally, have never found an application area where this implementation
of a stack is useful.  So I was wondering if someone could post an example
stack class that does not use an array implementation?

I would really appreciate it, my first few attempts at doing so, have proved
to me that I really don't know enough about C++....

Thanks in advance,

Ken Anderson
(C++ novice...)
Newsgroups: comp.lang.c++,comp.lang.c
From: cblaise@moose.uvm.edu.UUCP (Chris Blaise)
Subject: Re: Borland charges before delivers
Originator: cblaise@moose.uvm.edu
Organization: University of Vermont -- Division of EMBA Computer Facility
Date: Tue, 21 Jul 1992 23:21:13 GMT

From article <1992Jul21.170432.5012@msuinfo.cl.msu.edu>, by christ@cps.msu.edu.cps.msu.edu (Oliver Christ):
> 
> The mistake was to go through Borland.  I got my copy in 2.5 weeks
> through a local dealer.  Advice:  The dealer probaly doesn't have
> it in stock.  Make them call their distributor to give you an exact
> estimate of how long it will take to get the copy, don't just 
> "take their word" for it!  Order times vary with dealers.

	My roomate who is a dealer for a small computer exchange/sale
place down here is constantly preeming himself on how, as a dealer,
he can get things faster than the average customer can.  Case in point,
the upgrade to the Ultima VII game.  Origin was telling people
to wait 3-4 weeks after sending in their orginals for the upgrade.  My
roomate had them back the next week...
 
 TTYL
 Chris

Newsgroups: comp.lang.c++
From: bradley@zeus.franklin.edu (Ken Bradley)
Subject: Possible bug in overloading of function names
Organization: Franklin University
Date: Fri, 31 Jul 1992 18:35:54 GMT



	Please excuse me if this has been posted before.  The following 
segment of code produces the following compiler messages on IBM's C++ compiler:

"override.C", line 17.1: 1540-055: (S) "double" cannot be converted to "char*".
"override.C", line 17.1: 1540-306: (I) The previous message applies to argument
1 of function "foo2::In(char*, int)".


class foo
{
public:
	virtual void In (char *, int) = 0; 
	void In (float, int) { cout << "Base Class In \n" << flush; }
};

class foo2 : public foo
{
public:
	virtual void In (char *, int) { cout << "Derived Class In \n" << flush;}
};

main()
{
	foo2 *foobar = new foo2;
	foobar->In(2.0, 1);
}


At first I thought this was an IBM compiler problem, and reported it to IBM
as such, but upon further investigation I have found that this problem shows
up on other compilers as well (HP's and Oregon's C++ for VMS).  This leads me
to believe that it is possibly a ATT cfront problem.  This code compiles
fine under gcc.  Any help on this problem would be appreciated.

-Ken
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Newsgroups: comp.lang.c++
Subject: Re: classes referenced each in their declaration
Date: 21 Jul 92 21:44:06 GMT
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia

qincao@cs.uh.edu (Qin Cao) writes:
>    I am implementing an interface with C++. I need to declare several classes
> which are referenced each other in their definition. If I used pointer, then
> it works fine, but I really want to use dot notation to refer the class
> member, instead of "->" notation when using pointer.  ...
> 
> class X;
> class Y;
> 
> class X {
>   int a;
>   Y b;          // if I put "Y *b;" here, it works fine 
> };
> 
> class Y {
>  int c;
>  X d;
> };

Please use references. I just tested the following in
the GNU C++ compiler.

class X;

class Y {
	X& x;
public:
	Y();
};

class X {
	Y y;
public:
	X() {}
};

Y::Y(): x(*new X) {}

-Sekar
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Standards decided via E-mail
Date: 21 Jul 92 22:29:20 GMT
Article-I.D.: alice.23268
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <660@manutius.UUCP> garyp@manutius.UUCP (Gary Powell) writes:

> 2) -> is already
> in the language, just use that instead. (Koeing and Strustrups' basic argument)

I've never made that argument.

My feeling about operator.() is that there there are several different ways
of doing it, that each way I've seen has advantages and disadvantages,
and that it would be a mistake to vote any particular version into the
language without some really solid evidence that it is the best choice.

Moreover, any discussions on operator.() will take place in the Extensions
working group, which meets at the same time as the Core Language working
group.  I chair the Core Language group, so I can't simultaneously
participate in the Extensions group.  Thus I'm not interested in spending
a whole lot of time to decide which of the alternatives is the best.

Finally, in the March meeting, the Extensions group voted on which extension
proposals they felt were worth considering at present.  The operator.()
proposal came out pretty low on the list.  That makes me even less interested
in spending time on it.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Efficient 64-bit integer arithmetic
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 25 Jul 1992 14:50:49 GMT

In article <711997458snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
>I need to implement efficient 64-bit signed integer arithmetic in C++ (or C)
>on a machine with a 32-bit long (actually, 60 significant bits + sign
>would do fine). 
>
>I need addition, subtraction, multiplication, division, remainder, and 
>efficient multiply and divide by 10 (for conversion to/from strings).
>

	Write one yourself. It is not so hard. There is (virtually)
a whole book on it: Seminumerical Algorithms, by Knuth.

	Basically, do it like high school long division/multiply/
add/subtract. To get the carry, do 16 bit operations with 32 bit
result, the high 16 bits are the carry. You should be able to write
add and subtract and multiply in about 1 hour. Division is a little harder,
because as you know from high school you have to estimate the quotient
digit, do a trial multiply and subtract, and the correct the estimate
if you were wrong. Knuth give a good algorithm to improve the estimate.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: dds@speedy.CND.HP.COM (Darren Smith)
Date: Fri, 24 Jul 1992 23:41:19 GMT
Subject: Re: Handling of operator . proposal
Organization: HP Network and System Management Division
Newsgroups: comp.lang.c++

|   "." is only an operator in the sense that "::" is, i.e., syntactically;
|   it's not a run-time operation, like all the currently-overloadable
|   operators are.

It is true that operator. is *currently* only a syntactic operation,
and not a run-time operation.  Why can't it be both?

Here's an analogy for you: function calls.  In both C and C++, you can
make function calls that are resolved at compile time (OK.  technically
at load time.  Never-the-less, not at runtime).  This is sufficient for
most uses, and is all that some languages offer.  However, we also
have these things called "function pointers", that allow you to
determine which function to call at runtime.  Yes, the syntax is slightly
different from regular function calls, so this is not a perfect analogy.
However, I think this is largely because of the history of "C".  The
concept of being able to do something at runtime that most of the time
can be determined at compile or load time is not unprecedented in the
language.  The operator.() proposal essentially allows you to do
something at runtime that is currently only done at compile time.

[ Side note:  Is that last statement really truly?  If I do something
like (*anobject).member, the offset to member will be evaluated at
comile time, but the actual location in memory is determined at
runtime. ]

The argument that operator.() is only a syntactic operation is
essentially a meaningless, though true, statement.  The question is:
is there a good reason that it should remain so?  That is the issue
that should be addressed when you say it's not a runtime operation.
What problems are caused by it having the possibility of being a runtime
operation?  Are they solvable?

Also, saying that operator.() is only a syntactic operation, says that
you will never support *any* proposal that makes operator.() overloadable
in a way that requires a runtime decision (I can envision a scheme that
could work at compile time only).  If that is truly your position, then
make that a separate argument from a critique of a given proposal.  That
way people can understand better your position, which is not that a
given proposal is bad, but that all proposals for overloading operator.()
are bad.

--
Darren Smith 	dds@cnd.hp.com 	229-2536	Hewlett Packard
--
From: leary@progress.COM (James Leary)
Newsgroups: comp.lang.c++
Subject: Re: BC++ 3.0 (Help !): Can't load Windebug.dll
Keywords: BC++ 3.0
Date: 27 Jul 92 13:29:06 GMT
Organization: Progress Software Corp.

iwirawan@tartarus.uwa.edu.au (Indra Wirawan) writes:


> I just installed BC++ 3.0 and everything looks fine except Turbo
> Profiler for Windows and Turbo Debugger for Windows. Here is my
> problem:
>     - Both T. Profiler and T. Debugger refused to load a file (EXE file
>       with its source code). The error message I received said "Can't 
>       load Windebug.dll" (I launched them from Windows 3.1).

>I've already checked that the file Windebug.dll exists in the same
>directory as T. Profiler and T. Debugger reside in.

>Have I done anything wrong ? (Path already set to include these
>executable files).

>Any suggestion will be appreciated.


You must either get the patch that Borland offered to correct these problems
or upgrade your compiler to Version 3.1.  Call the Borland Order desk for information.

Jim Leary
From: horvath@granite.ma30.bull.com (John Horvath)
Newsgroups: comp.lang.c++
Subject: Design of Constructors
Date: 30 Jul 92 21:19:45 GMT
Organization: Bull HN Information Systems Inc.
Originator: horvath@granite.ma30.bull.com

Executive summary: If constructors can't return values, is it their intent
they should not try to do anything that can fail?
-----

  Constructors are suppose to be the place were a class's
initialization takes place. Since they can't return a value (directly),
it seems that the only initialization that they should be doing is
stuff that can't fail. (e.g. they shouldn't do things like memory
allocation, open files or access devices). In the FAQ for this group,
it mentions that one possibility for solving a failed constructor is to
include a status data member that indicates if the class is "alive" or
not. Later, other class functions can check if the class is active
before doing any action.
  This seems a little contradictory (shifting initialization checking
to functions who should only be doing their functional purpose). I'm
trying to resolve, for myself, the intended purpose of this limitation
to constructors. If the constructor involves actions that could fail,
should they instead be included in a separate function that can
initialize the class? Something like an activate function that can
return a failed status? But this requires that the class usage has an
explicit protocol which doesn't seem to fit in with my perception of
the "information hiding" paradigm.

       constructor (simple initialization)
       activator (completes initialization with error return)
       action_function (can assume activator successful)

  I understand how throw & catch can solve this, but I think that using
them still hides the basic question about why constructors were
designed with this restraint.


john horvath
internet: j.horvath@ma30.bull.com