HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: PROPOSAL: Hidden private parts of classes
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 7 Nov 1992 15:52:48 GMT

In article <klamer.720538594@mi.el.utwente.nl> klamer@mi.el.utwente.nl (Klamer Schutte) writes:
>]But such knowledge is not necessary; the LINKER can decide the layout of
>]data in memory!  But alas, that would require new smarter linkers, and
>]then you couldn't use a cfront compiler.
>
>OK, that holds for global / static variables. But how for auto variables?
>These generally are efficient to use, but to be efficient, their size
>must be known at compile time. 

	Why? Why cant the size be calculated by a smart linker
at link time? Why cant assembly output be made by the compiler
with 'sizeof_someobject' as a symbol yet to be determined?

>and thus can only a pointer to an object on the heap be used.

	NO, and I have SEEN it done otherwise in a Modula compiler,
I used it and it worked.

-- 
;----------------------------------------------------------------------
        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: f43703a@nucc.cc.nagoya-u.ac.jp (SUPRATIC GUPTA)
Subject: HGelp needed - C++
Organization: Nagoya University Computation Center, Nagoya, Japan.
Date: Thu, 12 Nov 1992 04:05:31 GMT


Dear friends,
    I am having a problem with C++, can you help me? Please answer
to me directly.

#include <stream.h>
#include <stdio.h>
#include<stdlib.h>
#include <string.h>
   
main(){
    char* objname[2];
    for(int i = 0; i < 3; ++i){
        objname[i] = "UNDEFINED";
    }
    char* ZZZ = "                                        ";
        if(k == 0) ZZZ = "aaaaaaaaa";
        if(k == 1) ZZZ = "bbbbbbbbb";
        if(k == 2) ZZZ = "ccccccccc";
        for(i = 0; i < 3; ++i){
            cout <<"after  " << i << "  "<<  objname[i] << endl;
        }
     objname[k] = ZZZ;
    }
}

The out put is OK It looks like this;

0  UNDEFINED              1  UNDEFINED              2  UNDEFINED
0  aaaaaaaaa              1  UNDEFINED              2  UNDEFINED
0  aaaaaaaaa              1  bbbbbbbbb              2  UNDEFINED

But if I use this program;

#include <stream.h>
#include <stdio.h>
#include<stdlib.h>
#include <string.h>

main(){
    char* objname[2];
    for(int i = 0; i < 3; ++i){
        objname[i] = "UNDEFINED";
    }
    char* ZZZ = "                                        ";
    for(int k = 0; k < 3; ++k){
        cout << "INPUT > " cin >> ZZZ;
        for(i = 0; i < 3; ++i){
            cout << i << "  "<<  objname[i] << "              ";
        }
        cout << " " << endl;
     objname[k] = ZZZ;
    }
}

The answer looks like this:

INPUT > aaaaaaaaa
0  UNDEFINED              1  UNDEFINED              2  UNDEFINED
INPUT > bbbbbbbbb
0  bbbbbbbbb              1  UNDEFINED              2  UNDEFINED
INPUT > ccccccccc
0  ccccccccc              1  ccccccccc              2  UNDEFINED

The answers are different, when the only difference is that in
second case I am using "cin" for input. Can any one explain?

with regards
SUPRATIC GUPTA

 
Newsgroups: comp.lang.c++
From: willittl@spock.NMSU.Edu (William  Little)
Subject: c++ & c+++
Organization: New Mexico State University
Date: Sun, 8 Nov 1992 22:26:37 GMT


Okay, a couple quick questions.

My employer recently bought Borland c++ compiler for
windows and told me he bought some new C+++.  I personally
have never heard of C+++.  Has anybody else?  Could he
be confused about the Borland C++ 3 compiler for windows?

Now, on to my c++ questions.

In the past week I bought a couple books on c++ so I can 
finally figure out what the difference is.  WOW!  I have
been doing things the hard way!  But, I guess I will find
out what it is worth when I start developing a windows
application... ick.

The books I bought were for beginners, and didn't tell me 
much.  I went through them in a couple hours, and came up
with some questions in areas they didn't cover.

They made references to the functions and variables in 
classes two different ways.

first:

class.variable
class.function()

That was expected...

Then, they did this:

class::variable
class::function()

Also, when they created a class such as:



class test   (simplistic flow - no flames please)
  {
  define variables....

  function1(){
     code;
     }

  function2(){
     code;
     }

  function3();
  }   // end class

test::function3() {
   code;
   }

main() { did the goodies }

They created function3 inside the test class, yet defined
the code for it out of the class definition, and used those
nasty ::'s that confuse me so well.

What do the ::'s do??

The books I bought used them all over the place,  but never
told me what they did.

Please help..  :)

Joseph Good
(The sole user of a good friends donated unix account)

willittl@nmsu.edu
From: ameesh@lsil.com (Ameesh Desai)
Newsgroups: comp.lang.c++
Subject: Re: Linked Lists in Shared Memory:
Date: 6 Nov 92 18:50:24 GMT
Reply-To: ameesh@lsil.com
Organization: LSI Logic Corporation

In article 17760@ermes.enea.se, eny@ermes.enea.se (Erik Nykvist) writes:

[stuff deleted]

>
>I have used a technique based on the new-operator with placement-syntax.
>If we have objects that can only be accessed by one process at the time it
>is possible to adjust the this-pointer using this operator.
>
>As long as the constructor used doesn't mutate the data members the affect of
>using this operator is only adjustment of the vtbl-pointer.
>

[ stuff deleted ]

>// We also use the placement syntax to allocate the shared object.
>=========
>PROCESS 1
>=========
>{
>	Shared* sp = new (shared_mem) Shared;
>	Lock lock(*sp);
>	// Adjust vtbl
>	new (shared_mem) Shared(IN_SHARED_MEMORY);


I am confused ... do you plan to allow creation of the object in one process and
its access in another. If so I am not sure what effect the above new statement
has - how does it fix the vtbl ? How does it effect the 'this' ptr - which 'this' ?

[stuff deleted]
>
>Erik Nyquist, ENEA DATA AB, 	erny@enea.se
>				eny@ermes.enea.se


Ameesh

---
______________________________     o__            
| _   /|     Ameesh Desai     \    ,>/_                              
| \`O.o'     LSI Logic Corp.   \__(_)`(_)_              email: ameesh@lsil.com
| =(_|_)=    MS E192, 1501 McCarthy Blvd. \             fax  : (408) 433-6802
|____U_______Milpitas, CA 95035____________\____________voice: (408) 433-4097 
Newsgroups: comp.lang.c++
From: donovan@well.sf.ca.us (Sean Donovan)
Subject: Re: Using 64k objects
Organization: Whole Earth 'Lectronic Link
Date: Fri, 6 Nov 1992 07:40:58 GMT


[ ... text of problem of allocating 64k object deleted ...]

When allocating an array of larger than 64k you need to declare that element
as a huge array.  There are special address normilizations which must be
added to address beyond the 64k segment boundry in 80x86 real mode.  Your
compiler will provide you with this is you declare the array as huge or if
you compile under the huge memory model.


Sean Donovan

Newsgroups: comp.lang.c++
From: mittle@watson.ibm.com (Josh Mittleman)
Subject: Re: Referencing `...' arguments in functions
Date: Mon, 09 Nov 1992 21:13:14 GMT
Distribution: usa
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center


> I wish to write a function having an unknown number of arguments.  I know
> that the '...' in the function declaration will allow for any number of
> arguments, but how do I actually access these variables.

According to ARM, p.146, the only guaranteed way to access the arguments
passed using ... is the va_list macros in stdarg.h.  They are used as
follows: 

  void f(int n, ...) {
    va_list theList;
    va_start(theList, n);
    for (int i = 0; i < n; i++)
      int j = va_arg(theList, int);
      cout << j << endl;
    va_end(theList);
  }

This function prints out a list of the n int arguments passed through the
ellipsis.  Note: There is no guaranteed method for accessing the arguments
passed with the ... unless there is at least one argument before the
ellipsis. 

> If there is a solution to that question (which I'm sure there is), is
> there any way for me to know the number of arguments and, more
> importantly, the variable type of each argument?

No.  You must either know this information a priori or pass it to the
function. 

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
Newsgroups: comp.lang.c++
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: enum labels
Keywords: enum labels
Date: 11 Nov 92 22:22:09 GMT
Organization: negligable

Thanks for the good news!  I wish *my* compiler implemented it...

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Oh I give my life so lightly		|
to my gentle lady.			|	-Richard Hartman	
Giving freely, and completely,		|	hartman@uLogic.COM
for my lady.				|
From: willis@cs.athabascau.ca (Tony Willis)
Newsgroups: comp.lang.c++
Subject: TI preprocessor on RS6000?
Keywords: TI COOL preprocess, hang
Date: 10 Nov 92 19:49:52 GMT
Organization: Athabasca University

Hi there

Has anyone managed to get TI's preprocessor that comes with the
COOL class libraries to compile and work properly on a RS6000?

It seems to process some code correctly, but occasionally
encounters code which causes it to hang up and cause my Rs6000
workstation to get into some kind of wait state.

It's important to me to get this thing to work; I'm involved in
a large c++ project in which we are using TI's preprocessor
to give us templates until Sun's c++ compiler can handle them
(most of my colleagues in this project are using Suns - IBM's
xlC compiler handles templates quite nicely!)

Thanks very much for any assistance you can give me.

Tony Willis

twillis@drao.nrc.ca
Newsgroups: comp.lang.c++,comp.lang.c,comp.os.msdos.programmer
From: brian@ganglion.Canada.Sun.Com (Brian Onn - OpCom Staff)
Subject: Re: Poll : Microsoft support on the Internet
Organization: Sun Microsystems of Canada, Inc.
Date: Sun, 8 Nov 1992 23:52:40 GMT

In article <BxF3z1.Ey9@ux1.cso.uiuc.edu> simms@ux1.cso.uiuc.edu (dan simms) writes:

> Regardless of what you (or even the whole internet) wants the internet is
> not for profit making, even if it would make it easier for academia to get
> support.  Microsoft providing customer support over the internet would 
> _have_ to be a violation..   
>
>						   dan

Many vendors already provide some customer support over the Internet, 
in one form or another.  What is or is not is a violation is governed
by the acceptable use policy of the regional network to which the
vendor connects.

Since these regionals ultimately connect to the NSFNet backbone, their
AUP's are typically modelled after the NSFNet's AUP.  Now, let me
first point out that I've never read the NSFNet's AUP.  The one that I
have read is ONet's (Ontario Regional Network) AUP.  Point 6 under 
uses that are considered acceptable, from ONet's AUP:

"6.  Uses relating to the investigation and support of vendors' products,
     such as the distribution of information or technical support material
     on request or the discussion of products' relative advantages and
     disadvantages."


To paint a full picture here, I am obligated to quote point 6 
of the section that lists unacceptable uses:

"6.  Uses of the ONet network that result in traffic to any connected
     network which violates published acceptable use specifications for
     that network...."

meaning that if the NSFNet (or CA*Net, which ONet connects to) does not
permit vendor support, neither can Onet connected vendors over those 
networks.

The point I am trying to make here is that what is or is not acceptable
use is clearly written in network policies, and may vary from region
to region.

Brian.
--
_____________________________________________________________________
Brian Onn.                  Internet : Brian.Onn@Canada.Sun.Com
Operation Commitment,	        Uucp : uunet!sun!suncan!brian
Product Support Specialist.    Voice : (416) 477-6745.
---------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: walduck@mpr.ca (Andrew Walduck)
Subject: Re: Multiple Header Files Problem
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Wed, 11 Nov 92 05:11:35 GMT

In article <rmartin.721442494@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>reindorf@us-es.sel.de (Charles Reindorf) writes:
>
>|In article <rmartin.721359424@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:
>However, using the #ifndef convention does not solve all the problems
>related to inclusion, nor obviate the need to make judicious use of
>forward declarations.  #ifndef, while it *does* keep the contents of a
>header file from being compiled more than once, does not keep the
>header file from being *read* more than once.  Thus, if care is not
>taken, compile times can grow quite long.

That too is easily fixed...

---(in a .h) ---

#ifndef Tsomething_inc
#define Tsomething_inc

// include file for something that a TSomething needs...
#ifndef TAnotherSomething_inc
#include <TAnotherSomething.h>
#endif

#endif

Voila...header files are now no longer included more than once...

Andrew Walduck





-- 
Andrew Walduck, MPR Canada, walduck@mprgate.mpr.ca
-------------------------------------------------------------------------------
(I hope someone will flatter me by using this as a .sig quote...)
 -- Reid Kneeland
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: What is wrong with it?
Organization: Rational
Date: Sat, 7 Nov 1992 01:01:26 GMT

oertelh@cs.tu-berlin.de (Helmut Oertel) writes:

|LOOKING FOR C++ EXPERTS,

|Description of Problems see below

|Program-Example Part One (without multiple inheritance and virtual base-classes):

[simple single inheritance example which did downcasting]

|Program-Example Part Two (using multiple inheritance and virtual base-classes): wheres the error?

[simple example using multiple virtual inheritance, and attempted to
downcast from a virtual vase]

|The first program-example yields the desired output ("ok") while the second one usually shuts down without any warning message. The questions is: ist there an error in the program itself or does my compiler (BORLAND C++ 3.1) have problems with virtual baseclasses and multiple inheritance.
|I am grateful for any comment (how can one solve this Problem, do other C++ compilers have similar problems, and so on..)

|

This is a problem in your code.  It is illegal to cast a virtual base
class into a derived class.  This is specified in the ARM 10.6c.  The
reason is that the virtual base class has no way of knowing the memory
layout of the derived object.  Therefore it cannot find the beginning
address of the derived object.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Xref: sparky comp.lang.c++:16203 comp.std.c++:1557
From: dcb@slsvitt (David Binderman 3841)
Subject: Re: c++ & c+++
Organization: SEL-Alcatel LTS Dept. US/ES
X-Newsreader: Tin 1.1 PL4
Date: Fri, 13 Nov 92 18:27:17 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: >times amusing).  No "normal person" trying to learn C++ now needs
: >ARM.

Nonsense. All sane C++ programmers should have the ARM. Its the closest
thing to a definition, pending ARM version 2, hint hint, or the ANSI C++
getting a result soon. Given that the language is changing rapidly,
the ARM is the target, and certainly I wouldn't trust any one compiler.

: 	I dont agree. No one in their right mind should attempt to
: write C++ without the bible. It is THE reference. 

Absolutely agree. If you doing C++, invest in the ARM. No negotiation.

The best 100DM/ 30pounds/ 50$ you can spend on the language.

Then you get to flame compiler vendors for not sticking to it ...

: I learned C++by reading the ARM (and a couple of other books as well).

I learned it by debugging cfront 1.1 a long time ago, and I've been in 
the C++ business ever since.

Regards

David C Binderman     Dept US/ESI, Bau 60, SEL-Alcatel AG, Lorenz Strasse 10,
D-7000 Stuttgart 40, Germany      dcb@us-es.sel.de   Tel: +49 711 821 3841
Newsgroups: comp.lang.c++
From: wells@cdsmn.mn.org (Rich Wells)
Subject: Re: Const Inheritance
Organization: Dicomed, Inc
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 5 Nov 1992 17:24:28 GMT

Duane Voth (duanev@devnull.mpd.tandem.com) wrote:
: frank@Cookie.secapl.com (Frank Adams) writes:
: >The idea comes from one of the standard examples of an inheritance
: >hierarchy: shapes.  Assume we have a class Shape, with a subclass
: >Rectangle, and we want to add Square as a class.  It seems logical that
: >Square should be a subclass of Rectangle.

Let us not confuse "subset" with "subclass".  "Subclass" is a concept
we use for implementation; it need not correspond directly to the
"subset" and "superset" concepts we may be modeling.

So: although the set of squares is a subset of the set of rectangles,
it does not (necessarily) mean that the class "square" should be a
subset of class "rectangle".  Inheritance can be used for both
genericity AND specialization.  In this case, perhaps Square may be
the immediate subclass of Shape, with Rectangle a more generic
subclass of Square containing an extra field for the extra degree
of freedom.

Of course, this leaves us with objects of type Square * which point
to objects which violate the basic tenets of Squaredom, which is that
all 4 sides are equal.  Therefore....

: Perhaps the common mathematical definition of a square has led to
: this delema.  Sounds as if, in this instance, there are more differences
: between a square and a rectangle than there are similarities.
: Would making class Square and class Rectangle peers of each other
: cause so much duplication that the simplicity is unwaranted?

No.  That is, Yes they may as well be peers.  The differences far
outweigh the similarities.
-- 

Richard Wells  wells@cdsmn.mn.org  or  ...!tcnet!cdsmn!wells
Newsgroups: comp.lang.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: how to initilize an array inside of a class??
Date: Thu, 12 Nov 1992 18:46:05 GMT
Organization: University of Birmingham

In article <BxL3t2.FKG@ns1.nodak.edu>, cooper@plains.NoDak.edu (Jeff Cooper) writes:
 [ example class with array member ] 
> Now what I'd need to do is initilize the array 'some_ints' with some
> preset values...normally one would do it like:
> 
> int some_ints[3000] = { 1, 6, 34, 3, ... ,0 };
> 
> But my compiler complains about that, saying that I can't initialize
> class members there.  The only other way I can think of doing it is
> to do something like:
> 
> Y::Y()
> {
>     some_ints[0] = 1;
>     some_ints[1] = 6;
>     ...
>     some_ints[2999] = 0;
> }
> 
> Is this my only other option??
Yes I'm afraid it is. I asked a very similar question to this last week. I
would like to see the array handling in C++ tidied up a bit, but the weight of
oppinion is against me. If I had my way you would be able to say:
Y::Y() {some_ints={1,6, ... 0}; }
or 
Y::Y() : some_ints({1,6,...0}) {}
but nobody seems to support me.
-- 
    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)
 .  _\\__[oo 
.__/  \\ /\@  E-mail: B.A.McCauley@bham.ac.uk
.  l___\\        Fax: +44 21 625 2175
 # ll  l\\     Snail: 197 Harborne Lane, Birmingham, B29 6SS, UK
###LL  LL\\     ICBM: 52.5N 1.9W
 
Newsgroups: comp.lang.c++
From: johnh@tt.com (John Hasselkus)
Subject: static data members of private types impossible?
Organization: Telecommunications Techniques Corporation, Germantown MD
Date: Thu, 12 Nov 1992 15:10:14 GMT

How do you define a static data member of a private type?  For example:

class A {
  private:
    enum FOO {
      FOO_1,
      FOO_2
    };
    static FOO foo;
};

A::FOO A:foo;	// <- Compiler won't let you use private types out here

Is this impossible?  Thanks for any inputs.
-- 
John Hasselkus
johnh@tt.com
From: vander@flab.fujitsu.co.jp (Mike van der Velden)
Newsgroups: comp.lang.c++
Subject: Invoking template base ctor
Date: 6 Nov 92 02:56:33 GMT
Organization: Fujitsu Laboratories Ltd., Kawasaki, Japan


I'm using g++ (2.2.2?) on a Sun Sparc S-4/1X.  I have the following
code segment.

    template <class T>
    class B {
    public:
        B () { /*  */ }
    };


    class D : public B<D> {
    public:
        D() : () {}     // compiles fine
        D() : B() {}    // error:  class `D' does not have any field named `B'
    };


I always used the second method of invoking the base class
constructor, but the compiler complained about it.  I was at wits end
until I noticed that the ARM uses the first method in one of its
examples in the section about templates (sorry, I left the book at
home this morning, so I don't know the exact page number).  This
works, even though the ARM also states that the first method is the
"old" way of calling a base class constructor.

Note that if class B is a regular class, and not a template, then
either method of invoking the base class constructor works.

Is this correct behaviour (ie. since the ARM does it...) or a known
deficiency in the g++ compiler?  How can I achieve multiple
inheritance in this case?

Our AT&T compiler (version 2.1) doesn't even handle templates, so
switching compilers at this point is not really an option...
 
--

-- 
Mike van der Velden             
s-mail: Distributed Systems Laboratory, Fujitsu Laboratories Ltd.
        1015, Kamikodanaka Nakahara-ku, Kawasaki 211, Japan
e-mail: vander@flab.fujitsu.co.jp
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Debugging output
Date: 6 Nov 92 18:05:07 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

pjl@cs.uiuc.edu (Paul Lucas) writes:
: 
: >In <spuler.720931050@coral> spuler@coral.cs.jcu.edu.au (David Spuler) writes:
: >>I was wondering whether anyone has any suggestions as to how to use the neat
: >	#ifdef DEBUG
: >	#	define	CDEBUG	if ( debug ) cerr
: >	#else
: >	#	define	CDEBUG	//
: >	#endif
[...]
: >	CDEBUG << "here\n";
: 
: >	This allows the flexibility of having debugging "togglable"
: >	during development, presumeably by a command-line option, but
: >	can be compiled-out in the final version.

I much prefer saying

DEBUG( cerr << "here\n" );

Much easier to see what is going on (IMHO), and useful for other things
than printouts.

#ifndef NDEBUG
#  define DEBUG(expr) if ( debug ) (expr)
#else
#  define DEBUG(expr) (0)
#endif

Note that DEBUG code is generated per default.  Reversing that is trivial.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------