HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com
Newsgroups: comp.lang.c++
Date: 17 Jul 92 19:26 MDT
Subject: Re: virtual call efficiency (Re: ar
Nf-ID: #R:9219919.15720@mulga.cs.mu.oz.au:-1880726321:146oruINNiom@early-bird.think.co:121153198:001:2138
Nf-From: think.com!barmar    Jul 17 19:26:00 1992


In article <1992Jul17.114522.15858@tfs.com> eric@tfs.com (Eric Smith) writes:
>There is one case where the virtual function would appear to be doing nothing
>but simple assignment, and that is where each concrete subclass may or may
>not implement it as appropriate for that subclass, and the base class defaults
>the action if not implemented in the subclass.  In that case, you have the
>superficial appearance of a function that does nothing but assignment, but it's
>really accomplishing more, because if you inlined it you would have to inline
>a switch to test whether to use the concrete assignment or default, and that
>would add a lot more overhead than the virtual function call.

This is probably a case where benchmarking would be appropriate.  It's
quite possible that the overhead of such a test would be less than the
overhead of a virtual call.

At first I thought that this wouldn't be true, since you'd probably want to
use a virtual call to find out whether the access should be done directly
or via a call, and that would clearly be worse than just a virtual call to
perform the access.  But then I realized that the base class could contain
a data member that the derived class could fill in.

class Base {
    private:
	int foo;
    protected:
	int foo_direct;
        virtual void internal_set_foo (int newfoo): { foo = newfoo; };
	virtual int internal_get_foo () { return foo; };
    public:
        Base(int initfoo = 0): foo(initfoo), foo_direct(1) {};
	void set_foo (int newfoo)
	    { if (foo_direct) foo = newfoo; else internal_set_foo(newfoo); };
	void get_foo ()
	    { return foo_direct ? foo : internal_get_foo();p };
};

class Derived: public Base {
    protected:
	void internal_set_foo (int newfoo);
	int internal_get_foo ();
    public:
	Derived(int initfoo = 0);
}

Derived::Derived(int initfoo = 0) {
    foo_direct = 0;
    /* Code to reinitialize foo from initfoo */
}

void Derived::internal_set_foo(int newfoo) {
    /* ... */
}

int Derived::internal_get_foo() {
    /* ... */
}
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

Xref: sparky comp.lang.c++:11466 comp.windows.interviews:2310
From: allan@ixos.de (allan)
Newsgroups: comp.lang.c++,comp.windows.interviews
Subject: Info on HP SoftBench and HP InterViews Plus
Date: 24 Jul 92 08:29:34 GMT
Organization: iXOS Software GmbH, Munich, Germany


Hi,

We're looking into HP Softbench for Sun as a C++ Programming
environment.  What are the advantages/disadvantages over other
products such as ObjectCenter and SparcWorks (or GNU g++/gdb for
that mater) ?  

We are dealing with large software projects with large binaries
and many libraries, so performance is also a big issue.

Thanks
Allan Brighton
From: daniel.edelson@inria.fr (Daniel R. Edelson)
Newsgroups: comp.lang.c++
Subject: Re: X3J16 spec
Date: 21 Jul 92 12:19:35 GMT
Reply-To: Daniel R. Edelson <daniel.edelson@inria.fr>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France

In article <76246@ut-emx.uucp>, jamshid@ut-emx.uucp (Jamshid Afshar) writes:
|> 
|> You can get a paper copy by sending a request to:
|> 	Standards Secretariat
|> 	CBEMA
|> 	311 First St NW, Suite 500
|> 	Washington, DC  20001
|> Ask for the latest version of `Working Paper for Draft Proposed American
|> National Standard for Information Systems -- Programming Language C++'.

The 5 June 1992 draft is ANSI document number X3J16/92-0060
(and ISO Document WG21/N0137).
Newsgroups: comp.lang.c++
From: kinne@delfin.com (Kinne Strong)
Newsgroups: comp.lang.c++
Subject: Re: classes referenced each in their declaration
Date: 22 Jul 92 22:20:36 GMT
Reply-To: kinne@netcom.com
Organization: Foxglove Associates
X-Newsreader: Tin 1.1 PL4

gs4t@virginia.edu (Gnanasekaran Swaminathan) writes:
: 
: Please use references. I just tested the following in
: the GNU C++ compiler.
: 
: class X;
: 
: class Y {
: 	X& x;
: public:
: 	Y();
: };
: 
: class X {
: 	Y y;
: public:
: 	X() {}
: };
: 
: Y::Y(): x(*new X) {}

It compiled. Did you try to make an X or a Y? I did. It used up all
available swap space and died. That's still an infinite object.

If you say

	Y big;

the space for the first Y is allocated on the stack. It needs an X, so
it does a new X, which allocates space for the second Y, which also
needs an X, so it does a new X, which allocates space for the third Y,
which also needs an X, so ...

--
Kinne Strong
kinne@netcom.com
From: Oliver.Otto@f2006.n241.z2.fidonet.org (Oliver Otto)
Newsgroups: comp.lang.c++
Subject: Probs using GNU and the Libs :-(
Date: 19 Jul 92 14:22:52 GMT
Article-I.D.: fast.711745200.F00002

Hello All!

I am using the GNU C++ compiler under OS/2 and have lot's of trouble with
the libaries. Some days ago when I start installing GNU C++ all went fine
but know I always get this message

D:SPRACHE\GCC\g++include-/_G_config.h:72: warning: unknown escape
sequence'\S'
D:SPRACHE\GCC\g++include-/_G_config.h:72: warning: unknown escape sequence
'\G'
D:SPRACHE\GCC\g++-include-/G_config.h:72: warning: unknown escape sequence
'\g'
In file included from D:SPRACHEGCCg++include-iostream.h:25, from
D:SPRACHEGCCg++
It ist just a simple TEST prog with only one include <stream.h> -
Heeeeelllp


Oliver

   _____  _____   _____   ___
  / _  / /  __/  /  __/  /  /  Oliver Otto
 / // / __\ \   __\ \   /  /   FIDO:     2:241/2006
/...././..../. /..../. /../.   INTERNET: OLIVER.OTTO@OSSI.FIDO.DE
From: bielak@arco.com
Newsgroups: comp.lang.c++
Subject: Opinions? Convince Mgmt..
Keywords: Opinions on C++ use
Date: 30 Jul 92 13:15:30 GMT
Reply-To: bielak@arco.com
Organization: ARCO Exploration and Production Technology
Originator: dbsjwb@doofus


Your opinions and experiences are welcome:

Having had a week-long training in C++, and after reading (much of) Booch,
Rumbaugh, and Coplien, I am convinced that C++ could be A Good Thing here
where I work. Using C++ to work with many of the physical and conceptual
geologic objects I encounter would certainly help application modularity,
understanding, maintenance, etc.

But there is a problem. Management holds the position "There is no
standard... We've been burned before using half-baked technology, and
we don't plan to get burned again" (my apologies if my paraphrasing
does not exactly express their sentiment).

I learned and wrote K&R C for years before X3J11 arrived, and when it did,
none of my code "broke". In fact, by the time the standard arrived, I
was impatient to obtain a "real" compiler which implemented standard C, and
my style of writing had improved to the point that I doubt I would really
want to use any of my earlier attempts. If I had waited for ANSI, I would
still
be trying to figure out a good use for unions.

Consequently, aside from my personal feelings that I am being left
in the dust, I spend (too) much of my time trying to translate many of 
my ideas into C code which will implement some of the the utilitarian
aspects of OO. My List and ListNode, along with the "encapsulation",
"inheritance" and "objectiveness" with which they are implemented, are
attempts to create generalized objects which are as uncomplicated as 
possible, yet provide opportunity for reuse and extensibility in the 
immediate future. OTOH, I run into disagreement with another group here 
which claims that the X Windows "Object" class is "the way to go", 
because "X will be here forever".

1) What arguments can be used for/against allowing development in C++
   today (UNIX workstation shop), in spite of / due to the lack of a
   standard?

2) If you were to hold the position preventing use of C++, yet wanted
   to encourage conceptualizing objects in C, would you advocate strict
   use of the X Object class, or would you encourage code which utilizes
   OO concepts, is to the point, and gets the job done without the 
   X overhead?

Sorry for the long post, and apologies if this topic has been covered before,
but I feel stuck, and could use your opinions or prior summaries.

Feel free to email any responses, and if there is sufficient interest,
I will be glad to post a summary.

Thanks,
jwb... bielak@arco.com





-- 
bielak@Arco.COM             ARCO Exploration and Production Technology
james.bielak@Edm.Arco.COM   2300 W. Plano Parkway PRC-D3239
(214) 754-6184              Plano, TX 75075
Newsgroups: comp.lang.c++
From: mittle@watson.ibm.com (Josh Mittleman)
Subject: Re: classes referenced each in their declaration
Date: Tue, 21 Jul 1992 19:20:39 GMT
Distribution: na
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

qincao@cs.uh.edu (Qin Cao) writes:

> I need to declare several classes which are referenced each other in
> their defination. If I used pointer, then it works fine, but I realy want
> to use dot notation to refer the class member, instead of "->" notation
> when using pointer. Unfortunately without using pointer, the C++ compiler
> does not buy that, it gave a error message...

Use references:

class Y;
 
class X {
  Y& b;
};

class Y {
 X& d;
};

You must initialize X::b in every constructor for X and Y::d in every
constructor for Y, but otherwise everything should work just fine.  

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
Newsgroups: comp.lang.c++,comp.std.c++
From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Re: Language extensions for run-time type identification
Organization: netmbx, Berlin, Germany
Date: Thu, 30 Jul 1992 07:47:54 GMT

shang@corp.mot.com (David (Lujun) Shang) writes:

>In article <BryFLI.Hz2@world.std.com> wmm@world.std.com (William M Miller)  
>writes:
>function.

>> The challenge, then, for those who view RTTI-via-vtable as
>> insufficient is to provide *concrete* counterexamples to this
>> assumption: applications where derived-to-base casting does occur
>> without the need for virtual functions and for which RTTI would
>> nevertheless be useful.  Are there such applications?
>> 

The assumption here is that RTTI should be provided only as a means
of safe downcasting within domestic systems.  That is obviously nice,
but does nothing to help implement a variety of general purpose tools
which need more information.

>  
>And I'm sure many OO database and OS people can tell more.

Well, the biggest problem for OO databases is that the current RTTI
proposal does not give us enough info even for classes *with* virtual
tables.

A less serious problem: it seems silly to force our users to add
virtual methods in order to store a class in the database.

So far I don't think the current RTTI proposal will affect us at all.
We will continue to use our precompiler.  I would like to see a better
proposal which would allow us to throw our precompiler away.

>Since OO technique is aimed mainly to developing large, complex and  
>cooperative systems, C++, as general purposed OO language, should at least  
>cover some main application areas.

Absolutely!  The general purpose tools which fit so well into the C++
programming environment are precisely those which need RTTI.


Jonathan

===========================================================================

Jonathan Robie		jrobie@netmbx.UUCP
Arnold-Zweig-Str. 44	jrobie@netmbx.in-berlin.de
O-1100 Berlin		
Deutschland		Phone:  +37 (2) 472 04 19  (Home, East Berlin)
				+49 (30) 342 30 66 (Work, West Berlin)


-- 
Jonathan

===========================================================================
From: pluto@cs.ucsd.edu (Mark Plutowksi)
Newsgroups: comp.lang.c++
Subject: Re: Protogen Code Generator
Date: 29 Jul 92 18:33:57 GMT

mickey@sfera.kharkov.ua (Mickey Serg Antonoff) writes:

>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)

>  Hi !

> I guess, that if You plan to do a serious work then You have nothing to do
>with it, 'cause it is (as the most of such environment) too simple to do
>smth. larger than 
>main()
>{
>	printf( "Hello world !!" );
>}

>	With the best wishes,
>				Mickey <mickey@sfera.kharkov.ua>


Actually, I like it a lot, myself.  If you are familiar enough with
the OWL interface (which is a C++ interface with Windows resources)
you can pretty quickly slap together your menus & dialog boxes
with Resource Workshop, and then pull them together using Protogen,
which will then generate code for "running" your interface.  Then
you need to link in your function calls etc. with the generated code.
Protogen requires much less learning curve than OWL or Windows, so
IMHO it's worthwhile if you do Windows programming using BCW 3.1.

Once you generate your first "final draft" of your interface, you
may find it easier to make tweaks to the code yourself
rather than have Protogen regenerate.  

CAVEAT: Get the newest release of Protogen for BCW 3.1 ... it is much
MUCH improved over the older version.  Note also that the new version
(in my experience) will not run correctly with BC 3.0.


= Mark
Nf-ID: #N:tisdec.tis.tandy.com:6800005:000:354
Nf-From: tisdec.tis.tandy.com!kevinl    Jul 28 07:36:00 1992


	Does anyone know why istream extraction and ostream insertion
operators (ie >> and << respectivly) are not overloaded for the strstream
class in Borland C++?  It's not any problem to inherit them into a class
that overloads them, and you can always to the strstreamobject.rdbuf()
thing, but I don't think you should have to.  I'd appreciate a clue. 8-)

Newsgroups: comp.lang.c++,comp.std.c++
From: chip@tct.com (Chip Salzenberg)
Subject: Re: Downcasting and mortal sin (was run-time type checking)
Date: Thu, 30 Jul 1992 19:42:11 GMT
Organization: TC Telemanagement, Clearwater, FL

According to shang@corp.mot.com:
>In article <2A75806A.826A@tct.com> chip@tct.com (Chip Salzenberg) writes:
>> virtual boolean Animal::can_mate_with(const Animal&);
>
>I'm interested in the implementation of your "can_mate_with" in a derived  
>class. Whould you show me how it is done without RTTI?

Of course.

>(1) Do not supply your own RTTI through virtual functions.
>(2) Do not flood virtual functions in the base for each possible derived  
>    classes.

Ah, so you already know how it can be done.

>Okay?

No, not okay.  I do not program with one hand tied behind my back.
The complete language is always at my disposal.
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
   "Do Rush place weird subliminal backmasked messages in their songs to
 compel unwilling geeks to commit evil .sig atrocities?"  -- Dean Engelhardt
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Speed, Correctness, Availability, and the Real World
Organization: TauMetric Corporation
Date: Tue, 21 Jul 1992 16:53:23 GMT

jimad@microsoft.com (Jim Adcock) writes:

>I also would suggest that if the committee feels overwhelmed by the number
>of suggestions coming in, then the first activities the committee should
>"chop" are work-items that the committee has made for itself out of whole
>cloth -- items that don't exist anywhere in written-down form.

I don't believe there are any such work items.


>IE some of the "standard" libraries suggestions.
>If some committee member or non-
>member thinks that some library that hasn't anywhere been written should
>be part of the "standard" then such person should *start* by writing such
>a library, and then write up a proposal for such a library's inclusion.

That is exactly the procedure which has been followed.  Nothing is being
considered for the standard library which does not exist as a written
proposal (with an implementation).  When a member or non-member suggests
something new, he or she is requested to write it up.  No written
proposal, no consideration.


>Note that there is no hard-and-fast reason why such new libraries *have*
>to be part of the C++ *langauge* standard -- such new libraries are perfect
>candidates to be factored *out* of the C++ *language* standard to be handled
>as separate standardization efforts in their own right, when the time comes.

I in fact argued this point at the early C++ Committee meetings.  I
challenged every statement of the form "of course class X must be in the
standard library."  The overwhelming majority of the committee wanted
some standard classes.  So far, only IOstreams and some sort of String 
class(es) are certain to be in the standard library.  A generic dynamic
array class will probably be in the library.  A bitset class has been
proposed and discussed for some time, and might be adopted in some form.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++,comp.std.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: Downcasting and mortal sin (was run-time type checking)
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Wed, 29 Jul 92 16:43:43 GMT

In article <2A75806A.826A@tct.com> chip@tct.com (Chip Salzenberg) writes:
 
> Therefore you need this:
> 
>     virtual boolean Animal::can_mate_with(const Animal&);
> 

I'm interested in the implementation of your "can_mate_with" in a derived  
class. Whould you show me how it is done without RTTI?  Two conventions:

(1) Do not supply your own RTTI through virtual functions.
(2) Do not flood virtual functions in the base for each possible derived  
classes.

Okay?

David Shang
Newsgroups: comp.lang.c++
From: kkt@philabs.philips.com (Kim-Kiat Tan)
Subject: Borland 3.0 patch
Organization: Philips Laboratories, Briarcliff, New York
Date: Thu, 30 Jul 1992 17:35:52 GMT

	Any one knows either the ftp site or Borland's BBS no. for getting the
patch for Borland C++ 3.0's profiler for it to work with window 3.1 ?
From: drenze@icaen.uiowa.edu (Douglass J. Renze)
Newsgroups: comp.lang.c++
Subject: A question about the sizeof operator
Date: 31 Jul 92 00:05:03 GMT
Organization: University of Iowa, Iowa City, IA, USA

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

The following program:

#include <iostream.h>
 
class s1 {
        struct name {
                char last[10], first[10], mi;
        };
        s1* next;
};
 
class s2 {
        struct name {
                char last[10], first[10], mi;
        };
};
 
int main(void) {
        cout << "sizeof s1 = " << sizeof(s1) << '\n';
        cout << "sizeof s2 = " << sizeof(s2) << '\n';
        return 1;
}

produces the following output:

sizeof s1 = 4
sizeof s2 = 1

Yet this next program...

#include <iostream.h>
 
class s1 {
        char last[10], first[10], mi;
        s1* next;
};
 
class s2 {
        char last[10], first[10], mi;
};
 
int main(void) {
        cout << "sizeof s1 = " << sizeof(s1) << '\n';
        cout << "sizeof s2 = " << sizeof(s2) << '\n';
        return 1;
}

produces this next output...

sizeof s1 = 26
sizeof s2 = 22

Naturally I didn't expect the "sizeofs" to be *identical* between the two
programs (after all, one contains a struct within the class, and the other
doesn't), however, I did expect them to be more nearly equal than that.  Can
anybody explain this difference to me?  My curiosity is piqued.  Is it that
the struct name isn't included within the class's memory allocation, or what?

Peace,

Doug

-- 
| Douglas J Renze            | "Jerry [Brown] is the equivalent of a          |
| drenze@icaen.uiowa.edu     |  drive-by shooting."                           |
| drenze@chop.isca.uiowa.edu |                                                |
| drenze@aol.com             |         * NPR's Morning Edition, 13 July 1992  |
Newsgroups: comp.lang.c++,comp.std.c++
From: mat@uunet.uu.net!mole-end
Subject: Re: Language extensions for run-time type identification
Summary: Yeah, that's it--BREAK CODE!
Organization: :
Date: Sat, 25 Jul 1992 07:11:25 GMT

In article <1992Jul23.200803.22371@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> 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.

You wouldn't, but I would.  That's an awfully high-priced change.  And I
think that there are a few hundred million lines of C++ in the various
programs that would be affected.
-- 
 (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: han@lipari.usc.edu (Jung-Hyun Han)
Newsgroups: comp.lang.c++
Subject: wow!! C++ interface
Date: 28 Jul 1992 07:18:06 +0100
Organization: University of Southern California, Los Angeles, CA
Distribution: world
NNTP-Posting-Host: lipari.usc.edu

I am sorry I omitted my address:
It's han@lipari.usc.edu or junghyun@pollux.usc.edu

thanx a lot

Jung
Newsgroups: comp.lang.c++,comp.std.c++
From: mat@mole-end
Subject: Re: Handling of operator . proposal
Summary: Well, there IS no place like an ANSI C++ meeting ...
Organization: :
Date: Tue, 21 Jul 1992 09:55:06 GMT

In article <1992Jul21.005444.836@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> In article <1992Jul18.211602.11671@mole-end> mat@mole-end writes:
> |Attending this last meeting was an eye-opener for me.  (Although those
> |eyes spent quite a bit of time glazed over by the material.)  The next
> |meetings will be held in Boston (November) and Portland (March).  I
> |strongly suggest you attend.
 
> I strongly suggest you [and others] suggest HOW I might attend?
> Am I to click my heels together three times while reciting:
> 
> "There's no place like an ANSI C++ meeting!"

I'm afraid it's much simpler than that.  It involves a rare, hard-to-get
thing called _money_.  I think you can sign up as an x3j16 Observer for
a half-year now that the year is half-gone.  I can't tell you what airfare
to Boston will be in the fall, but I'm pretty sure it will involve money,
too :-).  Oh, and a week of your time, which might have to come out of
your vacation.  (I know of at least several people who brought their families
along to Toronto; I'm sure they found something to do.  Boston should be
able to keep people busy for a week as well.  Portland, I'm not so sure
about.)
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++