HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: downcasting (was Re: GOTOo wars)
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 1 Oct 1992 17:41:20 GMT

In article <347@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>In article <1992Sep25.060915.28073@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>>	I've presented thoughts against downcasting, for example.
>>Doesn't mean I'm against it. Means I'm concerned, and want--actually
>>desire--that someone will show me my concerns are unjustified.
>>But I dont go around saying anyone believing in downcasting
>>is stupid. Hell, they might be right :-)
>
>We're using the NIH Linked List.  When you get something off
>the list it is just an Object *.  To actually use it you have
>to downcast it to it's proper (and hopefully Object-derived :)
>class.  If someone knows a way around this, please let me know
>and I will *gladly* give up my use of castdown......
>

	I havent seen NIH but I understand it is like the Smalltalk
classes, and has aggregates of Object*. This is an out of date 
and very poor design technique for C++. (NOT for Smalltalk, where
it is perfectly correct).

	The solution is to use a well designed library. If your
compiler doesn't have templates, you'll just have to wait.

	If you have templates, either

	a) use a better library
	b) write your own (which is hopefully included in (a) above)
	c) encapsulate the NIH list class in a template class
	so the downcast is hidden safely away in a single piece
	of source code.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: elliot@ansoft.com (mike elliot/.nam)
Subject: Re: constructors & sizeof in C++
Organization: Ansoft Corp. Pittsburgh
Date: Fri, 2 Oct 1992 13:43:40 GMT

In article <wL06TB1w165w@csource.oz.au> david@csource.oz.au writes:
>Is this sort of constructur legal/advisable?

Yes it is legal. No it is not advisable.

> class Foo {
>   private:
>     int mem1;
>     int mem2;
>     char mem3[10];
>   public:
>     Foo (void) { memset(this, 0, sizeof(Foo)); }
>   };
>
>Is sizeof(Foo) guaranteed to be the size of the structure containing the
>declared object's non-static data?

No. While in this case it will probably work just fine. In alot of
cases it won't. For instance, if Foo were derived from Bar and Bar
had virtual destructors associated with it, your call to memset, would
set the pointer to the destructor to NULL and you would either core dump
when the destructor was called (like on the IBM) or it just wouldn't get
called (like with cfront).

-mje

-- 
Mike Elliot                  Did Adam and Eve have navels?? -Milo
elliot@ansoft.com

Disclaimer: My boss doesn't listen to what I say, why should you?
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Sigh. So, what is a proper class definition ?
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 30 Sep 1992 08:15:09 GMT

kanze@us-es.sel.de (James Kanze) writes:

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

>> 	A list is an array with insert and remove operators.
>> Arrays have [] access and a length operator. I dont bother
>> with iterators for lists---integers do just fine. This
>> approach is inefficient, but a cache can improve that.
>> (If I really want ultra fast access I can use 'first' and 'next',
>> but I hardly ever bother)
>
>And what happens if efficiency later becomes important.
>
>I almost never use int (for anything).  It's almost always better to
>whip up a small class.  How much work would it be to encapsulate your
>int in an iterator class?  And if efficiency does become important,
>re-implement the iterator class in a more efficient manner.  Without
>breaking any code that uses it.
>
>Once you've used int as the iterator, you're stuck.  Any improvements
>break user code.
>
>BTW, I'm not saying that the lack of efficiency is bad.  Just
>encapsulate it so you can change later, without too much effort.

Ironically, encapsulating the iterator can sometimes *reduce* efficiency.
Many compilers are not smart enough to place structures in registers,
even if you don't take the address of the structure. Thus
	int i, j; ... // lots of uses of i and j
can be considerably more efficient than
	struct { int i, j; } s; ... // lots of uses of s.i and s.j
on these compilers.

Of course, the solution is to get a better compiler, rather than to
abandon encapsulation :-)

P.S.
    If you want to test your compiler, here is some sample code.
    Either profile it or examine the assembly output.

#define NUM 10000

int fast() {
    int i, j;
    int tot = 0;
    for (i = 0; i < NUM; i++)
	for (j = 0; j < NUM; j++)
	   if (i & j) tot++;
    return tot;
}

int medium() {
    struct { int i; } s;
    struct { int j; } t;
    int tot = 0;
    for (s.i = 0; s.i < NUM; s.i++)
	for (t.j = 0; t.j < NUM; t.j++)
	   if (s.i & t.j) tot++;
    return tot;
}

int slow() {
    struct { int i, j; } s;
    int tot = 0;
    for (s.i = 0; s.i < NUM; s.i++)
	for (s.j = 0; s.j < NUM; s.j++)
	   if (s.i & s.j) tot++;
    return tot;
}

int main() {
    fast();
    medium();
    slow();
    return 0;
}

-- 
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!
From: jamiller@hpcupt1.cup.hp.com (Jim Miller)
Date: Tue, 29 Sep 1992 00:02:05 GMT
Subject: Re: Re: GOTO, was: Tiny proposal for named loops.
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.lang.c++


This has (mostly) been an interesting discussion - IMHO.

> Readability is subjective.  I find code without gotos more readable
> than code with gotos.  Others, like you perhaps, find gotos to be more

Readability has a LOT to do with maintainability.  If something is
a lot more readable with a GOTO than without, I'd vote for use of a GOTO.

I use GOTOs about once every 3 years.  Would not want to not have them
in my toolbox.  However, I try and avoid them because usually they mean
that I have not thought out the problem well in the first place.

Story: In a course at Stanford, my term project had a (one) GOTO.
The instructor circled it, wrote "a GOTO !!!!" in red, but continued
to give full credit.  The situation was begging for a GOTO and the
exception variable would have muddied things up considerably.


> However, maintainability is much less subjective.  Gotos create
> dependencies between blocks which complicate their flow patterns.
> This makes them intriniscally more difficult to maintain.  Gotos also
> tend to be used to merge many different control flows into one.  This
> is also difficult to maintain since, as time wears on, exceptions
> accumulate in the merged flows.

> 
> Robert Martin                        Training courses offered in:

None of these things happen any worse than with with GOTO-less programming
if you use GOTO but rarely and with forethought.

Bad programming happens regardless of the constructs used.  OOP scares me
mightily!  THINK what havoc to readability and maintainability bad OOP
*will* do!  Never the less, I think OOP is the best coder technology
change in the last 30 years.

Just because something can be mis-used, just because it WILL be mis-used
sometimes, is not a reason to abandon it completely.


One more story:  When adding new functionality to an existing product
I found almost every procedure had at least one "GOTO 999", some had 
several.  This PASCAL has no procedure "return" statements.  The
consistency of the practice of "GOTO 999" being an error exit to
each procedure's clean-up code resulted in easy to understand, easy to
maintain code.  


GOTO's forever!  (But try, hard, not to use them).

   jim - my $.02 - miller
   jamiller@cup.hp.com
   (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... )
   Anything I say will be used against me ...
   But my company doesn't know or approve or condone anything of mine here.
From: marc@dumbcat.sf.ca.us (Marco S Hyman)
Newsgroups: comp.lang.c++
Subject: Re: GOTOo wars
Date: 1 Oct 92 05:40:31 GMT
Organization: MSH Software, Hayward, CA

In article <717712154.68@mailbox.bison.mb> Hendrik.Boom@mailbox.bison.mb.ca (Hendrik Boom) writes:
 > Burroughs 1700 series were microcoded to support the Structured Constructs.
 > 
 >  * Origin: The Electronic Mailbox (1:348/7.0)

Ahh, yes -- the loadable instruction set.  As I recal the set for cobol
differed from that for RPG-II.  Caused a memory hit when you were
multi-tasking applications written in different languages.   But that was over
15 years ago and the memories fade...

// marc
-- 
marc@dumbcat.sf.ca.us -- pacbell!dumbcat!marc
Xref: sparky comp.lang.c++:14237 comp.std.c++:1238
From: brennan@hal.com (Dave Brennan)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Conceptual Constness
Keywords: const, const member, lazy
Date: 28 Sep 92 18:40:52 GMT
Organization: HaL Computer Systems, Austin, TX
NNTP-Posting-Host: yosemite.hal.com

I write a lot of C++ classes that are optimized to not do anything any
sooner than they have to.  Here's a contrived example:

class Foo;

class FooList
{
  public:
  FooList ()
    : foo_list (NULL) { }
  // ...
  foo operator [](int);
  // ...

  protected:
  foo **foo_list;

  void create_foo_list ();
};

foo &
foo_list::operator [] (int index)
{
  if (foo_list == NULL)
    create_foo_list ();

  // [ error checking ommited ]

  return (*foo_list[i]);
}


The list of Foo objects doesn't exist until a user of a FooList tries to
access an element of the list.  Conceptually accessing an element is an
operation that I would be like to be able to perform on a const object
because conceptually it does not modify the FooList.

My complaint is that C++ doesn't provide a way to indicate this conceputal
"constness."  I really want to have a const FooList and be able to call a
conceptually const function.  The current alternatives are either don't use
const or do some ugly casting with "this" in conceptually const member
functions.  The first solution makes it harder to insure conceptual const
correctness, while the second is just plain ugly.

Has this problem ever been addressed or pondered before by anyone else?
Is there a better way around the problem?  Is this a problem worthy of a
<*gasp*> language extension?  (A dirty word around here, I know.  Almost
as bad as "new keyword" :-)

--
Dave Brennan                                      HaL Computer Systems
brennan@hal.com                                         (512) 794-2855

Visit the Emacs Lisp Archive: archive.cis.ohio-state.edu:pub/gnu/emacs
From: shite@sinkhole.unf.edu (Stephen Hite)
Newsgroups: comp.lang.c++
Subject: Re: C++ to C converter
Date: 30 Sep 92 04:28:10 GMT
Organization: University of North Florida, Jacksonville

In article <1992Sep19.034754.21944@nuscc.nus.sg> suresh@argon.iss.nus.sg (Suresh Thennarangam - Research Scholar) writes:
>I  hope this not  an FAQ !
>
>I am looking for a program that does a decent job of converting C++ code
>to readable C code( I don't mean cfront obviously). Has anyone ever come
>across such a program and knows where  I can get hold of it ?

   Yes, this is a frequently asked question.  You have two choices:

   1. Use g++.

   2. Get your wallet out.



Steve Hite
shite@sinkhole.unf.edu
From: bytor@grumpy.bellcore.com (Ross Huitt)
Newsgroups: comp.lang.c++
Subject: Re: Access to file descriptor within fstream class?
Date: 6 Oct 92 13:29:12 GMT
Organization: Bellcore

In article <1992Oct5.173048.9948@pixel.kodak.com>, morss@ssd.kodak.com (Charlie Morss) writes:
|> 
|> I recently asked a question in regard to record locking using
|> the fstream class. Steve Clamage replied and suggested that
|> I derive a class from fstream called lfstream in which I could
|> then have a lock and unlock member function. Now the question
|> is how do you get the file descriptor from the fstream class? 

You don't get the descriptor from the stream class, you get it from the
underlying streambuf class, in this case a filebuf object. The following
should get you pointed in the correct direction.


int descriptor;
descriptor = open(...); // or whatever...

fstream aStream(descriptor);
filebuf *buf;

buf = aStream.rdbuf();

buf->fd() == descriptor;   // filebuf::fd() is the magic function call that
                           // returns the file descriptor...

|> Thanks in advance,
|> 
|> Charlie

Ross Huitt
bytor@ctt.bellcore.com

|> 
|> -- 
|> -----------------------------------------------------------------
|> Charlie Morss                               Voice: (716) 726-5461
|> morss@eksignal.kodak.com                      Fax: (716) 726-4850 
|> -----------------------------------------------------------------
Newsgroups: comp.lang.c++
From: fsaleem@admiral.uucp (Farzan Saleem)
Subject: UAE at install!
Reply-To: fsaleem@admiral.uucp (Farzan Saleem)
Organization: The Grid/Waffle BBS, 203-661-2873, -1279, -0450, -2967
Date: Tue, 29 Sep 1992 22:00:24 GMT

Well, I bought C++ off of a friend of mine and stuck in the install
disk. When I tried to run install from the PM, I got a 
General Protection Fault error in Kernel386.... Same error if I 
try to run it in standard mode.
 
Any ideas, or do I demand my money back?????
 
FS!

--
fsaleem%admiral.uucp@yale.edu (Farzan Saleem) <yale!admiral!fsaleem>
The Admiral's Public UNIX - Greenwich, CT - System Administrator: Doug Fields
(HST/V32) (203)661-2873 -- (PEP/V32) -1279 -- (V32) -0450 -- (V29/MNP6) -2967
>FREE!< Unix shell accounts, Usenet access, and Internet-style mail available
From: carney@rocky.rational (Mike Carney)
Newsgroups: comp.lang.c++
Subject: Re: Problems with Abstract base class and pure virtual functions.
Date: 29 Sep 92 15:56:15 GMT
Organization: Rational, Santa Clara, CA
In-reply-to: kmr@netcom.com's message of 29 Sep 92 06:55:51 GMT


In article <8-+p9xr.kmr@netcom.com> kmr@netcom.com (KMR) writes:
   I could not find an answer to my problem  of abstract base class
   and pure virtual functions in ARM, any help will be appreciated.

   Consider the following:

   class A {
       public :
	   int i;
	   virtual void foo1() = 0;
	   virtual void foo2() = 0;
	   virtual void g() {} 
   };

   class C : virtual public A {
       public :
	   virtual void foo2() = 0;
	   virtual void gG() {}
   };

   class B : virtual public A {
       public :
	   virtual void foo1() {}
	   virtual void foo2() {}
   };

   class D : public B, public C {
       public :
	   virtual void foo2() {}
   };

   main()
   {
       D	*bb = new(D);

       bb->i = 1;
       bb->foo1();  
       bb->foo2();  
   }

   When compiling the above on SUN 2.1 Cfront, the compiler fails 
   informing me that D is an abstract class and thus cannot be "newed"
   I can rationalize the cause of failure (though I am still not certain)
   however seeing it documented and the case explianed will help.

   kmr@netcom.com

I think that your real problem here is that class C does not have an
implementation of foo1(). If a class is an abstract class (i.e. any of
its virtual members is declared line foo1() and foo2() in class A
above), then all of its derived classes *must* have implementations of
those virtual member functions that were declared abstract. The error
you got sounds like a bug in the Cfront that you have. I hope that
this is helpful.



--

                                |     |                         
    Michael D. Carney           \\_V_//
    email: carney@rational.com  \/=|=\/   
    phone: 408-496-3790          [=v=]     
                               __\___/_____
                              /..[  _____  ]
                             /_  [ [  M /] ]   
                            /../.[ [ M /@] ]            
                           <-->[_[ [M /@/] ]  
                          /../ [.[ [ /@/ ] ] 
     _________________]\ /__/  [_[ [/@/ C] ]
    <_________________=>>0--]  [=\ \@/ C / /                           
                      ]/000o   /__\ \ C / /           
                              /....\ \_/ /                      
                              [___/=\___/ 
                              [...] [...]
    "Remember...No matter     [___/ \___]
     where you go, there      <---> <--->
     you are."                [..]   [..]
                             _[__]   [__]_
                            [____>   <____]
From: ddv@unix.brighton.ac.uk (Domenico De Vitto)
Newsgroups: comp.lang.c++
Subject: Extra-long double
Date: 5 Oct 92 13:03:45 GMT
Organization: University of Brighton, UK

Anyone seen a 'extra-long double' class ie. one that gives a specified or
expanding precision floating-point ?

Any help much app.

Dom De Vitto
Newsgroups: comp.lang.c++
From: janzen@lichen.mpr.ca (Martin Janzen)
Subject: Missing flex/initscan.c while building COOL
Reply-To: janzen@mprgate.mpr.ca
Organization: MPR Teltech Ltd.
Date: Tue, 29 Sep 92 20:24:37 GMT

I'm trying to build the COOL library, and have managed so far to build most of the
"pisces" utilities.  However, when I got to "flex" (2.1 beta), I ran into trouble.
The Makefile tries to use flex itself to convert scan.l to scan.c, but of course I
don't have flex yet...  I found an older version in the comp.sources archives, but
it didn't work on scan.l.

The README file refers to an initscan.c file which has been pre-"flex"ed, but there's
no such thing in my distribution.  I'd really appreciate it if someone out there could
send me either initscan.c or scan.c.  Many thanks in advance...

-- 
Martin Janzen                     janzen@mprgate.mpr.ca (134.87.131.13)
MPR Teltech Ltd.                  Phone: (604) 293-5309
8999 Nelson Way                   Fax: (604) 293-6100
Burnaby, BC, CANADA  V5A 4B5
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c++
Subject: Re: Persistance Problem Solved by Memory-Mapped Files?
Date: 29 Sep 1992 15:59:33 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <d8_p1zq.feustel@netcom.com> feustel@netcom.com (David Feustel) writes:
>I'm wondering whether the problem of persistant objects could be
>solved by use of memory-mapped files to store the C++ data structures
>used by C++ programs. Comments?

Not really.  Memory-mapped files raise the problem of making object
representation independent of the address space in which the object
resides.  Pointers between objects have to be replaced with offsets from
the base of the file.  Linkage to virtual member functions would have to be
done differently; if the vtbl lives in the shared memory then the function
pointers will have to be done in an process-independent manner, but if the
vtbl lives in the per-process memory then the vptr will have to be
process-independent.  You can't assume that functions will be in the same
place in each process, since an object library may be linked into many
different programs.

Also, memory-mapped files only work if all the cooperating processes share
a file system that supports it.  I'm not sure how reliable writing to
memory-mapped files is when NFS is in use (I don't think each write to the
mapped memory results in an NFS write, so multiple copies of the file could
get out of sync).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.c++
From: arthur@solomon.technet.sg (Arthur Sombrito)
Subject: friend declarations
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 7 Oct 1992 03:33:50 GMT



--

Hi,

I'd like to know if the following friend declarations are valid in ARM.
g++ and Sun cfront give different results.

  class A {};
  class B;
  class C
  {
    friend A;         // ok
    friend D;	      // create a class D
    friend class E;   // create a class E
    friend B *bP;     // Is this valid? 
                      // If it is, is bP a pointer to class B
                      // w/c in turn is a friend of class C?
    friend class F G; // Is this valid?
                      // If it is, does it mean that a class F
                      // and a class G are created?
  };

Thanks for any replies.
Newsgroups: comp.lang.c++
Subject: The -NEW- C Primer Plus FOR SALE
From: powalisz@nrlvx1.nrl.navy.mil
Date: 29 Sep 92 13:25:19 -0400
Organization: NRL SPACE SYSTEMS DIVISION
Summary: book for sale or trade

FOR SALE (book only $20.00 + shipping)

   Title: The -New- Waite Group's New Primer C Plus
   Authors: Mitchell Waite and Stephen Prata
   Publisher: Sams
   Edition: 1991
   Comment: A really good introduction to C for beginners. Order forms in the
            back for a companion disk or a 'Mastering C' tutorial disk. Winner
            of the 1991 Computer Press Association's "Best How- To Book".

OR EVEN TRADE FOR:

   Title: C: The Complete Reference, 2nd Edition
   Author: Herbert Schildt
   Publisher: McGraw-Hill
   Edition: 1990

Please include your mailing address if you are interested.

My home mailing address is:
Ron Powalisz
4281 Dudley Rd.
Mech., Md. 20659

Contact me via E-mail at: POWALISZ@NRLVX1.NRL.NAVY.MIL if interested.
From: vincent@datmuc.UUCP (vincent)
Newsgroups: comp.lang.c++
Subject: static reference
Date: 6 Oct 92 14:35:39 GMT


class a {
	static a *sap;
	static a &sar;
public:
//	a () { if (sar == 0) init_stuff };
};

a *a::sap;
a &a::sar;


Ok what of that?

MC cl complains about 'sar' having to refere to something. Fine I want it
initialize to zero. 


I had a list of stuff with a static head pointer, It works fine but after
reading 'Effective C++' I started to use reference more and more.

vincent@datmuc.dat.de

Newsgroups: comp.lang.c++
From: jurlwin@gandalf.UMCS.Maine.EDU (Jeff Urlwin)
Subject: Re: Borland C++
Organization: University of Maine, Department of Computer Science
Date: Wed, 30 Sep 1992 23:03:58 GMT

In article <30SEP199216144907@pavo.concordia.ca> j_theof@pavo.concordia.ca (THEOFANOPOULOS, JOHN) writes:
>Hi all...
>
>I'm planning on purchasing Borland C++ v.3.1, and have a question.  I currently have
>a choice between getting the regular version or paying $120.00 more and
>getting the version with Application Frameworks.
>
>Most of my work (all of it actually) is done in DOS, and all my programs
>are made to run under DOS, so would this Application Frameworks really
>help me?  I spoke to a Borland Rep and he wasn't too much help in 

Application Frameworks provides two things:  TurboVision and ObjectWorks
(or some stupid names...).  Basically, TurboVision is their Object Oriented
event-driven program "shell".  If you've seen Borland's IDE, you've seen
the type of front end you can "easily" create with TurboVision.  It provides
a set of classes, etc to help you with the construction of an event-driven
front end.  ObjectWorks (or whatever it is) helps you do the same, but with
MS Windows (3.0 or 3.1).  Thus they provide a User interface "framework" for 
you to use to build your app.

NOTE:  They are NOT source level compatible with each other.  They do NOT
contain the same class defs, etc.  So when you are creating an app under
one, it is not compilable under the other.  

This shouldn't bother you, since all of your work is under Dos (text mode I
presume).  If you don't need such beasts, you may not wish to spend the
extra $120.

Jeff



-- 
--------------------------------------
jurlwin@gandalf.umcs.maine.edu