HDTenEightyP/NetNews huggingface dataset:
From: dschieb@muse.cv.nrao.edu (Darrell Schiebel)
Subject: template disappointments ... (suggestions?)
Organization: National Radio Astronomy Observatory
Distribution: comp
Date: Tue, 29 Dec 1992 18:35:56 GMT


I am fairly disappointed with the template implementation in Sun's SC2.0.1
(and cfront 3.0 (I suppose)). So far two things are particularly annoying:

	(1) The inability to derive templated classes from a non-templated 
	    base class of the same name:
		class typeinfo {};
		template<class t> class typeinfo : public typeinfo {};

	(2) but worse than this minor item, it seems as though it is 
	    impossible to compose templates from templates:
		template<class t> class vector {};
		template<class t> class list {};

		list<vector<int>> list_vec_int;

	    certainly various kludges will work some of the time:

		typedef vector<int> fred;
		list<fred> list_vec_int;

	    it is certainly unfortunate that one must enumerate each
	    of the templated expansions via typedefs in order to be able
	    to use them in other templates. In addition this is not always
	    possible:

		class typeinfo {};
		template<class t> class typeinfo_ : public typeinfo {};
		template<class t> class vector {};

		template<class t>  const typeinfo *typeid(vector<t> *) {
		  static typeinfo_<vector<t>> *storedId = 0;
		                   ^^^^^^^^^
		one gets a error like:
		"test3.C", line 110: error:  type expected for name

		Try our little trick from before:

		template<class t>  const typeinfo *typeid(vector<t> *) {
		  typedef vector<t> fred;
		  static typeinfo_<fred> *storedId = 0;

		And one gets:
		"test3.C", line 102: sorry, not implemented: local typedef fred within template function

I was afraid that the implementors would end up making template second class.
I think I was better off with TI's cpp. Does anyone have any suggestions?
I haven't finished reading all of the documentation so I could have missed
something. Thanks for any suggestions.


							Darrell Schiebel
							(dschieb@nrao.edu)
Newsgroups: comp.lang.c++
From: cmchan@dcs.warwick.ac.uk (C M Chan)
Subject: Simulate "Pointer to char" by an array
Organization: Department of Computer Science, Warwick University, England
Date: Wed, 30 Dec 1992 17:22:41 GMT


Hi out there,
 
I am sorry if this is faq for this newsgroup.   Here is my question:
 
How can I simulate "pointer to char" by an array in a class whose size will be \
delayed to be
defined at run time?
 
For example,
 
 
     class X {
 
     private:
             char string[      ];    /* not define size of the array */
                              ^^^^^^^^
     public:
             X(int);
 
             ...............
     };
 
 
     X::X(int size) {
             string[size];          /*  define size of string array now  */
             strcpy(string, "Hello");
     }
 
Any pointer to this problem will be greatly appreciated.   Thanks in advance.



-- 
C M CHAN         cmchan@dcs.warwick.ac.uk
From: tmr@faceplnt.dr.att.com (54626-RebmanTM(DR1867)000)
Newsgroups: comp.lang.c++
Subject: Re: where the name C++ came from
Date: 23 Dec 92 20:52:34 GMT
Reply-To: tmr@drutx!att.com
Organization: Bell Labs, DCTT, Denver, Co.

In article <1992Dec23.162758.10645@eagle.lerc.nasa.gov>, tostan@dumbo.lerc.nasa.gov (Stan Mohler) writes:
|> Hi-
|> I had a dream last night in which I figured out a possible reason for C++
|> having the name C++.  

I think you've been working too hard... take a vacation  {:^)

-- Tom R.  (tmr@drutx.att.com)
Xref: sparky comp.lang.c++:18265 comp.std.c++:1871
From: Heliotis.ROCH803@xerox.com (Jim Heliotis)
Subject: Overloading new without redefining new&delete?
Keywords: storage debug
Reply-To: Heliotis.ROCH803@xerox.com
Organization: Xerox Corporation, East Rochester, NY
Date: Wed, 23 Dec 1992 15:44:47 GMT

We wrote a version of new that takes extra arguments (namely, file name
and line #) so that debug information can be kept with every block of
storage allocated that uses this version of new.  We are doing this to
monitor storage leaks.

That's the specific situation; now, the general problem:

Writing a custom new does not allow one to write a corresponding
delete, since delete cannot be overloaded (we're talking global
new/delete here, not class-specific).  This means that, if any special
handling is required at delete time for this custom-allocated storage,
you must rewrite the standard delete.  This in turn means that no code
has access anymore to the old delete, so storage allocated with the
standard new could not be freed.  This means that you must customize
the standard new so that delete is sure of from whence the storage
came.

Whew!  Did anyone understand that?  If so, let me know if you have an
easier solution (besides "use garbage collection").  Thanks.

============================================================================
Jim Heliotis                                       Voice Phone: 716-383-7410
Xerox Corporation                                   FAX Phone:  716-383-7395
435 W. Commercial St.                                     Mail Stop: 803-01A
East Rochester, NY 14445              Electronic Mail: JEH.ROCH803@Xerox.COM
============================================================================
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.lang.c++
Subject: Re: Give me safe C++
Date: 21 Dec 92 09:51:45 GMT
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

In article <1992Dec17.235544.5983@rd.hydro.on.ca> twriter@rd.hydro.on.ca writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>>	Next, I feel NO language has addressed the concept
>>of coroutines (except possibly Simula?). C provides
>
>There was (is) a language called Concurrent Euclid which was invented at
>the University of Toronto some years ago.  In my opinion, it addressed
>the problem of concurrency (coroutines) quite effectively.  

	In my thinking, processes differ from coroutines.
First, processes operate concurrently, and so must be synchronised,
whereas coroutines use a single thread of control that
swaps back and forward under the control of the coroutines
themselves (transfer of control is explicit).

	The other difference is that coroutines share the environment
they are instantiated in. If Unix processes cause the stack
to be duplicated, then coroutines cause the stack to fork.
>
>When the program starts up it immediately creates two processes
>(coroutines) up and down.  The output might look something like this.
>
>1 >2 >3 >2 >3 >4 >3 >2 >1 >0 >-1 >0 >...

	Random. Coroutines, on the other hand, are completely
deterministic. They are like subroutines for which the
caller and callee cannot be distinguished. (Or rather,
the distinction is relative).

>
>Euclid also provides a means of synchronizing processes using signals
>and conditions although I don't remember enough to describe it.
>

	Coroutine are sometimes used to simulate processes.
However a proper coroutine facility would have to provide
the shared memory context and forked local context.
Of course this can be simulated using objects .. but simulations
are not the same as syntax. Inventing a syntax for filters
is not so hard .. but I've never got beyond that. Perhaps
objects are the only general solution?



-- 
;----------------------------------------------------------------------
        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: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Newbie Wants Advice on C-Programming
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 3 Jan 1993 17:09:17 GMT

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. 

	C++ makes class oriented programming possible. I would
not wish to say 'C++ uses the object oriented approach'.
Programmers do that, and C++ makes many other approaches available.
For example, ADT programming -- not unrelated to the OO approach,
but with the emphasis on values rather than objects.

	Then again there is more than one OO approach: a dynamic
one (generally frowned on in C++) with Object heirarchies,
or mixins (to name but two).

>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++.
>
>This approach was much more fruitful: the C++ language became just
>a mechanism to express these object oriented mechanisms. 

	As it can be used as a mechanism for other mechanisms.
Which is why you might have failed the first time: you were
trying to teach OO and not C++.


>IMHO there are tree types of `beginners':
>
>- First time programmers;
>- Experienced programmers but still unaware of the OOD concepts;
>- Experienced programmers aware of OOD concepts, but they don't know
>  anything about the C++ language.

	Type 4 is experienced C++ programmers *with* OO knowledge.
Most of use would still consider ourselves beginners :-)
After all, the language hasn't even been officially born yet.
>
>I think that one has to be a beginner of the third kind to be able
>to learn the C++ language successfully.

	It also helps to look at the non-OO features of C++.
These are surprisingly rich and powerful: C++ being class
based does not have the dynamic power of OO systems like
Smalltalk, or even Eiffel.

	Type 3 programmers with say Smalltalk experience
often have a lot of trouble with C++. It is hard to believe
these two languages really operate on the same paradigm at all.

	Although the transition might be slower, I suspect
experienced C programmers have the least trouble with C++
style in the long run. They at least can extend their
paradigm(s) rather than having to radically alter them.

-- 
;----------------------------------------------------------------------
        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: andrew@tagsys.com (Andrew Gideon)
Subject: Re: Complexity in the eyes...V2.0
Followup-To: comp.lang.c++
Summary: That which the errorstack stacks
Keywords: error errorstack
Organization: TAG Systems inc.
Date: Wed, 23 Dec 1992 03:19:30 GMT


In article <rmartin.724631935@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>
	...
>
>ErrStack e;
>e.PushMessage("Device error");
>e.AddParam(deviceAddress);
>e.AddParam(errorCode);
>
>--
>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++


Hmm.

If I understand your proposal, you'd have me add an ordered collection
of "parameters" to the base error atom class?  Interesting thought.

Well, let me describe my vision of the error atom - something that I
stayed away from in previous posts.

The base error atom class ErrorAtom provides virtual methods
like theSeverity(), theMessage(), isWarning(), etc.  Each module
(or some other partition of code) provides a subtype of the error
atom for a specific domain of errors.  

So instances of the DeviceErrorAtom class might contain a severity
value and an offset into an array of error messages.  This array would
be a class member (static member).  This provides for easy copying of
atoms, nicely partitioned error spaces, a good starting point for user
documentation, etc.

In practice, I rarely got this far.  Instead, I used a generic error
atom which contained a severity and a message string.  The strings
were efficient, but the solution was not nearly as complete as I'd
originally envisioned.  

I can certainly envision an atom class accepting additional parameters, 
and then having these used in generating the message returned by
theMessage().  It is an good idea.  Thanks.

But I might change your example to:

	ErrorStack	err;
	DeviceError	devErr;

	devErr.theError(code);
	devErr.theAddress(deviceAddress);
	err.pushMessage(devErr);

Add a reasonable constructor, and we have:

	ErrorStack	err;
	err.pushMessage(DeviceError(code, deviceAddress));

A later call to theMessage() on that atom might yield:

	"EMP scrambled device brains at address 0x666"

Hey.  I like it.

	- Andrew Gideon

=== 
 -----------------------------------------------------------
| Andrew Gideon              |                              |
| Consultant                 |                              |
|                            |   TAG Systems inc.           |
| Tel: (201) 890-7189        |   D2-181 Long Hill Road      |
| Fax: (201) 890-1581        |   Little Falls, N.J., 07424  |
| andrew@tagsys.com          |                              |
 -----------------------------------------------------------
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: template disappointments ... (suggestions?)
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 2 Jan 1993 08:14:10 GMT

In article <1993Jan1.170812.26511@taumet.com> steve@taumet.com (Steve Clamage) writes:
>erc@netcom.com (Eric Smith) writes:
>
>>In article <1992Dec30.173230.22878@taumet.com> steve@taumet.com (Steve Clamage) writes:
>>How is >> different from > in that respect?  a>b is a perfectly valid
>>int expression.
>
>The '>' is always a '>' token.  The proposal was that sometimes '>>' is
>a '>>' token and sometimes it is two '>' tokens.  

	It doesnt have to be construed that way. One could just
extend the grammar to allow the single >> to terminate two levels of open
< brackets.

>The compiler would have
>to decide which interpretation to use.  One interpretation might wind up
>being unparseable only after an arbitrary number of additional tokens.

	The compiler has this same problem parsing '-' in the sense
that it might be a single token "unary or binary minus" or two
different tokens "unary minus" or "binary minus".
>
>Suppose there are several sets of '>>' in a template expression.  Each
>one is a branch point for additional possible parses.  The compiler has to
>verify that exactly one of a set of interpretations leads to a valid parse.

	How does this differ from '>' already causing the same problem?
>
>A whole new kind of parsing is therefore required just to allow
>programmers to omit a blank between consecutive closing template brackets.

	You may be right, indeed it appears to me you are,
but the technical question is probably whether '>>' could mean
"shift or double template right bracket" and still be parsed
using an LALR parser. (Is there an LALR grammar for C++ anyhow?)

>
>It isn't impossible to have a language like this.  The question, as
>always, is whether the additional compiler complexity and other
>disadavantages are outweighed by the advantages.  The decision in C
>and C++ has always been to choose context-free lexical analysis and
>the "maximum munch" lexical rule.

	The lexical analyser would be regular surely, not context
free, and the parser hopefully less than context free: a backtracking
parser would have no problem with '>>', but the users waiting
hours for a compile might :-)

	It is surely easy to make a rule that when two levels
of < have been seen, they are closed by >>. If you really
want a shift, use brackets.

	< ... < ... >> 

	< .. < ... (a>>b) .. >>

	This sort of rule is already in place for the stupid
comma operator. I'm certainly not suggesting we do this,
but it would be interesting to establish whether '>>'
can be implemented using the same sort of parsers
currently used for 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: jrichard@cs.cs (John 'MacGyver' Richardson)
Subject: Re: Wanted C++, LEX++, YACC++ etc.
Organization: /usr/ug/1993/jrichard/.organization
Date: Mon, 28 Dec 1992 21:35:29 GMT

In article <15010002@hpsgwr.sgp.hp.com> plim@hpsgwr.sgp.hp.com (Peter Lim) writes:

   Can any kind soul please tell me where can I get the following? Preferrably
   they should have been proven to work on HP-UX systems (both HP9000 series 300
   and series 700?)

	   [01]	A complete C++ compiler system

g++ (better known as gcc) see the FAQ for details

	   [02]	Good class libraries for the above (X11 Widget, database?)

X window classes can be implemented with Interviews3.1 and g++

	   [03]	Implementation of LEX and YACC useable with C++
		   (LEX++ & YACC++ ???).

GNU's Flex and Bison work with g++ as well.  (I can verify this as I just
finished a compiler with g++,flex, and bison. 

   E-mail:  plim@hpsgwk.sgp.hp.com   Snail-mail:  Hewlett Packard Singapore,
   Tel:     (065)-279-2289                        (ADC, ICBD-Singapore)
   Telnet:        520-2289                        1150 Depot Road,
						  Singapore   0410.

I believe the source for g++, flex, and bison are at prep.ai.mit.edu and
look at comp.windows.interviews for places to find interviews.  All are
currently freely available with code.

John Richardson            |"sun dogs fire on the horizon        \ \   \
jrichard@cs.ulowell.edu    | meteor rain stars across the night   * *   \   /\
			   | ...the spark still flies                /\  * /  \
"Anyone have some duct 	   | reflected in another pair of eyes." /\ /  \/\/
tape?!?"	           |              -- Neil Peart    ------  \   / / 


Newsgroups: comp.lang.c++
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re:  Give me safe C++
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Mon, 21 Dec 1992 14:17:35 GMT

In article <BzICnn.LDx@fiu.edu> feathers@serss0 (Michael Feathers) writes:
>My conclusion was that run time checking was being used as a crutch.

Be careful what you say.  I have heard managers object to debuggers because
the people used them as a crutch.  While I agree with you that it is good
to code properly in the first place by habit, I disagree with your implied
reluctance to use the tools at your disposal.  There are those who object
to code walkthroughs done by computer (i.e. using the debugger to step 
through code to make sure that it does what it is supposed to do), and I
suppose there are still those who insist on checking their code for syntax
errors before running the compiler.  Are you sure that the runtime checking
was being used as a crutch and not a development aid?

Stuart

--
: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Virtual base classes
Organization: Rational
Date: Tue, 22 Dec 1992 15:02:46 GMT

roger@genie.UUCP (Roger H. Scott) writes:

|In article <724475492snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk writes:
|>In article <445@genie.UUCP> roger@genie.UUCP (Roger H. Scott) writes:
|>> If Kludge is a non-public subclass of WellFormed then there
|>> isn't much point in talking about Kludge redefining WellFormed's virtual
|>> functions since you can't use a Kludge in a place where a WellFormed is
|>> expected (i.e., who would ever have hold of a Kludge and send it one of
|>> WellFormed'd messages, other than a member function of Kludge?).
|>
|>Imagine that WellFormed's constructor adds all WellFormeds to some 
|>Collection of WellFormeds. Notice that all Kludges will also be added to 
|>this collection. Now imagine some calling some virtual function for all 
|>WellFormeds in the Collection.

|This seems to raise an interesting question: does there exist an Is-A
|relationship between Kludge and WellFormed, and if not, what does it mean to
|have a collection of objects that *claim* to be WellFormeds but are in fact
|Kludges?  

Whether there is an ISA relationship between WellFormed and Kludge
depends upon who you are.  Page 244 of the ARM says: "Members and
friends of class X can implicitly convert an X* to a pointer to a
private immediate base class of X."  Thus, for friends and members of
Kludge, the ISA relationship exists.  But for any other function, the
ISA relationship does not exist.  

Thus, a member function or friend of Kludge can convert a pointer to a
Kludge to a pointer to a WellBuilt and return it.  This will allow
other functions to manipulate the Kludge as a WellBuilt.  Its virtual
functions will behave normally.  

In Nikki's example, it is the constructor of WellFormed that puts the
newly constructed object onto a list of WellFormed.  Other functions
can then use these objects, not knowing that they are Kludges.  The
virtual functions will be deployed as usual.

|Do we see a small whole in the type system here, where within
|member functions inherited from a non-public base class an object which
|is in fact a Kludge can be used interchangably with an object that is a
|WellFormed (the example cited by Nikki uses the base class's constructor, but
|any member function of the base class will do)?  

There is no real hole in the type system.  A Kludge object can
masquerade as a WellBuilt as long as the pointer or reference to the
WellBuilt is created by WellBuilt's constructor, or one of the members
or friends of Kludge.  The point is that none of Kludge's clients
knows that it is really derived from WellBuilt.  This fact is
completely hidden from 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++
From: jordan@aero.org (Larry M. Jordan)
Newsgroups: comp.lang.c++
Subject: Re: Zortech C++ v3.1
Date: 23 Dec 1992 19:00:50 GMT
Organization: The Aerospace Corporation
Distribution: usa
NNTP-Posting-Host: daystrom.aero.org

In article <1535@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
>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.
>
[stuff deleted]
>
>/[3] Does the debugger support AT&T version 3.0? 
>
>	I'm not sure what you mean here.
>
Does the debugger 'understand' templates, for example? (I hope!)

--Larry %)
From: nicted@toz.buffalo.ny.us (Nicole Tedesco)
Newsgroups: comp.lang.c++
Subject: C++/Views: A Model-View-Controller Library For C++
Date: 26 Dec 92 16:26:37 GMT
Organization: The Tower of Zot - (716)8338-616

Has anyone ever used C++/Views?  Any comments?  Suggestions?  Gripes?
I am planning on using that library in an upcomong C++ project.

Thank you!
- Nicole Tedesco

---------------------------------------------------------------------
nicted@toz.buffalo.ny.us (Nicole Tedesco)
-- Change this!
Newsgroups: comp.lang.c++
From: isc@panix.com (David Koosis)
Subject: Re: Lex-compatible grammar for C++?
Date: Wed, 30 Dec 1992 20:04:11 GMT
Distribution: usa
Organization: PANIX Public Access Unix, NYC

In <1992Dec29.215541.17559@cs.tulane.edu> cleeland@cs.tulane.edu (Chris Cleeland) writes:


>Does anybody know where I might find a lex-compatible grammar
>for C++?

There's a yacc-ish grammer in the public domain which can be found 
various places:

check FAQ in comp.compilers (& here in comp.lang.c++ ?) for
locations.

(I'm assuming that you meant yacc rather than lex, no?)

best,
dkoosis
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ISC Consultants // Technical Training & Consulting Since 1973 // 212.477.8800
Newsgroups: comp.lang.c++