HDTenEightyP/NetNews huggingface dataset:
From: steve@taumet.com (Steve Clamage)
Subject: Re: Having this=0, class-name: :main() and tasking in c++
Organization: TauMetric Corporation
Distribution: usa
Date: Tue, 28 Jul 1992 16:14:38 GMT

pjl@sparc13.cs.uiuc.edu (Paul Lucas) writes:

>In <23318@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

>>In article <1DDA4ACFA5BF800C41@ursula.lucas.lu.se> KOSU_MATSB@ROUTH.KOSUFY.LU.SE writes:

>>> Question #1:	Having a 0 "this" pointer. Standard?

>>No.  ARM page 176:

>>	The effect of calling a nonstatic member function of a class X
>>	for something that is not an object of class X is undefined.

>*****>	Oops!  I was in error about my previous post; sorry.  But _why_
>	isn't guaranteed to work for nonstatic, nonvirtual member
>	functions?

>		C++			C-code
>		===			======
>		((X*)0)->f();	==>	f( /* this= */ 0 );

Let's call a non-static non-virtual member function an "ordinary member
function".

An ordinary member function must be called in conjunction with some
object of appropriate type.  Conceptually, it gets a "this" pointer
to that object.  The language specification does not say how this is
to be implemented.  You show the obvious implementation, but the
obvious implementation is not required.

No object will be located at the address represented by literal zero.
Any member function which attempts to manipulate non-static class data,
or which calls functions which do, will fail with a null "this" pointer.

An ordinary member function usually operates on class data, or calls
other class functions which do.  It might seem reasonable to say that
an ordinary member function which uses no non-static class data, calls
not functions which do, and calls no virtual functions of the class,
should be guaranteed to work with a null "this" pointer.  (Such a
function would be expected to be static, but let's ignore that.)

It might be that the implementation requires more than a simple
passing of the "this" pointer, and the manipulation might fail on a
null pointer.

For all these reasons, the language standard cannot guarantee success
for any member function which gets a null "this" pointer.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: kreiser@aostra.GOV (Barry Kreiser)
Subject: Re: Sun C++ 2.1 and RPC
Keywords: RPC
Reply-To: kreiser@aostra.GOV
Organization: Alberta Oil Sands Technology and Research Authority
Date: Tue, 21 Jul 92 20:28:48 GMT

In article 419@cs.tulane.edu, huangx@cs.tulane.edu (Xinyu Huang) writes:
>We plan to buy Sun C++ 2.1. It has RPC libraries. But I want to know whether
>the RPC support C++ language. For example, can C++ class be transferred
>between client and server? If someone know the answer or can tell me whom
>I should ask,please send me an email. I have called 1-800-USA-4SUN, no
>use.
>
>huangx@cs.tulane.edu


I am interested in this as well....   Is there an RPCGEN++ or something else out
there that automatically serializes and deserializes instances of classes...

Please Reply...

Thank-you in advance

---
=====================================================
DISCLAIMER: My opinions are my own ....

Barry Kreiser
A.O.S.T.R.A.
kreiser@aostra.GOV


Newsgroups: comp.lang.c++
From: cs8023@ee21.ncu.edu.tw (ee76536)
Subject: Re: latest g++ for VMS?
Organization: Dep. of EECS, National Central University, Chungli, Taiwan, R.O.C.
Date: Thu, 30 Jul 1992 03:46:39 GMT

In article <1992Jul29.073025.301%boot.decnet@edwards-tems.af.mil> elston%boot.decnet@edwards-tems.af.mil (Mark Elston, NSI Inc., Edwards AFB CA) writes:
>Does anyone know where I can get the latest port of g++ for VMS?
>
>I have 1.37.1 but before I invest a lot of time trying to install it on our
>system I might as well try to get the latest version.
>
>Thanks for any help.
>

I think most of GNU sits provided VMS G++ v1.39 (not yet 1.41?)

>Mark
>__________________________
>Mark Elston
>elston@edwards-tems.af.mil
>


-- 
>>> Anthony Li <Li3, Shih4 Hao2><Li:fruit's Name><Shih:Scholar><Hao:Hero>   <<<
<<< Institute of CSEE, National Central Univ, Chungli, Taoyuan, Taiwan, ROC >>>
<<< Bitnet:	U230700@twncu865.bitnet					    <<<
>>> Internet:	U230700@ncu865.ncu.edu.tw oper2@ncuee.ncu.edu.tw	    >>>
From: maxtal@extro.ucc.su.OZ.AU
Newsgroups: comp.lang.c++
Date: 17 Jul 92 20:07 MDT
Subject: Re: many set/get member functions in a 
Nf-ID: #R:1992Jul08.121838.13948@jho.com:2043735141:1992Jul17.160748.28162@ucc.su.oz:1351187194:001:2133
Nf-From: extro.ucc.su.OZ.AU!maxtal    Jul 17 20:07:00 1992


In article <rmartin.711297034@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:
>|
>|	In short, making the variable public is safer and more
>|	correct IMHO. Use get and set only under duress.
>
>I disagree.  Under no circumstances should an instance variable be
>directly manipulated by a client.  To do so is to abandon the
>abstraction of the server, and tie the clients hopelessly to its
>implementation. 

	No and yes respectively :-)

	The public variable ENFORCES a particular semantics,
and if that happens to be the desired abstraction, use it.

>
>get/set functions are not much better, but every little bit counts.

	I contend that perhaps sometimes the ADVANTAGE of enforced
semantics outweighs the disadvantage of loss of independence
from representation: it does so when that abstraction
corresponds directly to an existent type variable.

>If you really and truly cannot find a way to get rid of your get/set
>functions, then put them in, they are preferable to declaring your
>member variables public.

	Not convinced. Where a change in implementation would
ALWAYS be a change in semantics then the variables are best
because the FORCE you to examine every use, as a change in
semantics should.

	The get/set hides BOTH the semantics and the representation,
the former is not desirable while the latter is.
>
>But, try hard to get rid of most of your get/set functions.  They are
>strong indicators of an incomplete abstraction. 
>

	Usually, yes. I agree in principle.
	There are SOME cases where a simple public data
	structure is useful. Quite a few, actually.

	Not all programming in C++ is OO.

	But for many abstractions, public data is not desirable.

	Proper semantics specification is, but that is not
	in the language, not even preconditions, invariants
	etc which Eiffel has.

-- 
;----------------------------------------------------------------------
        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: glenm@bnr.ca (Glen Martin)
Subject: PD class browsers?
Reply-To: glenm@bnr.ca
Organization: Bell-Northern Research Ltd.
Date: Tue, 21 Jul 92 20:47:19 GMT

I'm sure this is probably a FAQ, but can anyone provide me with leads
to any public domain class browsers for C++?

Respond via email, please, and I will summarise to the net.

--------------------------------------------------------------------------------
Glen Martin              Bell-Northern Research          Ottawa, Ontario, Canada
Phone : (613) 763-7299   Fax: (613) 763-2626             Internet: glenm@bnr.ca
--------------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: de@cray.com (Duane Eitzen)
Subject: Re: Renew?
Organization: Cray Research, Inc.
Date: 25 Jul 92 15:12:27 CDT

In article <23315@alice.att.com> ark@alice.UUCP () writes:
>In article <THOTH.92Jul25110048@wave.cis.ufl.edu> thoth@wave.cis.ufl.edu (Robert Forsman) writes:
>
>> The absence of an analog for realloc is one of my MAJOR gripes with
>> C++
>
>So make a proposal.  I and several other people have thought about
>it from time to time but so far I have not seen a proposal I like.
>
>There is also the problem that it is potentially very difficult to
>implement in a C-based environment if it is required to use realloc.
>The trouble is that you can't tell whether realloc will move something
>until after it's too late.
>

To restate the problem: if your C++ is actually just a C++ to C translator,
you can't use realloc() in your implementation of renew.

This is true. Two ways around this: one is to implement your own
memory management (difficult, as you say). The other is to take
advantage of the fact that renew can do the move every time and still
adhere to the specification (although not providing the implied
performance gains). With this approach, renew can be implemented with
only malloc().

So in the worst case, renew would just be short hand for a new, a bunch
of copies and a delete. With a good compiler and a little luck, it
could provide significant performance gains. This is all that realloc()
claims to be now. And I like realloc.

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?

Duane.
Newsgroups: comp.lang.c++
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: classes referenced each in their declaration
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia
Date: Fri, 24 Jul 1992 22:55:24 GMT

nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
|> 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 !

You are right. It is a bug in the GNU C++ compiler.
GNU C++ didn't catch it.

You can either change the copy constructor to be X(Y& y1): y(y1) {}
or define the member y to be const Y& y; to correct the program

-Sekar
Newsgroups: comp.lang.c++
From: Ivan.Murray@comp.vuw.ac.nz (Ivan Andrew Murray)
Subject: Re: MATRIX C++ library - anyone????
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.
Date: Wed, 29 Jul 1992 22:09:14 GMT


In article <1992Jul27.123524.8657@odin.diku.dk>, fedtmule@diku.dk (Jens Markussen) writes:
|> Some time ago, I posted a request on a C++ Matrix manipulation library
|> here, but didn't receive any replies. What I'm looking for is a simple
|> Matrix Class, with functions that will allow me to do basic matrix
|> manipulations (e.g. add, multiply, invert, transpose, calc. determinant).
|> 
|> There MUST be someone out there that knows of such a library....
|> 
|> Please help,,
|> 
|> Jens Markussen
|> 
|> 
|> fedtmule@diku.dk       DIKU = Department of computer science, Copenhagen.

Could you *email* them to me as well please (I don't have FTP access)

Thanks,
Ivan.
-- 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Ivan A. Murray,                       |    email: imurray@comp.vuw.ac.nz
 BSc Student (Computer Science)        |
From: maxtal@extro.ucc.su.OZ.AU
Newsgroups: comp.lang.c++
Date: 18 Jul 92 10:33 MDT
Subject: Re: X3J16 spec
Nf-ID: #R:1992Jul17.181021.17378@iitmax.ii:1059225064:1992Jul18.063348.386@ucc.su.oz.a:-1601529533:001:552
Nf-From: extro.ucc.su.OZ.AU!maxtal    Jul 18 10:33:00 1992


In article <1992Jul17.181021.17378@iitmax.iit.edu> thssmdt@iitmax.iit.edu (Mark D. Turner) writes:
>Can anyone tell me how I can get a copy of the latest X3J16 spec?

SURE: become an Observer if you don't work for a company already
a member, if you do, get it off your company rep.

-- 
;----------------------------------------------------------------------
        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: 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: Thu, 30 Jul 1992 16:38:21 GMT

In article <1992Jul28.094428.15393@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
>
>> > 	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).
>
>RTTI is only needed when an object can have an apparent type and an actual
>type.  In C++, that requires derivation.  

	Not so. RTTI could easily be useful for distinguishing between
unrelated types.

	In fact, these type *might* have a base in common, but the
is not relevant.

	Consider the syntax

	f(X[Y,Z]*);

which is taken to mean a pointer to X, with downcasting to Y and Z
allowed. If we allow,

	f([Y,Z]*);

then it is much the same, except that there is no 'default' type,
and the argument cannot be used directly.

One can easily see how this can be used to implement a Lisp system:

	typdef [float,int,string] atom;

	class node {
		node *CAR;
		[node, atom]* CDR;
	};

The notion is equivalent to a pascal variant record with run-time
checking on the discriminant.

In the case above, tagged pointers may have to be used.

When there is a common base with a virtual member, RTTI in the object
can be used instead. But that is an compiler implementation detail.

-- 
;----------------------------------------------------------------------
        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: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Re: Covariant Types in Derived Classes
Organization: netmbx, Berlin, Germany
Date: Tue, 21 Jul 1992 10:19:15 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>	OO database: don't know.

You have an arbitrary object.  It needs to be stored.  If your database
has a sensible interface then its references should automatically be
resolved to the right types and stored.  When you load an object from
the database you need to find its complete inheritence tree and load
it correctly, building the vtables, etc.  I don't know how to do this
without run time type identification.

>	Comms package: not sure.

If it is exchanging objects, then the same arguments apply as for
an OO database.

>>
>>Think of stream I/O.  Don't you feel stupid coding an << operator for
>>each type you want to be able to print?  

>	No. I never use stream IO. I hate it. It is not well
>designed. Too complicated. Tries to do everything at once.
>And in Windows, there is no console anyhow.
>Personally, I use Gets or like for input, and puts for output in
>textfiles.

>>An intelligent stream facility
>>would be able to print any object with a sensible default format which
>>could optionally include the name and type of each field.  Try to code
>>this without run time information.  Since the I/O stream is coded first
>>and can impose no restrictions on user objects I do not know of any way
>>to solve this without adding my own precompiler.

>	I dont understand. I define string->stream. Once.

>	Now all my objects have a 'print' command that outputs
>a string. I can print anything. No run-time type info required.
>Just a virtual function. (And the output can be used in the
>string package to do other things---much better than stream IO.)

>	Even better, use a mixin:

>	class printable { public: virtual string print()const=0; }

>	class anyclass : public virtual printable, ... {

Anybody who follows *your* conventions can then use *your* objects
in this way.  I assume that you define not only string->stream,
but also a stream conversion for every single base type.  Then you
need to find out how many members you have in each class and how to
access them.....

Unfortunately, everybody else has *their* conventions.  How many
class libraries implement an Object type?  What if they are not
compatible?  Now do you expect the class libraries you buy to
follow *your* conventions?  If not, maybe the language specification
should make this information available to everybody in a uniform
way.


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

===========================================================================
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Handling of operator . pro
Date: 31 Jul 92 13:50:46 GMT
Article-I.D.: alice.23368
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <memo.551143@cix.compulink.co.uk> vadim@cix.compulink.co.uk writes:

>   class Something &k;
>   k.anything();

> In the case of references 'operator .' DEFINITELY HAS runtime behaviour.

Not really -- it is the use of the reference that matters, not the use of .

For example, if I say

	class Something* p = &k;

exactly the same runtime behavior will occur.
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: allan@ixos.de (allan)
Newsgroups: comp.lang.c++
Subject: Bug (known ?) in AT&T C++ 2.1 with (expr ? A : B)
Date: 31 Jul 92 10:18:41 GMT
Organization: iXOS Software GmbH, Munich, Germany



I found a bug that I think comes from AT&T C++ 2.1.  
It turns up on SUN-C++ 2.1 and on SINIX C++ 2.1, but not on CenterLine C++ 2.1 or g++.
Is this already a known bug ?

The problem shows up in expressions of the form: 'EXPR ? X : Y' where X and Y
are of different class types (for example "String" and "const String").

Here is an example that demonstrates the bug:

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

#include <iostream.h>
#include <string.h>


class String {
public:
        char* p;
        String(char* s) :p(s) {}
        virtual ~String(){}
        virtual int operator==(const String& s) { return (strcmp(p, s.p) == 0); }
        friend ostream& operator<<(ostream& os, const String& s) { os << s.p; return os; }
};


main()
{
    String s1 = "x";
    const String s2 = "y";
    String s3 = (0 ? s1 : s2);
    cerr << "s3 = " << s3 << endl;
}

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

Output: 

% a.out
s3 = x

(Output should be "y")


Allan Brighton
C++ Consultant
From: weh@abasin.dr.att.com (William E. Hopkins)
Newsgroups: comp.lang.c++
Subject: Re: Q: static members and private constructors
Date: 23 Jul 92 19:42:54 GMT
Organization: AT&T Bell Laboratories

In article <YDD5OTF@hp832.informatik.hu-berlin.de>, loewis@informatik.hu-berlin.de (M.v.Loewis) writes:
|> 
|> In the following program, it is not possible to create static (class)
|> instances of a class with only private constructors. I suppose it is
|> a general compiler error:
|> 
|> class B;
|> class A{
|> friend class B;
|> A(int);
|> int i;
|> };
|> 
|> A::A(int){}
|> 
|> class B{
|> static A m;
|> public:
|> int func();
|> };
|> 
|> int B::func()
|> {
|>  return m.i;
|> };
|> 
|> A B::m(1);
|> 
|> The problem is the last statement: I think it should be possible to create
|> the m member of B somehow, since B is a friend of A, but all compilers I 
|> tried complained about sth:
|> BC: A::A(int) is not accessible in function _STCON_()
|> g++: In function _GLOBAL_$I$__1Ai(): ...invalid initializer to constructor
|> 	for type A
|> CC: sorry, not implemented: static member B::m of class A with constructor

The error message from cfront 2.1 is clearer on the subject:

"static.c", line 21: error: global scope cannot access A:A(): private member
1 error

The Annotated C++ Reference Manual (ARM) is not explicit on this subject,
but a sentence in section 9.4 ``Static Members'' that is relevant (pg. 180
of first printing):

	Static members of a global class are initialized exactly like
	global objects and only in file scope.

Thus, the initialization of B::m takes place in file scope, which does not
have access to the private parts of A.

It is not a bug; it is a feature.  If you want it to work, you can join the
ranks of the well known netters attempting to get changes considered by the
ANSI C++ committee...  Good luck!

From the statement in the ARM, it qualifies static members as those of
global classes, from which I deduced that maybe nesting classes would work.
I was wrong (having tried various formulations).

Below is a kludge I fashioned to more or less accomplish what you wanted
(but probably at the expense of allowing some access you wished to avoid):

class B;
class A{
	friend class B;
	A(int);
	int i;
public:
	A(); // added public default constructor
};

A::A(int){}

class B{
	static A m;
public:
	static int init_m(); // added public initializer function
	int func();
};

int B::func()
{
 return m.i;
};

A B::m; // allowed because A::A() is public
static int dummy = B::init_m();

int B::init_m () { m = A(1); return 1;}


		Bill Hopkins
Newsgroups: comp.lang.c++
From: kinne@delfin.com (Kinne Strong)
Subject: Re: classes referenced each in their declaration
Organization: Foxglove Associates
X-Newsreader: Tin 1.1 PL4
Distribution: na
Date: Wed, 22 Jul 1992 19:19:39 GMT

qincao@cs.uh.edu (Qin Cao) writes:
: 
: 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;
: };

Do you realize that the above declares two classes whose objects must
have infinite size? If you say

X big;

There must be a big.b, and a big.b.d, and a big.b.d.b, and .....

--
Kinne Strong
kinne@netcom.com
From: gbol@rglnext.geol.vt.edu (Gregory Lampshire)
Newsgroups: comp.lang.c++
Subject: merits of dynamic loading and runtime type identification in a GUI?
Date: 31 Jul 92 14:24:11 GMT





I would appreciate if anyone could point out a paper or a discussion which  
argues the merits of dynamic object code loading and runtime type  
identification in GUI appilication kits.  What I am wondering is if ObjC  
is inherently better then C++ for building GUI application kits.  I would  
hope that the argument would be based on some software engineering  
principles etc of cohesion,  coupling etc...  I would also suppose that in  
the best case CLOS or Smalltalk-80 would be the ideal but I am mainly  
interested in maintaining some rudiments of runtime efficiency and C  
compatibility.


I am wondering if it is inherently better to write a GUI application kit  
in C++ or in something like ObjC.


--
Gregory Lampshire 
Virginia Tech 
Bradley Department of Electrical Engineering
gbol@rglnext.geol.vt.edu (NeXTmail welcome)
------------------------
My opinions are my very own and do not reflect the opinions of any  
employer
Newsgroups: comp.lang.c++