HDTenEightyP/NetNews huggingface dataset:
From: gls@windmill.ATT.COM (Col. G. L. Sicherman)
Subject: H-P C++ 3.0
Organization: AT&T
Date: Tue, 26 Jan 1993 20:23:52 GMT

I've been using Hewlett-Packard C++ 3.0 lately.  It's pleasantly strict
about many things that version 2 was lax about.  On the other hand,
generating the -I options for template linking is a nuisance, and we've
been bitten by a couple of unrelated bugs:

1. The standard components generously let you use version 2 of the
   List class by #including <List_old.h>.  You still have to convert
   your declarations to angle brackets, but that's progress.  Anyway,
   the old routines that return a copy of an element used to deal with 
   "no such element" in this fashion:

	// if (no such element)
	// return 0;

   In other words, somebody programmed them to return 0, was perplexed
   when the compiler rejected it, and reluctantly commented the statement
   out.

   In version 3, some of these statements have been uncommented.  The
   result is that you can't compile List<String> at all.  You can't
   compile a list of any type with two or more constructors, unless
   one of them takes an int.

2. CC -S sometimes generates bogus assembly code.  We're getting
   DS (define symbol) directives with an argument of /dev/null.
   Of course, /dev/null is not a legal name for a symbol.  If we
   compile to C first and then to assembly language, there's no
   problem.

We've solved problem 1 by restoring the screw marks, and problem 2 by
compiling to C first.  Does anybody have any better ideas?
-- 
Col. G. L. Sicherman
gls@windmill.att.COM
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.lang.c++
Subject: Re: MI vs. SI
Date: 26 Jan 93 21:58:37 GMT
Article-I.D.: ucc.1993Jan26.215837.3981
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

>
>What about using delegation through class members?
>
	Delegation is more powerful than inheritance, and thus
more error prone and harder to use. Mixins are the borderline:
the mixin demo I'm writing at the moment uses delegation
where inheritance just cant cope.

	In particular, with inheritance construction/destruction
are automatic, whereas with delegation you have to have some
protocol to decide when and who deletes the delegated to class.
(In languages with garbage collection the problem is less severe,
which is why perhaps in Stalk delegation is a more workable 
substitue for inheritance than in C++)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------
Newsgroups: comp.lang.c++
From: mcfall@cs.hope.edu (Ryan Mcfall)
Subject: Problems with TI's COOL libraries
Reply-To: mcfall@cs.hope.edu
Organization: Hope College
Date: Fri, 29 Jan 1993 02:42:26 GMT

Is anyone out there using Texas Instrument's COOL libraries??
I'm having a strange problem, and wonder if anyone else has encountered it.

Not always, but occasionally when I try to compile I get these types of
errors:

ld: Undefined symbol 
   List_char::print_self(ostream&) const 
   List_char::type_list() const 
   List_char::map_over_slots(int(*)(Generic*,char*,void*,char*,void*),void*)

It is always these three functions, and they occur for various instantiations
of list classes.  I have an idea that it may deal with the placement of the
DECLARE and IMPLEMENT statements, but I could be way off.

Thanks in advance,
Ryan McFall
mcfall@cs.hope.edu

Newsgroups: comp.lang.c++
From: gmr6139@ultb.isc.rit.edu (G.M. Richard)
Subject: Help!!!  Turbo C++ freezes up my computer!!
Organization: Rochester Institute of Technology
Date: Sun, 24 Jan 1993 19:30:23 GMT

I am using Turbo c++ 2.0 on my Tandy 1000, with 640k of memory.  When
I try to compile programs, my computer completely locks up, and I need
to reset it.  It doesen't happen all the time, but (seemingly) ramdomly
and it is quite frustrating.  I'm writing standard ANSI C code, no 
special compiler or assembler instructions, and nothing really weird (or
so I think).  If anyone else has had this problem, or thinks they can
help me, please send me e-mail!!

Any help at all would be greatly appreciated!

-- 
  _  _                __                         gmr6139@ultb.isc.rit.edu
 /| /|  __  _/__/_   /__) ' __  /_  __ ,_  __/  gmr6139@george.cs.rit.edu
/ |/ |_/-/__/__/____/ \__/_/___/ /_/-/_/__/_/  gmr6139@ritvax.isc.rit.edu
____________________________________________  gmr6139@ritlav.isc.rit.edu
Newsgroups: comp.lang.c++,comp.object
From: wayne@schaefer.math.wisc.edu (Rick Wayne)
Subject: need help with OO design question, or "What's My Hierarchy?"
Organization: Univ. of Wisconsin Dept. of Mathematics
Date: Thu, 21 Jan 93 03:59:51 GMT



hello all, i have a question for you object.experts.  i'm involved in 
the design of an app which were going to implement in BC++ 3.1 TVision.
i'm having a hard time coming up with a solution that's elegant.  please
bear with me if you think "but that's *obvious*", put it down to my
inexperience.

our app deals with documents.  there are several kinds of documents,
doc1, doc2, and doc3.  each kind of document shares many behaviors and
features (e.g. output as ASCII).

documents are made up of sections.  sections can be of several different
types, like ID, Module, and Stats.  sections also share a lot of 
behavior, for instance they too need to be able to represent 
themselves as ASCII on a stream.

let's say that doc1s have just ID, doc2s have ID and Stats, and doc3s 
have ID, Module(s), and Stats.

so far, so good.  Document is an abstract superclass, with as much 
behavior as i can find in common.  doc1, doc2, and doc3 are subclasses.
Section is another abstract superclass, with ID, Module, and Stats 
deriving from it.

question 1: an obvious way to implement, say, doc3, is to define it with
members ID, Module, and Stat.  however, every time i want to have the 
whole Document write itself out to ASCII, i have to say

	mydoc3.ID.ascout();
	mydoc3.Module.ascout();
	mydoc3.Stat.ascout();

or some such.  i also have to repeat this for each Document subclass.
is there a clean way to use a container class here instead of defining 
the sections as members, and just have document-wide methods iterate 
over the contents of the container?

question 2: notice that IDs are common to all documents.  they could
therefore be part of Document, instead of doc1, doc2, and doc3, right?
on the other hand, ID Sections in doc2s have to have behavior that's 
just *slightly* different.  unfortunately, if the ID is part of 
Document, i'm stuck with the generic version -- right?  you can override 
a method inherited from a superclass, but not a method contained in a
*member* inherited from a superclass, nor can you override the member
itself (i.e. i'd love to override the inherited member ID with myID).

final question: is that last point a desirable language feature?


rick

(please direct email replies to wayne@express.uwex.edu -- thanks!)
Xref: sparky comp.lang.c++:19930 comp.sys.next.misc:24105
From: steve@taumet.com (Steve Clamage)
Subject: Re: inline and varargs clash???
Organization: TauMetric Corporation
Date: Thu, 28 Jan 1993 18:21:55 GMT

pete@arl.wustl.edu (Peter Flugstad,,,) writes [abridged example]:

>#include <stdio.h>
>#include <stdarg.h>

>inline void Debug_Sys_Print (char *format, ...)
>{
>  va_list args;
>  va_start (args, format);
>  vprintf (format, args);
>  va_end (args);
>}

>main ()
>{
>  Debug_Sys_Print ("Hello, %s\n", "World");
>  printf ("done...\n");
>}

>The problem I am having is that I get a linker error:

>pete> CC -D_ERR_DEFINE -o print print.C
>ld: Undefined symbol 
>   __builtin_va_alist 

The variable-arg mechanism usually relies on arguments being passed
in a certain way on the stack.  An inline function usually doesn't
pass arguments that way.  (This is all extremely implementation-
dependent.)

If an implementation supports inlining of variable-arg functions, it
must provide a set of macros in <stdarg.h> which will work with inline
functions.  Otherwise, it can simply generate variable-arg functions
out-of-line.  (A compiler is never obligated to generate an inline
function in line.)

It appears that this implementation attempts to inline the function
but does not have a suitable <stdarg.h>.  I have to consider this a bug.
You are lucky in that the program failed to link, rather than simply
crash or produce bogus answers.

Fortunately, the workaround is simple.  Don't declare variable-arg
functions to be inline.

If a function is heavily used and its calling sequence is comparable
in size or speed to the body of the function, it is a good candidate
for inlining.  Otherwise, inlining may be counter-productive.  It seems
unlikely that a variable-arg function is a good candidate for inlining.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c++
From: kbad@netcom.com (Ken Badertscher)
Subject: Re: Creating Libraries within the Borland IDE
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 28 Jan 1993 05:10:13 GMT

gisie@wam.umd.edu (Satan) asks:

|	Can the IDE manage my library(ies) and how do I set
|	up a project to do so?

Check Options|Make|After Compiling.
-- 
Ken Badertscher                         I need something...
kbad@taligent.com, kbad@netcom.com      ...I just don't know what it is.
From: mjackson@gssec.bt.co.uk (Mark Jackson)
Newsgroups: comp.lang.c++
Subject: Mixins (was Re: C++ Multiple inheritance)
Keywords: multiple inheritance
Date: 22 Jan 93 14:18:45 GMT
Organization: BT, Software Engineering Centre, Glasgow, Scotland

In article <1993Jan21.011328.4841@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> In article <1993Jan20.135930.14615@gssec.bt.co.uk> mjackson@gssec.bt.co.uk (Mark Jackson) writes:
|> >In reply to Dennis Marer and SR Heintz (sorry, my email doesn't
|> >recognise your mail address), I think I have a 'real world' example
|> >for you...
|> >
|> >The system is Client-Server based, communicating via common IPC
|> >service classes.
|> >
|> >class IPCEventHandler : public IPCClient, public EventHandler
|> >{
|> >  public:
|> >    ......
|> >    // Virtual method Inherited from EventHandler
|> >    void HandleEvent( Event& theEvent )
|> >    {
|> >        // Build an IPC Message from the Event data
|> >        IPCMessage theMessage( theEvent.getData() );
|> >
|> >        // Send the resulting message over the IPC
|> >        // using method inherited from IPCClient
|> >        SendMessage( theMessage );
|> >    }
|> >    ......
|> >};
|> >
|> >Unfortunately, at this point, I was supposed to come up with the reason why
|> >I couldn't just inherit from the EventHandler class, and have the IPCClient
|> >as a data member, but try as I might, I can't remember....................
|> 
|> 	I'll remind you: you override a method from Event handler,
|> thus you cant have it as a member.

BULL, as you say below. If you'd read what I wrote, you'd see
I'm talking about having an IPC object as a member,
NOT the EventHandler. This would look like

class IPCEventHandler : public EventHandler
{
  private:
    IPCClient *ipc;

  public:
    ......
    // Virtual method Inherited from EventHandler
    void HandleEvent( Event& theEvent )
    {
        // Build an IPC Message from the Event data
        IPCMessage theMessage( theEvent.getData() );

        // Send the resulting message over the IPC
        // using IPCClient object
        ipc->SendMessage( theMessage );
    }
    ......
};

Still can't remember why I couldn't do this, though, which is really beginning
to bug me #$^@!&

|> 
|> >P.S. I still think using MI with more than 2 parent classes is decidedly
|> >dodgy. 4 is right out. (Book of Armaments: Ch. 4 v. 5) 
|> >
|> 	Bull. Use as many as is appropriate.
|> 	With mixins, that could be quite a few.

I've seen you championing mixins in other articles. Could you give
us a few wee, but not Noddy, examples.
Then you may be able to twist my arm...

|> 
|> 
|> -- 
|> ;----------------------------------------------------------------------
|>         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
|> 	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
|> ;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------

-- 

   !!!!!!!     __________________________
   +(.)(.)    (                          )
   C   > )    |  I, and only I, said it. |
    \ V / ----(__________________________)
     ---

Mark Jackson
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Overloading Operators
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 26 Jan 1993 12:08:25 GMT

gray@celia.UUCP (Steve Gray) writes:

>> Like Nikki, I can't think of any way in which a const or volatile
>> reference differs from a plain reference.  Is there a difference?
>
>A const reference differs in a very important way from a plain reference:
>it clearly states that the member function has no side effects.

The term "const reference" was being used in this thread to indicate
	int & const ref
not
	const int & ref
So it doesn't indicate that the object referred to is not changed.

I agree with the earlier statements that const references don't differ from
plain references. But I can see that a volatile reference might differ from
a plain reference, although I see no useful way of using this difference.

	int i;
	int & volatile ref = i;		// 'volatile' here prevents compiler
					// from optimizing away 'ref' if
					// it is not used?

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c++
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: References to functions?
Reply-To: swillden@cs.weber.edu
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Tue, 26 Jan 93 16:26:24 GMT

KOCHER@nvdv.e-technik.uni-stuttgart.dbp.de (HARTMUT KOCHER) writes:
: In <1993Jan25.182507.13761@fcom.cc.utah.edu> swillden@news.ccutah.edu writes:
: > : Not exactly. Let's say I have a callback class which takes a pointer
: > : to a function in its constructor. If I use a pointer, a 0-pointer may be
: > : passed. If I use a reference instead, I can make sure, that the user
: > : supplies a valid function.
: > Not really.  Try:
: > typedef int (callbackfunc)(int);
: > extern void set_callback(callbackfunc&);
: > void foo()
: >     {
: >     callbackfunc* callback = 0;
: >     set_callback(*callback);
: >     }
: > : Hartmut Kocher
: > Shawn Willden
: > swillden@icarus.weber.edu
: 
: Sure, but it's always undefined to dereference a 0 pointer.

Yes, it is undefined, not illegal.  A compiler could warn about it in
this case, I suppose, but a quick experiment shows that g++ 2.3.3, and
Cfront 3.0.1 accept the above code without complaint and there are
many situations in which the compiler couldn't know.

: With a reference you always clearly state, that you are 
: expecting a valid object/function, etc.

This is true, as long as you realize that you are only stating that
you expect a valid object/function.  You are not forcing the the user
to supply a valid argument, which was what I understood your intent to
be.

: Therefore, it's the callers responsibility to make sure he's passing a valid
: argument, whereas with pointers, the function implementor has to check for
: 0 pointers, because these are allowed by the language.

It's always the caller's responsibility to pass a valid argument.  I
agree that passing a reference *should* make it clear to the user that
he needs to pass a valid function.  If you intended the reference
parameter to be a reminder then I agree.  This is, however, a
strictly stylistic thing, not an example of a need for function
references.  Now, if we had a way to impose run-time checks on the
validity of pointers that are dereferenced and cast to references...

: Hartmut Kocher

--
Shawn Willden
swillden@icarus.weber.edu
Newsgroups: comp.lang.c++
From: rickt@rmtc.paramax.com (Rick Thompson [RMTC/ISP])
Subject: gcc/2 and dll's for OS/2
Organization: Paramax Systems
Date: Tue, 26 Jan 1993 20:09:14 GMT

Hello,

I was wondering if it is possible to create dll's using gcc/2 for OS/2?
If so could someone send me an example?


Thanks,

Rick  rickt@rmtc.paramax.com
Newsgroups: comp.lang.c++
From: rmartin@stripe.Rational.COM (Bob Martin)
Subject: Re: Virtual function call within constructors
Organization: Rational
Date: Tue, 26 Jan 1993 22:47:01 GMT

steve@taumet.com (Steve Clamage) writes:

>gschwarz@dcc.uchile.cl (Guillermo Schwarz Utrup) writes:

>To: gschwarz@dcc.uchile.cl
>Subject: Re: Virtual function call within constructors
>Newsgroups: comp.lang.c++
>References: <1993Jan24.051330.3721@dcc.uchile.cl>

>In comp.lang.c++ you write:

>>I have found that virtual functions are not handled as one could expect
>>when called from a constructor.

>That is because you are not expecting the right thing.  Look up
>virtual functions in constructors in any good C++ text.

>When constructing a base class, only functions visible from that class
>constructor can be called.  The derived class has not been constructed yet,
>so you can't call any of its functions.  For example, the derived version
>of the virtual function might depend on data set up by the derived
>constructor, which won't have yet been called.

Let me add to Steve's excellent explanation by talking about the
dangers of calling pure virtual functions from within constructors and
destructors.  

When an object is being constructed, its constructors are called in
the order of inheritance.  The process starts by calling the
constructor of the base-most class and ends by calling the constructor
of the most derived class.  Now it is one of the jobs of the
constructor to set the virtual table.  (This is implementation
dependent, but the concept and results should be the same in all
implementation sof the compiler)  Thus, as each constructor is called,
the virtual table is changed to correpspond the the class of the
currently executing constructor.  This is why, when you call a virtual
function from a constructor or destructor it will never deploy any
deeper than the class of the currently execuring constructor or
destructor.

Now, what if you call a virtual function which, at the current level,
is declared as a pure virtual.  Since the entry in the virtual table
is undefined, the result of the call will be undefined.  (This
typically means some kind of nasty crash).

Many compilers will prevent you from calling a pure virtual function
from a constructor or a destructor, but there are ways around this.
It is possible, from within a constructor or destructor, to call a
function which calls a pure virtual function.  Most compilers cannot
detect that.

So be very careful in your constructors and destructors.  Since
virtual functions don't deploy, they should not be called.  If calling
them is necessary then use the scope operator to call them directly:
(e.g. MyClass::MyVirtualFunction()).  Never call a pure virtual
function from a constructor or a destructor.....


--
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: raymond@es.ele.tue.nl (Raymond Nijssen)
Newsgroups: comp.lang.c++
Subject: Re: What is LEDA?
Date: 22 Jan 93 12:09:31 GMT
Organization: Eindhoven University of Technology, Eindhoven, The Netherlands
In-reply-to: schmidt@rz.uni-passau.de's message of 19 Jan 93 13:58:54 GMT

In article <schmidt.27@rz.uni-passau.de> schmidt@rz.uni-passau.de (SCHMIDT GUIDO) writes:

>   I've heard of the C++ classlib LEDA. 
>   What are its features? And where can you get it?


The README that comes with LEDA says:

---------------------------------------------------------------------->8-----


                                  LEDA

             A Library of Efficient Data Types and Algorithms


                             Stefan N"aher
                   Max-Planck-Institut f"ur Informatik
                  Im Stadtwald, 6600 Saarbr"ucken, FRG
                          stefan@mpi-sb.mpg.de


The LEDA library of efficient data types and algorithms is available via
anonymous ftp.

SITE:  ftp.cs.uni-sb.de (134.96.252.31)

FILE:  /pub/LEDA/LEDA-<version>.tar.Z   (compressed tar file)



 * LEDA is not in the public domain, but you can use and distribute
   it freely for research and teaching.

 * Do not distribute modified sources. Please report discovered bugs,
   critics, suggestions, and any changes you make to stefan@mpi-sb.mpg.de

 * Maybe, if you like LEDA, you want to support us by a donation of 100 DM.
   Our account:  Postscheckamt Saarbr"ucken
                 account 926 28-663
                 bank code 590 100 66

 * Send a message to stefan@mpi-sb.mpg.de if you want to be on the LEDA user
   mailing list
---------------------------------------------------------------------->8-----


Hope this helps,
-Raymond

PS: I decided not to use it, so I'm afraid I won't be able to answer questions
    about it.


--
Raymond Nijssen             | Eindhoven University of Techology
       phone: +31-40-473373 | Department of Electrical Engineering
       fax:   +31-40-464527 | Design Automation Section (ES),  room EH 7.16
"WP is for morons"          | PO. Box 513, 5600 MB Eindhoven, The Netherlands
Newsgroups: comp.lang.c++
From: richarm@a.cs.okstate.edu (MCINTYRE RICHARD D)
Subject: Re: Why is C++ not considered a true OOL?
Organization: Oklahoma State University, Computer Science, Stillwater
Distribution: na
Date: Sat, 23 Jan 93 20:06:21 GMT

In article <1993Jan22.192629.295@base> xinxu@stam.qe.bell.ca (Xin Xu) writes:
>I'm doing a presentation of C++ for a Comparative Languages course.  During 
>my readings, the authors mentioned that C++ isn't a true object oriented 
>language, but they never said why.  This is ofcourse in comparison with 
>smalltalk.  Does anyoune know why this isn't the case.  Could it be that C++ 
>does not meet the definition of what true OOPs are supposed to be.  The 
>books I have look at C++ from C, and they give a definition of what OOPs 
>are supposed to look like, and C++ meets all there criteria.  But later 
>they say it isn't a true OOL.
		     ^^^^

Are you sure your not confusing the concepts of pure vs. true?  Yes,
according to most definitions of "object oriented", C++ is a true OOL.

However, C++ is not a pure OOL, as is Smalltalk.  In Smalltalk the
only way to accomplish anything is through message passing.
Everything is an object.  This is not the case with C++ because
it is a superset of the C language.  A C++ program is only object
oriented if you write it so that it's object oriented.  C++ programs
can be written without using ANY object oriented concepts, and
therefore, it's not a pure OOL.  But it is a true OOL in the sense
that it does have the potential to do all of those things that an OOL
is required to do.


-- 
Name :		    Dallas McIntyre
Occupation :	    Student - Still looking for a "real" job.
Favorite Far Side : Tarzan Introducing Himself to Jane.
Email Address :	    richarm@a.cs.okstate.edu