HDTenEightyP/NetNews huggingface dataset:
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Linked list of several classes.
Organization: University of Illinois at Urbana-Champaign
Date: Thu, 21 Jan 1993 19:10:23 GMT

In <1jlaifINNm4t@msuinfo.cl.msu.edu> dulimart@cps.msu.edu (Hansye S. Dulimarta) writes:

>To C++ gurus:
>  I am having problem with defining a "generic" linked list. For instance,
>I would like to define a linked list of furnitures where each element can
>be either a Desk or a Table. The immediate "solution" that came to me was
>to define four classes:

>	1) List (for the list)
>	2) ListEl (for the list item)
>	3) Desk (derived from ListEl)
>	4) Table (derived from ListEl)

>Also, inside class List, I definde a method "search" that will return the
>pointer to a ListEl and another method "append" that will append a new
>element to the list. 

>Function "append" behaves as I expected, that is, I can add element of
>class Desk and Table to the list like in the following:

>    List inventory;

>    inventory.append (new Desk(/*...*/));
>    inventory.append (new Table(/*...*/));

>BUT......
>  Whenever I do a 'search' I would like to get a return value of type
>  'Desk *' or 'Table *' depending on the element in the list that satisfies
>  the search criterium. But the code, as it is written, always returns a
>  'ListEl *' and I lost the information whether the element is a Desk or a
>  Table. I don't see a simple way to do this in my code.

	Bingo!  You want run-time type-identification.  This is not
	currently part of C++.  See Stroustrup, 13.5 for one of many,
	many ways to do this.

-- 
	- Paul J. Lucas
	  AT&T Bell Laboratories
	  Naperville, IL
Newsgroups: comp.lang.c++
From: litsios@iis.ethz.ch (James Litsios)
Subject: Re: Dangling pointers & suggestions on future implementations of "delete"
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Fri, 22 Jan 1993 09:39:54 GMT

rhw@att.com (Robert Wentworth) writes:

>For debugging purposes, I track down memory problems by overloading new
>to store extra information with each object and overloading delete to
>check/update this extra information.  (Also add some code to allow other
>checks).

> ...

>Anyone else have nifty techniques that they use to root out memory
>problems?


I have a new and delete redefinition package that essentially does the same
thing with the added cappability of numbering each memory block. I then have
a little input file in which I can set "break points" on specific memory
blocks. For example:

B A 2333

specifies the when the memory block number 2333 is allocated and freed then
call a predefined function. I then have a real debugger break point on this
function with stops the execution of the program.

This feature is really useful because if you run a program twice with the
same input you get same numbering of the memory (this is not always true, but
in that case you are in more trouble) so if you find something strange with
a memory block you get its number and relaunch the program with a break point
on that number you can then figure out when it was allocated, who is accessing
it and if it is being freed too early.  I use this to find memory leaks by
adding break points to all memory block that still exist at the end of an 
execution, I relauch the program and it stops on each allocation that has
no deallocation.

Right now I redefine the new and delete operator, but I currently feel very
insecure about this methode because if you redefine the new but not the delete
or the delete but not the new you can end up with more trouble than you had in
the first place.  I now believe that short circuiting the malloc and free
routines is a better way to go.


>(I suppose I could provide a copy of my code for this, if anyone really
>needs it.)

Yes, people do need it. People do not realize how useful this type of tool
is and how much time you gain debugging your code.

James Litsios

--
James Litsios                   Phone:       +41 1/256 49 50
Integrated Systems Laboratory   Fax:         +41 1/252 09 94
ETH Zurich                      E-Mail:      litsios@iis.ethz.ch
CH-8092 Zurich, Switzerland    
Xref: sparky comp.lang.c++:20053 comp.lang.c:20330
From: dbbergac@culebra (Dave Bergacker)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: Pointers to Functions
Date: 28 Jan 1993 15:28:26 GMT
Organization: University of Colorado at Colorado Springs
NNTP-Posting-Host: culebra.uccs.edu
X-Newsreader: TIN [version 1.1 PL6]

acctpu@vaxa.hofstra.edu wrote:
: 	I was wondering.  If I define a pointer to a function
: 
: void (*fp)()
: 
:        How would I get the pointer to *point* to a function, and how would I
: *execute* the function the pointer is pointing to.
: 
: Thanks in advance,
: 
: Gary Graffagnino
: ACCGSG@VAXC.HOFSTRA.EDU

Well, assuming no parameters to the function, you really want:
void (*fp)(void);
then assuming you have a function of type void with no parameters,
void foo(void);
the assignment is:
fp = foo;
and the execution is:
fp();
BTW this is all ANSI stuff, if you wan't K&R the execution is
something like:
(*fp)();
which is much less transparent to a new user, or other person reading your
code.  I don't know for sure, but you might want to check the FAQ for
this group....

--
___________________________________________________________________________
| Dave Bergacker			|				  |
| dbbergac@culebra.uccs.edu		| "I am NOT a merry man!"         |
| Any opinions expressed are almost	| Lt. Worf, Enterprise Security   |
| certainly not those of UCCS.		| "Have gahk, will travel"	  |
---------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: dvines@syl.dl.nec.com (Don Vines)
Subject: Re: Smalltalk -> C++
Organization: NEC Systems Lab., C&C Software Technology Center (Dallas, TX)
Distribution: usa
Date: Wed, 27 Jan 1993 18:29:00 GMT



>>Does anyone know of a reliable program which can
>>convert Smalltalk to C++?


We implemented Smalltalk's runtime type support (RTTS) for C++.
This is documented in the January issue of C++ report.  We used it
to implement the OMGs ORB.  After doing this one of our visions was
to see what it would take to convert the Smalltalk collection
classes to C++.  Given that our RTTS implemented many of Smalltalk
kernel classes, we thought that it might be possible to
automatically translate the Smalltalk libraries into C++.  Although
converting the collection classes using the RTTS was fairly
straightforward, it still required a human to read and interpret the
Smalltalk code in order to do the conversion.  On the other hand,
our C++ collection classes with RTTS seemed to be a much closer
approximation of Smalltalk than NIHCL.

Don



-- 
Donald H Vines, Jr.
NEC Systems Laboratory, Inc.                  Phone: (214)518-3486             
1901 Gateway Dr.                              Fax  : (214)518-3552             
Irving, Texas 75038                           Email: dvines@syl.dl.nec.com   
Newsgroups: comp.lang.c++
From: rmartin@stripe.Rational.COM (Bob Martin)
Subject: Re: Address of Member Functions
Organization: Rational
Date: Tue, 26 Jan 1993 23:12:17 GMT

pbender@qualcomm.com (Paul Bender) writes:

|Is there a reason why this will not valid?

|class X {
|private:
|  void g1(void);
|  void (*g)(void);
|public:
|  X(void);
|  void f(void);
|};

|void X::f(void)
|{
|  g = &g1;                // line 12
|}

|main(void)
|{
|  X x;
|}

|When I compile it using g++, I get the following error message:
|test.C:14: assignment between incompatible pointer types

This question, and questions like it, have got to be the most
frequently asked questions in this group.   

g1 is not a function.  It is a member function.  void (*g)(void)
declares g to be a pointer to a function, not a pointer to a member
function.  The two pointer types are incompatible. 

If you want 'g' to point to member functions of X then you must declare it
as follows:

	void (X::*g)(void);

Pointers to members and member functions are complicated beasties.  I
suggest you pore over a *good* C++ book to learn how they are used.

--
Robert Martin       | Design Consulting    | Training courses offered:
R. C. M. Consulting | rmartin@rational.com |  Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004  |  Object Oriented Design
Green Oaks, Il 60048| Fax: (708) 918-1023  |  C++
From: kessel@eos.arc.nasa.gov (Karen Kessel)
Subject: textbooks on AI for c++
Summary: there is none
Keywords: C++ AI book
Organization: NASA Ames Research Center
Distribution: usa
Date: Wed, 27 Jan 1993 21:57:31 GMT

This note is for those who wrote to me asking for the names
of any books that had been recommended to me regarding C++
and AI.  Unfortunately, there don't seem to be any.  I got
one response about a book by David Hu, C/C++ for Expert Systems
MIS press, 1989.  However, a colleague of mine told me that
this book is old C++ and not very good anyway.

Oh Well.... guess we'll just have to write our own book.
Karen

Newsgroups: comp.lang.c++,comp.std.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Callbacks -- suggested approaches??
Organization: Rational
Date: Thu, 28 Jan 1993 23:57:12 GMT

davidm@consilium.com (David S. Masterson) writes:

|The problem in what you describe is still one of dispatching the message
|received by a process to the appropriate object that will handle the message.
|The issue is what does the dictionary look like and how does the process read
|it and know what to call.  Here you must assume that the number of messages
|that the dictionary can interpret is sufficiently large and diverse (ie. not
|all the same type) in order to make the solution interesting.  For the most
|part, the question is one of syntax allowed by C++ (ie. what's the most
|type-safe way of doing it?) rather than one of modelling (there are many
|models that may be chosen).

All messages derive from an abstract class Packet.  Although the
structure of each packet is different, they all have one thing in
common, they know the ID of the object that they are being sent to.
The process receiving the packet asks the packet who it is for and
then looks that ID up in a Dictionary.  The Dictionary associates the
ID with a Receiver object.  Receiver is an abstract base class which
knows how to receive a Packet.  Subclasses of Receiver know how to
decipher a packet and build a message for the target object.  They
also contain a pointer to the target object so that they can send the
message.

The only type-system problem in this scheme is in the Receiver which
must accept a generic Packet and then decide what "Type" of packet it
is.  It may than be forced to downcast the packet to the correct type.

Even this downcast may be eliminated if a reasonable presentation
layer scheme is used to codify the packet.  Something like X.209 (the
companion to ASN.1)  


--
Robert Martin       | Design Consulting    | Training courses offered:
R. C. M. Consulting | rmartin@rational.com |  Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004  |  Object Oriented Design
Green Oaks, Il 60048| Fax: (708) 918-1023  |  C++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Is (p) instead of (p!=NULL) portable? 
Organization: TauMetric Corporation
Date: Tue, 26 Jan 1993 19:18:31 GMT

nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:

>> ... the constructs 
>>       if (p)
>> and
>>       if (!p)
>> checks for NULL and non-NULL respectively.  Is this portable to *all*
>> platforms?

>It is NOT portable for C.
>It is portable for C++ which is the group that you have posted to -
>did you mean to?

Just to reduce confusion, Hounsome's comments are not correct.
Tony Hansen posted the best answer to this question.

Both C and C++ guarantee that any pointer which compares equal to a
null pointer constant is a null pointer, and any null pointer compares
equal to a null pointer constant.  Finally, any null pointer compares
equal to any other null pointer when suitably cast.

In C++, a literal zero is most appropriate for use as a null pointer
constant.  In any event, for both C and C++, use the NULL macro which is
supplied in the standard header files in preference to writing your own
macro.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c++
From: gilstrap@sbctri.sbc.com (Brian R. Gilstrap)
Subject: Re: Object Request Broker
Organization: Southwestern Bell Technology Resources
Date: Wed, 27 Jan 93 20:51:35 GMT

In article <OLE.93Jan15163048@delab.sintef.no>, ole@delab.sintef.no (Ole-Hjalmar Kristensen) writes:
|> I am looking for implementations of an Object Request Broker as
|> specified by OMG and X/Open. Any hints?
|> 
|> Lacking that, does anyone know about a C++ implementation of RPC which
|> allows you to use a service without knowing beforehand on which server
|> it is located, and which is reasonably efficient?

There is a product from a startup called HyperDesk which is their implementation 
of a Distributed Object Management System (a DOMS is the ORB plus some of the 
as-yet-un-standardized services on top of the ORB).  As far as I know, this is 
the only product on the market which conforms completely to the OMG ORB 1.1 

A number of companies are working on implementations (e.g. Sun, NCR, HP, IBM?, 
etc.)  DEC's product may implement the complete ORB spec now (last time I looked 
at it it did not support the static interface...can anyone give an update?).
As far as I know, a number of the other companies expect to deploy their ORB
and DOMS products during 1993 (originally claims were for early '93 but I
expect this software will be like most other software and come out 1-3 quarters
later than originally announced).

NOTE: I'm not affliated with any of the aforementioned companies except as a
current or potential customer.  However, I do represent my company to the OMG.

Brian Gilstrap

-- 
Brian R. Gilstrap                      Southwestern Bell Technology Resources
gilstrap@calvin.sbc.com                550 Maryville Centre Dr.
Phone: 314-529-7639                    St. Louis, M0 63141          USA


-- 
-- 
Brian R. Gilstrap                      Southwestern Bell Technology Resources
gilstrap@calvin.sbc.com                550 Maryville Centre Dr.
Phone: 314-529-7639                    St. Louis, M0 63141          USA
From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Newsgroups: comp.lang.c++
Subject: Re: Optimized C++ library
Date: 22 Jan 1993 09:42:43 GMT
Organization: TH Darmstadt, FG Systemprogrammierung
Distribution: world
NNTP-Posting-Host: spice.iti.informatik.th-darmstadt.de

In article <1jng9aINN39s@male.EBay.Sun.COM>, pauln@loopkill.EBay.Sun.COM (Paul Nguyen) writes:
> 
> We have an application that runs OK when all the libraries were compiled with the
> -g option.  But when the libraries were re-compiled with -O for optimization.  The
> application seems to crash randomly in one of the library.
> 
> Is it possible that compiling with -O uncovered a bug?

Yes, in the compiler. Might be that you use the CC of Sun? (0.5 :-)

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
From: denis@muskie.biostat.umn.edu (Denis Nagan)
Newsgroups: comp.lang.c++
Subject: FAQ
Date: 26 Jan 93 23:41:40 GMT
Article-I.D.: news2.C1HJ5E.1Hv
Organization: Dept. of Biostatistics, University of Minnesota

Help!!
Where can I find the FAQ list for c++. This is a new language for me and the FAQ
may be quite helpful.

thanks
denis
Newsgroups: comp.lang.c++
From: sherman@unx.sas.com (Chris Sherman)
Subject: Is this C++ advice from an OO book true?  (beginner question)
Date: Sun, 24 Jan 1993 04:24:29 GMT
Organization: SAS Institute Inc.

I read the following from a book that adviced how to do software projects
using OO-type languages.  In one of the appendixes, it gave some advice
on how to write C++ programs.  

I don't understand one of the book's recommendations:

  11.  Call virtual class constructors in dervied class constructors.

     I pity the poor fools who have to spend nights and weekends searching
     for the reason that a class variable occasionally takes on strange,
     unexpected values .  .  .  only to find through their bleary eyes
     that they forgot to allocate space for a virtual base (super) class,
     so that storage is allocated for the base class's members.  Even if
     the class has no members, declare it--you never know what future
     changes will come back to haunt you (or the person who inherits your
     mine field)!


Now, I thought that a contructor will allocate everything it needs, even
if it inherits from other classes.  I never heard that you had to call
all the constructors in all the bases classes manually.  This kind of
blows the idea that a class shouldn't have to explicitly know who its
parents are, right?

Or if this is very good advice, could someone give an example showing why
it is true?

This is a beginner question obviously--thanx for any help!
-- 
     ____/     /     /     __  /    _  _/    ____/
    /         /     /     /   /      /     /          Chris Sherman
   /         ___   /        _/      /          /
 _____/   __/   __/   __/ _\    _____/   _____/           sherman@unx.sas.com
From: iperrigo@csr.UVic.CA (Ian Perrigo)
Newsgroups: comp.lang.c++
Subject: Re: C++ Wrapper for XView
Date: 26 Jan 93 22:56:17 GMT
Reply-To: iperrigo@csr.UVic.CA (Ian Perrigo)
Organization: University of Victoria

In article <1jn4jhINNp6r@news.aero.org>, jordan@aero.org (Larry M. Jordan) writes:
>I think I recall seeing a product annoucement for a set of
>C++ Wrapper classes for XView.  I have forgotten the product
>name and who the manufacturer is.  Does anyone remember?  Please
>post or respond to me directly.
>
>Thanks in advance.
>
>--Larry Jordan
>

Try UIT, it's available via anonymous ftp from export.lcs.mit.edu in the contrib directory.

Ian.
(iperrigo@cs.uvic.ca)
From: stadt@cs.utwente.nl (Richard van de Stadt)
Newsgroups: comp.lang.c++
Subject: Re: Calling of a parent method
Date: 27 Jan 93 09:46:30 GMT
Organization: University of Twente, Dept. of Computer Science

In article <1993Jan21.001929.29231@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> In article <1993Jan20.153647.25160@neptune.inf.ethz.ch> mhof@iiic.ethz.ch (Markus Alexander Hof) writes:

|> >My question now: Is therea way to specify a call to a method of your immediate parent,
|> >without naming him, so that is is possible to insert an intermeddiate class without
|> >having to cchange the son e.g.
|> >
|> >something like
|> >
|> >void B::Write (xxxxxxxxxx)
|> >	{
|> >	PARENT::Write (xxxxxxxxxxx);
|> >
|> >	some stuff;
|> >	}
|> >
|> >I know this could be difficult with multiple inheritance, but I think, this could
|> >be resolved by the compiler.
|> 
|> 	From the notes on how to write a proposal
|> for C++. A keyword 'inherited' was proposed like your
|> PARENT:
|> 
|> Michael Tiemann
|> walked in and muttered something like ``but  we  don't  need
|> that extension; we can write code like that already.''  When
|> the murmur of ``but of course  we  can't!''  had  died  down
|> Michael showed us how:
|>      class foreman : public employee {
|>          typedef employee inherited;
|>          // ...
|>          void print();
|>      };
|>      class manager : public foreman {
|>          typedef foreman inherited;
|>          // ...
|>          void print();
|>      };
|>      void manager::print()
|>      {
|>          inherited::print();
|>          // ...
|>      }

Hmmm. I've tried to use this construction:
% CC typedef_inh.C
"typedef_inh.C", line 38: error:  inherited  declared as  employee  and  foreman 
"typedef_inh.C", line 47: error:  qualified name employee :: print not found in 
manager

If the first typedef is left out, it compiles correctly.

Richard.
-- 
R.R. van de Stadt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stadt@cs.utwente.nl
Usually I use vi instead of xedit^[:wq
Newsgroups: comp.lang.functional
From: sullivan@teal.csn.org (Steve Sullivan)
Subject: Re: concurrent ML
Organization: Colorado SuperNet, Inc.
Date: Fri, 22 Jan 1993 14:13:34 GMT

  > From: amohamed@loria.crin.fr (AIT MOHAMED Othmene)
  > 
  > I am looking for papers/thesis/article on concurrent ML (cml). Interested
  > in functional language and parallelism, I am interested in knowing wether
  > any research is being done in this area. If so, how to get the relevant
  > materail.

The PhD thesis of John Hamilton Reppy describes CML.
It is titled "High-Order Concurrency".
It might be available as a tech report from Cornell U.
Dept of Computer Science, Ithaca, NY.  Published
June 1992, number 92-1285.


Steve Sullivan
sullivan@csn.org



Newsgroups: comp.lang.functional
From: leonp@cs.kun.nl (Leon Pillich)
Subject: Re: FPL on Macintosh
Organization: University of Nijmegen, The Netherlands
Date: Fri, 22 Jan 1993 08:34:59 GMT

In <C17n7s.Cs2@dcs.glasgow.ac.uk> kh@dcs.glasgow.ac.uk (Kevin Hammond) writes:

>In article <1993Jan21.134744.4873@lth.se> d92mbe@efd.lth.se (Martin Bergendahl) writes:
>>>there is concurrent Clean for the Mac available by ftp from University of Nijmegen which also offers the scope for stand-alone applications.
>>
>>How large is it?  Can you do good applications with it? What is the
>>difference between concurrent Clean and Standard ML? 

>They're pretty different.  The Clean people will tell you how.

I'm not an official spokesman but I know something about
Concurrent Clean.
First of all it is based on graph rewriting (it actually is a
graph rewriting language).
You can develop full flavoured Mac applications with it
(here someone wrote a multiple window text editor with it).
The code that is produced by the compiler is rather efficient.
(The editor is about as fast as any editor on Mac can be!).
The compiler comes with a integrated development environment
(no debugger however). There is also a simulator available to let you trace
concurrent clean programs.

There is a library available (actually is being completed now)
that supports a very high level gui programming environment.

All this is (or will be) available for anonymous ftp
at ftp.cs.kun.nl in directory pub/Clean (I think).
There is also a version available for Sun3/Sun4 (of the compiler,
the above mentioned gui librarie will also be available for sun4
within short time).
I think that one can use the compiler for any non-commercial activities
(but more about this can be found in the docs I think).

>> Is Clean, Gofer or maybe Dylan the future for FPL on mac? 
>> Answers, comments please!

>As far as I'm aware, Dylan isn't a pure functional language (or
>released?), so that leaves Clean or MacGofer, at the moment. 
>I see these as complementary rather than competing systems.

 ... Stuff about MacGofer deleted ...

Hope this helps,


Leon Pillich
University of Nijmegen, Holland
email: leonp@cs.kun.nl
-------------------------------------------------------------
 Life is what's happening when you're making other plans ...
                                      John Lennon