HDTenEightyP/NetNews huggingface dataset:
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: Nested classes & Inheritance
Date: 14 Oct 92 16:40:55 GMT
Article-I.D.: alice.23891
Organization: AT&T Bell Laboratories, Murray Hill NJ



dcb@slsvitt (David Binderman 3841 @ SEL-Alcatel LTS Dept. US/ES) writes

 > bs@alice.att.com (Bjarne Stroustrup) writes:
 > : 
 > : dcb@slsvitt (David Binderman 3841 @ SEL-Alcatel LTS Dept. US/ES) writes
 > : 
 > :  > Given the following code
 > :  > 
 > :  > class A {
 > :  > public:
 > :  >      class B { };
 > :  > };
 > :  > 
 > :  > class C : public A {
 > :  >     class D {
 > :  >         B y;
 > :  >     };
 > :  > };
 > :  > 
 > :  > Then does the declaration of y require A::B or only B ?
 > :  > Or, is B accessable from D directly ?
 > :  > 
 > :  > The ARM, Stroustrup 2 & Lippmann 2 didn't help in this case.
 > : 
 > : Well, the lookup rules in 10.4 of the manual (in the ARM or my 2nd
 > : edition) ought to have helped. In a class, having looked locally,
 > : you start looking for names in base classes. B is a name is the
 > : scope of A so that the B in `B y;' must refer to A::B.
 > : 
 > : Names of nested classes obey all the usual lookup rules for member names.
 > 
 > Unfortunately, I looked at section 9.7 fourth sentence, which is the
 > last sentence on page 185 in my copy of the ARM.

 > The sentence seems to me to contradict the advice in 10.4 section.

It doesn't. D's enclosing class is C. Naturally, the usable names from
C includes those of C's public base A.

 > My understanding is that class D doesn't have class A as a base
 > class, and so has no knowledge of its contents.

D doesn't have A as its base but D's enclosing class C does.
Newsgroups: comp.lang.c++
From:  alex@erma.msk.su (alex)
Subject: Re: Should friends obey access?
Date: Fri, 9 Oct 1992 06:10:54 GMT
Reply-To: alex@erma.msk.su
Organization: JV ERMA International, Moscow

> From article <WARSAW.920ct5181127@anthem.nlm.nih.gov>, by warsaw@nlm.nih.gov (Barry A. Warsaw)
>
> ... Why not have friend declarations obey access specification? Thus,
> declaring something as a friend would only extend friendship to the part
> of the interface in which the declaration was included ...

        I believe any programmer develops its own style, its own
general concepts of software design. And occasionally he/she
(me too) wonders why these "general" principles aren't
supported directly by language. It's quite natural. Probably
only Bjarne Stroustrup  never gets into such a trouble with
C++ :-)

        As for me, I'm considering functions as a means of
description of class interface. Implementation of interface
should have full access to class members, regardless whether
this function is 'public' or 'private'. Friend functions are part
of interface, thus that's all OK with them.

        I don't consider class as interface to another class, at
least it is not general case. Should I come up with idea of
prohibiting classes to have 'friend' modifier?

Alexander Pavlov
ERMA International, Moscow, Russia.
E-mail alex@erma.msk.su
FAX: (095) 415-2973
From: wgarcia@upf.es (Walter Garcia-Fontes)
Newsgroups: comp.lang.c++
Subject: Libraries for Constrained Optimization
Date: 15 Oct 92 11:19:53 GMT
Article-I.D.: upf.9210151222.AA04299
X-Unparsable-Date: Thu, 15 Oct 92 12:17:31 WETDST

Anybody knows of libraries in C++ for constrained optimization that
are in the public domain (ftp-ables...)?

Thank you very much for any information that you can provide,


Prof. Walter Garcia--Fontes            Tel.: (3) 484 9667
Departamento de Economia               Fax.: (3) 484 9746
Universitat Pompeu Fabra               wgarcia@upf.es
Balmes 132
                     _
Barcelona 08008, Espana
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: virtual destructors
Date: 13 Oct 92 12:47:26 GMT
Article-I.D.: alice.23868
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Oct12.235515.4506@netcom.com> nagle@netcom.com (John Nagle) writes:

>        It's not your fault.  The language is badly designed in this area.
> Destructors should always be virtual, and it should be an error (at least
> a warning) to declare one that isn't.

The trouble with that approach is that a class with no virtual functions
would thereby incur a potentially serious time and space overhead, especially
for the kinds of tiny objects that don't have virtual functions.

In typical C++ implementations, the first virtual function costs an extra
word per object.  This is not serious for objects with lots of data in them,
but amounts to 100% overhead for objects that are only one word long to
begin with.  Similarly, an empty destructor takes no time at all to execute
if it is inline, but if it is virtual, inline expansion becomes impossible
in the not uncommon case where objects are being deleted through pointers.
(If you never delete an object through a pointer, you never need a virtual
destructor).  While virtual function overhead is not great in absolute terms,
any overhead at all is infinitely worse than zero!
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: pkoch@news.weeg.uiowa.edu
Subject: C++ library for UNIX/PC console I/O
Organization: University of Iowa, Iowa City, IA, USA
Distribution: usa
Date: Tue, 13 Oct 1992 13:11:42 GMT

Could someone tell me where I could purchase or download a cross-platform
c++ library for console I/O. I need to write user interfaces that will 
compile both on PC's and UNIX machines. I can't use any Windowing
software.

===========================================================================
Peter Koch                                              Phone: 708-534-5200
Weston Gulf Coast Labs                     email:pkoch@umaxc.weeg.uiowa.edu
2417 Bond St.
University Park, IL 60466
===========================================================================
Newsgroups: comp.lang.c++
From: vinoski@apollo.hp.com (Stephen Vinoski)
Subject: Re: My objects are too big - why?
Date: Fri, 9 Oct 1992 15:58:26 GMT
Distribution: comp
Organization: Hewlett-Packard Corporation, Chelmsford, MA

In article <1992Oct09.141039.18062@watson.ibm.com> mittle@siena.watson.ibm.com (Josh Mittleman) writes:
>barmar@think.com (Barry Margolin) writes:
>> In article <RWK.92Oct7142833@silver.sbi.com> rwk@silver.sbi.com
>(Richard W. Kreutzer Consultant) writes:
>> >When executed on a Sparc (with either AT&T cfront 2.1 or gcc-2.2.2)
>> >sizeof(Derived) displays as 8.
>> 
>> Since you have virtual functions, the size 8 is due to 4 bytes for the data
>> member of type int and 4 bytes for the virtual table pointer.
>
>That doesn't entirely answer the question.  The same experiment without the
>virtual function shows that sizeof(Base) = 1 and sizeof(Derived) = 8.   Any
>idea why?
>
>class Base { };
>
>class Derived : public Base {
>public:
>  int a;
>};
>
>main () {
>  Base b;
>  Derived d;
>  cout << sizeof(b) << " " << sizeof(d) << endl;  // output: 1 8
>}

The Base class is empty, but must have a non-zero size (ARM, chapter
9, page 164), so its size is 1.

Derived adds an int, which I will assume is of size 4.

The total size of 8 for the Derived class is due to alignment.  The
int is aligned on a 4-byte boundary.  The class is laid out like this:

	--------------------------------------------------
	| Base |     |     |     |  D  |  D  |  D  |  D  |
	--------------------------------------------------

The Base takes 1 byte, then there are 3 empty bytes due to the
alignment of the Derived int member (the bytes marked "D").

-steve
-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
From: alindbac@aut.abb.se (Anders Lindbck)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: Preconditions and PostConditions in C++
Date: 7 Oct 92 12:54:41 GMT
Organization: THHS (krfc) tlps

In article <Bvq8tF.J3C@fiu.edu> feathers@serss0 (Michael Feathers) writes:
>I advance this idea with some trepidation... (ooh! noo! new language 
>feature!) but has anyone considered adding Eiffel-style pre and post 
>conditions to C++?

Yes, and it is rather trivial to do so using macros.

>I know that proposed features are routinely vetoed if there is some other
>way of achieving the same effect using the current features of the language.

Yes, and I think falls under this hat. I would also like the idea with
pre and post conditions but since it available already, why bother to put
it into the languages. I agree with them in the fact that no new languages
constructs should be added unless absolutly needed.

[Some lines deleted]
>In this case, it would be ideal to have the signature of the offending 
>function, and the condition, thrown or reported in a development as char 
>pointers in a development environment.  The name of a function is not
>available during preprocessing, so macros are no help unless programmers
>type in the name of each function themselves.  This issue really looks 
>like it touches on the environment a bit (unfortunately) but there is a real
>benefit to be gained.

How about file and line number ? You have that with macros and that is 
actually often more helpful than which class and member funcion it is
in. Since in most cases you did not write it yourself and has to rumble
about and find which file in which directory it is written to se what is
going on. At least when one has large software systems.

Anders
From: matt@centerline.com (Matt Landau)
Newsgroups: comp.lang.c++
Subject: Re: (QUERY) How to call an object's member function?
Date: 16 Oct 1992 13:44:06 GMT
Organization: CenterLine Software, Inc.
NNTP-Posting-Host: 140.239.1.32

In <1992Oct16.063011.22925@msi.com> bill@snoopy (Bill Poitras) writes:
>In Unix, under any widely availible debugger, how do you call a method on
>a variable:

Well, in ObjectCenter, you'd say "print a.value()", unless you wanted
to do something more than just print the value, in which case you'd 
type arbitrary C++ code at the C++ listener and it would be executed.
--
 Matt Landau			Waiting for a flash of enlightenment
 matt@centerline.com			  in all this blood and thunder
Newsgroups: comp.lang.c++
From: lazarus@ug.cs.dal.ca (Chuck Turner)
Subject: trying to use TCXL Window Libraries with Borland C++
Organization: Math, Stats & CS, Dalhousie University, Halifax, NS, Canada
Date: Wed, 14 Oct 1992 16:24:43 GMT

Hi y'all.

I'm trying to use the TCXL Window library with Borland C++, but I get compiling
errors.  What's baffling are the errors I get:

   Type mismatch in parameter (parameter) in call to (function).

and

   Cannot initialize void(near*)() with void(near*)().

In both cases, the error message is telling me that I'm trying to match 
incompatible types; but the truth is that they are of the same type.

Has anyone else tried to use TCXL?
Or can anyone tell me what's going on?


						Chuck

 _______________________________________ 
|                                       | '..err..of course I suck blood.' 
| "--whether you are quiet and ALIVE or | 'I don't believe you.' 
| quiet and DEAD makes no difference to | 'I've got a straw right here PAL! 
| Cerebus."                             |  You want a demonstration?!'
|       - Cerebus the Aardvark          |                   - The Tick 
|_______________________________________| Chuck Turner -> lazarus@ug.cs.dal.ca
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: Re: GOTO, was: Tiny proposal for named loops.
Date: 13 Oct 92 00:20:31 GMT
Organization: negligable

Someone has mailed me the obvious rewrite of that.  I don't know
what to say except my brain must not have been  functioning on 
all 3 cylinders that day....  Maybe it was the decaf espresso...

		-Richard Hartman
		hartman@ulogic.COM

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

Newsgroups: comp.lang.c++
From: ilan@seas.gwu.edu (Ilan Berkner)
Subject: Turbo C++ / Heap sort algorithm
Organization: George Washington University
Date: Tue, 13 Oct 1992 03:33:06 GMT

I'm trying to develop an abstract Q system on Turbo C++.
One of the requirements for the system is that a possible implementation
for a Q would be a heap sort of either ascending or descending order.
(Using a tree, not an array.)
I know what a heap sort is and how it works. How ever, I am fairly new
to the C++ environment.
If anyone has implemented such an algorithm or has somesort of sample code
please e-mail directly.
Your help would be appreciated.
Thanks,
	ilan@seas.gwu.edu

Newsgroups: comp.lang.c++
From: steven@concave.cs.wits.ac.za (Steven Ruskin)
Subject: Zortech c++ - advice wanted
Organization: Computer Science, University of the Witwatersrand
Date: 15 Oct 92 09:12:53 GMT

I am currently using Borland C version 2 and am looking to upgrade to c++.
I am considering Zortech C++ wich is available with advanced mathematical classes whic could pose to be very usefull. My alternative is Borlands C++. Both come with windows classes. 

I would appreciate it if anyone can provide me with details of their experience with the Zortech compiler and Borland compiler in particular any major shortfalls of either. 

I look forward to replies to my email address Steven@concave.cs.wits.za
Steven Ruskin


Newsgroups: comp.lang.c++
From: ctaylor@sparc7.cs.uiuc.edu (Conrad W Taylor)
Subject: > The C++ Report...? ( SUMMARY OF REPLIES )
Organization: University of Illinois at Urbana-Champaign
Date: Sat, 10 Oct 1992 21:26:35 GMT


From vinoski@APOLLO.HP.COM Thu Oct  8 08:55:24 1992

In article <1992Oct8.025619.7161@sunb10.cs.uiuc.edu> you write:
>         I was wondering, is the C++ Report a good and worth it
>magazine for someone who'll be doing C++ programming in
>the near future?  To all that reply to this post please elaborate
>on your feeling concerning the magazine (good or bad).

I think it is pretty good.  Stan Lippman has been the editor for
several months now, and he has lined up some good authors and
columnists.  The October issue came out yesterday and is chock full of
good articles by well-known C++ people.

-steve

Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.

From gt@rundart.demon.co.uk Thu Oct  8 11:17:07 1992

In my opinion, it is an excellent magazine.  Well worth the (expensive)
subscription.  If you are doing any C++ work then you need to subscribe.
Some of the articles deal with very advanced subjects.  Persevere with
them.  C++ is a lot more complex than C.

Giles.
-- 
Giles Todd                      gt@rundart.demon.co.uk (Internet)
Voice: +44 925 33472            PGP 2.0 public key available.
Rundart Ltd, 5 Brentnall Close, Great Sankey, Warrington, WA5 1XN, UK

From vinoski@APOLLO.HP.COM Thu Oct  8 12:44:39 1992

 >            I was wondering does the magazine, C++ Report, provide sample
 >  code and things of that nature? 

They show useful sample code, discussions about the theories behind
C++, and everything in between.  I've been reading it for several
years now and have always enjoyed it and found it valuable.

-steve

Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
-------

From gt@rundart.demon.co.uk Fri Oct  9 01:26:24 1992

>          Where can one obtain subscribtion information for the C++
> Journal or did you mean C++ Report in your reply to my post?  Thanks
> in advance.

I meant "C++ Report".  I also subscribe to the "C Users Journal" and I
confounded the names (but I was referring to the "C++ Report"
throughout).  Apologies.  "C++ Report" subscription requests should go
to

C++ Report
Dept CPR
PO Box 3000
Denville
NJ 07834
USA

US rates are $69 for 9 issues according to the September edition.  We UK
punters pay rather more.

Giles.
--
Giles Todd                      gt@rundart.demon.co.uk (Internet)
Voice: +44 925 33472            PGP 2.0 public key available.
Rundart Ltd, 5 Brentnall Close, Great Sankey, Warrington, WA5 1XN, UK
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: virtual destructors
Date: 13 Oct 1992 01:23:12 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Oct12.235515.4506@netcom.com> nagle@netcom.com (John Nagle) writes:
>       It's not your fault.  The language is badly designed in this area.
>Destructors should always be virtual, and it should be an error (at least
>a warning) to declare one that isn't.

I disagree; destructors should not always be virtual.  They should always
be virtual in any class that has virtual functions; they should not be
virtual in classes without virtual functions.  As for those who say that
there should not be classes without virtual functions: you're stuck in
only one paradigm.  It simply isn't true that every class should be
designed to be inherited from, and there is also the C compability issue.

Most compilers these days give you a warning at the point where you're
likely to get into trouble: another class is derived, it has virtual
functions and a destructor, and the base destructor isn't virtual.




--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: simple question on self modifying strings
Keywords: strings, self modify
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 12 Oct 1992 14:02:56 GMT

In <hess.718881592@rzdspc15> hess@rzdspc15.informatik.uni-hamburg.de (Hauke Hess) writes:

>Hi,

>I`m working on a small text editor in a graphical application package. It
>will be possible to have those pretty text-editing features of block marking
>etc.

>I would like to implement a String-class that supports block-marking through
>two int`s called BlockStart and BlockEnd, and a function that replaces the
>actual mark with a string. Think of

>"Hello World"
>   ^   ^
> Start End

>where ReplaceBlock("BLA") would change the string to

>"HeBLAorld"

>Now this seems like a problem to me because I don`t like modifying "this" and
>the char * is private to the master class I`m deriving of.

*****>	Huh?  I was with you 'til this last paragraph.  The "change from
	here to there" function would be a member function of the String
	class.  What's the problem.  For my own (yet another) String
	class, I used operator():

		class String;

		class SubString;
			String	*s;
			int	at, len;
		public:
			// ...
		};

		class String {
			char	*rep;
		public:
			// ...
			SubString operator()( int at, int at_most );
		};
	
	Substring is a helper class that only holds a string reference
	and the start/length positions in the referenced string, e.g:

		String s = "Hello world!";
		s(5,6) = "there, everybody";	// s = "Hello, everybody"
	
	operator() returns a SubString; when one appears on the LHS of
	an =, SubString::operator=() modifies the string referenced
	instead by calling appropriate member-functions in String to do
	it.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: caspers@fwi.uva.nl (John Caspers)
Subject: changing a const object..
Summary: At pp 60 & 61, does Coplien violate rules for const objects
Keywords: C++, const, coplien
Organization: FWI, University of Amsterdam
Date: Wed, 7 Oct 1992 14:37:07 GMT

Coplien (Advanced C++ Programming Styles & Idioms) writes the following code
on pages 60 and 61:

class String
{
  public:
    String( const String& s )
    {
      s.rep->count++;
      // ...
    }
    // ...
  private:
    StringRep *rep;
};

class StringRep
{
  friend String; private:
    // ...
    char *rep;
    int count;
};

The question is: in String's copy ctor, the argument 's' is const.
But the statement 's.rep->count++' changes the state of the StringRep
object s.rep is pointing to...
Any comments on this? My compiler (BC++ 3.1) didn't complain about
changing an object pointed to by a member of a const object. Should it?

John Caspers
From: rwk@silver.sbi.com (Richard W. Kreutzer Consultant)
Newsgroups: comp.lang.c++
Subject: Object size revisited
Date: 9 Oct 92 13:59:13 GMT
Distribution: comp
Organization: Integra Software Corporation

Thanks to those who replied to my post regarding the "too large" size of
derived class objects.  I understand that the vptr in a base class which
contains virtual functions will add extra bytes to the derived class which is
fine since you get something for it.  The problem is, and I failed to clarify
this in the original post, that you get extra bytes EVEN when there are no
virtual functions in the base class - which, judging from some of the replys i
got back, is news to some of you.  It was of course news to me.

Dick
--

--
        Richard W. (Dick) Kreutzer
Net:    rwk@quark.sbi.com				CIS:	70702,2174
Voice:  +1(801)571-2446					FAX:	+1(801)571-2448
Mail:   Integra Software Corp.; 1378 Jasmine Avenue; Sandy, UT 84092 (USA)
Newsgroups: comp.lang.c++
From: mittle@siena.watson.ibm.com (Josh Mittleman)
Subject: Re: Const and Reference
Date: Fri, 09 Oct 92 19:14:59 GMT
Organization: IBM T. J. Watson Research

Sekar replied to me:

> : The correct output is '+'.  A reference is an alias, so any change to a is
> : also a change to b.  
> 
> I disagree. The correct output is '-' and a reference to a
> const T is not an alias as I can understand from ARM.

But it isn't a reference to a const, it is a const reference.  There is a
difference: A const reference is a reference through which no change can be
made to the traget data.  A reference to a const is a reference (which may
or may not itself be const) to a piece of data which may not be changed.
This is precisley the same distinction as between a const pointer and a
pointer to const.

> :   double d = 1.0;          // normal initialization
> :   const double& rcd = d;   // rcd refers to d
> 
> Also the above quote from p. 154 of ARM does not say anything
> about the constness of the initializer.
> 
> So, if I understand the quote from p. 154 correctly, 
> rcd should refer to a temporary initialized with d.

Since I quoted the examples directly from ARM, I would suggest that you
re-think your argument.  

===========================================================================
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++