HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Should I use a generic object which all others inherit from
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 20 Nov 1992 13:34:41 GMT

In article <1992Nov17.190821.18348@informix.com> cshaver@informix.com (Craig Shaver) writes:
>In article <3762@news.cerf.net> hlf@nic.cerf.net (Howard Ferguson) writes:
>>I am working on the early stages of design on an embedded C++
>>project. One of the decisions which we will have to make in the
>>near future is whether to make all of the objects inherit from 
>>onie generic object at the top of the tree or to go for the forest 
>>approach. 
>>
>
>You have some of the benefits of OOP in mind, such as inheritance, reuse, 
>and information hiding.  Then if you are willing to take small dings in
>performance go all the way and use the tree approach as pioneered by
>Smalltalk.  

	Please do NOT do this. This approach requires dynamic type
checking which cannot be done in C++ (yet). IMHO the object model
of Smalltalk is totally inappropriate in C++. You should do exactly
the opposite, IMHO. C++ now has multiple inheritance (MI), use it.

>I recently saw a review of the toy code that comes with the
>borland compiler.  The article's author commented that the tree type
>libraries were "passe" because of templates.  What a stupid thing to say!

	I dont agree and neither does Borland (I assume) since they
provided an updated version using templates. The original 'object'
version is one of the worst pieces of code I've ever seen (sorry
Borland, twas the best that could be done with only single inheritance
and no templates I suppose).

>
>One of the big wins of OOP is reuse.  By using an inheritance structure
>you can reuse existing code and do incremental development.  

	By using a 'tree' structure you can only do 'layered development'.
To do proper 'incremental' development you must use mixin techniques,
which require abstract virtual bases.

>Related and
>unrelated classes can be used in the same context where a similar protocol
>is enforced.  

	Absolutely not in C++. C++ unlike Smalltalk is strongly typed,
the only support for 'protocol' based reusability is with templates.
(My tagged pointer proposal extends this considerably).

>
>I have to think some of the people involved with C++ have no idea what the
>basis of OOP really is.  They are simply using C++ as an improved C.

	Nothing wrong with that. C compatibility is one of the principal
guidelines of the standardisation people. Using C++ as an ADT language
is a good use of C++ in my opinion, that is, as C with user defined
types.

	If you really want dynamic object orientation, C++ is probably
not the best language to use. Why not use Smalltalk in the first place?

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: 00skolis@leo.bsuvc.bsu.edu
Newsgroups: comp.lang.c++
Subject: accessing this group under ANU-News
Date: 17 Nov 92 16:05:31 GMT
Organization: Ball State University, Muncie, In - Univ. Computing Svc's

I am trying to access this news group. When I enter the command 
   open comp.lang.c++ 
I recieve an error with the "+" sign. It will not allow
access. Can you tell me how to access this news group directly at the 
news prompt?

I am running ANU-NEWS under VAX/VMS operating system.
Newsgroups: comp.lang.c++,comp.std.c++
From: gkrishna@alt.uucp (Gopal-Krishnan)
Subject: Re: something nasty 
Keywords: cfront nasty 
Organization: Unisys Corp, Camarillo, CA - 93010.
Date: Tue, 17 Nov 1992 17:26:33 GMT

>dan@BofA.com (Dan Brockman) writes in <1992Nov1.224626.771@BofA.com>:

> "DealStruct.c", line 165: internal <<AT&T C++ Translator
> 2.1.03 08/31/90>> error: bus error (or something nasty
> like that)
> Compilation failed 

  In the summary I did not see the following as 'possible causes'. And so,
 here I am posting this:

1. When the nesting level is too high cfront dies this gracefully!. 
  That is if you have code that says 
  {
   blabla
   {
    blabla
    { ...etc.
  I think the AT&T C++ Language System Release Notes or some such document gives
  this number as 20 for 386 machines etc. So, if your program has more than 
  that specified number of open '{', then you get this internal error.
  Even if your code does not have that many '{, remember that each variable
  definition midway your code introduces a scope. 
    I mean things like 
       x= y+z;
       int a = 4; //this introduces a scope.

  Way out:
  Just get rid of those unnecessary scopes you have, if any.
  Make extra functions by splitting your code, if that is possible.
  Better still, ask your compiler guy. He should be able to give a fix for you.
  My compiler guy was able to give me a fix (after some time though).

2. When your code has complicated 
   while ... for ... while loops the same thing happens.
  
  Way out: 
  Same as above.
  
3 onwards:
  I had a few more cases when I got this 'nasty' thing. They are complicated
  code, and hence is not possible to generalise and post them. 

  Anyway, try workarounds by modifying your code. 
  In most cases, it is possible.

My compiler guy said, that he has a handful of signal handlers installed in 
the system, and when any of them is invoked, this msg is printed.
That is why the msg sounds so nasty. 
-----------------------------------------------------------------------
Gopal Krishnan          | internet: alt!gkrishna@uunet.UU.net
Unisys Corporation      | voice: 805-389-4446
Open Systems Group      | fax  : 805-389-4420
5155, Camino Ruiz       | Take charge. Somebody has to do it - 
Camarillo, CA - 93012.  |  It might as well be you.
-----------------------------------------------------------------------


Xref: sparky comp.lang.c++:16410 comp.std.c++:1581
From: rns@npg-sd.SanDiegoCA.NCR.COM (Rick Schubert)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: something nasty report
Date: 16 Nov 92 20:31:30 GMT
Organization: NCR Corp., Network Products - San Diego

In <1992Nov14.233744.27337@ornl.gov> mullens@jamsun.ic.ornl.gov (James A. Mullens) writes:

>In article <5798@npg-sd.SanDiegoCA.NCR.COM>, rns@npg-sd.SanDiegoCA.NCR.COM (Rick Schubert) writes:
>|> In <BxIp1L.M37@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
>|> 
>|> >When a compiler dies with an internal error, causes an access
>|> >violation, etc. it is *always* a bug.
>|> 
>|> Not *always*: if the internal error is caused by an error in the program
>|> being compiled, it is merely a very user-unfriendly error message (I
>|> consider "segmentation violation -- core dumped" to be the ultimate
>|> diagnostic).

>You forgot the (;-), right?

I purposely omitted it, but it was implied.  I try to be subtle.

Sorry to decrease the signal/noise ratio of comp.std.c++, though.  I had
second thoughts after posting (although the original article, and resulting
thread, shouldn't have been cross-posted to comp.std.c++, anyway).

>I'd say *always*.  I'd also say that C++ compilers are more prone to this
>problem than any other language compilers (my experience anyway).

cfront seems to be prone to this.  Are these other C++ compilers cfront-based?
[You don't have to answer that.]

>When I'm faced with an access violation/segmentation violation/bus error,
>and I really have no clue as to what's causing it, I start removing large
>blocks of source code with #if 0 ... #endif until the compiler finishes
>successfully.  Then I reintroduce parts of code until the compiler bombs
>again.  In the end, the problem is isolated.  I may have a programming
>error there, or the compiler may just be batty.  I always send a bug report.
>I'd like to send a bill for my time ( at $60/hour :-).

It's always a good idea to try to isolate a problem before reporting it:
it increases your chances of having the bug fixed (not to mention helping
out the people supporting the software).

Follow-ups probably not appropriate, but I'm not redirecting them.

-- Rick Schubert (rick.schubert@SanDiegoCA.NCR.COM)
From: cshaver@informix.com (Craig Shaver)
Newsgroups: comp.lang.c++
Subject: Re: Should I use a generic object which all others inherit from
Date: 19 Nov 92 16:55:29 GMT
Organization: Informix Software, Inc.

In article <5232@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>cshaver@informix.com (Craig Shaver) writes:
>: In article <3762@news.cerf.net> hlf@nic.cerf.net (Howard Ferguson) writes:
.......   blah blah blah
>: performance go all the way and use the tree approach as pioneered by
........  blah blah blah
>: 
>: One of the big wins of OOP is reuse.  By using an inheritance structure
>: you can reuse existing code and do incremental development.  Related and
>: unrelated classes can be used in the same context where a similar protocol
>: is enforced.
>
>Perhaps you would then kindly enlighten the rest of us:

OK!

>
>If I go for the tree approach, with a base class MyObject inherited

YourObject is worthless, just use MyObject....

>by all my classes, how am I going to reuse _your_ classes, which all
>inherit from class YourObject?  Multiple inheritance?  What

Use delegation instead of MI ...

>if the protocol of my base class conflicts with your base class?
>How do I reuse tree-type libraries from several sources, each with
>it's own base class protocol?

You don't!  C++ bites it bigtime because of a lack of the one thing
that would really make it good -- a standard base class library.

>
>Enforcing a common protocol (by inheritance) for all your classes,
>_hampers_ reuse of your classes by anyone except yourself.

Hold on there pardner!  Start your own branch if you don't like mine.
Trim the damn tree, make sure you have access to all source for classes.
This statement sounds bogus.  What is your point?

>
>Once a reference to an object has been passed as a generic
>object reference, for example into a collection, how do you (safely)
>call the actual methods of the objects (derived) class?
>
>-- 
>--------------------------------------------------------------------------
>| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
>| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
>--------------------------------------------------------------------------

Soooooo, give me your rebuttal in terms of flat class hierarchy and let me
attack you.  Templates are useless and should be removed from the language.

Craig.......

-- 
Craig Shaver  (cshaver@informix.com for now) (415)390-0654 (415)926-6407
Productivity Group POB 60458 Sunnyvale, CA  94088
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Idempotent header file proposal
Organization: TauMetric Corporation
Date: Fri, 20 Nov 1992 01:00:09 GMT

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

>Can we not have a standard pragma to say that a header file is idempotent
>(A long word  I discovered that means that it only need be included once).

Not quite.  It means that (in this context) multiple inclusions have
the same effect as one inclusion.

>eg. put #pragma IDEMPOTENT in the header and have the preprocessor
>understand that it need not bother reading this file again it seems
>very easy to implement provided only that you use an ANSI preprocessor
>and it requires no language extension since it is only a convention
>which the preprocessor can ignore if it does not understand it.

Some compilers have this feature, often called "#pragma once".

This solves a problem outside the language, and for that reason is
probably not appropriate to put in the language Standard.  In
particular, you are assuming that a standard header is a file, and
that it is read and processed by the compiler in the way user text
files are processed.  Nothing in the language specification requires
this to be the case.  Any compiler is free to recognize the names of
the standard headers and do any kind of magic, so long as the net
result is what the Standard specifies.

For example, the compiler could have the contents of the standard
headers already available in its symbol table but inactive when
the compiler starts up.  It would activate the definitions
associated with a standard header when the include directive was seen.
This takes no time, and has no penalty if done more than once.

One problem with pragmas is that they are not necessarily harmless
when not implemented on another compiler.  My favorite example, for
which I cannot take credit, involves "#pragma once".  As I noted
earlier, on some compilers it means "ignore further requests to
include this header."  On another compiler, it might mean "turn
on Customer Engineer features."  These features are turned off
with "#pragma offce".

Many people involved with standards efforts believe that there should
not be such a thing as a "standard pragma".  A pragma by its nature
controls something non-standard, non-portable, or system-specific.
If the thing controlled were generally portable, it should probably
be a language feature, not a pragma.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Idempotent header file proposal
Organization: TauMetric Corporation
Date: Sun, 22 Nov 1992 17:37:34 GMT

frank@Cookie.secapl.com (Frank Adams) writes:

>In article <1992Nov20.010009.24900@taumet.com> steve@taumet.com (Steve Clamage) writes:
>>nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
>>>Can we not have a standard pragma to say that a header file is idempotent
>>
>>This solves a problem outside the language, and for that reason is
>>probably not appropriate to put in the language Standard. [...]

>This is a generic problem; it
>does *not* apply only to some systems.  So a standard is appropriate; but if
>it is neither to be a language standard nor a standard pragma, how is it to
>be done?

Some compilers are very slow.  How about a standard pragma "#pragma fast"
which would direct the compiler to compile more quickly if it could.
Some compilers require too much memory at compile time.  How about a
standard pragma "#pragma small" which would direct the compiler to use
less memory if it could.  If the compiler could not comply, it would
ignore these pragmas.

I hope these suggestions sound silly to you.  These, along with the
repeated include file problem, are not C++ (or C) language problems.
They are "quality of implemenation" issues.

Please note I am not saying that an implementation should not provide
pragmas (or command-line flags) to cater to specific features of the compiler
or runtime system (including "fast", "small", or "once" pragmas).  I am
saying that these are not issues for the language specification to address.

[Perhaps we have a slight communication problem.  When I use the word
"standard", I mean in the sense of an agreed-upon language specification.
For C, this means the ANSI/ISO C Standard.  For C++, it currently means
the ARM, and will eventually mean the ANSI/ISO C++ Standard.  I don't
use the word "standard" to mean merely "popular".]

As Jim Adcock has noted in another posting, compilers exist which address
the include file problem without requiring source code modification.
Precompiled headers and incremental compilation are two ways existing
compilers avoid entirely the problem you are trying to fix with a language
extension.  Other solutions are also possible.

If your compiler is too slow or uses too much memory, get another one
which better suits your needs, or lobby your vendor to make improvements.
If your compiler doesn't deal intelligently with repeated includes,
take similar measures.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Multiple Inheritance - Necessary?
Keywords: c++ inheritance
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Sat, 21 Nov 1992 00:08:40 GMT

In <By17An.4uH@usenet.ucs.indiana.edu> ezachris@iroquois.ucs.indiana.edu writes:

>A friend of mine who programs in Objective-C argues that multiple  
>inheritance is unnecessary and complicated. 

*****>	S/He doesn't _have_ to use it if s/he doesn't understand it.
	It's useful when you need it; useless otherwise.  (This state-
	ment is true of everything.)

>Let's say you have a pencil-object and an eraser-object and to create a  
>pencil-with-an-eraser-on-it you'd inherit from both the pencil and the  
>eraser object, right?

*****>	I wouldn't (this is a bad example, IMHO).  A pencil-with-eraser
	is-a pencil but it isn't-an eraser.  I would derived pencil-with
	-eraser from pencil that has-an eraser.

>My Objective-C friend would make a new object "Pencil-with-eraser" that  
>would declare two objects inside it.

>Like this:

>     PENCIL-WITH-ERASER
>        Eraser TheEraser(...);
>        Pencil ThePencil(...);

>To implement the functionality of the pencil and the eraser he'd write a  
>bunch of functions that call the functions inside the pencil and the  
>eraser objects. 

*****>	Then a pencil-with-eraser can not be used in all places a pencil
	can since it's not derived from it.

>I think this sounds like hogwash. What do you think?

*****>	Hogwash.  MI, like all things, has its place. 
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Xref: sparky comp.lang.c++:16612 comp.os.ms-windows.programmer.misc:3563
From: smrttadm@uniwa.uwa.edu.au (Jeffrey Smartt)
Newsgroups: comp.lang.c++,comp.os.ms-windows.programmer.misc
Subject: Do virtual tables have to be in the DATA seg with Borland C++?
Date: 20 Nov 1992 10:20:30 +0800
Organization: The University of Western Australia
NNTP-Posting-Host: uniwa.uwa.edu.au
Keywords: borland bcc bc virtual

G'day,

does anyone know if the virtual lookup tables produced by the Borland
compiler must be in the DATA segment of the application being built - if
this is the case it would appear that there is a limit to the size of
an application when using the compiler...

Can virtual tables be forced into their own segment?

Jeff.
Newsgroups: comp.lang.c++
From: bell@nella4.cc.monash.edu.au (mr g.a. bell)
Subject: TurboVision and SB Pro card
Keywords: Tvision,SBPRO,help
Organization: Monash University, Melb., Australia.
Date: Sun, 15 Nov 1992 21:35:07 GMT



Hi Netters, 

I am having trouble linking in the sbpro libraries
to a TurboVision program. The application works fine if I remove
the sound card calls but when I place the sbpro code in the program
it does not work.

I have found the the order of linking is also a problem, for example
if you do not link in the sbpro library last the program hangs the
computer. You must have not default libs linked and add the libs
you need to the project file.

I get an Abnormal Program termination error which does not occur
when no sbpro libs are linked. 

Can any one help me.

I am using BCC 3.1 on a 486.

Thanks,

Gary.


-- 
``````````` bell@nellads.cc.monash.edu.au `````````````````````````````````````
| Gary Bell                                                                   |
| Department of Robotics and Digital Technology                               |
|Faculty of Computing, Caulfield Campus, Monash University, Australia         |
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: Overload operator to concatenate Strings?
Date: 18 Nov 92 00:35:17 GMT
Organization: negligable

NIHCL uses the & operator, so at least there's precedent.  I prefer '+'
myself.  To me a String is a String, and if it's underlying representation
is "a vector of char" that is immaterial.  (I mean, isn't that what this
Object stuff is supposed to be about? :)  Adding two Strings resulting
in a single longer string seems perfectly reasonable to me.   '&' is
intuitive if you consider the common english usage for it, but I have
the C usage (bitwise and) too firmly embedded in my mind for me to like 
it as the String concatenation operator.  Using '||' (or '&&') would
be right out.  Since they have program flow uses that get lost if you
overload them (if I understand the previous article correctly...)

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"186,000 mi/sec.  Not just a good idea, it's the LAW!"

Newsgroups: comp.lang.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Templates parameterized on templates (!)
Date: Sat, 21 Nov 1992 18:03:44 GMT
Organization: Security APL, Inc.

In article <1992Nov19.215956.20239@cssc-syd.tansu.com.au> pete@cssc-syd.tansu.com.au (Peter Alexander Merel) writes:
>template<template Container, class T>
>class troppo
>:
>    public Container<T>
>{
>    ...
>};
>
I'm not up on whether real live 3.0 compilers will do this
>or not. If they don't I think they should. 

They don't, and I think they should, too.  But the first line should
probably be either:

template<template<class> Container, class T>

or

template<template Container<class>, class T>
---------------
In the mean time, you can write:

template<class Container, class T>

with the assertion that the template will only work if Container is a
container class whose element type is T.
Newsgroups: comp.lang.c++
From: mcgrant@rascals.stanford.edu (Michael C. Grant)
Subject: Two things: typeof() and exceptions
Organization: Information Systems Laboratory, Stanford University
Date: 15 Nov 92 13:41:27


First of all, I'm disappointed that the typeof() operator suggestion did 
not generate much discussion, save a couple of e-mail messages. Don't you
think that it would extend the utility of templates?

One person pointed out that, in my example,
template <class T> class Foo {    ---> <double>     <complex>
        T data;                   ---> double data; complex data;
        typeof(abs(T)) norm;      ---> double norm; double norm;
}                                 --->
that it must be considered that abs(const T&) should be a possible
substitution as well (thought the tone of his message was that he
didn't think it was necessary). Well, I agree that abs(const T&) should
be considered by typeof(abs(T)), since standard overloading would
consider it, but perhaps then the syntax is a bit confusing.

Secondly, I was reading the reference manual for Dylan (Apple's new OO
language) and I noticed something that was pretty hot in the exception-
handling domain. Basically, in any given procedure you can define a set
of instructions that are guaranteed to be executed even if the rest of
the procedure is terminated early due to an exception. Currently in C++,
automatic variables are destroyed as the stack is unwound. But, with 
a set of 'unwind' statements in a function, I could destroy all of the
variables I allocated on the heap as well.

If I had the Dylan manual with me I'd give you the exact syntax and
description. But, if you understand that last paragraph, please
comment! Note that that behavior could be simulated by defining a 
class local to that function that contains in its destructor all of
the said 'unwinid' statements. Then, when that class is destroyed by
the stack-unwinding procedure it would give the desired effect. But,
since exceptions haven't been implemented on a wide basis yet perhaps
the Dylan model can be considered.

Michael C. Grant
Newsgroups: comp.lang.c++