HDTenEightyP/NetNews huggingface dataset:
From: feathers@serss0 (Michael Feathers)
Newsgroups: comp.lang.c++
Subject: Re: More Gnu C++ fun
Date: 1 Jan 93 13:55:23 GMT
Organization: Florida International University, Miami

In article <1992Dec30.195714.9824@adimail.uucp> tel@adimail.uucp (Terry Monks) writes:
>This minimal program
>
>
>class node 
>{
>public:
>  static int level;
>  
>  node(){};
>};
>
>main()
>{
>  node::level=1;
>}
>
>
>compiles and links fine using the AT&T compiler from Sun, but will not link
>under Gnu c++.  (sparc-sun-sunos.4.1)
>
>I get the message
>ld: Undefined symbol
>   __4node$level
>
>
>Any clues?
>
>-- 
>Terry Monks        Automata Design Inc    (703) 742-9400

I think that the problem may be that you don't have a definition of 
node::level in your program.  It is declared within the class but
technically, no data is allocated.

Imagine if it were.  Every file that you include your class declaration
within would have a static instance of node::level.  Some implementations,
I suppose, will create the single instance you want in one particular file
behind the scenes, but many compilers force you to define all your class
static variables outside class declarations.  In fact, I think the ARM
requires this now.   

For your program, you can achieve the effect you want by placing the
following line before main ():

int node::level = 1;

You can delete the initialization within main also.  Since node::level is
truly static, you can give it that initial value in its definition.

Michael C. Feathers

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My opinions are not those of any organization because organizations do
not have opinions.
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Special-purpose-heap-managers - references, FTP?
Date: 30 Dec 92 21:25:05 GMT
Organization: Microsoft Corporation

In article <1992Dec29.184536.22437@src.dec.com> detlefs@src.dec.com (Dave Detlefs) writes:
|I regard the proposition that special-purpose heap managers are "much
|faster" than *all* general purpose ones as quite unproven.  

The counter-proposition also remains "unproven."

| It is
|certainly true that there exist bad general purpose allocators, and
|that special purpose allocators are much faster than these.  But this
|does not imply that there can't be a really good general-purpose
|allocator whose performance approaches the performance of writing a
|special-purpose allocator for each class in your program.  In fact, I
|believe that some variation on the Quickfit algorithm [1] fits the
|bill.  If you want to look at some very interesting empirical studies
|of allocator performance, I strongly recommend some papers by Ben Zorn
|and Dirk Grunwald at the University of Colorado [2], [3].

I agree that Quickfit is a good algorithm that people should seriously
examine for their object allocation needs if they haven't already done so.
Mallocs are typically designed to handle larger-sized allocations than
single-object, so mallocs are typically pretty poor choices for such needs.
Converesly Quickfit doesn't help with large allocations.  Looking at 
the inline code the authors generate for quickfit allocations makes
it clear that fix-sized class-based allocations should be possible
about twice as fast with about half as much generated code, so class-
based allocators will remain popular for people trying to get very
fast allocations.  Also, quickfit works pretty well for objects
when temporal locality remains fixed [ie objects that are allocated
together continue to be used together, and objects that weren't allocated
together continue not to be used together].  Works terrible in situations
where this is not true.  For example, in OODBMSs queries pull
together objects into new working sets.  Objects needed together in this
query may never had a relationship to each other in the past.  Quickfit
does poorly in such a system since its assumptions that temporal locality
~= spatial locality are violated.  Such systems need moveable objects 
and allocation systems supporting moveable objects instead.
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.lang.c++
Subject: Re: Zortech C++ v3.1
Date: 22 Dec 92 17:42:29 GMT
Reply-To: bright@nazgul.UUCP (Walter Bright)
Distribution: usa
Organization: Zortech, Seattle

In article <1garn0INN7fq@news.aero.org> jordan@aero.org (Larry M. Jordan) writes:
/Just got an upgrade announcement in the mail for Zortech C++ v3.1.
/[1] Is there a Windows hosted IDE included in the package?  
/    i.e. has zwb been ported to Windows?

	Sorry, no Windows hosted IDE yet. We are still working on it.

/[2] Does the debugger debug ALL memory models?  Does the debugger debug 
/    the DOS extender code?

	The debugger does not support the DOS extender code.

/[3] Does the debugger support AT&T version 3.0? 

	I'm not sure what you mean here.

/[4] Has the earlier debugger been completely supplanted by Multiscope?

	No.

/[5] Is the product shipping as we speak?

	Well, it got sent to manufacturing :-) :-)
Newsgroups: comp.lang.c++
From: kocks@leland.Stanford.EDU (Peter Kocks)
Subject: Re: Newbie Wants Advice on C-Programming
Organization: DSG, Stanford University, CA 94305, USA
Date: Wed, 30 Dec 92 21:19:24 GMT

In article <1313@ottawa.opl.com.opl.com>, sas@regina.aruba.UUCP (Steve Sciandra) writes:


You are all off your ROCKER !!!!!!!!!!!!

When someone asks the question, "Should I learn C before C++?", the answer is
always, "That depends on what you want to do".

I took me some time to realize that it is not the language that counts, but the
paradigm or idiom you use.  The language is important, but not as important as
knowing a few of the basic computer *tricks*.  For example, do you know what
the following things are:

1)  Linked list
2)  Hash Table
3)  bTree
4)  Recursion  (a critical programming trick that most fortran programmers 
                no nothing about).
5)  Data structures
6)  Modularity
7)  Shell sort

All of the above can be done in FORTRAN 90 (not f77).  Actually, I not that
sure they can all be done without some significant hacking.  

8)  Inheritance
9)  messaging
10)  Code sharing
11) weak vs strong type checking
12) static vs. dynamic binding.

This list can get very long, so I will not try to be complete.

If you know the very basics of any computer language (like what an array is and
what assignment means (eg c = c + 2), you can learn all of these techniques
by just reading books.  Yes, many of these books may have "C" or "C++" in the
title, but you can read them just the same.  You may not understand all the
syntax in the examples, but you will get the general concept.  It is much
more important to get the general concept early, than wait 5 years and get
it from experience in a specific language.

So, first decide whether you really need to let's say "inheritance", then
pick your language.

Most FORTRAN programmers really need to learn recursion and hash tables first,
before anything else.  For most scientific applications this can speed
up your code by boat loads.  FORTRAN 90 makes these techiniques easier to
port from one machine to the next, but both hash tables and recursion can be
done on most FORTRAN 77 compilers.

--Peter Kocks
  kocks@chemistry.stanford.edu

PS.  You're probably a scientist if you are asking this question, so you
should READ READ READ first, code later.
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Newsgroups: comp.lang.c++
Subject: Re: BORLAND C++ ; new int(1,000,000)
Date: 2 Jan 93 15:40:18 GMT
Organization: Computer Science, University of Melbourne, Australia

mwb@ulysses.att.com (Michael W. Balk) writes:

>ghica@fig.citib.com (Renato Ghica) writes:
>> 
>> Is it possible to allocate more than 640K (from extended or
>> expanded memory) on a DOS 5.0 system using a borland 3.1 C++ program?
>> 
>> Using the huge memory model, I'm trying to do the equivalent of 
>> 	new int(1,000,000);  
>> I have not successed. (I know I can allocate 64k+ at the time).
>
>According to the Borland 3.1 C++ Programmer's Guide, even though the
>total static data for the huge model can exceed 64k, it must be less
>than 64k within *each* model.

I think that it says each _module_, not each model.
(That is, in each source file.)

>Given that statement, I don't see
>how new int(1000000) could ever work.

new int(1000000) is *dynamic* allocation, so the limitations on *static*
data don't apply. It is possible to allocate objects >64k, I think, but
not >640k. (Get a _real_ operating system, like Linux, not this horrible
MSDOS :-)

-- 
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++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Intersting Data Structure
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 23 Dec 1992 15:54:32 GMT

In article <1992Dec22.034816.28702@netcom.com> erc@netcom.com (Eric Smith) writes:
>In article <BzMpBt.2Ip@cmcl2.nyu.edu> reznick@acf3.nyu.edu (Daniel Reznick) writes:
>>Can anyone suggest a feasable Data Structure/Class Hierarchy to
>>implement a Rubik's Cube?
>
>You mean to have it solve the puzzle, or to have it present the puzzle?
>If just to solve the puzzle, it is trivial, and you don't even need C++
>because you can just use fixed arrays and sequence through permutations
>till success.
>
	Hey, but if you want the shortest solution in general,
its definitly NOT trivial. I spoke to one of the Group Theorists
who first solved it. The one Rubic came up with after
(I forget what its called) is even harder.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: erc@netcom.com (Eric Smith)
Newsgroups: comp.lang.c++
Subject: Re: Intersting Data Structure
Date: 22 Dec 92 03:48:16 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)

In article <BzMpBt.2Ip@cmcl2.nyu.edu> reznick@acf3.nyu.edu (Daniel Reznick) writes:
>Can anyone suggest a feasable Data Structure/Class Hierarchy to
>implement a Rubik's Cube?

You mean to have it solve the puzzle, or to have it present the puzzle?
If just to solve the puzzle, it is trivial, and you don't even need C++
because you can just use fixed arrays and sequence through permutations
till success.

But if you want to present the puzzle as a picture on the screen and let
the user manipulate it, C++ is better, and you should look for some good
graphics libraries and/or user interface libraries.
Newsgroups: comp.lang.c++
From: fleurent@IRO.UMontreal.CA (Charles Fleurent)
Newsgroups: comp.lang.c++
Subject: GNU C++
Date: 23 Dec 92 23:03:18 GMT
Reply-To: fleurent@IRO.UMontreal.CA (Charles Fleurent)
Organization: Universite de Montreal


 
 I have started using Borland C++ a couple of months ago. I am 
 now thinking of porting some of my programs to UNIX. We have 
 here an old version of GNU C++ (version 2 preliminary) which does not 
 support templates. 

 I have a few questions:

 1. Is 2.3.1 the latest version of GNU C++? Does it support
 templates?

 2. Are the classes provided by libg++ usefull? Is the documentation
 clear enough to quickly learn how to use it?

 3. From your personal experience, would you recommend GNU C++ or would you
  advise to use another compiler and pay for it?

 Any comments would be very appreciated. Please respond via E-mail.
 Happy holidays to everyone.

 Charles.

--
____________________________________________________________________________
|Charles Fleurent                      | Telephone: (514) 343-6111 # 3512  |  
|Universite de Montreal,               | Fax: (514) 343-5834               | 
|Dep. I.R.O., C.P. 6128, succursale A  | E-mail: fleurent@iro.umontreal.ca |  
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Standard library functions and macros
Organization: TauMetric Corporation
Date: Sat, 2 Jan 1993 19:13:36 GMT

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

>jimad@microsoft.com (Jim Adcock) writes:

>>The fact that macro implementations are allowed under ANSI reserves the
>>entirety of the name space of a standard function to the library if
>>the header is included.  If the programmer doesn't like this, then
>>the programmer is permitted to simply declare the function required
>>out of the standard library, and just use that.  Which your changes
>>will also break.

>... I think that perhaps you are overreacting a
>little, Jim. Could someone who has actually read (or written ;-) the changes
>confirm that they would not break
>	extern char *puts(const char *);
>	inti main() { puts("Hello world\n"); return 0; }
>?

Jim is correct on this point.  The change says that you must include a
standard header for standard functions, and that the results of providing
your own declarations are undefined.  The reasons for this are to allow
implementors the freedom to use existing C libraries and declare the
functions to be extern "C", or to write new library functions with C++
linkage (or a mixture of both).  A portable program cannot assume what
choice was made.  (I suppose the functions could use Fortran or PL/I
linkage, for that matter.)

If an implementation uses the same library for C and C++, which is
true for current implemenations, you can successfully do this:
	extern "C" int puts(const char *);
	int main() { puts("Hello world\n"); return 0; }
You are just not assured the code will work.

Jim missing a point, I think.  Let's say, under his scenario, that I
create a class with a member function getchar.  I am careful not to
use <stdio.h>, and everything is fine.  A later programmer wants to use
stdio as well as my class library, and the code won't compile.

We have (at least) two choices.  Jim wants to leave the C headers alone,
meaning that the names of all the C library functions are unavailable
for use as class member functions.  The choice which was adopted says
that some existing C code would have to be modified under some C++
implementations -- you might have to use standard headers instead of
homebrew declarations of standard functions.  I don't think you can make
a case that either choice is just plain wrong; it is a judgement call.
The C++ Committee made a judgement, and anyone is free to disagree.

Jim also identified one "quiet change":  If you take the address of a
standard library function in C, the address will compare equal across
compilation units.  With the C++ change, inline versions of a standard
function might (but might not) have different addresses in different
compilation units.

A few weeks ago I asked for analyses of this situation, or of any other
problem associated with the change in C library rules for C++.  I did
not get any response.  I renew the request.  If the Committee has made
a bad decision, this is the time to correct it.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: template disappointments ... (suggestions?)
Organization: TauMetric Corporation
Date: Wed, 30 Dec 1992 17:32:30 GMT

jbuck@foucault.berkeley.edu (Joe Buck) writes:

>In article <24508@alice.att.com> ark@alice.UUCP () writes:
>>In article <DSCHIEB.92Dec29133556@muse.cv.nrao.edu> dschieb@muse.cv.nrao.edu (Darrell Schiebel) writes:
>>> 		list<vector<int>> list_vec_int;
>>
>>Huh?? This works fine -- just remember to put a space between the
>>two > characters so the >> won't be taken for a shift-right symbol.

>This is such a common error (and is so ugly) that compiler writers
>would be well advised to add productions to their grammar that catch
>it, or magic that splits the >> token into two tokens in this case
>if that fits in with the compiler's structure.

>Yes, I know that the rules of lexical analysis force the >> to be one
>token, but list<vector<int>> is a perfectly natural way of writing
>this thing, so perhaps it should be permitted even at the cost of
>adding an ugly rule to the grammar.

It isn't quite as easy as it might appear.  We discussed the lexical
and syntactic issues extensively in the C++ Committee.

In a template instantiation, the 'int' argument might be any expression,
including one containing right shifts.  If you try to allow what appears
to be a right shift to be two closing ">" instead, you wind up with
nondeterministic lexing/parsing, ambiguous grammars, or context-sensitive
grammars.  If you allow the above example to compile as the programmer
intended, you will probably also allow examples to compile which
really do contain syntax errors.  This can lead to bugs which are very
hard to find.

There are already comparable lexical problems in C and C++, so we
decided not to fix this one.  The above example is ill-formed code, and
the compiler will complain.  This seems better than allowing ill-formed
code which the compiler finds a way to accept.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: feedback wanted on appropriate OOPL
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 28 Dec 1992 03:38:19 GMT

In article <92358.192930COP80196@UCF1VM.BITNET> Bill Laird <COP80196@UCF1VM.BITNET> writes:
>I am taking object oriented programming in the upcoming semester,
>and wanted to get some feedback from you all.
>
>Much to my shagrin, I have found out that Smalltalk will be the
>programming language  used. 

	Probably a good choice for a course in OOP.

>I have read that Smalltalk implements
>dynamic typing, and that everything, even language defined types
>such as int or float are considered objects.

	It is much more 'OO' than C++ :-)
>
>"Why C++ must be the choice", the author states "Smalltalk may
>retain an interest because of its rapid prototyping capabilities, but
>for industrial applications it is far too slow and uses too much
>memory. 

	Note relevant for learning concepts though?

>Furthermore, the dynamic environment of Smalltalk
>where everything is an object means that everything can be changed
>by a developer, including basic features of the language."

	This doesn't follow, even if it happens to be true of Stalk.
>
>Keep in mind that many of the students probably won't know
>anything about OOP, and that in addition to learning a new language,
>all of the methodology of OOP needs to be learned. Also consider that
>all of the students have used C in the past, and the temptation to make
>C act like C++ may be a problem to some.
>
	IMHO Smalltalk OO and C++ OO are so different it is
almost impossible to sensibly conceive both as OO in the same sense.
I tend to call C++ a class oriented language, where 'class'
has implications of static strong typing.

>this idea.  I want to do C++ programming when I graduate, and feel
>that Smalltalk is going to slow me down (pun intended) in this endeavor.

	Stalk might be a good thing to learn to understand exactly
how NOT to write C++ :-)

-- 
;----------------------------------------------------------------------
        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: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Access non-static data members in Motif callback functions.
Organization: Rational
Date: Wed, 23 Dec 1992 16:54:02 GMT

jng@aslslc71.asl.dl.nec.com (James Ng) writes:

|We use X11/R4 and Motif 1.1 for our GUI development. Our C++ compiler is
|Object Center C++ (formerly called Saber C++). When we try to use a
|non-static member function as a callback, sometimes nonstatic data members
|get corrupted inside the callback function. Static data members seem to
|maintain their integrity. Does anyone have similar experience or even
|solution to solve the above problem? Any suggestion will be appreciated.
|Suggestion can be mailed to jng@asl.dl.nec.com or posted if you prefer.

Callbacks cannot be non-static member functions unless the caller
knows the exact type of the member function to be called.  Typically
in GUI callbacks this is not the case.

Remember that a pointer to a member function IS NOT a pointer to a
normal functions.  There is much more information being jockeyed
around when pointers to member functions are involved.  

I recommend that you read the section of your favorite C++ book which
describes pointers to members....


--
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++
From: tequila@ccwf.cc.utexas.edu (Mario Garcia)
Newsgroups: comp.lang.c++
Subject: Re: Newbie Wants Advice on C-Programming
Date: 4 Jan 93 01:53:12 GMT
Organization: The University of Texas at Austin, Austin TX

In article <4284@dozo.and.nl> jos@and.nl (Jos Horsmeier) writes:
>
>I think there's a bit more to leaning C++ than there is in learning C.
>C++ uses quite a different paradigm: the object oriented programming
>approach. Here at my company, they made me volunteer (with a gun pointed
>to my head ;-) to teach the programmers team the concept of object
>oriented design and programming. My first attempt was using your book
>along the line of explaining inheritance, polymorphism, data encapsulation
>etc. etc. We ended up discussing the misty details of the C++ language.
>I completely failed here. My second attempt was, not using any programming
>language at all, but just a clear explanation of the object oriented
>concepts and mechanisms. When all that was clear, we switched to C++.
>

I'm trying to make the switch from traditional Mac and UNIX C programming
to C++ and Objective C.  Can you recommend a good book for learning OOP 
in general ?

----------------------------------------------------------------------------
Mario L. Garcia                      E-mail mario@truth.asg.arlut.utexas.edu
Applied Research Laboratories
The University of Texas at Austin
----------------------------------------------------------------------------

Newsgroups: comp.lang.c++
From: tel@adimail.uucp (Terry Monks)
Subject: Gnu C++ - what did I miss?
Organization: Automata Design, Inc.
X-Newsreader: TIN [version 1.1 PL7]
Date: Tue, 29 Dec 1992 22:07:01 GMT

I just installed Gnu g++ version 2.3.2, but...where am I
supposed to get <stream.h> from?

(my version is sparc-sun-sunos4.1)


-- 
Terry Monks        Automata Design Inc    (703) 742-9400

Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Cecil
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 23 Dec 1992 15:59:33 GMT

	My apologies to using News but the email bounced ...
"Object Oriented Multi-Methods in Cecil", Craig Chambers.
chambers@cs.washington
ECOOP 92 conference proceedings.

-- 
;----------------------------------------------------------------------
        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++