HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: IS C++ a language for the "average programmer"
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 15 Dec 1992 13:33:17 GMT

In article <1992Dec12.234407.15044@ennews.eas.asu.edu> gopi@enuxha.eas.asu.edu (Bulusu Gopi Kumar) writes:
>
>I have been following a lot of articles on this group for sometime now.
>There seems to be a lot of confusion on a large number of topics in c++
>among the programmers! Is this because of the fact that c++ is a relatively
>new language ? 

	Partly, yes. Partly because there is no standard, and there are
'holes' and imprecise wordings in the definitive reference, the ARM.

	Partly because there is a lot of disagreement about OO,
what it means, how to use it. And C++ does not purport to be
an exclusively OO language anyhow, many say it is not OO at all,
and some say it is class based which is quite different.

	It is certainly a different language than Smalltalk,
CLOS/LISP/FLAVOURS or other OO languages, resemling Simula
and Eiffel more than these.

	C++ can be use for procedural programming, functional
programming, OO/class based programming ... its a hybrid.

>Is it because c++ is becoming more and more complex by the
>addition of features like "TEMPLATES". 

	Partly, yes. But partly because with experience some of
the more subtle points come up.

	Partly the complexity derives from C compatibility too.

>Infact even after 2 years of reading
>and reading (though without much of project experience) I often get confused
>with some combinations of c++ features.

	Me too. Also most members of the committee would agree,
probably Bjarne does too sometimes :-)

>Is it that "complex" projects can be
>handled by only complex languages ? Any takers for this question ? 

	It depends what type of complexity. A simple language
can support complex algorithms. But there are many other issues
in the real world, like compatibility with existing code,
existing data, and existing programmers, not not mention
actual machines, operating systems and compilers...

	C++ does not mandate a single style because it is 
general purpose and not enough is known to design a simple
genral purpose language. Instead it provides a variety of
features and leaves it up to the programmer to sort out
the best techniques for particular problems.
>
>There used to be a language called PL/1 . . .
>

	And it was a pleasure to use compared with COBOL
or FORTRAN. And perhaps not as complex as C++ at that.

	Compare the idealised Eiffel described in
'Object Oriented Software COnstruction' by Meyer,
with the real world version 3 of the language.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: steve@taumet.com (Steve Clamage)
Subject: Re: Initialization {} of Aggregates with Static Members
Organization: TauMetric Corporation
Date: Tue, 15 Dec 1992 17:43:30 GMT

jdp@polstra.uucp (John Polstra) writes:

|I'd like some opinions on something that the ARM doesn't seem to address
|directly:

|    struct X {
|	int a;
|	static int b;
|	int c;
|    };

|    X foo = { 1, 3 };

>I believe that this is legal, and that foo.a and foo.c should get
>the values 1 and 3, respectively.  Static member b should remain
>uninitialized by the code shown here; it would have to be defined
>exactly once elsewhere in the program.

That is correct.  The ARM is not clear on this point, but there is
no question about what was intended.  At the last C++ Committee
meeting (November 1992, Boston) we voted in a clarification of
the wording on this subject.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Operator "new" - how to catch array-allocation?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 20 Dec 1992 12:25:27 GMT

In article <1992Dec17.131239.8036@daimi.aau.dk> sabroe@daimi.aau.dk (Morten Sabroe Mortensen) writes:
>The reason I raised this in the first place is, I'm about to build my own
>special-purpose-heap-manager, -the way I would like it to work, is to attach
>"something" to a given class, and then the result should be, that all dynamic
>allocation involving that class should be managed - the way you allocate
>should be independent of how heap-management is controlled - controlled by
>the normal general-purpose manager or a special-purpose manager!
>As I see it, -now-, I can't get this independency - except when allocating 
>single instances of the used class! Right?
>

	It is not currently possible to overload operator new[],
if only because there is no such operator. There is a proposal
before the committee to allow this, and I dont believe there are any
in-principle objections to it. 


-- 
;----------------------------------------------------------------------
        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: jimad@microsoft.com (Jim Adcock)
Subject: Re: static members in derived classes
Date: 16 Dec 92 19:21:47 GMT
Organization: Microsoft Corporation

In article <1992Dec15.150612.28264@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
|I don't see how it follows that allowing "virtual static" data dictates
|a particular implementation. 

If you are not presuming a particular implementation of virtual statics,
consider then an implementation that implements them in a manner as-if similar
to the following:

#include <stdio.h>

class A
{
	static int _a;
public:
	int& s;
protected:
	A(int& aa) : s(aa) {}
public:
	A() : s(_a) {}
};
int A::_a = 1;

class B : public A
{
	static int _b;
public:
	B() : A(_b) {}
};
int B::_b = 2;

main()
{
	A a;
	B b;

	printf("a.s = %d, b.s = %d\n", a.s, b.s);

	return 0;
}

======

But, this particular implementation is *already* available to you,
and far from hard to program.
Newsgroups: comp.lang.c++
From: pete@borland.com (Pete Becker)
Subject: Re: Overriding the order of constructors?
Originator: pete@genghis.borland.com
Keywords: constructor ordering
Organization: Borland International
Date: Mon, 14 Dec 1992 18:18:23 GMT

In article <robison1.724307343@husc10> robison1@husc10.harvard.edu (Keith Robison) writes:
>dembo@csri.toronto.edu (Prof. Ron Dembo) writes:
>
>
>
>>What is the rational for not allowing a programmer to override the
>>default calling order of constructors and initializers?  I see
>>the importance of having a well defined default.  However, why
>>shouldn't the ordering of the initilizers be significant?  
>
>
>	I believe you can effectively accomplish this dangerous
>goal by calling virtual functions in your constructors:
>
>
>class A {
>  A() { reroute(); do_A_ctor_stuff(); }
>  virtual void reroute(); { }
>}
>
>class B : public A {
>  B() {}
>  void reroute ()  { do_B_ctor_stuff(); }
>}
>
>
>This will cause B's reroute() to be executed before any 
>A constructing has occurred.
>

	This won't work.  Virtual functions are effectively non-virtual when
called from a constructor or a destructor.  If they weren't, you could call
a member function on an uninitialized object.
Newsgroups: comp.lang.c++
From: krc@wam.umd.edu (Kevin R. Coombes)
Subject: Re: Static vars in member functions
Organization: University of Maryland, College Park
Date: Wed, 16 Dec 1992 18:26:06 GMT

In article <1992Dec13.185540.20212@math.ufl.edu> X9999BVJ@oak.circa.ufl.edu writes:
>
>When calling a function of a class with a static variable declared in it,
>what is the standardized behaviour for that variable?
>
>E.g.
>
>class Foo
>{
>   public:
>      void Blah( void );
>};
>
>void Foo::Blah( void )
>{
>static int i;
>
>   i++;
>};
>
>void main( void )
>{
>Foo a, b;
>
>   a.Blah();
>   b.Blah();
>   a.Blah();
>}
>
>When the second "a.Blah()" is executed, will i be 2 or 3?
>
>Brian

The question is ambiguous, since the value will be 2 when the function is 
entered, and will be 3 when it exits. (Since this is not comp.std.c++,
I did not look for chapter-and-verse in the ARM to support my claim. I
did enter the code into g++ and looked at the result.) The point is that
member functions belong to the class, and not to the object. Since there
is only one version of the function, there is only one version of its
static int i. 

Kevin Coombes <krc@math.umd.edu>
Newsgroups: comp.lang.c++
From: gchopra@cs.iastate.edu (Gagan Chopra)
Subject: equivalent of getchar().
Organization: Iowa State University, Ames IA
Date: Mon, 14 Dec 1992 16:08:21 GMT

Can anyone suggest a function equivalent to the getchar in C. I would like
to be able to read a character from the keyboard unbuffered ( without pressing
the return key.
Thanks in advance.
						Gagan.

Newsgroups: comp.lang.c++
From: stevep@ims.com (Steve Poulsen)
Subject: Re: Smart Pointers
Reply-To: stevep@ims.com
Organization: Integrated Measurement Systems, Inc.
Date: Fri, 11 Dec 1992 15:52:17 GMT

In article <1992Dec9.032215.26534@philips.oz.au>, awadh@philips.oz.au (Awadh Pandey) writes:
|> 	I would like to have a copy of the paper "Smart Pointers: by Daniel Edelson of INRIA, from the 1992 Usenix C++ Confrence Proceedins.
|> 	Could any one please tell me how can I get it. Is there any electronic copy available which is ftpable.


Try:

host: ftp.cse.ucsc.edu 
addr: 128.114.134.19
file: pub/tr/ucsc-crl-92-27.ps.Z

This information copied from another message from: daniel@ucsc.edu
(Daniel R. Edelson)

--
Steve Poulsen, Integrated Measurement Systems, Inc.  Beaverton, OR  USA
Voice: 503-626-7117   Fax: 503-644-6969   Fidonet: 1:105/31.6
INTERNET: stevep@ims.com   Compuserve: [70262,3115]
Newsgroups: comp.lang.c++
From: hansen@myria.cs.umn.edu (David Hansen)
Subject: Re: How to call C++ functions in a C program?
Organization: University of Minnesota
Date: Fri, 18 Dec 1992 14:51:49 GMT

In article <SCHOUTEN.92Dec17125550@sp95.csrd.uiuc.edu>, schouten@sp95.csrd.uiuc.edu (Dale Schouten) writes:
|> 
|> I'm not sure how standard it is, but with at least some compilers
[..]
|> extern "C" {
|> int Cplusplus_function(int,char *);
|> }
|> 

Pretty standard.  See the ARM, sections 7.4 and 7.1c.  In the above example,
you could also use the form:

   extern "C" int Cplusplus_function(int i_parm, char * p_parm)
   {
      // C++ code to implement function
   }

					-=Dave
Xref: sparky comp.lang.c++:18093 comp.os.ms-windows.programmer.tools:1729
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++,comp.os.ms-windows.programmer.tools
Subject: Re: Define WIN30/WIN31 ?
Date: 16 Dec 92 21:26:46 GMT
Reply-To: jamshid@emx.utexas.edu
Followup-To: comp.os.ms-windows.programmer.tools
Organization: The University of Texas at Austin; Austin, Texas

Crossposted and followups redirected to comp.os.ms-windows.programmer.tools.

In article <1ge3raINN5k3@agate.berkeley.edu> jeff@emily10.Berkeley.EDU (Jeffrey C. Ely) writes:
>Well I my first attempt at compilation was the step1.cpp program.  I was a 
>little bothered that the compilation failed because "OWL applications require 
>either WIN30 or WIN31 to be defined."

Are you compiling using the IDE?  The project file that I have has
WIN31 defined.  If you would rather use the command line compiler, use
prj2mak since there are lots of compiler/linker options that must set.

>I know nothing about these macros (?)
>and can find nothing about them in the documentation.

Look in the borlandc\owl\doc directory (and borlandc\doc) for
this and other important information.

>Just as an experiment I added the line #define WIN30.

It's better to add it in the Options or on the command line.

>error only to get a whole bunch of new errors, the first of which were four 
>repetitions of "Cannot access Object.H" 

I don't know.  Try using the project file and reading the 'doc' text
files).  If you installed TC++ in a directory other than the default
directory you might (not sure) have to change some paths.

Jamshid Afshar
jamshid@emx.utexas.edu
From: ventura!vs@UCSD.EDU (Shankar Venkataraman)
Newsgroups: comp.lang.c++
Subject: Using C++ classes in DLLs with MSC 7.0
Date: 12 Dec 92 22:26:50 GMT
Reply-To: ventura!vs@UCSD.EDU
Organization: Ventura Software, Inc., A XEROX Company

compiler. According to Microsoft ( based on a article in MSJ ), 
C++ and DLLs are not matched to work together. Borland has given a
 solution to this problem, but unfortunately, we cannot shift to the
 BC++ compiler due to other reasons. The solution provided by 
Microsoft is to use C API routines to access the class methods in 
the DLL. Has anyone got a better solution ?

Shankar
ventura!vs@ucsd.edu
Newsgroups: comp.lang.c++
From: sdm@cs.brown.edu (Scott Meyers)
Subject: Re: Should char arrays be deleted with delete[]?
Keywords: C++
Organization: Brown University Department of Computer Science
Date: Sat, 19 Dec 1992 19:09:16 GMT

In article <78593@hydra.gatech.EDU> andy@federation.gatech.edu (Andy Register) writes:
| In article <1992Dec18.161338.28124@promis.com> fogel@promis.com (Richard Fogel) writes:
| >Should char strings allocated as follows:
| >
| >char *str = new char[10];
| >
| >later be deleted by:
| >
| >delete []str   OR    delete str  ?
| 
| To quote from Meyers, "In the case of an object type like char that has no
| destructor, this issue isn't important, but in general this is something
| you do not want to forget.  *Always* make sure that you use [] with 
| delete if and only if you used [] with the corresponding call to new."

Unfortunately, Meyers is wrong in this case.  I know because I'm Meyers.
Sigh.

The ARM is actually quite clear on this matter: regardless of the object
types involved (including built-in types like int and char), you must use
the [] form of delete when deleting arrays.  If you don't, the behavior of
your program is undefined.  That being the case, the general rule is
simple, has no exceptions, and (I am relieved to report) is correct in my
book (p. 19):

  If you use [] when you call new, you must use [] when you call delete.
  If you don't use [] when you call new, don't use [] when you call delete.

I've added the mis-statement above to the errata list for my book,
"Effective C++."  You can get a copy of the errata list via anonymous ftp
from wilma.cs.brown.edu.  The file is pub/Effective_C++_errata.txt.

Scott


-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."
Newsgroups: comp.lang.c++
From: erc@netcom.com (Eric Smith)
Subject: Re: Survey: File Extension
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Sat, 12 Dec 1992 01:48:34 GMT

In article <78146@hydra.gatech.EDU> andy@federation.gatech.edu (Andy Register) writes:
>In article <1gb1h0INNle2@tsavo.hks.com> webb@hks.com writes:
> >I have a survey question for you all:
> >
> >	What extension do you believe is correct for C++ source code?
> >	Is a clear majority winner emerging?  The contenders are: .C, .c
> >	and .cxx. 
>
>don't forget .cpp for all us borland users.
>
>Toodles
>Andy


That's not just Borland.  A lot of other vendors, such as Microsoft and
Zortech, use it too.  I think the reason why a lot of Unix compiler
vendors didn't like .cpp and used .cc, .C, .cxx, etc. was that the name
C++ wasn't originally intended to be pronounced "see plus plus", as the
++ operator was originally called the increment operator, and a lot of
C programmers considered people who called it "plus plus" to be
uneducated.  But that has gradually changed over the years, and now the
majority calls C++ "see plus plus" and uses .cpp as the filename
extension.  So we might as well standardize on .cpp, because that's the
way it's going anyway and no one can stop it.
Newsgroups: comp.lang.c++
From: pete@borland.com (Pete Becker)
Subject: Re: TRY ... FINALLY
Originator: pete@genghis.borland.com
Keywords: Exception Handling TRY FINALLY
Organization: Borland International
Date: Fri, 18 Dec 1992 17:22:33 GMT

In article <1992Dec18.094624.28329@us-es.sel.de> reindorf@us-es.sel.de (Charles Reindorf) writes:
>
>The important point here is that ANY exit from the TRY block results in "statements2"
>being executed, this includes the equivalent of returns, branches, break, continue,
>and normal exit from the loop. It is therefore *not* equivalent to the C++ example ...
>
>
>   try
>   {
>       statements1
>   }
>   catch(...)
>   {   statements2
>       throw;
>   }
>
>Is there any proposal in the ANSI C++ committee to introduce some sort of "TRY ... FINALLY"
>type of clause into C++. I have found that this is an extremely useful construct (even
>in the absence of exceptions) for putting general "clean-up" code in the "statements2" section
>which frees up new'ed memory, resets state variables, and so-forth. I cannot think of any
>other concise and wieldy way of doing it.
>

	Code that must be executed whenever a function returns can be put
in a destructor.  Since such code is typically cleaning up things that were
done earlier in the same function, that probably means that the earlier stuff
should have been done in a constructor.  Which, in turn, means that you're
dealing with a class.
	-- Pete

Newsgroups: comp.lang.c++
From: mscott@quaver.urbana.mcd.mot.com (Mark Scott)
Subject: Re: Give me safe C++
Reply-To: mscott@urbana.mcd.mot.com
Organization: Motorola Computer Group, Urbana Design Center
Date: Mon, 14 Dec 1992 16:34:37 GMT

In article <1536@ozz.oasis.icl.co.uk>, dom@oasis.icl.co.uk (dominic alston) writes:
|> jimad@microsoft.com (Jim Adcock) writes:
|> >In article <716@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
|> >|the cry comes "oh powers that be, protect us from ourselves", and thus
|> >|we get laws requiring people to wear seatbelts.  It is no that
|> >|I am against seatbelts (or safety), but I was perfectly capable
|> >|of wearing a seatbelt before the law existed. 
|> >
|> >To warp your analogy just a little bit, I am reminded of the rental car
|> >I was stuck with recently that "automatically" -- in the name of "safety" 
|> >presented a motorized shoulder harness across my neck every time I tried
|> >to climb in or out of the car.  Meanwhile, while I was automagically getting
|> >strangled, there was no equivalent mechanism to connect the seatbelt, 
|> >so if you did crash, you'd be strung up for good.
|> >
-- 
My brother, who is an Indiana State Trooper told me of a woman who was 
decapitated by the exact scenario described. Sometimes the *tools* 
can present a whole new set of problems.


Post replies to alt.folklore.urban  :-)

_________________________________________________________________________
Mark Scott			| "The heart of the wise inclines to the 
Motorola Computer Group 	|  right, while the heart of the fool 
Urbana Design Center		|  inclines to the left."  
#include <std/disclaimer.h>     |                          Eccl. 10:2  

Newsgroups: comp.lang.c++
From: pete@borland.com (Pete Becker)
Newsgroups: comp.lang.c++
Subject: Re: Private base classes
Date: 17 Dec 92 17:13:43 GMT
Organization: Borland International
Originator: pete@genghis.borland.com

In article <921216205429_76336.3114_EHJ34-2@CompuServe.COM> 76336.3114@CompuServe.COM (Kevin Dean) writes:
>In the excitement generated by the fact that someone had managed to post
>to comp.lang.c++ from CompuServe, the intent of my original posting was
>lost.  Here it is again:
>
>I tried to do the following:
>
>class A {};
>class B : private A {};
>class C1 : public B, public A {};
>
>My compiler naturally warned me about A being both a direct and indirect
>base class of C1 and so refused to compile it.  I was able to get around
>the problem:
>
>class CA : public A {};
>class C2 : public B, public CA {};
>
>My first thought, however, was that the declaration of C1 should have
>been allowed.  If A is a private base class of B, no class derived from B
>can access A so there should be no ambiguity in accessing members of A
>from C1: the only A visible is the direct base class of C1.

	No.  The only A _accessible_ from C1 is the direct base.  Both A's
are visible. The rule is that ambiguities are detected before applying
access restrictions.  That's so that changing an access specifier won't
result in ambiguities.

	-- Pete
Newsgroups: comp.lang.c++
From: gsingh@eng.wayne.edu (Gautam Singh, Graduate Student (ECE), 577-4725)
Subject: Re: How to call C++ functions in a C program?
Reply-To: gsingh@eng.wayne.edu
Organization: College of Engineering, Wayne State University, Detroit Michigan, USA
Date: Fri, 18 Dec 1992 10:09:49 GMT

Have you tried compiling both the functions using the C++ compiler!


Newsgroups: comp.lang.c++
From: erics@cadkey.com (Eric Smith)
Subject: Re: What is this CFRONT 3.0 warning message trying to tell me?
Organization: cadkey
Date: Thu, 17 Dec 1992 18:48:41 GMT

In article <BzBzL2.5rx@apollo.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
  [ interesting problem deleted ]
>
>Your assignment operator first frees any memory pointed at by the
>Thing::str data member, then copies directly into that freed memory.
>For self-assignment, it is also copying from that same freed memory.
>
>To fix all of these problems, you should reimplement the assignment
>operator as follows:
>
>	Thing &
>	Thing::operator=(
>	    const Thing &rhs	// note the addition of const here
>	)
>	{
>	    if (this != &rhs) {
>		if (str != 0) {
>		    free(str);
>		}
>		s = strdup(rhs.str);
>	    }
>	    return *this;
>	}
>
>-steve
>
>Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
>Distributed Object Computing Program
>Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.

Isn't there a problem with this code, since it checks to see if this
is the same as the right hand side by pointer comparison?  Aren't
pointer comparisons only defined if they point within the same object
or array of objects?

My reading of the ARM (section 5.9) says that this comparison is
undefined (or rather implementation dependent).  ANSI C (actually, I'm
looking in the ISO document, I'm not sure if the section numbers are
the same) has similiar language in 6.3.8 and 6.3.9.

I bring this up because I have a similar need for this comparison.  I
need to know if this is the same as one of my arguments.  In light of
the recent "total pointer ordering" discussions, I think there might
be a problem here.

Any ideas?

Eric.
From: mr@delfin.com (Mark Rosenberg)
Newsgroups: comp.lang.c++
Subject: What is this CFRONT 3.0 warning message trying to tell me?
Date: 15 Dec 92 18:36:49 GMT
Reply-To: mark@delfin.com
Organization: Delfin Systems, Sunnyvale CA

I'm porting a large application from a CFRONT 2.1-based compiler (Sun) to
a CFRONT 3.0-based compiler (Solbourne). The following warning message
has me somewhat mystified:

"main.cc", line 31: warning: temporary used for non-const Thing& argument; no changes will be propagated to actual argument (anachronism)

I've boiled the offending code down to:

#include <string.h>
#include <malloc.h>
#include <stdio.h>
class Thing
{
   public:

   char *str;
   Thing(){ str = (char *)0; };
   Thing(char *s){str=strdup(s);};
   Thing &operator = ( Thing & rhs  );
};

Thing &
Thing::operator = ( Thing & rhs )
{
   if( this->str )free( this->str );
   strcpy( this->str, rhs.str );
   return *this;
}

Thing getThing()
{
   Thing t("a thing");
   return t;
}

main()
{
   Thing t1("");
   t1 = getThing();             // warning
   printf("value: %s\n", t1.str );

   Thing t2 = getThing();       // no warning
   printf("value: %s\n", t2.str );
}

When this program is run you get the expectable result:

value: a thing
value: a thing

I realize that getThing should really return a reference and that using
stdio is really bad style but I don't understand why the first call to
getThing generates a warning but the second doesn't.
-- 
Mark Rosenberg
internet:mark@delfin.com
phone: (408) 562-1126	fax: (408) 748-1140
snail: Delfin Systems, 3000 Patrick Henry Drive, Santa Clara, CA 95054-1814