HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Arrays and Lists
Keywords: const, const member, lazy
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 2 Oct 1992 15:21:23 GMT

In article <1992Oct1.170427.8044@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>In article <1992Sep29.160411.9737@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>>In article <1992Sep29.140750.29438@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>>>[The]
>>>	operator[](int index)
>>>should not be a member of a list class. Lists only provide sequential
>>>access; Arrays provide random access.
>>
>>	I dont agree really. If you can get the first element,
>>and get the next element, then you can get the n'th element.
>>As far as I'm concerned, a list is an array with 'insert' and 'remove'
>                                 ^^^^
>>operations.
>
>Is that really an "IS-A"? Just like in public derivation of one class
>from another? Would  you write
>
>class List : public Array {
>  // ...
>};
>
>for example? 

 	Yes. Indeed:

	template<class T>
	struct array {
		virtual int operator+()const=0; // n elements
		virtual T& operator[](int)=0;
		virtual const T& operator[](int)const=0;
	};

	template<class T>
	struct list : public virtual array {
		virtual void insert(const T&,int);
		virtual void remove(int);
	};
	

>I'm just checking, because I don't want to read more into
>your statement than you may have intended. For me, an Array is primarily
>characterized by supplying constant-time random-access to any of its
>elements. 

	So an array is a data structure. But my array is an abstraction.
No mention of contiguous storage. It is a map 

	array: 0..n -> T,

in which n is constant, but the T elements are mutable.
A list is the same without the restriction on n.

I suppose I should have called it an extensible array, not a list.

>The two are equally primitive; one can be implemented
>in terms of the other; forcing a particular dependence or implementation
>seems to me to be to restrictive.
>

	I didnt even mention implementation. My 'array' and 'list'
are ADTs. It is mathematical nonsense to have a 'sequential
data structure'. If you can get the 'nth' element of a list,
then you can get the n'th element of the list.

	A genuine sequential access list would allow
only access to the top element, would have a destructive
next operator, and would not allow assignment or copying.

	If you can copy a list, you can get the n'th element.
If you can get the n'th element, why make it hard for the user?

	Anyhow, perhaps what I've done is used my own
private meanings for 'array' and 'list' as ADTs, certainly
the ability to insert and delete in the singly linked list
data structure influenced my decision to call an array
with insert and delete a list.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Xref: sparky comp.lang.c++:14487 comp.std.c++:1294
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: declare keyword, type inference
Date: 4 Oct 92 01:36:54 GMT
Reply-To: tmb@idiap.ch
Followup-To: comp.lang.c++
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: maxtal@extro.ucc.su.OZ.AU's message of 1 Oct 92 17:59:58 GMT

In article <1992Oct1.175958.725@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

   How do you feel about:

	   int x,y;
	   long z;

	   declare var=z+x*y;
	   declare const cvar=x/y;

   that is, when 'declare' (or dcl for short like PL/1) is used,
   the type is infered from the initialisation. Am I correct in
   assuming that the type is always determined?

C++ made a decision to go with overloading. Overloading doesn't
coexist well with type inference.

   Would this be 'a good thing' or do you hate it?  Does the syntax
   actually work?

Type inference is important when you use very complicated data types
(often involving higher-order functions) and (Milner-style)
polymorphism, since without it, you'd spend most of your programming
effort on trying to come up with the right type for every variable.
But C++ is not very well-suited to expressing those kinds of problems
in the first place because of other limitations (e.g., no closures).
For many of the domains to which C++ is well suited (e.g., numerical
code involving linear algebra, complex numbers, geometrical objects),
I find that overloading is more useful than type inference.

					Thomas.
Newsgroups: comp.lang.c++
From: cok@islsun.Kodak.COM (David Cok)
Subject: Re: declare keyword, type inference
Organization: Eastman Kodak Co., Rochester, NY
Date: Tue, 6 Oct 92 16:06:34 GMT

In article <23810@alice.att.com> ark@alice.UUCP () writes:
>In article <5044@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>
>> : But we can't do this because C already requires x, y, and n to be int in
>> : the declarations above and I don't think we can get away with breaking
>> : C compatibility here.
>
>> Why not?
>
>It's a pragmatic judgment on what I think the standards committee
>and user community will be willing to accept.
>
>I would be delighted to see myself proven wrong in this case.
>-- 
>				--Andrew Koenig
>				  ark@europa.att.com
I wonder how often people have explicitly declared something "auto"?
Adjusting the meaning of "auto" would break C compatibility, but I 
am not sure it would break a lot of code. (At least it wouldn't break mine.)

David Cok
cok@Kodak.COM

Newsgroups: comp.lang.c++,comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Conceptual Constness
Keywords: const, const member, lazy
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 1 Oct 1992 16:50:34 GMT

In article <1ackm3INNno2@fido.asd.sgi.com> linton@marktwain.rad.sgi.com (Mark Linton) writes:
>This subject has been visited in the past.  There have been several language
>proposals, though I don't know if any are being taken seriously.
>
>Several people missed the basic issue, which is that you have a member function
>that you want to be able to pass a const object (such as a const parameter)
>but the implementation of the function wants to modify member data.
>This happens commonly for cached or lazily-evaluated data, where modifying
>the data doesn't change the future behavior of the object.  The example I typically use
>for this is a matrix object that has an identity() test.  It is easy to imagine that
>
>    We want to call identity() on a const matrix.
>    We don't want to compute the identity test until necessary.
>    We don't want to compute the identity test more than once for the same matrix.
>    We can use access functions to detect changes to the matrix.
>    We don't want a pointer to an extra structure for the matrix representation
>        because we want to create matrices on the stack quickly.
>
>Perhaps most importantly, we shouldn't have to change the specification
>of identity() if we decide to change the implementation (switching between
>non-caching and caching or lazy and non-lazy, for example).
>
>Splitting the class into two classes, one read-only and one read-write doesn't help
>because we really want to call the member function in question on an immutable object

	Spliting into two classes DOES help. IMHO it is cheating
just like casting away const but it works:

	class cache {
	public: int isIdentity;
	};

	class Matrix {
		cache* p;
		int Identity()const { .. actual calculation .. }
		......
	public:
		.....
		int isIdentity()const
		{
			if(p->isIdentity==-1)p->isIdentity=Identity();
			return p->isIdentity;
		}
	};
	
>
>There are only two solutions as the language currently stands.  One is
>to cast "this" to a non-const object in the member function.  I agree with
>the original poster that this is ugly, but I suspect others find it
>acceptable enough to classify the whole problem as low priority.
>
>The other solution is not to use const at all.  The downside of this approach
>is that without const you cannot really use ref parameters without risking
>warning messages when you construct temporaries for arguments
>(some compilers are unhappy when you pass a temporary to a non-const ref).
>Without refs it becomes a bit more painful to use objects with natural definitions
>for operations, such as comparisons on strings.

	And the third method is to use a pointer.
-- 
;----------------------------------------------------------------------
        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: adam@dadhb1.ti.com (Adam Hudd)
Subject: Re: Problems with Abstract base class and pure virtual functions.
Organization: Texas Instruments, Inc., Houston, TX
Date: Tue, 29 Sep 1992 18:27:11 GMT

(Mike Carney) writes:
   (KMR) writes:
      I could not find an answer to my problem  of abstract base class
      and pure virtual functions in ARM, any help will be appreciated.

      Consider the following:

      class A {
	  public :
	      int i;
	      virtual void foo1() = 0;
	      virtual void foo2() = 0;
	      virtual void g() {} 
      };

      class C : virtual public A {
	  public :
	      virtual void foo2() = 0;
	      virtual void gG() {}
      };

      class B : virtual public A {
	  public :
	      virtual void foo1() {}
	      virtual void foo2() {}
      };

      class D : public B, public C {
	  public :
	      virtual void foo2() {}
      };

      main()
      {
	  D *bb = new(D);

	  bb->i = 1;
	  bb->foo1();  
	  bb->foo2();  
      }

      When compiling the above on SUN 2.1 Cfront, the compiler fails 
      informing me that D is an abstract class and thus cannot be "newed"
      I can rationalize the cause of failure (though I am still not certain)
      however seeing it documented and the case explianed will help.

      kmr@netcom.com

   I think that your real problem here is that class C does not have an
   implementation of foo1(). If a class is an abstract class (i.e. any of
   its virtual members is declared line foo1() and foo2() in class A
   above), then all of its derived classes *must* have implementations of
   those virtual member functions that were declared abstract. The error
   you got sounds like a bug in the Cfront that you have. I hope that
   this is helpful.

Mike this doesn't work either.  I just tried it by adding

  virtual void foo1() = 0;

to class C. BTW I compiled KMR's original and got exactly the same on my
Domain/C++ 2.1.0 compiler.
--
Adam Hudd               adam@dadhb1.ti.com             __o
Texas Instruments Inc,                                -\<,
Houston, TX                                     .....O / O
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Persistance Problem Solved by Memory-Mapped Files?
Organization: Rational
Date: Wed, 30 Sep 1992 00:57:08 GMT

feustel@netcom.com (David Feustel) writes:

|I'm wondering whether the problem of persistant objects could be
|solved by use of memory-mapped files to store the C++ data structures
|used by C++ programs. Comments?

I know someone who has cooked up some classes which use mapped files
to provide some persistence.  In his model, you derive your classes
from the persistent class.  The persitent base class provides all the
member functions for mapping the object to the file.

Pointers are problematic.  As long as every application maps the file
into the same address space, then persistent pointers to persistent
objects may be sharable between processes.  If the mapped file is
being shared between two processes, it is important that the
persistent objects not internalize any pointers to local
(non-persistent) objects.

If the mapped file cannot be mapped into the same address space for
each process that uses it, then persistent pointers to persistent
objects will be useless.  This is a big disadvantage since most
persistence mechanisms need to store the structure of societies of
objects rather than just the objects themselves.

Some means must be found for making the methods that act upon objects
safe for multiple threads.  This is non-trivial. 

--
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++
Xref: sparky comp.lang.c++:14460 comp.std.c++:1289
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: Conceptual Constness
Date: 2 Oct 1992 20:33:51 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu


In <1afrmuINN93r@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe Buck) writes:
>> For such objects, "delete" would
>> do nothing, since no action is required to free the statically allocated
>> memory.  This would only be permissible if operators new and delete
>> were not overloaded.
>
In article <aldavi01.718004230@starbase.spd.louisville.edu>
aldavi01@starbase.spd.louisville.edu (Arlie Davis) writes:
>You assume that the constructor and the destructor do nothing but modify
>the state of the object.  This is very often not the case.  Many objects
>register themselves in a collection of other objects on construction, and
>remove themselves from the collection on destruction, or do other such things.

I asssume no such thing, as would have been clear if you hadn't lopped off
one short passage from its context.  The shortcuts I propose can only be
done when the complete constructor and destructor bodies are visible at
the point where the object is declared, and there are no side effects like
the ones you speak of.  This usually requires inline constructors and
destructors (or the lack of one or the other).

To make it clearer, consider the following:

class DumbVector {
private:
	double * data;
	int myLength;
public:
	DumbVector(int n) : myLength(n), data(new double[n]) {}
	~DumbVector() { delete [] data;}
	int length() const { return myLength;}
	double& operator[] (int idx)
	{
		if (idx < 0 || idx >= myLength)
			throw RangeError(*this,idx);
		return data[idx];
	}
};

Now, given the declaration, at file scope:

DumbVector globalVector(1000);

I was pointing out that this object can be initialized at compile time,
by turning it (in a cfront-like implementation) into

struct DumbVector globalVector = { _ptr_somedata, 1000 };
double _ptr_somedata[1000];

and not generating any code to construct or destruct it.

The fact that this cannot be done in general doesn't prevent it from
being done in cases where it is possible.  And there are many more cases
where part, but not all, of the initialization can be done with techniques
such as these.  As is pointed out in John Reiser's paper "Static
Initializers: Reducing the Value-Added Tax on Programs", (from the 1992
Usenix C++ Conference), code to do static initialization of objects has a
large cost in large programs, partly because it tends to page-fault in
the entire application.  The more initializations we can avoid doing at
program startup, the better.  The fact that, as Arlie Davis points out,
we can't do it in every case shouldn't stop us from handling the common
cases where we can.

--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.lang.c++
From: optkap@hp4at.eunet.co.at (Hochleitner)
Subject: NIHCL:Problems with I/O-streams
Organization: EUnet EDV-Dienstleistungsgesellschaft m.b.H
X-Newsreader: Tin 1.1 PL4
Date: Tue, 6 Oct 1992 07:31:29 GMT

I have installed the NIHCL-3.0-package on a Sparc with AT&T C++2.0. But there
exist very hard problems. All verify facilities do not succeed. The Problem
has something to do with the streams, but I couldn't locate the problem exactly till now. Perhaps I have a troublesom configuration file.
Is there someone out there who can help me in this field and/or has
allready successfully installed the NIHCL package on a similar Configuration?
Any hints are very appreciated


-- 
------------------------------------------------------------------------------
Andreas Hochleitner                    phone: +44 1 81111 4139
<<< KAPSCH AG                            fax:   +44 1 81111 4156
A-1120 Wien,Wagenseilg. 1              email: Andreas.Hochleitner@kapsch.co.at
Newsgroups: comp.lang.c++
From: mcgrant@isl.stanford.edu (Michael C. Grant)
Subject: Deriving classes for the sole purpose of adding new methods
Organization: Information Systems Laboratory, Stanford University
	<23794@alice.att.com> <TMB.92Oct4201915@arolla.idiap.ch>
	<23797@alice.att.com> <1992Oct04.231318.109058@watson.ibm.com>
Distribution: all
Date: 6 Oct 92 02:31:43


In article <1992Oct04.231318.109058@watson.ibm.com>
lrn@watson.ibm.com (Lee R. Nackman) writes:
   In article <23797@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
   |> In article <TMB.92Oct4201915@arolla.idiap.ch> tmb@idiap.ch writes:
   |> > 	template <class T> typedef Array<Array<T> > Foo;
   |> Does this buy anything over
   |> 	template <class T> class Foo: public Array<Array<T> > { }
   Yes.  Foo won't have any constructors or operator=() that Array<T> has.
   Lee Nackman

And, the constructors are not inhereted.

Boy, and what a bummer that is. Suppose I've defined a Matrix<T> template
class (with the obvious function). I would, for consistency, like to
define

class doubleMatrix : public Matrix<double> {}

class complexMatrix : public Matrix<complex> {
public:
// methods specific only to complex matrices, like Real(), Imag(), Conj()
}

This is perhaps a poor example because certainly Real(), Imag(), and Conj()
could easily be defined for the doubleMatrix class as well, and have the
correct meaning.

But, my point is that doubleMatrix and complexMatrix are inherited from
another class (not necessarily templated, I might add!), for the sole
purpose of defining a new class with additional methods---and yet, I cannot
do this without re-defining every constructor, which may be especially
painful if the constructor had varargs (something I personally avoid, though). 

Why not allow such a construction? perhaps even add a keyword to the 
'public, protected, private' inheritance type keywords to signify just
such a mechanism, such as 'expand' or 'enhance'.

Michael C. Grant
mcgrant@isl.stanford.edu
From: Hendrik.Boom@mailbox.bison.mb.ca (Hendrik Boom)
Newsgroups: comp.lang.c++
Subject: Re: GOTOo wars
Date: 23 Sep 92 17:33:16 CST

Organization: Visual Edge Software, St. Laurent, Quebec

mat@mole-end.matawan.nj.us writes:
: 
: Well, as one who spent some months enhancing a compiler, which is, after
: all, a code generator, I'd like to find a processor whose instruction
: set supports the Structured Constructs.
: 
Burroughs 1700 series were microcoded to support the Structured Constructs.

 * Origin: The Electronic Mailbox (1:348/7.0)

Newsgroups: comp.lang.c++
From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Subject: Re: yacc in c++?
Date: Tue, 29 Sep 1992 18:27:07 GMT
Distribution: usa
Organization: TU Darmstadt

In article <CARNEY.92Sep29085216@rocky.rational>, carney@rocky.rational (Mike Carney) writes:
> 
> In article <1992Sep29.011845.3409@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
>    In <BvB5oD.4FD@cs.columbia.edu> igor@cs.columbia.edu (Igor Pankevich) writes:
> 
>    >I am a student (forgive me if this is a FAQ, I couldn't find the
>    >answer at my site.)  I need to write a yacc grammar that will work
>    >with my c++ program.  Where can I find a version of yacc to do this?
> 
>    *****>	Standard yacc works with C++; you just have to write your own
> 	   .y.c (or .y.o) rule to replace the "extern char *malloc()" line
> 	   with "#include <stdlib.h>"
> 
> Not it the version of yacc that I have (SunOS 4.1.2). The output from
> this is K&R C, which will not compile with a C++ compiler. Therefore,
> I cannot have (with my version of yacc) C++ actions in my grammar. In
> fact, I've only seen third party products, and a special version of
> yacc from Sun called yacc++, which work properly with C++ code.

Then use bison. Available from all sites which keep GNU software. I've
used its output with C++ without changes. (Actually, without changes
during the usage. At installation time I added a prototype for
alloca() to the parser skeleton. ;-)

Or use bison++. It outputs the parser as a C++ class which can be
instantiated.

bison++ is available via anonymous ftp
    in the US:
	wilbur.stanford.edu
	directory /pub

    in Europe:
	ftp.th-darmstadt.de [130.83.55.75]
	directory /pub/programming/languages/C++/tools

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
From: Eric.Taylor@mailbox.bison.mb.ca (Eric Taylor)
Newsgroups: comp.lang.c++
Subject: Re: How does a template work?
Date: 25 Sep 92 03:51:16 GMT

Organization: TIVOLI Systems, Inc.

In article <books.81.0@fsunuc.physics.fsu.edu>, books@fsunuc.physics.fsu.edu (Roger Books) writes:
|> This is a rather generic question, I can't seem to find anything on
|> templates in any books in my local bookstores.  I've already read through
|> and understand (fairly well, need more practice) several books.
|> 
|> Any pointers on where to look or what they are would be appreciated.
|> 
|> Does DJGCC or GCC support templates?


Lippman's C++ Primer describes it.

I am not sure how to define it well in words.
An example is worth a thousand words:

Suppose you want to make yet another linked list library
that works for anything in the world.
You would like an integer linked list and a floating point linked
list and you would like to use the same interface.

this is where templates come in.
They would allow you to define a class where the type
of the inserted item is a "parameter".  Very much like
a macro.

i.e.

template <class ItemType>
class LinkNode {
	ItemType item_type ;
	LinkNode *next ;
	LinkNode *previous ;
} ;


main()
{
	LinkNode<int> int_node ;
	LinkNode<double> doub_node ;
}

 * Origin: The Electronic Mailbox (1:348/7.0)
Newsgroups: comp.lang.c++,comp.realtime
From: riedel@cbnewsm.cb.att.com (david.p.riedel)
Subject: C++ and RTOS's
Organization: AT&T
Distribution: usa
Date: Wed, 30 Sep 1992 13:15:25 GMT
Followup-To: poster
Keywords: C++, realtime


Does anyone out there have any experience or knowledge of
a C++ compiler to be used in conjunction with a real time
operating system for a 80x86 target processor.  What combinations
of the above have been successfully used for real time embedded systems 
projects.  Any advice or suggestions would be greatly
appreciated.  By the way the host development system for the above 
is a PC.  Thanks in advance for any help offered.

Newsgroups: comp.lang.c++