HDTenEightyP/NetNews huggingface dataset:
From: moudgill@cs.cornell.edu ( Mayan Moudgill)
Subject: Help! Possibly another bug with templates
Keywords: templates, cfront 3.0, bug, help
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Wed, 6 Jan 1993 22:14:03 GMT

The problem that occurs is that the template constructor for objects
in GLOBAL scope that INHERIT from a template with a STATIC NON-FUNCTION
member are called too many times.

This can be exhibited by compiling the following file WITH
THE -ptn OPTION. (or by breaking it up into multiple files).

Question: Is this because the definition of the static non-function
member using a template is illegal?

The contructor gets called twice instead of once,
once from the main file, and once from the file inside
the ptrepository. Is this what should be happening?

The constructor gets called once if
 * the object is non-global.
 * the function contains a static function member, but not a non-function member
 * the static non-function member is explicitly declared.

:)
Mayan
(moudgill@cs.cornell.edu)

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

/* in file A.H */
template <class T>
class A {
private:
   static int n;
public:
      A()
   {
      cerr << "constructor called" << endl;
   }
};

/* in file A.C */
template<class T>
int         A<T>::n;

/* in file use.C */
class B : public A<B> {
};

B EEEE;

main()
{
}
Newsgroups: comp.lang.c++
From: rjohnson@aisun1.ai.uga.edu (Russell M. Johnson [MSAI])
Subject: Class library showing Directories 
Organization: AI Programs, University of Georgia, Athens
Date: Wed, 6 Jan 1993 16:50:21 GMT

Does anyone know of a class library that shows directories for the
purpose of opening and viewing files.  Mouse support would be
preferable.  Please e-mail any responses that would, in turn, be much
appreciated.


 |--------------------------------------------|----------------------------| 
 |    I would've gotten away with it too,     |      Russell M. Johnson    |
 | If it hadn't been for those meddlin' kids. | rjohnson@aisun2.ai.uga.edu |
 |--------------------------------------------|----------------------------|   
 |   -Famous last words from a variety of would-be villains foiled once    | 
 |         again by the clever detective work of Scooby and friends.       |
 |-------------------------------------------------------------------------|





Newsgroups: comp.lang.c++
From: euamts@eua.ericsson.se (Mats Henricson)
Subject: Re: Pros and cons of C++
Reply-To: euamts@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Thu, 7 Jan 1993 16:09:59 GMT

In article vp@gpu.utcs.utoronto.ca, yjohn@gpu.utcs.utoronto.ca (John Ross) writes:

// Deleted

#Why then is it becoming so popular?  Why the deluge of texts, articles,
#magazines, news groups, compilers, etc?  It seems to me that C++ _will_
#be the language of choice for programmers (except in specialized areas
#where other languages will continue to be used). It would be nice to get a
#balanced view of where C++ fits into the scheme of things.
#Unfortunately, language issues often assume the aspect of a religious
#war, with rabid supporters and detractors.

I think someone ought to do some sociological research on this. I can agree
with people claiming C++ is very complex, but I don't know any other OO
language, so I cannot say if it is overly complex or not.

All we can do is to sit down and face the facts: C++ is here to stay and
we just have to deal with its complexities.

Someone once said: C++ is the programmers revenge on managers, since C++
may imply that programmers in the future will once again walk around in
white coats and be payed handsomly.

Mats Henricson
Ellemtel
Sweden
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: Static global initialization outside of main() legal?
Date: 6 Jan 93 22:17:12 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <1993Jan4.153806.1062@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>In article <GIROD.93Jan4122311@kilohp.kiloapo.ts.tele.nokia.fi> marc.girod@ntc.nokia.com writes:
>>The most important is
>>guaranteed: that "the initialisation [...] in a translation unit is
>>done before the first use of any function or object defined in that
>>translation unit". 
>
>	This is not guarranteed at all, even if it says it is!

Right.  I never understood why the ARM says that.  Maybe r3.4 should
instead read:

	the initialisation [...] in a translation unit is done before the
	first use **(not related to the initialization of another static
	object)** of any function or object defined in that translation unit

>>There remains the "pathologic" case of mutual
>>dependencies, dealt with in the annotation part of the ARM for 3.4,
>
>	This is not how it works. There is no general solution
>to the problem, so no algorithms can be written to solve it.

Right, there's no solution to:
	//file one.cpp
	extern int y;
	int x = y+1;
	//file two.cpp
	int y = x +1;

but Marc may be referring to the situation where the initialization of
one static uses another static object (eg, it uses a global
'error_log' stream).  The ARM commentary demonstrates the
'nifty-counter' technique which would require a file-scope static
object in the error_log.h file that would initialize the global
error_log.  One thing the ARM doesn't mention about this technique is
that the constructor used for the 'error_log' definition must *not*
modify the object since it may be called *after* one of the static
initializers initializes 'error_log'. (err, is that clear?)

>	Typically, what happens is static variables are initialised
>to a constant value first (0 if not otherwise specified)

I have a question about this.  The ARM seems to only guarantee that
static objects are initialized to 0 before any dynamic initializations.
(I assume this does not necessarily mean all-bits-zero in the case of
pointers and floats/doubles).  Does that mean there's no guarantee that
'x' below will be 5 during the construction of a static in another file?
	int x = 5;  // 'x' is a global

Btw, I believe even the following is considered a dynamic initialization:
	int x;
	int* p = &x;
and therefore there's no guarantee that 'p' points to 'x' during the
construction of other globals.

>then modules get initialised in the order of linkage, 
>and variables in each module in the order of writing.

I hope the Working Papers have clarified 3.4.  Can someone with access
please outline the changes?

Thanks, Jamshid Afshar
jamshid@emx.utexas.edu

Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Standard library functions and macros
Date: 12 Jan 93 19:16:39 GMT
Organization: Microsoft Corporation

In article <1993Jan7.042121.23809@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
|jimad:	
||>   And such control
||> over inline expansion is precisely the control permitted deliberately
||> and explicitly in the base doc -- the ANSI-C base doc.
|
|You keep saying this, but you don't explain how you arrive at that
|conclusion.  What the C standard allows is being sure that a
|macro isn't in scope.  It does not let you control whether the standard
|functions are inlined. 

You are looking at it from the strictly conforming programmers point of
view.  I am discussing it from the implementors and the conforming
programmers point of view.  You right that ANSI-C doesn't require either
a non-inline or an inline implementation.  ANSI-C does require that if
an inline [macro] implementation is given that a non-inline implementation
also be present.  It is true that an optimizing compiler or linker could
take the non-inline and make it inline again.  This is the as-if rule.
So there is no strictly-conforming way the programmer can be guaranteed
this control.

However, from the view of the implementer and the conforming programmer,
implementations can and do follow the ANSI-C guidelines for how the
standard libraries are "suppose" to work.  And *conforming* programs
and programmers do make use of the features of those conforming implementations.
You are now suggesting removing the [reasonable] possibility of 
implementations continuing to support the ANSI-C libraries in the
manner the ANSI-C document calls out.  You have destroyed a clear intent
of the ANSI-C document, and you have done so without allowing for the
obsolecense period called for in the ANSI-C document.  This is a clear
violation of the ANSI-C base document.  Again, if you insist on violating
the rules laid down by the ANSI-C base document, then the ANSI-C++
committee should not claim the ANSI-C document is one of their
base documents.
From: kevinc@hpcc01.corp.hp.com (Kevin Collins)
Date: Thu, 7 Jan 1993 21:08:03 GMT
Subject: Porting Advice Needed
Organization: the HP Corporate notes server
Newsgroups: comp.lang.c++


We are trying to decide what strategy to use in porting our product 
to new platforms.  First let me describe our product :

- Developed on HP-UX.
- Two years old.
- Written in C++ with Motif.
- Uses HP's Allbase RDBMS.
- Uses the Tool Integration Platform architecture. (ie. Socket-based message
  passing.)
- Approximately 150,000 lines of code.
  Note : since this was our first large project with OO methods and C++
		 we think we can do things differently now.

We anticipate the need to port to Sun and IBM platforms and use other
database engines as well.

I have the following questions :

 1) Have you used a contractor who specialized in porting?  If so,
	what was your experience?

 2) How difficult is it to port to Sun, IBM from HP-UX?  
       - For a group only experienced with HP-UX.
       - For a group experienced with Sun and IBM.

 3) Is there a source/guideline document anywhere that could be used to
	help us through a porting effort?

 4) What is a rule of thumb in estimating a porting effort?  For example,
	a fraction of the original development time, an estimate based on
	how many lines of code, etc. 

 5) How critical is it that the person(s) doing the porting are actually
	familiar with the code?  If they are not familiar how much longer
	will it take them?

Thanks,

Kevin
From: rons@hardy.u.washington.edu (Ronald Schoenberg)
Newsgroups: comp.lang.c++
Subject: Re: Pros and cons of C++
Date: 7 Jan 1993 21:29:44 GMT
Organization: University of Washington, Seattle
NNTP-Posting-Host: hardy.u.washington.edu

In article <1993Jan7.160959.9381@eua.ericsson.se> euamts@eua.ericsson.se writes:
>In article vp@gpu.utcs.utoronto.ca, yjohn@gpu.utcs.utoronto.ca (John Ross) writes:
>
>// Deleted
>
>#Why then is it becoming so popular?  Why the deluge of texts, articles,
>#magazines, news groups, compilers, etc?  It seems to me that C++ _will_
>#be the language of choice for programmers (except in specialized areas
>#where other languages will continue to be used). It would be nice to get a
>#balanced view of where C++ fits into the scheme of things.
>#Unfortunately, language issues often assume the aspect of a religious
>#war, with rabid supporters and detractors.
>
>I think someone ought to do some sociological research on this. I can agree
>with people claiming C++ is very complex, but I don't know any other OO
>language, so I cannot say if it is overly complex or not.
>
>All we can do is to sit down and face the facts: C++ is here to stay and
>we just have to deal with its complexities.
>
>Someone once said: C++ is the programmers revenge on managers, since C++
>may imply that programmers in the future will once again walk around in
>white coats and be payed handsomly.
>
>Mats Henricson
>Ellemtel
>Sweden


I find programmers to have a generally myopic view of C++.  I do a lot
of numerics programming (and I'm really an applied mathematician, not
a programmer), and I find C++ incredibly simplifying.  I use matrix
classes (M++) which handle all the memory, garbage collection chores
for me so I really don't have to know anything about that to do my
number-crunching.  I build classes that do optimization, linear
programming, nonlinear least squares, basic statistical description,
without having to know much more than how to use the M++ classes.  

C++ is really about designing an interface, and that implies a
division of labor - those who design the interface, and those who who
use it.  I let someone else design all the dirty stuff, and then I use
it.  If I were a manager, I'd hire a really good programmer who would
design and maintain the interface, and if it is good it won't require
gurus to use it.  The designer of M++ had to really know what they
were doing to get the memory handling right, to work out the garbage
collection and solve the temporary problem, to design efficient
algorithms for operations on four dimensional arrays.  But the people
who use it don't need to know how to do any of that.  I find using M++
like using any of the array languages, like Matlab or Gauss, except
that I have access to all of the OO features of C++ as well.


-- 
Ronald Schoenberg                    fax: 206-727-6521
University of Washington           email: rons@u.washington.edu
Newsgroups: comp.lang.c++
From: gupta@utopia.sps.mot.com (Rajesh Gupta)
Subject: Linker problem
Reply-To: gupta@utopia.sps.mot.com
Organization: Motorola, Inc.
Date: Thu, 7 Jan 1993 16:42:50 GMT

I am creating a debuggable executable by statically linking in a few
archives. However, the linker fails to recognize the symbols in one
of the ar libraries ????

I can't see where the problem could be. Any clues will be appreciated.

---  Rajesh
************************************************************************
Rajesh Gupta                                gupta@adtaz.sps.mot.com
Motorola, Inc.                     
Tel: 602 897 3991                           FAX: 602 897 3518
************************************************************************
Newsgroups: comp.lang.c++
Subject: Re: Overloading [] for 2d+ matrixes
From: hugh@kahu.cosc.canterbury.ac.nz (Hugh Emberson)
Date: Tue, 5 Jan 1993 07:41:17 GMT
Organization: Computer Science Dept., University of Canterbury, New Zealand

>>>>> On 4 Jan 1993 20:27:33 -0600, cbusch@ub.d.umn.edu (Chris) said:

Chris>    I been programming in C++ for quite a while now, but something
Chris> occurred to me, how can you overload [] for 2d or 3d plus matrices?
Chris> Apparently the only allowable syntax is:
Chris>    myclass::operator [] (int);

There are two solutions that I have come across for dealing with this
problem.

1) The Elegant solution:

If you have a class X which contains a 2d array of Y's then define a
helper class called, say Yrow, which just holds a pointer to a row in
the array.  Then you have

	Yrow& X::operator [] (whatever);

which selects the row, and 

	Y& Yrow::operator [] (whatever);

which selects the column in that row.
You use it like this.

	X a;

	a[i][j];

which expands to

	(a.operator[](i)).operator[](j);

This is how multidimensional arrays work in C/C++.

2) The not so elegant solution.

Don't use [], use () instead.

	Y& X::operator () (whatever, whatever)

and use

	a(i,j);


It should be a bit faster, but its not as pretty.  It has the same
precedence as [] too.

Hugh
--
Hugh Emberson -- CS Postgrad
hugh@cosc.canterbury.ac.nz
Newsgroups: comp.lang.c++,comp.object
From: muts@estec.esa.nl (Peter Mutsaers)
Subject: Re: Pros and cons of C++
Organization: European Space Agency
Date: Tue, 12 Jan 1993 11:53:39 GMT

>>On 8 Jan 93 14:33:09 GMT, roger@author.ecn.purdue.edu (Roger J Cass) said:

  Roger> SUMMARY-- In my observations at 2 universities (BYU and
  Roger> Purdue) and at a National Laboratory (Sandia) not very many
  Roger> engineers have embraced the OO paradigm for modelling
  Roger> physical systems and solving engineering analyses.  C++ is a
  Roger> good way to move into OOP, but does not allow the OO paradigm
  Roger> to be realized in full-- which is important to an

Until now I had the idea that C++ does not enforce the OO paradigm
fully, but still it allows you to do if you want (except that the
basic types are a bit special cases, but that's not important). If I
am wrong, could you tell why C++ cannot do this?
--
_________________________________________________________________________
Peter Mutsaers.         |================================================ 
muts@pmcs.estec.esa.nl  |        Quod licet bovi, non licet Jovi
From: slyxg@cc.usu.edu
Newsgroups: comp.lang.c++
Subject: C++ ver 3.1 for windows for sale!!
Date: 5 Jan 93 10:48:51 MDT
Organization: Utah State University

I have the most recent version of Borlands C++ version 3.1 for windows.
It is only a couple of months old and is in excellent condition.

	I am asking $105 in US currency which includes shipping, which
	will be sent COD.

It comes with all of the manuals and documents.

if interested respond via e-mail to:

		Doug
		slyxg@cc.usu.edu

Newsgroups: comp.lang.c++
From: davidd@ctsx.celtech.com
Subject: oopslooking for PerClass/SizeFreeList, oops
Date: Mon, 4 Jan 1993 14:57:52 GMT
Organization: Cellular Technical Services, Seattle



Hello, I messed up and deleted the posting "mayan" put out about
his PerClassFreeList and PerSizeFreeList, and of course I also
lost his address...Could anyone (mayan?) send me another copy?
Thanks much.

David


-- 
============================================================================
David Doll                       UUNET: ..uunet!ctsx.celtech.com!davidd
Cellular Technical Services      Seattle, WA 98121             
2401 4th Ave., Suite 808         (206) 727-6372
Newsgroups: comp.lang.c++
From: hasko@heeg.de (Hasko Heinecke)
Subject: Re: Pros and cons of C++
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG
Date: Fri, 8 Jan 1993 17:11:32 GMT

In article <79416@hydra.gatech.EDU> mhopper@emperor.gatech.edu (Michael A. Hopper) writes:
>In article <TMB.93Jan7174627@arolla.idiap.ch> tmb@idiap.ch writes:
>>
>>What do I dislike about C++?
>>
> 1. > * No type safety.
> 2. > * No pointer safety.
> 3. > * No arithmetic overflow detection.
> 4. > * No module system to speak of.
> 5. > * No garbage collection.
> 6. > * Inefficient memory management.
> 7. > * Hairy scoping rules.
> 8. > * Hairy, implementation dependent linking.
> 9. > * A number of important optimizations are impossible.
>10. > * Insufficient language support for separating implementation
>    >   dependent/unportable features from the rest of the language.
>>
>>When I don't need to interface with existing C/FORTRAN code or when my
>>algorithms get complicated enough that these latter problems with C++
>>matter, I use a different language.
>>
>>					Thomas.
>
>It's important to remember that many trade-offs were chosen for C++ for
>the sake of PERFORMANCE.  This addresses points 2 and 5 above.  I either
>disagree or don't understand what Thomas means by points 1, 3, 4, 6, 9, and
>10.  I agree that points 7 and 8 are sometimes a hassle.  
>
>Another observation I have had with learning C++ is that many of the features
>that SEEM to be extravagant become ESSENTIAL when writing template classes
>and abstract base classes.  The more experience I have had with C++, the
>more I appreciate the decisions that were made in its creation.  C++ is a
>long way from being perfect, but the improvements it has offered over C has
>increased my programming and debugging productivity.

1. Why become extravagant features of C++ become essential when you try to
solve non-trivial problems?

2. Isn't it true that these are also the cases where points 7 and 8 are
a hassle?

-- 
+-------------------------------------------------------+
| Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
| I _never_ mean what I say - and nobody else does...   |
+-------------------------------------------------------+
From: eric.hochman@factory.com (Eric Hochman) 
Newsgroups: comp.lang.c++
Subject: BORLANDS NEXT C++ RELEAS
Date: 4 Jan 93 10:03:00 GMT
Distribution: world
Organization: Invention Factory's BBS - New York City, NY - 212-274-8298v.32bis
Reply-To: eric.hochman@factory.com (Eric Hochman) 

-> I saw an add for Turbo Pascal with Objects on the back cover of a
-> magazine. I personally could care less about Pascal Object Oriented
-> Programming (POOP) but I was interested in the claim of a DPMI
-> extender included with the package. Has anyone heard if Borland
-> International plans on including such an extension with the next
-> release of Borland C++? Any rumors and/or suggested availability
-> dates?
I spoke to someone at Borland about this; got an unofficial "we plan to
do this, eventually," so I'd predict the next release of C++ will have
it.  I doubt you'll get anyone to commit to a time estimate until they
are ready to formally announce a new version of C++.
                                                                                  
Newsgroups: comp.lang.c++
From: daniels@NeoSoft.com (Brad Daniels)
Subject: Adding default conversion to char?
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Thu, 7 Jan 1993 18:52:33 GMT

I am writing a shared compound string class as a self-imposed exercise
to learn C++.  One of the things I want to do is allow people to assign
to a character within a shared string by making the assignment generate
a copy of the string with the character changed.

To achieve this, I created a "shared character" class, which is just a
character with a pointer to the shared string it comes from.  I then
overload the [] operator on the shared string to return a shared character,
and overload the = operator on shared characters to handle string cloning.
All this is fairly straightforward.

I would like, however, to allow shared characters to be treated like characters
under every other circumstance.  I.e., I want to add a rule for casting a
shared character to type int or char, which simply yields the value of the
character field in the shared character object.  I can't figure out a way
to do this,though, since char isn't really a class.  The only way I can
think to achieve what I want is to overload every operator which might
read a character value so that it knows what to do with a shared character.
Obviously, that would be a lot more work, and won't handle the case where
a function call requires an argument of type char.

Is there a way to achieve what I want?  Since this is mostly a learning
exercise, I'm not desperate for a work-around, but I'd be interested in
hearing alternate ways to implement what I want to do if the approach I'm
trying isn't feasible.


The newsreader on this machine seems to be having trouble with this news-
group, so I'd appreciate if you could e-mail replies as well as posting.

Thanks,
- Brad