HDTenEightyP/NetNews huggingface dataset:
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Give me safe C++
Date: 23 Dec 92 01:51:18 GMT
Article-I.D.: arolla.TMB.92Dec22175118
	<716@ulogic.UUCP> <1992Dec20.010907.10429@ucc.su.OZ.AU>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: maxtal@extro.ucc.su.OZ.AU's message of 20 Dec 92 01:09:07 GMT

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

	   Have you lost something here? Yes, indeed, rapid
   prototyping is much more difficult when routines in
   parts of the code that never get called must still be
   called with correct parameters.

I don't think this is true. In the greater scheme of things, garbage
collection, static type checking, an interactive implementation, and
closures are important for rapid prototyping. Having to "call" "code
that never gets called" (I assume you are talking about stubs for
functions that haven't been written yet) with "correct parameters" is
no problem in my experience.

					Thomas.
Newsgroups: comp.lang.c++
From: dag@seldon.control.lth.se (Dag Bruck)
Subject: Re: Special-purpose-heap-managers - refere
Summary: Pool class available for free.
Organization: Department of Automatic Control, Lund, Sweden
Date: Mon, 21 Dec 1992 16:01:29 GMT


You can have our "Pool" class for free, if you want.  I would be
grateful if you (1) report any bugs, (2) acknowledge the original
author.  It has worked fine in our application, but I cannot guarantee
that the code is correct or portable; it compiles with AT&T 3.0 on a
Sun workstation, at least.

The code is available by anonymous FTP from "control.lth.se", internet
number 130.235.96.4.  The file is pub/c++/pool.shar.

Comments are gratefully accepted.

Dag Bruck
--
Department of Automatic Control		E-mail: dag@control.lth.se
Lund Institute of Technology
P. O. Box 118				Phone:	+46 46-104287
S-221 00 Lund, SWEDEN			Fax:    +46 46-138118
Newsgroups: comp.lang.c++
From: drraymon@watdragon.uwaterloo.ca (Darrell Raymond)
Subject: Delegation? Composition? Layering? Containment?
Organization: University of Waterloo
Date: Mon, 28 Dec 1992 22:33:40 GMT

  One sometimes includes an instance of a class within a class, thus
achieving information hiding without inheritance.   That is, instead
of doing:

class foo : public bar { ....  }

  one would do

class foo { bar  x; ...  }

  My question is, what do people generally call the second technique?
I have seen it described as `layering' (Meyers, Effective C++, p. 142),
`composition' (Lippman, p. 415), `containment' (Stroustrup, p. 410),
and I believe Gorlen et al. even refer to this as `delegation', which
is what I used to call it.  I don't think it is delegation, however,
since it does not confer the ability to redirect messages to an
arbitrary object.

  Do people have a preference for one of the other terms?  I'll moderate 
an e-mail vote and post the results, if anyone cares...

-Darrell.
Newsgroups: comp.lang.c++
From: pauljo@microsoft.com (Paul Johns)
Subject: Re: Make a deep copy!
Date: 23 Dec 92 21:02:24 GMT
Organization: Microsoft Corp.
Distribution: usa

Specifically, you need a copy constructor which
copies the data pointed to by the pointer in the
object.  (You should copy both the actual data
and the array of pointers--I think you missed
copying the array of pointers in your assignment
operator.)

Also, read a good C++ text for other pointers.
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Any inheritance experts out there
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Mon, 21 Dec 1992 17:49:33 +0000

In article <4019@hpwala.wal.hp.com> friedman@hp-and.an.hp.com (joel friedman) writes:
> I am writing device drivers for external memory devices. I currently
> have to support two types devices (say A and B), but that number could
> grow. The functions each device must support are common, but the
> implementations used to provide them are quite different for each. The
> type T below can be a char xor a short. The following template class
> defines these core functions: 
[ Template omitted. Oh, and do you think you could word-wrap your postings ?
It makes them a lot easier to deal with. ]

> I want to design the hierarchy so I can easily add device C, D, E etc.
> Here's the catch. How can I do this so that the application programs only
> need to see the core_function class declaration; not the derived class
> declarations for A or B. I need to enhance the core_functions class so
> that the user can call a core_functions function, and it will be directed
> to the implementation in the proper derived class (A or B). 

To start with, have a base class called something sensible and 
understandable, like maybe "Device". Make the core functionality virtual. 
Derive A, B (and maybe others) from it.

Now, who or what determines the type of device with which the application 
is dealing ? I assume (because you don't want the application to know 
about device types) that you have some function in your library which 
determines the actual type of device which is connected, and the 
application calls this. So, make the function retern a reference to a 
Device. The function itself constructs an A, B (or C ...) and returns a 
reference to it. The application continues to treat the returned Device 
reference as a Device reference. It does not need to know what kind of
device it is - it just calls virtual functions for the Device, and 
everything works.

Example :

Device &determineWhatKindOfMouseWeHaveAndReturnAReferenceToIt() // :-)
{
	if(wierdAndWonderfulIoctlCall(ISTHISASERIALMOUSE))
		return *new SerialMouse;
	if(anotherStrangeHardwareCall(ISTHISABUSMOUSE))
		return *new BusMouse;
	return *new NotVeryUsefulKeyboardDeviceThatEmulatesAMouse;
}

-- 
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Questions about iostream. Please help!
Organization: Rational
Date: Tue, 22 Dec 1992 16:47:01 GMT

ren@miles.mps.ohio-state.edu (Liming Ren) writes:

|The following program was posted in this group (not by me) a while ago. 

|#include    <iostream.h>
|#include    <strstream.h>
|#include    <fstream.h>
|int main( int argc, char ** argv )
|{
|    istream * is;
|    if( argc == 2 ){
|        is = new ifstream( argv[ 1 ] );
|    }else{
|        is = &cin;
|    }
|    while( *is ){
|        ostrstream out_str;
|        is->get( *out_str.rdbuf( ));
|        is->ignore( 1, '\n' );
|        cout <<out_str.rdbuf( )<< endl;
|    }

|    if( argc == 2 ){    // Delete the object created. 
|        delete is;
|    }
|    return 0;
|}


|After I study it, I have two questions:

|(1) If I use it as : a.out file1>file2, diff tells me there is an
|extra newline added to file2 at the end of file. I don't see how this
|can happen. How to correct it?

I think that there is one extra loop happening at the end.  The 'get'
on the last line terminates before the line-end.  The ignore gobbles
the line end, but the EOF has not been reached.  The loop continues
because EOF has not been reached.  The next get extracts nothing
because it hits the EOF.  The ignore finds no line-end.  But the cout
puts one out anyway.  

|(1) About the main while loop. It is my understanding that *is is a
|class instance of istream with the following picyure:

|	______	         _____________________
|	| is |---------->|                   |
|	------           |                   |
|	                 | istream           |
|	                 |___________________|

|How (*is) can be zero and how it is set to zero? Does this mean that
|the class instance is zero? I am comfused here.

*is points to an istream.  An istream is a derivative of class ios.
ios declares operator void*().  Thus a "user-defined" conversion takes
place whenever an ios object appears in a conditional syntax.  The ios
is converted to a void*.  The void* will be zero if the failbit or
badbit of the ios is set.  Otherwise the void* will be non-zero.

Thus you can do cute things like:

while (cin) {...}

which will loop until cin complains about something, typically EOF.




--
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++
Newsgroups: comp.lang.c++
From: hansen@myria.cs.umn.edu (David Hansen)
Subject: Re: Can't I initialize a dynamically allocated object in its constructor
Organization: University of Minnesota
Date: Sun, 27 Dec 1992 20:02:09 GMT

In article <1992Dec22.114251.6663@nuscc.nus.sg>, suresh@papaya.iss.nus.sg (Suresh Thennarangam - Research Scholar) writes:
[... most of included code deleted ...]
|> > 
|> > Vector Vector::operator+ (Vector& a){
|> >    if (getsize() != a.getsize()){
|> >       printf("operator '+':Vectors are not of the same size.\n");
|> >       exit(0);
|> >    }
|> >    Vector retVect(getsize()) ;
|> >    for (int i = 0 ; i < a.getsize() ; i++){
|> >       retVect.item[i] = item[i] + a.item[i] ;
|> >    }
|> >    return retVect ;
|> > }
|> > 
|> My apologies for including  the entire code above ....
|> Also to make things easier I have moved the function  
|> Vector Vector::operator+() to the bottom.
|> 
|> My point:
|> 
|> retVect used above is a automatic variable that will go out of scope
|> as soon as the function Vector::operator+() is exited and it's 
|> destructor will be called which will deallocate the memory
|> that was allocated by the constructor. Although the returned
|> Vector object is a copy and will have a valid item pointer, it will 
|> be pointing to deallocated data.

Ummm, I don't think so.  True, retVect is automatic and will be destroyed when
it leaves scope.  However, at least on _my_ system (CenterLine ObjectCenter),
the copy constructor is called _before_ retVect is destroyed.  The copy is
valid.  I would hope this is the way it is supposed to work...

What you describe is the problem that existed _before_ the copy constructor
was added.  Since none was defined, the compiler generated one which simply
performed a memberwise initialization of the copy.  Since one of the members
is a pointer to some memory which is then deallocated before the copy is used,
we have the classic "dangling pointer."  The copy constructor allocates its
own memory for the pointer, which is then freed when the temporary is destroyed.

Or is there something else I'm missing?

					-=Dave
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: where the name C++ came from
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 28 Dec 1992 02:06:14 GMT

In article <1992Dec23.162758.10645@eagle.lerc.nasa.gov> tostan@dumbo.lerc.nasa.gov (Stan Mohler) writes:
>Hi-
>I had a dream last night in which I figured out a possible reason for C++
>having the name C++.  Yesterday I was reading about C and C++.  I skimmed
>across a few lines showing the use of operators such as ++.  i++ measns to
>increment variable i.  Incrementing something means to increase it, expand it
>if you will.  Is it possible that "C++" simply means an "expanded C" in the
>most economical and cute way a C programmer might think of?
>
	I had a different dream when i first read the ARM.
I saw that by using multiple inheritance with abstract virtual
bases I could for the first time do 'incremental' programming.
(The technique is generally called mixin).

Sadly, my compiler vendor has disappointed me by stuffing up this
feature, which IMHO is Bjarne's greatest achievement.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: Simulate "Pointer to char" by an array
Date: 31 Dec 92 18:58:58 GMT
Organization: negligable

In article <1992Dec30.172241.11378@dcs.warwick.ac.uk> cmchan@dcs.warwick.ac.uk (C M Chan) writes:
>
>Hi out there,
> 
>I am sorry if this is faq for this newsgroup.   Here is my question:
> 
>How can I simulate "pointer to char" by an array in a class whose size will be \
>delayed to be
>defined at run time?
> 
>For example,
> 
> 
>     class X {
> 
>     private:
>             char string[      ];    /* not define size of the array */
>                              ^^^^^^^^
>     public:
>             X(int);
> 
>             ...............
>     };
> 
> 
>     X::X(int size) {
>             string[size];          /*  define size of string array now  */
>             strcpy(string, "Hello");
>     }
> 
>Any pointer to this problem will be greatly appreciated.   Thanks in advance.
>
>
>
>-- 
>C M CHAN         cmchan@dcs.warwick.ac.uk


Why? what is wrong with:

     class X {
 
     private:
			 char *string;

     public:
             X(int);
 
             ...............
     };
 
 
     X::X(int size) {
             string = new char[size];  /*  define size of string array now  */
             strcpy(string, "Hello");
     }


Am I missing something about your requirements?


btw: I apologize if this is posted twice - I did one w/ 
a "malloc(size)" instead of new (oops! my C is showing!)
but it didn't show up on the reader here, so I didn't
cancel it....


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Philosopher and plowman			|
each must know his part			|	-Richard Hartman	
to build a new mentality		|	hartman@uLogic.COM
closer to the heart!			|
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Newsgroups: comp.lang.c++
Subject: <None>
Date: 23 Dec 92 13:00:45 GMT
Organization: University of Birmingham
Distribution: world
NNTP-Posting-Host: vax1.bham.ac.uk

In article <GIROD.92Dec23081920@node_262d6.tele.nokia.fi>, girod@tele.nokia.fi (Marc Girod) writes:
> 
> Are my compilers correct in refusing me the access to private
> constructors, to build a private static member?

I think answered your own question. The answer is currently yes.

> 
> Sorry if this has already been dealt with...
> 
It has and I think this matter is currently being considered by the ANSI
people with a mind to changing it.

> ...And incidentally, Merry Christmas!
And a Merry Christmas to you too.
-- 
    \\   ( )    No Bullshit!     |  Email: B.A.McCauley@bham.ac.uk   
 .  _\\__[oo        from         |  Voice: +44 21 471 3789 (home)
.__/  \\ /\@    /~)  /~[   /\/[  |    Fax: +44 21 625 2175 (work)
.  l___\\      /~~) /~~[  /   [  |  Snail: 197 Harborne Lane,
 # ll  l\\    ~~~~ ~   ~ ~    ~  |         Birmingham, B29 6SS, UK
###LL  LL\\   (Brian McCauley)   |   ICBM: 52.5N 1.9W
From: sundvall@perrier.embnet.se (Mats Sundvall)
Newsgroups: comp.lang.c++
Subject: Help! SUN C++3.0 core dumps
Date: 22 Dec 1992 13:22:47 GMT
Organization: EMBNet Project Sweden
Distribution: world
Reply-To: sundvall@perrier.embnet.se
NNTP-Posting-Host: perrier.embnet.se
Keywords: C++ Solaris SUN

I have problems with Sun C++ 3.0. ptlink repetadly core dumps when processing
template containg code. I have talked to Sun Sweden but they don't know anything
about it. There is a workaround. Just compile again, and again and again again...
The link simulation phase is not very fast with the new compiler and having to go
through it six or seven times to get the code compiled does not make you happy.
But at last you get the beast compiled.

Am I the only one who has this problem. It is so obvious so one may wonder how
it ever got into a production release. 

Regards,

Mats Sundvall
Dept Medical Genetics
Uppsala University
Sweden

sundvall@perrier.embnet.se



Newsgroups: comp.lang.c++
From: mcgrant@gomez.stanford.edu (Michael C. Grant)
Subject: Re: template disappointments ... (suggestions?
Organization: Information Systems Laboratory, Stanford University
Date: 29 Dec 92 19:12:50


In article <1992Dec29.204431.13413@nrao.edu>
cflatter@nrao.edu (Chris Flatters) writes:
   In article 92Dec29133556@muse.cv.nrao.edu,
   dschieb@muse.cv.nrao.edu (Darrell Schiebel) writes:
   >	(1) The inability to derive templated classes from a non-templated 
   >	    base class of the same name:
   >		class typeinfo {};
   >		template<class t> class typeinfo : public typeinfo {};
Yeah, that's a bummer. I see no reason why typeinfo and typeinfo<T>
can't be distinguished by any reasonable compiler.

   This is according to the ARM:

           A class template name must be unique in the program and may not
           be declared to refer to any other template, class, function,
           object, value, or type in the same scope.
                                                           [p343]
What's yer point? That's why this is called 'template disappointments.'

Here are mine, both of which I've mentioned before, but nobody has managed
to convince me it can be simulated in the current language.

(1) Templated member functions. Someone gave me some lame argument that
    since you can specialize any templated function you can break into
    the private structure of a class, but since there are so many easy
    ways to do that already I don't accept that argument.
(2) A compile-type typeof() operator like GNU's that can be used in
    templates.

    For example:

    double abs(double);
    double abs(const complex&);

    template <class T> foo {
       T data;
       typeof(abs(T)) norm;
       ...
    }
 
    I suppose I wouldn't mind faking it like this if necessary
    (and, of course, if it's possible).

    template <class T> typedef T normType<T>;
    typedef double normType<complex>;

    template <class T> foo {
        T data;
        normType<T> norm;
       ...
    }
 
    But this is hardly elegant! The typeof() operator would be nicer.

Michael C. Grant

--
"Long hair, short hair--what's the difference once the head's blowed off?" (?)
Newsgroups: comp.lang.c++
From: dwr@cci632.cci.com (Donald W. Rouse II)
Subject: Re: Can't I initialize a dynamically allocated object in its constructor?
Organization: [Computer Consoles, Inc., Rochester, NY
Date: Tue, 22 Dec 1992 19:14:46 GMT

In article <1992Dec17.205113.1180@IRO.UMontreal.CA> laviers@IRO.UMontreal.CA (Cocotte Minute) writes:
>Hello,
>
>I have the following problem.
>
[ problem deleted ]

My off-the-top-of-my-head guess is that your problem is caused
by lack of a copy constructor.
When operator+ returns, the compiler probably invokes
a copy constructor to return the value of the operation.
Since you have not defined one, it creates a default copy
constructor which just copies item and size, but does not
allocate memory for *item, nor does it copy anything.
Now, the returned value.item and retVect.item point to the
same memory, so when retVect gets destructed, the array
gets returned to the heap.  Now (v1+v2).item points to free space.
Next, operator+ is called again.  When retVect is constructed,
it gets memory from the heap, which just happens to be the
memory that was previously freed.  If you do not initialize
the array, it retains its old values, and everything looks great.
(It isn't great, though; it just looks that way.)
If you do initialize, then of course the old values get scrogged.

All of this is speculation on my part, except for that fact that
you should define your own copy constructor:

Vector::Vector(Vector& v) { 
   item = new double[v.size] ; 
   size = v.size ;
   printf("copy constructing\n");
   for(int i=0;i<size;i++)item[i]=v.item[i];
}

Hope this helps.

PS.  IMO, compilers should warn about this type of thing.
I understand that g++ detects T operator=(T&) with no T(T&).
Kudos to them.  All compilers should do this.
It would also be nice if all compilers warned about
creating default copy constructors when other constructors
use "new".  Every little bit helps.
Newsgroups: comp.lang.c++
Subject: Help
From: cs283042@eeyore.stcloud.msus.edu (James Bond)
Date: 30 Dec 92 14:49:35 -0600
Distribution: World
Organization: St. Cloud State Univ., MN

      I was wondering if someone could point me in the direction
   of a decent book on c++. I would really like the help. Thanks.

 
                                          Jim B.
From: darcys@fraser.sfu.ca (Darcy Smith)
Newsgroups: comp.lang.c++
Subject: Re: Newbie Wants Advice on C-Programming
Date: 3 Jan 93 18:57:52 GMT
Organization: Simon Fraser University, Burnaby, B.C., Canada

Sorry that last one kinda got lost - it relly ment to goto comp.lang.c

Sorry D'Arcy
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: >>>>>>>>  Is it possible to use 'delete this' ?
Date: 31 Dec 92 00:46:54 GMT
Organization: negligable

In article <ssimmons.725636801@convex.convex.com> ssimmons@convex.com (Steve Simmons) writes:
>On page 66 of the ARM, there is an example of why you would want the 
>"delete this" capability.  Therefore, it is probably legal.  However, 
>the standard does also say that you must be careful not to delete 
>a pointer that is not allocated by new.  The resulting behavior is 
>undefined (maybe nothing or maybe core dump). 


Is it possible, within the definition of a class, to ensure that
the object may only be successfully created by "new" and not
by a simple declaration?

e.g.

	Object *p = new Object;		// ok
	Object O;					// fails


It would be nice if we could make a constructor such that
the second declaration gets flagged as an error, but out
of curiosity -- even if that is not possible is it possible
to create a class that at least generates a run time error
if you try to create one non-dymically?


		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Fosters!  It's Australian for beer, mate!"

Newsgroups: comp.lang.c++