HDTenEightyP/NetNews huggingface dataset:
From: walduck@mpr.ca (Andrew Walduck)
Subject: C++ FAQ and Style Guides
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Thu, 3 Sep 92 18:43:50 GMT

I'm looking for some C++ info...could anyone out there help me by giving
me pointers to where the items live???

1. The C++ FAQ
2. Various C++ styleguides...I especially want the APPLE C++ styleguide

Thanx
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: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: What does "::" really mean?
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Fri, 4 Sep 92 14:10:30 GMT


I'd like to add something to my last post on this subject.

Consider an example:

class AA
{ public:
    class NAA {};
};

class AA1: public AA
{ public:
    class AA
    {  public:
         class NAA{};
    };
};

class AA2: public AA
{ public:
    class AA
    {  public:
         class NAA{};
    };
};

class BB: public AA1, public AA2
{
   AA1::AA::NAA  x;     // what is the type of x???
};

What is the type of member "x" in class BB?

We should use:

   AA1.AA.NAA

to denote the class NAA nested in class AA nested in class AA1, and use

   AA1::AA.NAA

to denote the class NAA nested in the base class AA of AA1.

To conclude, we use"::" to denote a specific base when the member is ambiguous  
due to multiple inheritace, and we use "." to denote the member or property of  
a qualifying entity ( an object or a class ).

David Shang
Newsgroups: comp.lang.c++
From: tdukes@eng.auburn.edu (Todd J Dukes)
Subject: Borland BIDS Library
Organization: Auburn University Engineering
Date: Tue, 1 Sep 1992 23:21:52 GMT

I have been using the Borland Object based container classes. I am 
starting a new project and thought it would be a good time to change 
over to the template based container classes.

So far I haven't had much luck. I am just trying to insert a pointer
to a class into a list. I can get the same program to compile if I
just make a list of int, but it will not work for a simple class.
The following is a short program that I can't get to compile. I get
the following error:

\borlandc\classlib\include\listimp.h 502: Illegal structure operation


Am I doing something wrong or are the BIDS libraries useless?
(My guess is the former.:)

I am using BC++3.1 w/AF


thanks

Todd Dukes

/* attempt to use BI_ListImp */

#include <listimp.h>

class point
{
	public:
		int x;
		int y;
	point(int nx, int ny)
	{
		x = nx;
		y = ny;
	}
};

void main()
{
	BI_IListImp<point> PointList;

	point * pp = new point(1,1);

	PointList.add(pp);

}

Newsgroups: comp.lang.c++
From: cflatter@nrao.edu (Chris Flatters,208,7209,homephone)
Subject: Re: Turbo C++ vs. Gnu C++
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Tue, 25 Aug 1992 19:05:32 GMT

In article 27556@westford.ccur.com, macdonal@westford.ccur.com (Steve MacDonald) writes:
>I have a question regarding the following code. This compiles fine with the 
>Gnu C++ compiler, but when I compile this on the latest version of Turbo C++
>on a p.c., I get an error. I'll flag the line to the right of where it appears.
>
>#include <stream.h>
>#include <string.h>
>#include <new.h>
>#define endl "\n"
>
>			//Example3_8
>int classcount;		//Accessing an array of class pointers.
>
>class Test{
>public:
>	Test() {
>             print(word = "NO INITIALIZER SUPPLIED");
>	     count = ++classcount;
>	     }
>
>	Test(char *mess ="HELLO") 
>		{
>	     print(word = mess);
>	     count = ++classcount;
>	     }
>
> [...]
>
>for(int i = 0; i < 10; i++)
>	classptrarray[i] = new Test; ***TURBO C++ yields the following error
>					message:
>					Error c:\tc\examples.cpp 58: Ambiguity
>					between 'Test::Test()' and 'Test::
>					Test(char near*)' in function main()

Turbo C++ is doing the right thing, GNU C++ isn't.

For the purposes of argument matching Test::Test(char *mess = "HELLO") is
considered to be two different functions with the signatures Test::Test(char *)
and Test::Test() (see ARM section 13.2, p316).  Since you have explicitly
declared a Test::Test() constructor there is an ambiguity here.  Should
the compiler use the defined Test::Test() or should it use Test::Test(char *mess)
with the default value of mess.

The correct behaviour is to report the ambiguity and abort compilation.

	Chris Flatters
	cflatter@nrao.edu
From: don@surtsey.aero.org (Don C. Hancock)
Subject: Multiple Inheritance Problem
Organization: The Aerospace Corporation; El Segundo, CA
Date: Mon, 31 Aug 1992 23:03:11 GMT


I'm confused as to why the following results in what to me is the wrong
virtual function being called.  I'm sure the problem is somehow caused
by my casting the result of the function call from one base to the
other (and somehow lying to the compiler), but I'm not sure how else to
accomplish my task.

Any help would be greatly appreciated.  I've run this on the GNU C++
compiler as well as the Borland compiler with the same results, that
is, the call to derived::v2() ends up calling derived::v1().

Don Hancock

----------CUT HERE--------------
#include <stdio.h>

class base1 {
public:
	virtual void v1() {printf("base1::v1\n");}
};

class base2 {
public:
	virtual void v2() {printf("base2::v2\n");}

};

class derived : public base1, public base2 {
public:
	virtual void v1() {printf("der::v1\n");}
	virtual void v2() {printf("der::v2\n");}

};

base1 * fun() {
	derived *dd = new derived;
	return dd;
};

main() {
	base2 *bb2 = (base2 *) fun();
	bb2->v2(); // prints 'der::v1'  !!!!!????
}
From: Aurelius@cup.portal.com (Mark Christian Barnes)
Newsgroups: comp.lang.c++
Subject: Re: complex classes and temporary destruction.
Date: Mon, 31 Aug 92 00:09:30 PDT
Organization: The Portal System (TM)
Distribution: world
  <23563@alice.att.com> <64821@cup.portal.com> <23578@alice.att.com>
  <64878@cup.portal.com> <23587@alice.att.com> <64915@cup.portal.com>
  <23592@alice.att.com>

Andrew Koenig replies:

|>  If operator+(a,b) does, in fact, construct a temporary of type
|> String, then the compiler could determine its storage class,
|> perhaps based upon the storage class of the context to which
|> it is applied.
|
|Sorry, but I'm not going to tell you what operator+(a,b) does.
|I'm compiling it separately and giving you the object code to link
|in with your source code.
|
|Now, how is the compiler going to determine its storage class when
|it is compiling your program?

 Hmm, ok. Well then I'll write code defensively like:

extern class String;
extern String a, b;

void display ( void )
{
  auto String temp;
  auto char const *p;
  auto char const statement[] = "a+b is ";
  auto char const endOfLine[] = ".\n";

  temp = a + b;		// invoke String operator+()
  p = temp;		// invoke String operator char const *()
  cout << statement << p << endOfLine;

// every variable gets destructed about now. (except cout, a and b)
}

 In every case (well, so far ;-}) an unnamed object can be
declared as a variable with a known storage class. This is
why I feel that such "temporary" objects could be treated as
responsibly by a smart compiler. The kind of compiler C++
has been striving towards.

 I, as the programmer, can (and usually must) make such
determinations. I sometimes eliminate all unnamed objects during
alpha testing, in order to judge how well I've used the machine's
resources, within my functions and methods.

			Regards, Aurelius@cup.portal.com
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 3 Sep 92 13:39:47 GMT

jss@lucid.com (Jerry Schwarz) writes:

|I find this whole discussion of GOTO in comp.lang.c++ somewhat
|quaint.  Perhaps it should be moved to comp.lang.c. 

|If we've learned anything in the past 20 years, it is that
|that the way you write your code within a function is much
|less important than the way you structure your functions and
|types. The distinctive features of C++ (member functions,
|inheritance, ...) are concerned with global structure and
|not the local structure of functions.   

|   -- Jerry Schwarz

Jerry:

I agree with your priorities.  The structure of data and function is
certainly far more important than the structure of individual
functions.  Just as the structure of a building is more important than
the structure of its bricks...  Nor is this a new revelation.  The
practice of "modular programming", structuring your programming into
many small functions, predates "structured programming" by several years.

I did not intend to start a religious war.  (Or a quaint discussion.)
I had no idea that there would be such a reaction.  Structured
Programming is "old news".  Arguing about whether or not to use gotos
is like arguing about whether the world is round or flat. The question
was settled years ago.  

I find this discussion very appropriate for the C++ group, because the
old technology should not be forgotten in the pursuit of the new.  OO
is a new methodology which promises some advancement.  But if we leave
the old principles of Structures Programming behind in pursuit of the
new, then we will have lost ground.  But if we integrate the old
technologies with the new discoveries, and build upon the work of
past, then we are scientists and engineers, advancing by "standing on
the shoulders" of our peers and predesessors.

The principles of structured programming were an important advance in
the science of software engineering.  Those principles are still valid
today as a guide to structure the implementation of our methods.   We
should not forget them, and if they are in question, then we should
discuss them.


--
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: panetta@cithe503.cithep.caltech.edu (James Panetta)
Subject: Strange behavior with gcc 2.0 (bug?)
Reply-To: panetta@cithe501.cithep.caltech.edu.UUCP (James Panetta)
Organization: California Institute of Technology, Pasadena
Date: Thu, 27 Aug 1992 07:59:45 GMT


Folks-
   When running g++ on an IBM RS/6000 I come across the following 
strange behavior.  (gcc V2.2.2 from version.c)
	I've discovered an irritating problem with the following program:

/*********************************************************************/
/*
 *		File: really_FUBAR.cc
 *		Description: demonstrates a possible bug?
 *
 */
#include <iostream.h>

int main(void)
{
	unsigned i;

	i = 7U;
	cout << (long double)i <<endl;
	cout << i << " " << i << endl;
	cout << (long double)i << " " << (long double)i << endl;
	cout << i << " " << (long double)i << endl;
	cout << (long double)i << " " << i << endl;
}
 
/*********************************************************************/

The output is:
7
7 7
7 1.12722e+09
7 1.12722e+09
7 7


This output persists when _i_ is typecast to double also.  This would be
only a minor annoyance if this behavior didn't persist across function
call boundaries.  i.e.:

foo(i,(long)i);

inside foo:

foo(unsigned bar, long bazz){

	cout << bar << endl;
	cout << bazz << endl;
}

generates (for i=7U):

7
1.12722e+09

Any solutions?
Jim Panetta
-- 
Panetta@cithex.caltech.edu          :-(     A witty saying proves nothing.
Panetta@cithex.bitnet               :-|
Panetta@cithe503.cithep.caltech.edu :-)                             Voltaire
Newsgroups: comp.lang.c++
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: Explicit Calls to Destructors (SunCC=ok, gcc=not)
Keywords: destructors
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia
Date: Mon, 31 Aug 1992 16:38:59 GMT

schiebel@cs.wvu.wvnet.edu (Darrell Schiebel) writes:
|> 
|> 	In the Sun (SC1.0 w/ cfront 2.1 (I think)), an explicit call
|> 	to a class' destructor from within a one of the class' member
|> 	functions works:
|> 
|> 	void Tess::cleanup(Bool abort) {
|> 	  Tess::~Tess();
|>         }
|> 
|> 	However, in gcc-2.2.2 this does not work, and gives the error:

You have tried everything except the one that works in gcc:

	this->Tess::~Tess();

-Sekar
	
Newsgroups: comp.lang.c++
From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Subject: Re: Graph Library ?
Date: Mon, 31 Aug 1992 15:37:53 GMT
Organization: TU Darmstadt

In article <1992Aug31.132528.13265@info.ucl.ac.be>, lheureux@alysse.fai.ucl.ac.be (Olivier L'Heureux) writes:
> 
> LEDA can be ftp'ed from ftp.th-darmstadt.de (130.83.55.75), directory
> /pub/programming/languages/C++/c++-products
				 ^^^^^^^^^^^^

Please note: LEDA is not in that directory; this is the directory for
the C++ products list.

LEDA is found in /pub/programming/languages/C++/class-libraries/LEDA.
[It's an (automatic) mirror of the reference site, ftp.cs.uni-sb.de.]

(Should be easy to find for interactive ftp'ers, but the folks who
must use a mail gateway might appreciate the shortened search time...)

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Destructors and exit()
Date: 4 Sep 92 14:02:33 GMT

rad2r@uvacs.cs.Virginia.EDU (Robert DeLine) writes:


|Sorry for this novice question, but when I call exit() from a program compiled
|using g++ 2.1, the destructors for my objects don't get called.  This doesn't
|surprise me too much, but is this correct?  Does the ARM mention what should
|happen when exit() is called?  What if the program is ended due to an uncaught
|exception?  If destructors _are_ called when leaving via an uncaught exception,
|perhaps this is a better way than calling exit() to leave from deep inside a
|program?

The destructors for static objects should be invoked when you call
exit.  However the destructors for objects which are declared as
'auto' variables (on the stack) in the function which calls exit,
probably will not get invoked.  For example.

main()
{
  MyClass A;
  static MyClass B;

  exit();
}


The destructor for B should be invoked.  But the destructor for A
probably will not.  I say probably, because a clever compiler might be
able to figure out that, upon exit, the enclosing stack frames should
be destroyed.

The definition of the exception feature says that all destructors for
objects created as auto variables between the throw and the catch will
be invoked.  Thus, "exit" does not behave the way an exception would.
Presumably, an uncaught exception will be "caught" by the code that
calls main.  Thus, destructors will most likely be invoked for
uncaught exceptions.

I agree, when exceptions are implemented, the present a better
mechanisms for exitting a program than embedded calls to 'exit' do.
And remember, never use gotos.


--
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: steve@taumet.com (Steve Clamage)
Subject: Re: Tiny proposal for named loops.
Organization: TauMetric Corporation
Date: Wed, 26 Aug 1992 16:08:48 GMT

rmartin@thor.Rational.COM (Bob Martin) writes:

>rgp@mpd.tandem.com (Ramon Pantin) writes:

>| It is incorrect to attribute OOP to Dahl,
>|Dijkstra and Hoare, they where just writting a book and could not ignore
>|the OOP work done by others in (at least) the previous five years.

>Agreed.  I attribute to them the publishing, not necessarily the
>creation.  However, Dahl was one of the three authors of the "Simula 67
>Common Base Language" document (the others were Myhrhaug and Nygaard).
>So I think some of the OOP work can be attributed to Dahl.

Nygaard was the keynote speaker at the Usenix C++ conference earlier
this month in Portland Oregon.  He talked about what lead him to
the concepts of OO design and programming, and how these concepts
were, um, instantiated in Simula-67 (which built on earlier versions
of the language).  Fascinating.

Amongst all the arguing in this thread about goto's, breaks and
continues, I want to say what I always do when this discussion arises:

One really must read "ACM Computing Surveys", vol 6 no 4, December 1974.
It is a special issue devoted to structured programming.  There are
two articles in particular, one by Niklaus Wirth, the other by Donald
Knuth, which discuss goto's in considerable depth.  I believe it is
a waste of bandwith to argue the subject without having read both of
these.  (BTW, don't assume you know what these articles say.  You may
be surprised.)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: Monroe.Thomas@ttlg.UUCP (Monroe Thomas)
Sender: postmaster@ttlg.UUCP
Newsgroups: comp.lang.c++
Subject: Re: destruction of tempo
Date: 25 Aug 92  20:51:00 mst

EN>From: eny@ermes.enea.se (Erik Nykvist)
  >Path: alberta!kakwa.ucs.ualberta.ca!unixg.ubc.ca!ubc-
  >cs!destroyer!gatech!bloom-
  >beacon!eru.mt.luth.se!lunic!sunic!seunet!enea!ermes!eny
  >Newsgroups: comp.lang.c++
  >Subject: Re: destruction of temporaries
  >Organization: Project ERMES, Teli Telecom Sweden
  >Message-ID: <1992Aug25.113913.28554@ermes.enea.se>
  >References: <23487@alice.att.com>
  >Date: 25 Aug 92 11:39:13 GMT

EN>Maybe we should invent a new type of compound statement in C++. ;-)

EN>{!
  >    ....

EN>!}

EN>Within this type of compound statement all temporaries will survive until
  >end of scope. Within such a statement only a restricted set of C++ would
  >be allowed.

Problem with this is that it makes the programmer responsible for when
temporaries are going to be needed for the whole scope of a block.
Few enough programmers know what temporaries are let alone know when
they are going to be needed for a whole block.

-Monroe

 * OLX 2.2 * Kix are for trids.

 * Origin: Through the Looking Glass (42:100/14)
From: roth@ordin.cs.wisc.edu (Bill Roth)
Newsgroups: comp.lang.c++
Subject: a few rookie questions about testing for CLASSS membership.
Date: 25 Aug 92 20:44:48 GMT
Organization: U of Wisconsin Madison - Computer Sciences


I'm a relative rookie to C++, though not to OOP (due to many moons of
programming in Objective-C).

1. I have a pointer p to some object. How do I test if p is a member
of the CLASS a.

2. Is there a way to test if p, which is a pointer to an object, can
test if p can execute method m?

Please email your replies.
--

-------------------------------------------------------------------
Bill Roth, University of Wisconsin Computer Sciences Dept.
Internet: roth@cs.wisc.edu. BITNET: ROTH@WISCPSL. HEPNET: PSL::ROTH
Newsgroups: comp.lang.c++
Subject: Re: Novice Questions
From: Jesse Liberty <jliberty@zdi.ziff.com>
Date: 31 Aug 92 16:07:02 EDT
Distribution: world
Organization: Ziff Desktop Information
X-UserAgent: Nuntius v1.1.1d9X-XXDate: Mon, 31 Aug 92 16:11:03 GMTLines: 16

One aside, the orig. author seems to have the whole issue of "nulls"
confused. It may be worth pointing out that the way c (and c++) checks
for end of string is with a NULL (or zero). This is very different from
an ascii character zero.  Thus, the string "10"
Would have three guaranteed members
       string[0]  == '1'
       string[1] == '0'
       string[2]==0

String 1 is the ascii zero, string 2 is the value zero, and this makes
all the difference.

Hope that helps some. -j
Jesse Liberty, Ziff Desktop Information, 25 First St., Cambridge MA 02141
Internet: jliberty@zdi.ziff.com            CIS/ZiffNet: 72241,72
   Voice: (617) 252-5285                           Fax: (617) 252-5403
Newsgroups: comp.lang.c++
From: mcgrant@rascals.stanford.edu (Michael C. Grant)
Subject: Re: the 'standard' complex class
Organization: Information Systems Laboratory, Stanford University
Date: 26 Aug 92 23:22:10

In article <BtMGyz.52A@me.utoronto.ca> zougas@me.utoronto.ca (Tom Zougas) writes:

   mcgrant@rascals.stanford.edu (Michael C. Grant) writes:

   >Because the class does not need to be specially notified when the .re or
   >.im fields change, why not make them public? It certainly allows for
   >maximum flexibility; it won't break a single function already written
   >for complex numbers.

   Don't forget that complex numbers could also be represented in polar form.
   The point of abstraction is you don't want to know HOW the class is
   represented only WHAT is available. 

I don't need that old tired line again. I understand the value of
abstraction---of course that's true in general. But I have no desire
whatsoever to have a complex ABSTRACT data type. I want a CONCRETE
EFFICIENT data type. I want to know EXACTLY how the class is represented,
because I can easily make design choices that way to improve efficiency.
Despite the fact that even doubles are abstract data types, we really don't
think of them as such. We can easily assign values to them, perform
automatic type casts, etc. without worrying about which member function to
use.

If I wanted a polar class I could certainly whip one up with the
appropriate conversions to the standard complex class and so forth. And,
if it weren't for the fact that the angle probably ought to be represented
in fixed-point, I'd make its data members public too---because setting
the value of .r or .theta wouldn't trigger a chain reaction of events
as often happens in abstract data types.

   Inlining access functions might give
   the efficiency you need.

Nope, unfortunately that's not true---the way AT&T set things up, that is.
Their functions pass by value and not by reference, and from examining the
assembly I can tell you that the efficiency isn't there, even for the
inlined functions. Of course, when I manually changed appropriate functions
to accept 'const complex&' instead of 'complex', that improved things a
lot, but not quite to the point that I'm happy with keeping .re and .im
private. 

Michael C. Grant
From: sm86+@andrew.cmu.edu (Stefan Monnier)
Newsgroups: comp.lang.c++
Subject: Getting type info back !
Date: 1 Sep 92 06:19:01 GMT
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA


I would like to store different type of objects in a 'generic' structure,
using the (void *)
The problem I'm faced with is that of determining the real type of an 
object after storing in that structure (when I take it back)

It is a quite general question.
Given a class T2 subclass of T1 and objects o2 and o1 of type
respectively T2 and T1, you can safely do

o1 = o2

as o2 is of type T1, too. But how can I decide if
 
o2 = o1

is safe ? of course just o1=o2; o2=o1 IS safe, but in a more general
situation, it is not. Eiffel has for this special case:

o2 ?= o1 

If o1 is effectively of type T2 (and not only T1), then o2==o1, else, o2==NIL

Is there something equivalent in C++ ?


	Stefan Monnier


-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
Newsgroups: comp.lang.c++
From: kpearce@magnus.acs.ohio-state.edu (BULLDAWG)
Subject: sscanf, thanks for the answers.  : )
Organization: The Ohio State University
Date: Mon, 31 Aug 1992 17:53:40 GMT

Many thanks to those who responded.

I have found the answer to my question.

Thanks.