HDTenEightyP/NetNews huggingface dataset:
From: steve@taumet.com (Steve Clamage)
Subject: Re: A question about the sizeof operator
Organization: TauMetric Corporation
Date: Fri, 31 Jul 1992 17:03:41 GMT

drenze@icaen.uiowa.edu (Douglass J. Renze) writes:

>I was playing around with the sizeof operator today, and I found out some-
>thing curious.

>class s1 {
>        struct name {
>                char last[10], first[10], mi;
>        };
>        s1* next;
>};

[ sizeof(s1) = 4 ]
 

>Yet this next program...

>class s1 {
>        char last[10], first[10], mi;
>        s1* next;
>};

[ sizeof s1 = 26 ]


The first example defines a type called "name" inside s1.  There is no
instance of a "name" anywhere, so it doesn't take up any space.

For example, if you added
	typedef int foo;
	typedef double bar;
you wouldn't expect the size of the struct to change.

Change the first example by adding a member of type 'name' to 's1':

    class s1 {
        struct name {
	    char last[10], first[10], mi;
        } some_name;	// now s1 has a member of type "name"
        s1* next;
    };

Now the two versions should be (approximately) the same size.  (There
might be slightly different padding.)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Xref: sparky comp.lang.c++:11652 comp.std.c++:968
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: mating dogs and cats (Re: run-time type checking)
Date: 28 Jul 92 16:19:57 GMT
	<1992Jul22.022218.1115@cadsun.corp.mot.com>
	<1992Jul23.154254.5306@ucc.su.OZ.AU>
Reply-To: tmb@idiap.ch
Followup-To: comp.lang.c++
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: maxtal@extro.ucc.su.OZ.AU's message of 23 Jul 92 15:42:54 GMT

In article <1992Jul23.154254.5306@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

   The problem is why you proposed 'thisclass' and is a real problem.
   It is a problem for which RTTI is the wrong solution,
   but never-the-less is the best we will get for a while.
   We really need multiple dispatch.

   class Animal {
	   int mate(Animal&);
   };
   class Dog : Animal {
	   int mate (Animal&);
   };

   We REALLY want Dog::mate(Dog&), but we cant have it.

I don't see the problem.

class Animal {
	virtual int mate(Animal &) = 0;
	virtual int mate_dog(Animal &other) {error("not a dog");}
	virtual int mate_cat(Animal &other) {error("not a cat");}
};

class Dog {
	int mate(Animal &other) {return mate_dog(other);}
	int mate_dog(Animal &other) { ... do it the way dogs do it ... }
};

   This is a flaw in Object Oriented Programming IMHO.
   The solution requires multimethods which are inherently
   functional.

I don't see that this particular thing is a flaw with Object Oriented
programming. Nor do you need RTTI to solve this problem.

I assume that by "functional" you mean "CLOS-style methods". I agree
that they are more convenient and easier to maintain, but at least in
this respect, they don't give you more functionality.

					Thomas.
Newsgroups: comp.lang.c++
From: starkie@eddore.trl.oz.au (Brad Starkie)
Subject: I need a C++ class library to simulate concurrency
Organization: Telecom Research Labs,Melbourne, Australia
Date: Thu, 23 Jul 1992 05:34:18 GMT


I need a C++ class library to simulate concurrency. I've looked
at the C++ task library, but the Saber version of it doesn't seem
to run on a SUN4 and and my code will be re-using code from at least
two other libraries that can't be compiled under the sunCC
compiler. Has somebody ported the task library to a sun4 that 
is compatable with the saber compiler . 
What other C++ libraries are available ? The
actually scheduling required in my code is straight forward as
all of the interaction between processes would occur on clock
ticks. This should be able to be done without any low level
coding as is done in the task library.

I'm tempted to write a few classes myself.

What are peoples opinion of the task library anyhow?


Brad Starkie
______________________________________________________________________________
Brad Starkie,			Voice: +61 3 541 6439	   Fax: +61 3 543 1944
Telecom Research Laboratories, P.O. Box 249, Clayton, Victoria 3168, AUSTRALIA
Internet: b.starkie@trl.oz.au
X400:    g=brad s=starkie ou=trl o=telecom prmd=telecom006 admd=telememo c=au
______________________________________________________________________________

Newsgroups: comp.lang.c++
From: strachan@bilbo.cs.uct.ac.za (Craig Strachan)
Subject: I/O
Keywords: help
Organization: Computer Science Department, University of Cape Town
Distribution: all
Date: Thu, 30 Jul 1992 10:18:03 GMT


Help,
does anybody know how to assess the Comm.port on an IMB.pc,
using C++.
It is rather urgent, I only want to send a pulse to a pin.
ie: peek, poke in basic

+---------------------+-------------------------------------------------+
|          ^          |       FROM: Craig Strachan                      |
|        -----        |	      strachan@bilbo.cs.uct.ac.za               |
|      /       \      +-------------------------------------------------+
|     \ O    O  /     |      2nd year Bsc.Eng (Elec,Com.sci major)      |
|       \|| ||/       |              & part-time musician               |
|        |\ /|        |  ( co-founder of the perfect people's society ) |
|        || || hello! +-------------------------------------------------+
|        \/ \/        |    ( also part-time walrus & court jester )     |
+---------------------+-------------------------------------------------+
--
+---------------------+-------------------------------------------------+
|          ^          |       FROM: Craig Strachan                      |
|        -----        |	      strachan@bilbo.cs.uct.ac.za               |
|      /       \      +-------------------------------------------------+
Newsgroups: comp.lang.c++,comp.std.c++
From: mat@uunet.uu.net!mole-end
Subject: Re: Language extensions for run-time type identification
Organization: :
Date: Thu, 23 Jul 1992 18:30:41 GMT

In article <1992Jul22.150330.6160@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
> In article <1992Jul21.094204.20100@mole-end> mat@mole-end writes:
> > 
> > The assumption underlying the decision to include only classes with
> > virtual functions is that a class that has no polymorphic behavior
> > whatsoever (not even a virtual destructor) cannot be used in any way
> > that is both safe and interesting even with the proposed runtime type
> > support.  Can you refute this assumption?
> > -- 
 

> First of all and to be specific to C++, it is the class hierarchy, or  
> inheritance and the polymorphic pointers that lead to the necessity of
> run time type checking. It is not the virtual behaviors of a class.
> We still need run time type check even if we disallow any virtual behaviors
> in C++. Therefore, the assumption is laid on the wrong ground.

But without virtualization (polymorphic behavior) derivation is effectively
useless.  There is no reason to code inheritance without providing for
virtualization.  Then the case which you mention is of no use unless and
until it is provided with RTTI; providing RTTI for it using reasonable
and economical mechanisms would violate certain assumptions that C++ allows
its users to make (C struct compatability).
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: srikant@skorpio.usask.ca (Srikant Subramaniam)
Subject: C++ FAQ List ?
Organization: University of Saskatchewan, Saskatoon, Canada
Date: Tue, 21 Jul 1992 17:45:26 GMT

Could somebody pl mail me a copy of the *latest* C++ FAQ?

-- 
----- 
 |\/\/\/|      Srikant Subramaniam.
 |      |      srikant@cs.usask.ca 
 |	|
 |      |      Disclaimer: This is not what really I look like. 	
 | (o)(o)      Disclaimer: I didn't do it, nobody saw me do it, 
 C      _)                  can't prove anything. 
  | ,___|             
  |   /     
  /---\    
Newsgroups: comp.lang.c++
From: jms@spatial.com (Jim Sharpe)
Subject: ET++ for HPUX
Followup-To: jms@spatial.com
Originator: jms@flash
Organization: Spatial Technology, Inc. [Boulder, Co]
Date: Thu, 23 Jul 1992 19:04:10 GMT


Sorry if this is a FAQ, but I recently ftp'd a copy of ET++ 2.2 and although
there do seem to be some indications that HPUX specific tweeks have been 
done, it looks like there are quite a few more to do.  Either that, or I
missed finding some more configuration "switches".

Has anyone out there already gotten a relatively recent release of ET++
to build under HPUX 8.x?  If so, do you have a list of changes you
made, or even better gould you sent me the files you changed.


-- 
Jim Sharpe / jms@spatial.com - 

Spatial Technology Inc. 2425 55th Street, Boulder CO  80301    (303)449-0649
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: classes referenced each in their declaration
Distribution: world
Organization: Trumphurst Ltd.
Date: Wed, 22 Jul 1992 21:24:15 +0000


In article <1992Jul21.174445.24733@menudo.uh.edu> qincao@cs.uh.edu (Qin Cao) writes:

> class X;
> class Y;
> 
> class X {
>   int a;
>   Y b;          // if I put "Y *b;" here, it works fine 
> };
> 
> class Y {
>  int c;
>  X d;
> };
Quite apart from the impossibility of the compiler knowing how much 
storage to use for objects of type X, the quantity is, in fact, infinite :-(
---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Language extensions for run-time type identification
Date: 23 Jul 92 01:35:30 GMT
Article-I.D.: alice.23284
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <rmartin.711829160@thor> rmartin@thor.Rational.COM (Bob Martin) writes:

> Posh!  Every class should have a virtual destructor.  It is insane not
> to declare the destructor virtual.  There is only one, small,
> exception to this rule, which has to do with structs placed in ROM...

How about classes associated with small objects, such as Complex and Point?
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: vadim@cix.compulink.co.uk (Vadim Lebedev)
Subject: Re: Handling of operator . pro
Reply-To: vadim@cix.compulink.co.uk
Date: Fri, 31 Jul 1992 00:11:17 +0000



In article  <BryIM5.KFH@world.std.com>  wmm@world.std.com (William M Miller)
writes:

> The issue is one of analogy -- all the currently overloadable
> operators have a runtime component in the builtin version.  Adding
> runtime behavior to an operator that doesn't have it now would be a
> completely new thing.

You're not completely right here saying the 'operator . ' has not
runtime behaviour. 
Consider:
  class Something &k;
  
  k.anything();

In the case of references 'operator .' DEFINITELY HAS runtime behaviour.
So it is logical to expect the possibility to overload this runtime
behaviour in order to implement smart references.


BTW, I my viewa ll  computer languages including C++
should help us humans to  control 
computers, so if there is possibility to enchance C++ in a way that
help us to acccomplish this task, the possibility should be jumped on.
What i'm trying to say, is that when there is a language extension proposal
which is clearly useful to many of programmers such as
RTTI, extended RTTI, 'operator .',  'operator pow', delegation
the foolowing reasoning should be adopted IMHO,
   Is there a grand demand for this feature?
   if yes, so is this feature easily implementable?
   if yes, what pourcentage of existing programs would be broken by
   this feauture, if not too much, add the feature to the language.

-----------------------------------------------------------------------
Vadim Lebedev                      |   Kortex International
vadim@cix.compulink.co.uk          |   139-147 av. Paul-Vaillant Couturier
                                   |   93126 La Courneuve - CEDEX, France


Xref: sparky comp.lang.c++:11474 comp.object:2993
From: george@trwacs.fp.trw.com (George Fletcher)
Newsgroups: comp.lang.c++,comp.object
Subject: C++ success stories
Keywords: C++, Success, Industry
Date: 24 Jul 92 13:15:27 GMT
Followup-To: poster
Distribution: na
Organization: TRW Systems Division, Fairfax VA

OK, so I waited to long and am now in a crunch.  I am in *desparate*
need of the names of companies that have successfully developed
software systems using C++.  A brief general description of the
software system would be helpful as well.  I have a meeting with a
customer on Monday (hence the urgency) who is a little skeptical about
C++.  Also, any information relating to the benefits of using C++ over
ADA would also be appreciated (no language flame wars please :-).

Due to the short time frame, please reply by email and I will summarize
if there is enough interest.

Thanks in Advance.

George
==========================================================================
George Fletcher			UUCP:     uunet!trwacs!george
TRW Systems Division		Internet: george@trwacs.fp.trw.com
Fairfax Virginia

-- 
==========================================================================
George Fletcher			UUCP:     uunet!trwacs!george
TRW Systems Division		Internet: george@trwacs.fp.trw.com
Fairfax Virginia
From: jld2@ns1.cc.lehigh.edu (J. Lynch Davis)
Newsgroups: comp.lang.c++
Subject: Passing Open Streams
Date: 31 Jul 92 19:02:59 GMT
Organization: Lehigh University

If I open a stream and want to pass the stream for use in a subroutine, such
as using headers and footers in files, how would they be passed?

void    maind()
{
    fstream out;

    out.open("filename",ios::out);

    header(  ??? out ??? );

    return;
}

void    header( ??? out ???);
{
    ...
    ...
    ...
    return;
}

please send replies to jld2@lehigh.edu

Thanks,
Lynch
Newsgroups: comp.lang.c++
Subject: TurboVision TMenuBox problem
From: <LIBTWM@BYUVM.BITNET>
Date: Thursday, 23 Jul 1992 10:50:54 MDT
Organization: Brigham Young University


I'm trying (unsuccessfully) to nest a menubox from a pulldown menu item.
I haven't been able to find any sample code that demonstrates this.

One inconsistency (I believe) with the MENU.H is the following
declaration:


class TMenuBox : public TMenuView
{

public:

    TMenuBox( const TRect& bounds, TMenu *aMenu );
    TMenuBox( const TRect& bounds, TMenu *aMenu, TMenuView *aParentMenu);


The first constructor call is not supported in the TV.LIB but the second
call is.


Any help with this problem is greatly appreciated.


******************************
LIBTWM@VM.BYU.EDU
******************************
Newsgroups: comp.lang.c++
From: greyham@research.canon.oz.au (Graham Stoney)
Subject: Re: How to have a member function as an ISR
Organization: Canon Information Systems Research Australia
Date: Fri, 24 Jul 1992 00:05:17 GMT

sean@pegasus.com (Sean Donovan) writes:
>In article <emm.711411003@daneel.rdt.monash.edu.au> emm@daneel.rdt.monash.edu.au (Wendigo) writes:
>>Does anybody know how to use a member function of a class as an
>>Interrupt Service Routine using Borlanc C/C++ 3.0??

>First declare it as type interrupt.

>Second, write the equivalent of dos_setvec() for your class acception
>a pointer to a member function of your class to install the vector.

>Third, call it.

>Optional step, generalize the concept and bubble it up to a base class, so
>that you can reuse it.  This can get tricky with multiple inheritence
>with a virtual base class. (actually it is garunteed to choke bcc 3.0)

This is more complex than necessary. The easy answer is: declare the member
function as interrupt static, and just do the set_vect with it. Static
members act just like C functions and hence have no this pointer. This is
logically consistent since interrupt routines have no context. If the ISR
needs to operate on an instance of the class, you must leave a global pointer
around for it to use, and you can encapsulate this pointer in the class by
making it static too. And yes, I've done this several times.

Graham
-- 
Graham Stoney                    | "a Perl script is correct if it's halfway
Flip Dibner fan club, "Hi Flip!" |  readable and gets the job done before your
Ph: +61 2 805-2909  Fax: -2929   |  boss fires you." L. Wall & R. Schwartz
From: fojgoul@lims02.lerc.nasa.gov (JACK GOULD)
Newsgroups: comp.lang.c++
Subject: Re: Protogen Code Generator
Date: 23 Jul 92 17:30:00 GMT
Organization: NASA Lewis Research Center
News-Software: VAX/VMS VNEWS 1.41

In article <2386@bsu-cs.bsu.edu>, twpunix@bsu-cs.bsu.edu (Tim Parsons) writes...
> 
>  Having recently registered my Borland C++/AF 3.0, I got a call from a 
>Borland rep offering Protogen for $49.95 (regularly $495, she said).
>Does anyone know if it's worth getting, what it's particularly suited for?
>It'd have a money-back trial period, but I'd like to know if it's something
>to seriously look into, before I make even such a modest leap.  I've scanned
>back issues of PC Week, etc., but info is pretty sketchy.  Thanks.
> 
>Tim Parsons (twpunix@bsu-cs.bsu.edu)

Tim,

	When I ordered my BC 3.1 upgrade, I was offered the Paradox Engine 
for $49.95 (regularly $495).  Well, I bit.  After I placed the order, I did 
some checking with software catalogs.  I found out that the Mfr's suggested 
retail on Paradox Engine was $100.  The complete Paradox package (which I 
was not offered) had a mfr's suggested retail of $495.

	I felt I was mislead by the salesperson.  When my Paradox Engine 
arrived in the mail, I immediately sent it back with my sentiments.  I was 
dissapointed by this experience; but, as my grandfather says, "Good 
judgement comes from experience; and, experience comes from bad judgement."

	So, check out direct mail catalogs for the real scoop on the cost 
of Protogen.  You might find that you are not getting such a great bargain.

				- Jack
Newsgroups: comp.lang.c++
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: Overloaded operators and inheritance
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia
Distribution: usa
Date: Wed, 22 Jul 1992 16:31:10 GMT

doug@foxtrot.ccmrc.ucsb.edu (Douglas Scott) writes:
> class QueryValue : public QueryLabel {
> public:
> 	...
> 	void operator = (const QueryValue& rhs);
> 	...
> };
> class StringValue : public QueryValue {
> public:
> 	virtual ~StringValue();
> 	...
> };
> 
> The '=' operator is implemented such that any of the derived classes should be
> able to be assigned to one another, because I use virtual function calls to
> both the rhs and lhs instances in the expression:
> void
> QueryValue::operator = (const QueryValue& rhs) {
> 	set(rhs.value());
> }
> 
> However, 
> When I attempted to assign one of the derived class instances to another,
> using '=', I got this compiler error:
>
> ./request.c:129: assignment not defined for type `StringValue'
> 
> I looked through Stroustup, but could find no information about how operator
> functions are inherited by subclasses.  Why is '=' not defined?  How does this
> work??

First, operator = (assignment operator)  is not inherited by
the derived classes. But, if you don't define an assignment
operator in a class, a default assignment operator will be
generated unless the class has a const member, a reference
member, or a member or a base class with a private operator =

It appears that your compiler is not able to generate a default
assignment operator for class StringValue because of one
of the reasons listed above. 

ARM has a table on p. 306 that gives a summary of the characteristics
of operators and other functions. Perhaps, Stroustrup should include
that table in his book.

-Sekar
From: twpunix@bsu-cs.bsu.edu (Tim Parsons)
Newsgroups: comp.lang.c++
Subject: Protogen Code Generator
Date: 21 Jul 92 19:22:21 GMT
Organization: Dept of CS Ball State University Muncie In


  Having recently registered my Borland C++/AF 3.0, I got a call from a 
Borland rep offering Protogen for $49.95 (regularly $495, she said).
Does anyone know if it's worth getting, what it's particularly suited for?
It'd have a money-back trial period, but I'd like to know if it's something
to seriously look into, before I make even such a modest leap.  I've scanned
back issues of PC Week, etc., but info is pretty sketchy.  Thanks.

Tim Parsons (twpunix@bsu-cs.bsu.edu)
Newsgroups: comp.lang.c++,comp.std.c++
From: bobm@Ingres.COM (Bob McQueer)
Subject: Re: Language extensions for run-time type identification
Date: 27 Jul 92 18:01:15 GMT

In <1992Jul24.070325.1597@uunet.uu.net!mole-end>,
	dated Fri, 24 Jul 1992 07:03:25 GMT,
	mat@uunet.uu.net!mole-end writes:

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

I think it is just a first step anyway - when I want to know at run time if
an object is of a particular class, what I really want to ask is "is it this
class, or any class derived from it?", which implies somebody taking the
vtable (enhanced into class descriptor) pointer in the object instantiation,
and ascending through its parents.  With multiple inheritance, there can be
several flavors of this question.

As has already been said, this sort of thing can be abused, and is not a
substitute for proper use of virtual methods, but it IS useful.

I would also like to see the ability to parameterize the type handed
to the "new" operator - logically, this thing is a class descriptor also.

Perhaps the committee ought to be considering the various sorts of "meta"
operations people want to perform which involve parameterization of or
manipulation of type information, and see if we shouldn't surface the idea
of a "class descriptor" object of some sort as a formal part of the language?

I have not been using C++ extensively, but for the past couple years I have
been using another C based OO paradigm.  I have found that there are a certain
number of operations (yes, PARTICULARLY for debuggers) in which a formal idea
of a type object with appropriate methods is indispensible.
Newsgroups: comp.lang.c++,comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Language extensions for run-time type identification
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 23 Jul 1992 20:08:03 GMT

In article <1992Jul22.212111.12530@taumet.com> steve@taumet.com (Steve Clamage) writes:
>
>We could patch this up by saying you have to use 'class' rather than
>'struct' to get RTTI, but this would break existing C++ code which
>relies on the equivalence of 'struct' and 'class'.  Maybe this is
>not too high a penalty, but it would have to be carefully considered.

	IMHO making struct == class (baring access defaults) was a poor
decision. I would much rather 'struct' MEANT C-compatible. 
So I would not be dismayed at the change suggested above.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: microman@toz.buffalo.ny.us (microMAN)
Newsgroups: comp.lang.c++
Subject: Borland C++ 3.0
Date: 31 Jul 92 04:41:39 GMT
Organization: The Tower of Zot - (716)691-3865


Recently I have installed Borland C++ 3.0.  I am having problems running
BC.EXE under DOS 5.0.  The IDE will display but my system hangs and I must 
reboot the system.  The system must be rebooted cold the good 
ole CTL-ALT-DEL does not work.

I would appriciate any feedback.

Thank You.  
 


---------------------------------------------------------------------
microman@toz.buffalo.ny.us (microMAN)
-- Change this!
Newsgroups: comp.lang.c++