HDTenEightyP/NetNews huggingface dataset:
From: ssimmons@convex.com (Steve Simmons)
Newsgroups: comp.lang.c++
Subject: >>>> Is C++ "for the rest of us" ?
Date: 17 Aug 92 13:45:01 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

> 
> I have been talking to managers who are very nervous about
> moving to C++.  It seems to have a reputation for being
> difficult to master, and those of us who program in C++
> are sometimes considered Gurus.
>

Yes, we are so smart.... ;-)

> What guidelines would you give to a manager who is trying
> to decide whether to use C++ for an new project?  

Understand that there is a learning curve.  It takes time 
for people to change to a new programming environment.  
Start small... Use other people's work like the NIH library.
Having learning groups... Openly discussed good and bad 
style without any EGOs. Seriously, C++ is not hard but it can 
be disastrous if you have bad personalities on the team. 

Within 3-6 months, your programmers will probably be experts
at the language. However, build 3 months into the schedule 
for learning.  Give each developer a small task. Have them 
code a class object. Then, review each line of code without
proving the programmer wrong.  Just suggestions.... 

>
> Would you suggest that a team with average programmers 
> move to C++ ?
>

It is not brains but attitude.  If your programmers don't
like change then don't expect them to learn it without a 
fight.  It is a matter of your programmers wanting to learn
both the syntax of a new language and a new paradigm in 
coding. 

>
> Should a programming team attempt a C++ project if they do
> not have any C++ gurus to fall back on?
>

Yes.... At worst, you will make mistakes... expect it.... 
If you keep the code modular/object oriented, you will only 
need rewrite that one section. Again, start slow... Talk \
regularly about coding/design issues. 

Thank you. 

				Steve Simmons
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Handling of operator . pro
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 12 Aug 1992 14:51:48 GMT

In article <713558730snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
>
>In article <1992Aug9.205839.9139@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>[My summary]
>He said in a previous article - casts should be banned. Except for casts 
>to and from voids (because you need them for foreign interfaces).
>
>I said some casts were necessary.
>
>He kindly explained that the "casts" I said were necessary were in fact
>"conversions", not casts at all.
>
>My conclusion - yes, I would love a compiler where all casts produced 
>messages from the compiler (but conversions did not).

	Actually, one might want some conversions flagged too,
especially the implicit ones, and especially the 'demotions'.

	Although some have flamed PL/1, it made up for its
complexity in some ways by an superb reporting system. It 
could report almost anything, up to 10 reports including
complete cross-reference maps, details of all conversions,
expansion of factored types, etc. Used lots of trees though.

	Ever wondered *which* overloaded function got
called?
>
>I doubt that making such messages errors, rather than warnings, would ever
>be possible - it would break too much existing (bad ?) code.

	How about a 'severe warning' then :-)
>---
>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
>trmphrst.demon.co.uk is NOT connected with ANY other sites at demon.co.uk.
>Demon.co.uk is a dial-up subscription access point to the Internet.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: coates@newton.physics.uq.oz.au (Tony Coates)
Newsgroups: comp.lang.c++
Subject: Re: class used only once
Date: 20 Aug 92 21:34:01 GMT
Organization: Physics Dept. The University of Queensland

In article <1992Aug20.171413.49157@evolving.com>, dxs@evolving.com (Dan Stanger) writes:
|> i am developing a program containing a set of routines and data
|> where the data would have only one instance of it.  i am interested
|> in comments regarding making it a class vs putting it in a seperate
|> file and only exporting the routines that i need.
|> any comments would be appreciated.
|> thanks, dxs

Clearly, this is an area where declaring creating a class may not seem so necessary or
useful, since using a separate file and exporting routines can still give you a well-defined
interface and data-hiding (to some extent, at least).  I would nominate two advantages of
using a class with just one instance:

(i) *better* data-hiding, though the usefulness of this depends on the (lack of) discipline
    of the programmer

(ii) C++ handles the creation and destruction of objects itself - I have to write a lot of
     programs in C, not C++, and while I use a pseudo-object-oriented style, whenever I have
     data-structures to which I allocate memory at run-time, I have to explicitly call
     creation and destruction routines.  I think that it is cleaner and more reliable to just
     supply these routines and let the compiler decide when best to call them.

									Tony.
_______________________________________________________________________________

A.B.Coates (Tony)
Department of Physics
The University of Queensland  QLD  4072
Australia

Phone: (+617)365 3424           (Physics Departmental Office)
Fax:   (+617)365 1242           (   "         "         "   )
Email: coates@physics.uq.oz.au

"My messages mirror my feelings, but do not reflect University policy."
_______________________________________________________________________________
Newsgroups: comp.lang.c++
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Dumb questions about Borland C++
Organization: Texas Instruments Inc
Date: Mon, 17 Aug 1992 16:46:23 GMT

In <593@lax.lax.pe-nelson.com> twbrown@PE-Nelson.COM (Tom W. Brown) writes:

>In article <1992Aug13.152405.16170@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>|> In article <q!3m8wf.sjk@netcom.com> sjk@netcom.com (Shel Kaphan) writes:
>|> >
>|> >- Is there no memory model on the PC in which the stack can occupy
>|> >more than 64K bytes?  (more wishful thinking, I know ... don't flame me.) 
>|> >Don't ask why I care.
>|> 
>|> 	No. Its only a 16 bit machine. And the 386 still
>|> runs 16 bit operating systems.

>Wait for NT and then wait for Borland to release their compiler support for
>it (better get a deck of cards or something while you're waiting :-)

Or better yet, get OS/2 2.0 (available now) and wait for Borland to
release their compiler support for it (supposed to be by the end of
the year, which I suspect is going to be well before NT is generally
available (and working).

[Or, if you HAVE to have a Microsoft product, buy the 'pre-Beta' of NT
that is available.  Oh, yes.  Also buy a CD-ROM drive and make sure
you have at least 12 MB of memory.]


-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Garbage Collection for C++
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 18 Aug 1992 12:05:19 GMT

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

>Conservative GC with a "free" function is a safety net. If you don't
>run out of storage, you don't know it's even there. If you do run out
>of storage, it lets your program continue to run when it would
>otherwise have crashed. Whether you want to rely on this feature is up
>to you, but, in general, I can see no harm in having it in the
>language...

This presumes that you will only perform garbage collection when there
is *no* more storage available.

In fact that strategy amounts to the "bad old days" of GC, where programs
that used GC were resource hogs, ran slowly, and/or paused for lengthy
periods displaying the dreaded message "Garbage collecting... please wait".
It simply does not work with virtual memory.

It is therefore essential that a GC version of malloc() sometimes perform
garbage collection even though there is still (virtual) memory available.
The question is, how can we do this in a way that does not impact poorly
on the performance of programs that do mostly manual allocation?

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c++,comp.std.c++
From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Re: Object What is an OODBMS?
Organization: netmbx, Berlin, Germany
Date: Thu, 13 Aug 1992 07:34:32 GMT

bevan@cs.man.ac.uk (Stephen J Bevan) writes:

>In article <RCZ5NS@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
>   When we create a new class we frequently want to use code or data 
>   that already exist in another class.  For instance, if we have a class 
>   called LinkedList we might choose to use this when implementing our 
>   stack.  In fact, we might say that a Stack is a LinkedList which also 
>   has the push() and pop() functions.  We can do this directly using a 
>   mechanism called inheritence:

>       class Stack : public LinkedList
>       {
>       public:
>	   void    push(int i);
>	   int    pop();
>       };

>   In this example we would call LinkedList the base class and Stack the 
>   derived class.

>Is this generally considered good use/example of inheritance?
>I don't think a "Stack is a LinkedList" at all, rather a
>LinkedList is a possible implementation of a Stack.  I'd therefore use
>parametric rather than inclusion polymorphism to represent this (i.e.
>use a template in C++ speak).  Is my preference for parametric rather
>than inclusion polymorphism blinding me to some advantage in the
>above?

I think you are right.  I should have used private inheritance above
to hide the linked-list implementation details from the user.  After
all, the user could start using LinkedList methods, which would then
make it impossible for me to change the implementation later without
affecting the user.



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

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

Xref: sparky comp.lang.c++:12557 comp.sys.sequent:508
From: mathur@csgrad.cs.vt.edu (Anup Mathur)
Newsgroups: comp.lang.c++,comp.sys.sequent
Subject: Problem with AT&T C++ on DYNIX
Date: 19 Aug 92 17:11:22 GMT
Followup-To: comp.lang.c++
Distribution: usa
Organization: VPI&SU Computer Science Department, Blacksburg, VA


We are using the AT&T C++ compiler version 2.1, on a sequent
symmetry running DYNIX version 3.2. We are having the following 
problem, whenever we have a user defined function with a name
that is the same as a function defined in libc.a the loader/link editor
comes back and complains about multiple declaration of the said
function.

For example, say i wanted to write my own malloc and wanted to override
the system malloc.

Sometime back when we were using AT&T C++ compiler version 1.2
on the same machine running DYNIX version 3.0.18 everything
was fine i.e we were able to override functions defined in
libc.a.

Any help in fixing the above problem will be appreciated.
Please reply to mathur@cs.vt.edu
Newsgroups: comp.lang.c++
From: vidal@bae.bellcore.com (Vidal Graupera)
Subject: strstream question
Organization: Bellcore
Date: Tue, 18 Aug 92 14:29:28 GMT

I want to change the string in an existing strstream. 
This is what I tried on a Sun using their 2.1 compiler:

  char p[100];
  ostrstream tstream(p, 100);

  // do some stuff with tstream

  char t[100];
  tstream.rdbuf()->setbuf(t,100);

  // tstream still uses p NOT t

Any help much appreciated.

Vidal Graupera
Bellcore

email: vidal@bae.bellcore.com


Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Garbage Collection for C++
Date: 18 Aug 92 01:24:02 GMT
Organization: Microsoft Corporation

In article <1992Aug15.015237.17711@tfs.com> eric@tfs.com (Eric Smith) writes:
|Explicit memory management functions have traditionally favored memory
|economy over speed.  That was because memory was very expensive.  But
|now that memory prices have fallen through the floor, e.g. from $4000
|per megabyte in 1983 to $25 per megabyte in 1992, it no longer makes
|much sense to waste cpu time to save memory.

I disagree.  Today's computer user now uses that extra memory to support
GUI and multiple programs running simultaneously, such that proper maintainence
of the working set remains as large a problems as ever.  If anything, future
needs to query over the entire space of a project, a division, a company, or
the world, makes maintainence of the working set a bigger problem than ever.
|The main advantage of GC is that it simplifies programs and makes them
|easier to maintain.  This is a very substantial advantage, worth
|sacrificing a lot for.  But, if non-GC memory management can obtain
|nearly the same advantage, without the disadvantages of GC, then the
|sacrifices aren't necessary.  

Conversely, if GC'ed memory management can obtain the advantages of non-GC
memory management, without the disadvantages, then sacrifices aren't necessary.

|So, the question would be, how can non-GC
|memory management gain the advantage of simplifying programs and making
|them easier to maintain, to approximately the same extent that GC gains
|that advantage?

On the contrary, the question is why not simply implement modern GC
schemes such as generational scavenging which do not require a sacrifice?

|One answer would be that modern programming languages, using OOP and
|genericity, make complexity so much easier to manage that the complexity
|of non-GC memory management is no longer anywhere near as big a problem
|as it was with older languages.  OOP and genericity have almost unlimited
|potential to simplify complex software, to the point where the additional
|simplification provided by GC might become superfluous.

On the contrary, OOP and genericity have almost unlimited potential to 
simplify complex software, to the point where C++ programmers now spend
almost all their time tracking down pointer bugs.
Newsgroups: comp.lang.c++
Subject: Help : Extended and Expanded Memory
From: ebolog@elaine.ee.und.ac.za (EDWIN BOLOGNA : THIRD)
Date: 20 Aug 92 13:03:52 +0200
Organization: Electronic Eng., Univ. Natal, Durban, South Africa


Does anyone out there happen to have PAS, C, or ASM source code that is
able to access Extended or Expanded memory. This computer has got Three Mbytes
Extended memory and I am unable to use any of it in my programs.

Any information at all on this will be greatly appreciated.

        Desperate fellow programmer (And very Greatful for any information)

                E.B. (EBOLOG@ELAINE.EE.UND.AC.ZA)

PS : Please be kind hearted and Assist !
From: rose@tmipi5.telematik.informatik.uni-karlsruhe.de (Ortwin Rose)
Newsgroups: comp.lang.c++
Subject: Re: using (...) question
Date: 17 Aug 92 08:25:50
Organization: /usr/users/rose/.organization
NNTP-Posting-Host: tmipi5.telematik.informatik.uni-karlsruhe.de
In-reply-to: cyberman@toz.buffalo.ny.us's message of 15 Aug 92 23:28:42 GMT


I suggest you use the method defined in <stdarg.h>, if you know the
first parameter that is passed to your function (as in printf(char *, ...)).
Also possible is using <varargs.h>, however, it will fail on some machines
(such as MIPS-based RISCs) under certain circumstances. Compare also the
ARM, p. 146 where the usage of a variable number of arguments is explained
in detail. Here is a short example how to use the stuff declared there:

void dummy (char* form, ...)
{
  va_list ap;                   // must declare this to access params

  va_start(ap, form);           // and initialize it (using the last NAMED argument
                                // in the argument list. Now 'ap' points to the first
                                // of the unnamed parameters.

  <type> va_arg(ap, <type>);    // <type> is the type of the next argument
                                // in the argument list, and va_arg() will
                                // return a value of type <type> from the
                                // argument list and will modify 'ap' to point
                                // to the next argument. Repeated use of va_arg()
                                // will give you all the unnamed arguments.

  va_end(ap);                   // MUST call it to clean up
}


Regards

-- O. Rose
   University of Karlsruhe
   Institute of Telematics
Newsgroups: comp.lang.c++
From: mittle@watson.ibm.com (Josh Mittleman)
Subject: Re: Return value for the constructors.
Date: Tue, 18 Aug 1992 21:02:09 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center


In article <3462@unisql.UUCP>, nandraj@unisql.UUCP (Nandraj Arni) writes:
> 
>    Why does C++ not let you have a return value for a constructor?
> Is there any rationale behind this?

Before we answer that question, we should ask what do you want it for?  A
language can't provide every conceivable feature; unless a feature is a
significant improvement to the language, it is an unnecessary complication.


===========================================================================
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: jimad@microsoft.com (Jim Adcock)
Subject: Re: destruction of temporaries
Date: 17 Aug 92 23:39:23 GMT
Organization: Microsoft Corporation

In article <46140@sunquest.UUCP> bill@sunquest.UUCP (Bill Raves) writes:
|For example, Jim Adcock has suggested
|(<70784@microsoft.UUCP>) "NEVER rely on unnamed temporaries to do
|anything...", but this would seem to erode the expressiveness of the
|language: constructs like "foo(x + y)" and "foo()[i]" would no longer
|be permissible. 

When an unnamed temporary is assigned to a reference, then the unnamed
temporary is no longer unnamed.  I believe this should mean that the lifetime
of the temporary then becomes that of the reference, but its easy to find
lots of compilers that disagree with this.

The bottom line is, if you DO rely on unnamed temporaries to do anything,
you WILL be disappointed in the code generated by one or more compilers.

Some years after the ansi committee decides on the life times of temporaries,
what it means to give a name to a previously unnamed temporary [by assigning
it to a reference] whether functions return by copy or by value, when compilers
can create temporaries, and when compilers can leave them out, and how many
of these temporaries are created or not, what sequences points are and where
they exist, what "const" means, and what "volatile" means....

.... when the committee decides on these things, if ever, and then some
years later when C++ compiler reliably implement the standard, THEN and only
then can you, in practice, rely on the behavior of temporaries.  UNTIL THEN, 
good luck.

Today, if you want to write portable code, rely on named temporaries.
From: iwelch@agsm.ucla.edu (Ivo Welch)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 13 Aug 92 17:28:09 GMT
Organization: UCLA, Anderson Graduate School Of Management


I appreciate all proposals for a GC. As a plain user, not a language designer,
I believe a good and optional GC would induce many more people to  switch from
C/Fortran to C++.

Most of all, I hope that someone with the proper  expertise will [1] implement
a minimal GC in Gnu g++, and [2] approach  the ANSI standards committee with a
GC proposal.

/ivo welch
Newsgroups: comp.lang.c++
From: c0365384@techst02.technion.ac.il (Esteban D. Schnir)
Subject: There is a patch for BC++ 3.1 ?
Organization: Technion, Israel Institute of Technology
Date: Sun, 16 Aug 1992 21:34:12 GMT

There is any patch for BC++ 3.1, I think I have saw something in
this group about it. If somebody know something about it, please
mail me.


-- 
Esteban D. Schnir                                        eetlo28@Technion.Bitnet
Department of Computer Engineering              c0365384@TechSt02.Technion.Ac.Il
Technion - Israel Institute of Technology            bs778@Cleveland.Freenet.Edu
Tel.:+(972)-(4)-294538   Fax.:+(972)-(4)-223854            eschnir@Nyx.Cs.Du.Edu
From: pchi@zorch.SF-Bay.ORG (Eric Chi)
Newsgroups: comp.lang.c++
Subject: A template question
Keywords: template, BC++ 3.1
Date: 19 Aug 92 09:18:47 GMT
Distribution: usa
Organization: SF-Bay Public-Access Unix

Hi, I am using Borland C++ 3.1 implementing 2 classes: vector and matrix.
I have the Vector class defined as a template:

	template <class Type>
	class Vector
	{
	public:
		Vector( int dim);
	...
	};

Now I tried to define the matrix by utilizing the vector:

	template <class Type>
	class Matrix: public Vector< Vector< Type>>
	{
	....
	};

Is this a correct way? Borland C++ seems do not understand the syntax.

Eric.
Newsgroups: comp.lang.c++