HDTenEightyP/NetNews huggingface dataset:
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: tagged unions, an alternative to RTTI (Re: run-time type checking)
Date: 30 Jul 92 22:13:26 GMT
	<1992Jul25.172045.24675@ucc.su.OZ.AU> <BryL9q.K5I@watcgl.waterloo.edu>
	<1992Jul28.183746.24287@ucc.su.OZ.AU>
	<TMB.92Jul29125322@arolla.idiap.ch> <TMB.92Jul30152807@arolla.idiap.ch>
Reply-To: tmb@idiap.ch
Followup-To: comp.lang.c++
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: tmb@arolla.idiap.ch's message of 30 Jul 92 19:28:07 GMT

Deviasse Robert N writes:

   Tagged unions may be simulated in C++ by the method described in "The C++ 
   Programming language 2nd Ed" page 168.

Even in C, people have simulated tagged unions for a long time. In
fact, unions have no interesting portable semantics unless you keep a
tag somewhere. By making the tag explicit in the language and letting
the compiler know about it, you can obtain the benefits of static
and/or dynamic type checking resulting from explicit compiler support.

   [... messy example deleted ...]

   Yes, it's verbose, but this is the type of contortions that the compiler
   has to go through if tagged unions were added to C++ -- this is probably
   the reason why tagged unions were not introduced into C++.

Adding tagged unions to the C++ language would be a very minor
extensions. There is nothing messy or complicated about it.

   (besides, what
   is the error() function above, is it an exception, an assert(), ...)

You can, in fact, define tagged unions such that no use of a tagged
union can result in a runtime type error. In this regard, tagged union
are nicer than RTTI (in the current RTTI proposal, type errors show up
as NULL pointers that you might forget to handle). This is also the
reason why "simulations" of tagged unions are not as nice as language
built-ins: simulations will have to raise runtime type errors for many
problems that, in principle, could be diagnosed at compile time.

RTTI and tagged unions are not replacements for one another. However,
tagged unions would be a safer alternative to RTTI in many cases. In
particular, tagged unions would allow you to have heterogeneous
collections of objects of arbitrary, unrelated types. I think it
would be nice to have them in the language.

					Thomas.
Newsgroups: comp.lang.c++
From: jens@Xenon.Stanford.EDU (Jens Christensen)
Subject: Re: Sun C++ 2.1 and RPC
Keywords: RPC
Organization: CS Department, Stanford University, California, USA
Date: 21 Jul 92 23:37:36 GMT

kreiser@aostra.GOV (Barry Kreiser) writes:

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

  You might want to take a look at NetClasses from PostModern
Computing.  It provides serialization and deserialization of C++
objects, as well as Remote Method Invocation (RMI), a C++ version of
RPC.  A description of NetClasses can be gotten via anonymous ftp from
thor.stanford.edu in the /pub/netclasses directory, or you can
reach PostModern at (415) 967-6169.

Jens Christensen



Newsgroups: comp.lang.c++
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: strdup() Was: Re: Renew?
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia
Date: Thu, 30 Jul 1992 16:15:36 GMT


hansen@pegasus.att.com (Tony L. Hansen) writes:
>    #include <string.h>
>    char *nstrdup(const char *s)
>    {
>	if (!s) s = "";
>	char *ret = new char[strlen(s) + 1];
>	if (ret) strcpy(ret, s);
>	return ret;
>    }

Elegant answer but has a little problem.

char* ptr = nstrdup(0); // ptr = ""; not allocated by new
delete [] ptr;		// error

Therefore, I suggest the following change.

if (!s) return 0;

-Sekar
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: New C++ type: boole
Summary: w_char is a real type
Date: 30 Jul 92 13:07:06 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ



jimad@microsoft.com (Jim Adcock @ Microsoft Corporation) writes

 > A similar, and more important problem [IMHO] occurs because w_char is not
 > a separate type:
 >
 >	w_char chSqrt = '\x221A';
 >
 >  cout << chSqrt;
 >
 > doesn't cause the Unicode square root sign to be printed out, but rather
 > some decimal integer.

At the Toronto meeting of ANSI-X3J16/ISO-WG21 meeting w_char was voted a separate
type. This is of course an incompatibility with C, but it was decided that the
benefits (in C++) of having w_char a real type so that the overloading mechanism
works for it outweighed the incompatibility problems. This decision closely matches
the decision to give character literals, such as 'a', the (obvious) type char rather
than int. Naturally, L'a' is of type w_char.
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: reference to C++ assertion macro package?
Keywords: C++, assertions, precondition, postcondition, invariants
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 24 Jul 1992 14:03:09 GMT

In article <18608@drutx.ATT.COM> weh@abasin.dr.att.com (William E. Hopkins) writes:
>I can't recall the reference to an article I read that described a macro
>package that provided assertions for C++ in the flavor of what is in
>Eiffel (can I write ``Eiffel'' in this newsgroup, or should I use
>``*ffel'', ``eye-full'', ``I fell'', or some other appropriate code?).

	Does anyone have details of the proposed assertion
facility for C++? Really, C++ is not a serious class language
without them. (Oh, and the're a run-time-type checking facility
I'm in favour of :-)



-- 
;----------------------------------------------------------------------
        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: fred@cv.ruu.nl (Fred Appelman)
Subject: Re: compilers for i386/SVR4?
Date: Tue, 21 Jul 1992 19:45:30 GMT
Organization: University of Utrecht, 3D Computer Vision Research Group

In <5002@transfer.stratus.com> jwer@benson.az.stratus.com (justin werner) writes:

>I'm looking at two C++ compilers for i386 + ATT SVR4:
>Computer Innovations & Liant/LPI.
>
>1.	If you have had experience with one or both
>	of these compilers, could you relate your
>	problems/flames/plus-points/etc. to me?  Either
>	e-mail or post would be fine.

LPI works reliable but it is slooooooww!!!
Good debugger. I also have g++, and use that most of the times.

Fred
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: Having this=0, class-name: :main() and tasking in c++
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 27 Jul 1992 05:03:15 GMT

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

>Two (three) questions on C++:

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

*****>	I don't know what you mean by "standard."

>	If i happen to use a method using an explicit pointer to 
>	an object which for some reason of another happens to be 
>	0 (which i probably don't want to do ;-) i have noticed 
>	that G++ (ver 2.2.2 for VAX/VMS) get's a bit carried away 
>	when the method starts to access the items of the object.
>	However, it is possible to catch this since the "this" 
>	pointer is 0 and a controlled exit is possible. If the 
>	method is virtual the program crashes at the call
>	(naturally). Is this of a 0 "this" pointer in a method
>	within the standards of C++ or a feature of G++?
>	(i.e. can i use the feature in a program and expect it to
>	work on another type of machine and copmiler?)

*****>	Any pointer can be zero; 'this' is no exception.  I have
	implemented a Link class that checks for a nil 'this'; if it's
	nil, just return.

	I don't know what you mean by "can I use this feature..."  What
	feature?  The lanuage can't prevent you at run time from calling
	a member with a nil this pointer.  If you try to access members,
	you program will crash.  It's perfectly valid to check 'this'
	for nil.

	BTW: The virtual member will work if it's not called via
	pointer.

	[ other questions deleted because I don't know the answer ]
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: svb@cs.purdue.EDU (Stephan Bechtolsheim)
Newsgroups: comp.lang.c++
Subject: Re: Renew?
Date: 27 Jul 92 03:55:54 GMT
Organization: Department of Computer Science, Purdue University

What about if you simply define your own little member function
which does a realloc, call it realloc()? You might have to keep
track of the length of an array of class objects.

Stephan v. Bechtolsheim
Computer Sciences Department			svb@cs.purdue.edu
Computer Science Building			(317) 494 7802
Purdue University			   FAX: (317) 494 0739
West Lafayette, IN 47907
From: russw@cs.utexas.edu (Russ Williams)
Newsgroups: comp.lang.c++
Subject: Re: New C++ type: boole
Date: 28 Jul 1992 13:38:51 -0500
Organization: Great Northern Hotel
NNTP-Posting-Host: cs.utexas.edu

The proposal seems ill-considered, e.g., lack of concern for what it does
to the standard library.  Plus the misunderstanding that ++ was being used
for logical negation when in the SUN code example given (& every other
such example I've seen) ++ is used for "= true"... this doesn't inspire
confidence...

I'd love to have strict boolean types; I once had a subtle bug involving
passing a pointer to a boolean to a function which was to check the bool
value and possible change it... I checked the pointer p instead of *p,
but since that was syntactically legal, I got no warning, and it took a
long time to track down this typo bug.  But I must agree with the people
who point out that much existing code uses this feature, even if my code
does not, and so I think a strict boolean type would break much existing
code.

Russ
Newsgroups: comp.lang.c++
From: 890751r@dragon.acadiau.ca (Dave Ritacco)
Subject: Compiling IBM Moria with TC++
Organization: Acadia University
Date: Thu, 30 Jul 1992 19:23:27 GMT

What must be specially configured to get this prog to compile with Borland TC++?I have tried re.games.moria and no one seems to clued in...

-- 
************************************************************************
*        Dave Ritacco                Product of Acadia University      *
*           "Why don't you pull the trigger and find out?"             *
*        ritacco@otter.phys.uvic.ca                W.H.Bonney          *
Newsgroups: comp.lang.c++,comp.std.c++
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: strdup() Was: Re: Renew?
Date: 28 Jul 92 19:59:15 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Jul28.163356.3019@taumet.com> steve@taumet.com (Steve Clamage) writes:
>Since strdup is a very tiny function, your best bet is to write one
>yourself for use with C++, using new rather than malloc if you wish.

Like so:

#include <string.h>

char * strdup_new (const char * input) {
	return strcpy(new char*[strlen(input)+1],input);
}

You might consider making it inline.



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.lang.c++
From: Jamie Billing-Ross <bross@src.honeywell.com>
Subject: Passing C++ member functions to C functions
Organization: Honeywell Satellite Systems Operation
X-Useragent: Nuntius v1.1b1
Date: Fri, 24 Jul 1992 00:53:23 GMT

This is similar to a problem I have seen stated but I haven't seen an
answer to quite this one.

I have a C routine defined as follows:

extern "C" void add_ext_int_func(int level, int (*ptrfunc)());

Normally I just pass a C interrupt handler function as the 2nd argument

add_ext_int_funct(2,timer_int);

What I would like to do is pass a member function to this same routine..

add_ext_int_funct(2,CCclock::timer_int);

where the call is made from inside another member function of CCclock.
if I typecast the member function,ie (int(*)())CCclock::timer_int I seem
to get only the function offset address rather than the absolute entry
point address..

So I am looking for any suggestions for converting from int(Class::*)() to
a int(*)()

Thanks

Jamie
Newsgroups: comp.lang.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: wchar_t (was Re: New C++ type: boole)
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Thu, 30 Jul 92 02:00:40 GMT

In article <1992Jul29.195155.15634@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
|> 
|> A similar, and more important problem [IMHO] occurs because w_char is not
|> a separate type:
|> 
|> 	w_char chSqrt = '\x221A';
|> 
|>   cout << chSqrt;
|> 
|> doesn't cause the Unicode square root sign to be printed out, but rather
|> some decimal integer.
|> 

At the July meeting, X3J16/WG21 voted to make wchar_t (which is 
the ANSI C spelling) a distinct builtin type.  

  -- Jerry Schwraz

Newsgroups: comp.lang.c++
From: mat@uunet.uu.net!mole-end
Subject: Re: Language extensions for run-time type identification
Summary: Humptying and Dumptying about Const
Organization: :
Date: Sat, 25 Jul 1992 07:02:47 GMT

In article <1992Jul23.175944.9090@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> In article <23284@alice.att.com> ark@alice.UUCP () writes:
> >In article <rmartin.711829160@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
> |
> |> Posh!  Every class should have a virtual destructor.  It is insane not
> |> to declare the destructor virtual.  There is only one, small,
> |> exception to this rule, which has to do with structs placed in ROM...
> |
> |How about classes associated with small objects, such as Complex and Point?
 
> Exactly!  How ABOUT them?
 
> They OUGHT to be ROMABLE.  They OUGHT to be guaranteed to be const.
> A programmer writing:
 
> const complex imag_pi(0, pi);
 
> OUGHT to be able to assume that his/her constant IS constant, and generates
> the quality of code expected of constants.
 
> BUT, none of this is true given the committee's decision to support
> "Humpty Dumpty" const.

Eh?  Under the current proposal, if the class has no  ~const  members
AND IF IT HAS NO CONSTRUCTORS OR DESTRUCTORS it can be placed in ROM.
Complex  should probably have constructors or destructors, so it is left
out, but that has nothing to do with Humpty Alice Dumpty.

On the other hand, under the current proposal, with no ~const members,
casting away const for classes can be reduced to the unsupported sort
of thing you are asking for.  The class declaration, by default, supports
bitwise const; with the appropriate declarations the meaning of const is
weakened for that class.  It's up to the implementor of the class.

What more do you need?  I grant you, this is just a proposal, but it's
one the Extensions WG actually likes.  If the gruelling analysis to which
it must be put doesn't discover any serious obstacles, the WG is likely to
recommend it to the full co-committee.
-- 
 (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: chip@tct.com (Chip Salzenberg)
Subject: Re: Handling of operator . proposal
Date: Wed, 29 Jul 1992 19:59:46 GMT
Organization: TC Telemanagement, Clearwater, FL

According to wmm@world.std.com (William M Miller):
>Adding runtime behavior to an operator that doesn't have it now would
>be a completely new thing.

Not so.  Consider "p->m".
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
   "Do Rush place weird subliminal backmasked messages in their songs to
 compel unwilling geeks to commit evil .sig atrocities?"  -- Dean Engelhardt
Newsgroups: comp.lang.c++,comp.strd.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: Fri, 24 Jul 92 14:51:47 GMT

> > In article <1992Jul21.143131.6902@cadsun.corp.mot.com>, shang@corp.mot.com 
> > (David (Lujun) Shang) writes:
> > > 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.
> 
> > In article <1992Jul22.091752.22521@mole-end> mat@mole-end writes:
> > > Just a point of fact:
> > > Not quite true. Those multiple vtable references in a complete object
> > > all have to point to vtables whose only differences are their `offset
> > > adjustments.'
>
> In article <1992Jul23.134515.12794@cadsun.corp.mot.com>, shang@corp.mot.com  
(David (Lujun) Shang) writes:
> > Good point! To compare two types then can be done by comparing the segment  
> > or page number of two vtables. The penalty is only for those C++ 
> > implemented in 16-bit environment. The vtable reference cannot be a 16-bit 
> > pointer for small programs.
>
In article <1992Jul24.070325.1597@uunet.uu.net!mole-end>  
mat@uunet.uu.net!mole-end writes:
> Eh?  I was not using `offset adjustment' in reference to a segmented memory
> addressing scheme; I was using it to describe a necessary feature of a
> vtable for MI: an explicit or implicit displacement by which a pointer must
> be adjusted during the invocation of a virtual function.
>
I'm sorry if I misunderstood. If what you said is true, each vtable should  
contain an integer for the "offset adjustment" whether for MI or non-MI,  
otherwise you should have some tag to distinguish a vtable of a base class  
which is use in a MI or not in MI. Anyway, you should have some additional  
thing for each vtable. If so, I would prefer to a unique integer identifier for  
a specific class.

> And not to make you too happy: comparing vtable pointers could only be
> a first step unless you are absolutely sure that the compilation and
> linking system will never duplicate a vtable.  This is a hard assumption
> to prove, especially with dynamic linking of new types.
>
The compiler and linker should essure that the vtable for a particular class is  
unique. 

Anyway, after a sencond thought, I still insist on my original opinion, that  
is, it is not a good idea to use vtable pointer as the type-id. Vtable pointer  
is environment-dependent, it cannot serve as a type identifier to communicate  
between two defferent environments.
 
David Shang

Newsgroups: comp.lang.c++
From: kv07@IASTATE.EDU (Warren Vonroeschlaub)
Subject: matrices/rational polynomials
Reply-To: kv07@IASTATE.EDU (Warren Vonroeschlaub)
Organization: Ministry of Silly Walks
Date: Sun, 26 Jul 1992 17:32:54 GMT

  I am doing some research, and need to find the Null space(*) of a matrix of
polynomials in 2 variables.  Sounds awful, huh?  I have tried some of the
commercial symbolic manipulators (Maple V, Mathematica), but they die on
matrices bigger than 4x4, and even on a 4x4 matrix they need to be hand fed the
first few steps.

  What I am looking for is code for row-reducing matrices, preferably ones that
don't do division.  If they do division I am also going to need an object for
handling rational polynomials in two variables (I already have some, albeit
innefficient, code for handling 2 variable polynomials).

  Anybody out there been through this before?

(*) The null space is the set of vectors which, when multiplied with the matrix,
give the zero vector.  In these cases I already know the null space will have
n-1 elements.  Once the matrix is in reduced echelon form the null space is
obvious.

***********************************************************************
* Warren Kurt   *  "The devil is an optimist if he thinks he can make *
* vonRoeschlaub *   people meaner" -Karl Kraus                        *
***********************************************************************
Newsgroups: comp.lang.c++
From: rring@willamette.edu (Robert Ring)
Newsgroups: comp.lang.c++
Subject: Format State Question
Date: 22 Jul 92 16:32:41 GMT
Article-I.D.: willamet.1992Jul22.163241.26675
Followup-To: rring@jupiter.willamette.edu
Organization: Willamette University, Salem, OR

Hello, world.

I would like to be able to support the following code
which would print out my object in two different
formats:

  #include "foo.h"
  #include <iostream.h>
  
  main()
    {
    foo x;
    cin >> x;
    cout << x;      // this line prints x out normally
    cout << hex << x;     // this line prints x in hex
    return 0;
    }

using the standard hex stream manipulator.  I read
Lippman and discovered setf(), which eventually led to
the following code:

ostream& operator<<(ostream& os, const foo& x)
  {
  long current_base = os.setf(ios::dec, ios::basefield);
  if (current_base & ios::dec)
    {
    // output foo in "normal" format
    }
  else
    {
    // output foo in "hex" format
    }
  os.setf(current_base, ios::basefield);
  return os;
  }

This works, but it's clumsy.

Question:  Is there any way to directly check the format
state of cout, that is, not go through the above gyrations
with setf?

Thanks in advance.

--R.
-- 
Newsgroups: comp.lang.c++
From: scott@surf.news.mitre.org (Scott Blomquist)
Subject: Re: X3J16 spec
Organization: The MITRE Corporation
	<76246@ut-emx.uucp>
Date: Tue, 21 Jul 1992 15:00:43 GMT


   In article <76246@ut-emx.uucp> jamshid@ut-emx.uucp (Jamshid Afshar) writes:
   >In article <1992Jul18.063348.386@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
   >>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.

   >According to the FAQ (ftp sun.soe.clarkson.edu, pub/C++/FAQ) you don't
   >have to know or become a member.  Has anyone actually ordered the
   >"Working Paper"?  Is it a real, ready document?  How recent is it?
   >How much does it cost?  Does it provide much over the ARM?  Anyway,
   >the FAQ and answer are appended.

   >Jamshid Afshar
   >jamshid@emx.utexas.edu

	[deleted FAQ quote]


I wrote a letter to the Standard Commitee asking for a copy of the
C++ draft standard.  They wrote back with a nice letter stating that I may
purchase a copy for $25.  They also included the address of the X3J16
chairman to contact for the most up to date info.  Unless you're really
implementing the C++ language or really interested in the latest stuff
with C++, I'd recommend just getting the ARM.


			Later...
				...Scott

--
------------------------------------------------------------------------------
Scott E. Blomquist : The Mitre Corp. : scott@surf.mitre.org
------------------------------------------------------------------------------
Disclaimer * my_disclaimer = new Disclaimer(); cout << my_disclaimer;
Newsgroups: comp.lang.c++