HDTenEightyP/NetNews huggingface dataset:
From: pkturner@world.std.com (Prescott K Turner)
Subject: Re: Conceptual Constness
Keywords: const
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 30 Sep 1992 09:42:22 GMT

Johan Bengtsson writes:
> pkturner@world.std.com (Prescott K Turner) writes:
> : Another workaround is to have two classes, the conceptually const class
> : being the base of the regular class.
> 
> I don't understand how this helps you avoid cast-from-const.
> Could you provide an example?

You don't use 'const'.  Here's how the technique would work out in the 
interface to a numeric class:

	// The conceptually const class is just like a plain 'number' class,
	// except that the non-const member functions are private.
	class const_number {
	public:
		const_number (const_number &);
		friend const_number zero ();
		friend const_number one ();
		friend const_number operator+ (const_number, const_number);
		friend const_number operator- (const_number, const_number);
		friend const_number operator* (const_number, const_number);
	private:
		const_number & operator= (const_number &);
		const_number & operator+= (const_number &);
		friend class number;
	};
	
	// The conceptually modifiable class makes the non-const member functions
	// available.
	class number : public const_number {
	public:
		number (const_number &n) : const_number (n) {}
		number & operator= (const_number &n) { *(const_number *)this = n; }
		number & operator+= (const_number &n) { *(const_number *)this += n; }
	};
	
The derivation of number from const_number provides the conversions you
need from number to const_number, const_number to number, 
number* to const_number*, and number& to const_number&.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com

Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Can a class inquire about subclass data members by name?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 1 Oct 1992 15:59:15 GMT

In article <1aciv3INNlu@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992Sep30.145631.26176@wl.com> agrafiot@wl.com (Dimitris Agrafiotis) writes:
>>1. Can a class find all its subclasses ?

	Please dont use sub/superclass terminology. Inheritance in C++
is not restricted to forming subtypes.

	It is not sensible to ask if a 'class' can 'find' anything.
Classes exist only in the mind of the compiler:-).

	IMHO (and most other do not agree with me :-) it is plain
bad news to attempt to obtain ANY information about an object
not statically known.	That is the purpose of having a declared
interface.

>>2. If 1 is true, can it find the names of the data members of its subclasses ?

	How would you use this information? There is no way
to connect the textual name of a data member with that member
in general.

>>3. If 1 and 2 are true, can you write a piece of code in the superclass
>>   that sets the values of these data members ?
>
>The answer to all of these is "no".  C++ provides no built-in facilities
>for inspection of the class structure.  As with ordinary C (and most other
>languages), names only exist at compile time.

	This is how it should be (IMHO).


-- 
;----------------------------------------------------------------------
        TIM (TAL) LISTER,         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: westes@sti.com (Will Estes)
Subject: Declaration for constant pointer to array of constant ints?
Organization: Mail Group
Date: Sun, 4 Oct 1992 21:23:02 GMT

The subject line more or less says it: how do you declare a constant pointer 
to an array of constant ints?  Please send the answer by mail if you feel
the question is too basic for discussion on the list.  Thanks!

-- 
Will Estes		Internet: westes@netcom.com
Newsgroups: comp.lang.c++
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: The concept of templates considered ill designed
Summary: it's just current implementations; the workaround isn't a problem
Date: 7 Oct 92 03:29:11 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <RAYMOND.92Sep28145010@cobra.es.ele.tue.nl> raymond@es.ele.tue.nl (Raymond Nijssen) writes:
>If this is true, then I'm afraid the design of the concept of templates has
>some heavy repercussions for any programmer using it: you'll have to #include
>almost all *.h and *.cc files into most .cc files, which is little different
>from putting all your code into one big file, particularly wrt. compiling it.
>[...]
>Or... is gcc 2.2.2 flaky wrt. templates?

All current compilers implementing templates are a bit flaky wrt
templates.  Nevertheless, after several months of using them, I would
just as soon use a C compiler as a C++ compiler without templates.
Templates are much better than and go far beyond what could be done
with macros.  A macro template-like function would have to be
explicitly declared in order to be used during overloading resloution.
A macro template-like class is a pain to debug and requires a
centralized declaration (eg, two .h files couldn't both
DECLARE_LIST(String)) and definition.

The next version of compilers will probably be smarter and should be
much more correct.  Remember that all these compilers are first
generation implementations of templates and that the ANSI C++ draft
isn't even out yet.

An upwardly-compatible solution would be to have your .h file, which
defines the template class/function, #include its .cc file at the end.
Wrap this #include statement in a conditional for implementations
which don't require this.  Users of your templates then only need to
#include your .h file.  Your template code is still separated in a .h
and .cc file.  I like this system and it works well for me.

Remember, though, that templates cannot be compiled to object code (at
least in the usual sense).  Because of the few restrictions on how
template parameters are used (a good thing, IMHO) the template code
must be recompiled for each set of template paramaters.  This means
that the only way a library vendor could distribute only header and
object files would be if compilers started "compiling" templates into
a parsed sequence of tokens which were then stored in the object file
(basicly, it could only perform the preprocessing phase).  The linker
would then have to compile these tokens, substituting the user's
template parameters.

Jamshid Afshar
jamshid@emx.utexas.edu
Newsgroups: comp.lang.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: downcasting (was Re: GOTOo wars)
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Tue, 6 Oct 92 15:31:33 GMT

In article <1992Oct4.114145.21060@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John  
MAX Skaller) writes:
> >And templates only help in defining homogeneous container classes.
> >If you really need a heterogeneous list, it's hard to avoid castdowns.
> >
> 
> 	I cant agree with this.
> 
I'm not willing to pick up our old argument, John. But...

 
> 	typdef [Base,D1,D2,D3] *T;
> 
> and use the Base* for polymorphic calls and the D1, D2 and D3 
> pointers for heteromorphic ones.
>

   T t;
   t = new D1; // okay;

   t->MemberFunctionOnlyInD1(...);  // Is it required? Is it a downcast?

   D1 d1 = t;  // Is it required? Is it a downcast?

   void foo (D1 *d1);
   foo (t);    // Is it required? Is it a downcast?

If "T" cannot be passed to a narrowed interface by downcast, 
what's the use of the tagged pointer? I can use Base* for the 
same purpose.

Type-safe downcast nerver casts objects in different types. 
I think we should avoid using the wrod "downcast" because it 
relates to something like type cast. What is the proper word? 
Will you suggest one? I give the definition as follow:

     ?Downcast? passes an object of type T from an interface C 
     (C comprises T) to a narrowed interface C' (C comprises C'  
     and C' comprises T).

 
    
David Shang
Newsgroups: comp.lang.c++,comp.std.c++
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: The concept of templates considered ill designed
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Mon, 5 Oct 1992 16:00:22 GMT

In article <0enxJ1W00awTMNepU8@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
>Excerpts from netnews.comp.lang.c++: 5-Oct-92 Re: The concept of
>template.. Andrew Koenig@alice.att. (287)
>
>> In article <Ienr=wm00awU8A=Ecc@andrew.cmu.edu> osoelgaultier+@CMU.EDU
>> (Stefan Monnier) writes:
>
>> > But the suggested 'templates with type constraint' would
>> > permit to change it into an implementation issue.
>
>> Really?  Why do you think so?
>> -- 
>> 				--Andrew Koenig
>> 				  ark@europa.att.com
>
>
>As are currently implemented templates, you don't know
>anything about the actual type at compile-time.
>So that no method calls or variable accesses can be compiled
>for any variable of 'template type'.
>
>The only thing you can do at compile-time with those variables
>is to store them and retrieve them in a structure, but, again, 
>without making them execute anything.
>
>A hashtable (which requires the type to have at least a
>'hash' method) couldn't be compiled, as the compiler 
>can know where the 'hash' method will be in the actual type !
>
>That's why Eiffel has those type constraints: it's not a feature,
>it's just necessary to be able to compile it separately ! (and to
>typecheck separately also)
>

	But this has very little to do with templates.  Constrained parameters
and no further knowledge of the actual type is equivalent, as far as I can see,
to simply carrying around a pointer to the actual class, and dealing with it
only through the known interface.  You don't need templates to implement this,
and I don't see that there's anything gained by using the template mechanism
to do it.
	Templates avoid the extra indirection that's needed when you don't
know what type you're dealing with.
From: Tim.Budd@mailbox.bison.mb.ca (Tim Budd)
Newsgroups: comp.lang.c++
Subject: Interaction templates/const member functions
Date: 24 Sep 92 21:36:09 CST

Organization: Oregon State University, Computer Science Dept.

Don't know if this is a bug in g++ (version 2.2) but it seems to disagree with
my reading of the ARM.  This has to do with an odd iteraction between
template classes and constant member functions.

Consider the following simple program:
---------------------
template <class T>
class box {
public:
	box(T & v);
	void foo () const;
private:
	T value;
};

template <class T> box<T>::box(T & v) : value(v) { }

template <class T> void box<T>::foo() const
{
	cout << "foo " << value << '\n';
}

main() {
	const box<int> x(5);
	x.foo();

}
----------------
If I remove the template stuff, substituting int for T, it works as expected.

With the template stuff, g++ complains about the consts, 
giving the following messages:

contest.cc: In function `int  main ()':
contest.cc:10: template for method `foo' doesn't match any in class `box<int>'

My reading of ARM page 177, however, seems to indicate the program is
correct.  If I remove the first two const's the program compiles, but
gives the expected error message about using a non-const member function
on a const object.

Any suggestions?

 * Origin: The Electronic Mailbox (1:348/7.0)
From: sbate@atl.ge.com (Stephen Bate)
Newsgroups: comp.lang.c++
Subject: (Q) Lispish class libraries for C++?
Date: 6 Oct 92 15:37:20 GMT
Reply-To: sbate@atl.ge.com
Organization: GE Advanced Technology Laboratories

Could someone please supply me with information on C++ class libraries that
implement Lisp-like list manipulation and garbage collection. Either
PD or commercial products are of interest. Thanks.

--
Stephen Bate                |
GE Advanced Technology Labs | Internet: sbate@atl.ge.com
300 Route 38, Bldg. 145-2   | Voice: 609-866-6603
Moorestown, NJ 08057        | Fax:   609-866-6397
From: yhong@cs.utexas.edu (Yu Hong)
Newsgroups: comp.lang.c++
Subject: C++ debugger running on SUN
Date: 26 Sep 1992 02:24:19 -0500
Organization: CS Dept, University of Texas at Austin
Distribution: usa
NNTP-Posting-Host: needmore.cs.utexas.edu
Keywords: dbxtool, gdb?

Could someone tell me what I can use to debug a C++ programm on
Sun? I tried dbxtool and it only worked for c.

Thanks.

Hong Yu
Newsgroups: comp.lang.c++
From: acmtsv@gsusgi2.gsu.edu (Thomas Scott Vaughn)
Subject: Finding good applications for c++
Organization: Georgia State University
Date: Wed, 30 Sep 1992 23:53:42 GMT


I'm doing research on the use of OOPL by the private sector.  I'm
looking for some common benefits and problems that software developers
have experienced using C++, in order to get a better understanding
of what OOP is good for.  I'm especially interested to hear about 
the specific failures you've had using C++.  Was it too complex?  Too
cumbersome?  Please take a minute to fill out the following
questionaire and mail it to me.  Feel free to be as verbose or as
brief as you like.  Any responce will be appreciated.

Thanks.
Tom Vaughn
acmtsv@gsusgi2.gsu.edu

------------------------------------------------------------------
Name (optional):


Company and location (optional):


Applications:


Benefits gained from using OOP:


Problems incurred from using OOP:


Newsgroups: comp.lang.c++
From: ron@syacus.acus.oz.au (Ron Williams)
Subject: Borland Class Browser
Organization: ACUS Australian Centre for Unisys Software, Sydney
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 29 Sep 1992 07:03:41 GMT


Is anyone else disappointed with the Borland C++ 3.1 class browser? I had 
hoped that the browser this time around would have allowed the (rudimentary) 
graphical class display to be saved, printed, or otherwise accessed for later 
reference. Not so - all you can do is admire it for the brief period of it's 
existance. Admittedly, there isn't much else which allows even such a limited
view as this, but surely it wouldn't have been all that difficult to output
the shaded boxes and lines as postscript?

--
Ron Williams                  ACSnet : ron@syacus.acus.oz
Ph : +61 2 390-1366         Internet : ron@syacus.acus.OZ.AU
Fax: +61 2 390-1391             UUCP : uunet!munnari!syacus.acus.oz.au!ron
Standard Disclaimers Apply
Newsgroups: comp.lang.c++
From: speros@csri.toronto.edu (Speros Armyros)
Subject: Machine generated C++ code (?)
Organization: CSRI, University of Toronto
Date: 27 Sep 92 17:34:12 GMT

	
	Hello everyone,
     
	Some time ago I posted a message asking about C++ code generators,
but my question was vague enough and not very well specified. So I would 
like to elaborate on what I am looking for exactly.

	I would like to generate some C++ code for testing a compiler.
The usual approach to this is to obtain/develop a set of synthetic test 
cases (toy programs) and real-life applications. I would like to explore
another approach where valid and invalid code produced by a code generator
is fed to the compiler.

       Usually code generators produce code that is quite complex and unlikely
to be written by humans. I would be interested in developing a system
which produces machine generated code, based on certain inputs, such as the 
language grammar. Something that produces arbitrarily complex expressions
or constructs (nested blocks, classes) etc.

	Systems like this have been developed for other languages such as
C by companies like HCR (SCO). I could try extending such a system to 
work for C++, but maybe I could get some opinions from people that might 
already have experimented on something similar to this. Perhaps I could 
get some references too.

	Much thanks in advance.
        Speros Armyros
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: Tue, 29 Sep 1992 16:04:11 GMT

In article <1992Sep29.140750.29438@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>In article <BRENNAN.92Sep28124052@yosemite.hal.com> brennan@hal.com (Dave Brennan) writes:
>>sooner than they have to.  Here's a contrived example:
>
>Although I agree that the difference between "conceptual constness"
>and "physical constness" is a real issue in C++, I cannot resist the
>impulse to complain about some details of the admittedly contrived
>example.
>
>My first complaint is that
>	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.

	However, it is true that one can have a list *iterator*
than cannot be rewound, and which can only get the next element.
Thus it is list iterators that supply sequential access, not lists
themselves. 
	
-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: pj@sam.wpd.sgi.com (Paul Jackson)
Newsgroups: comp.lang.c++
Subject: Re: How to ensure correct argument type provided.
Keywords: integer promotion argument type checking
Date: 3 Oct 92 06:51:48 GMT
Reply-To: pj@sgi.com
Organization: Silicon Graphics, Research & Development

In article <2572@devnull.mpd.tandem.com>, rgp@mpd.tandem.com (Ramon Pantin) writes:
|> In article <1992Oct2.035453.25085@odin.corp.sgi.com> pj@sgi.com writes:
|> >
|> >I have some routines that pass around a couple of small integer
|> >arguments, amongst other args.  I want to type these args so that
|> >the compiler will warn if args of the wrong type are passed.
|> 
|> The only thing that has worked for me is to have a #define that
|> takes one argument (a type name) and that expands into a trivial
|> class that functions exactly as an integer (i.e. it contains an
|> integer and overloads all the appropriate operators so that it
|> behaves like an integer) but with no conversion operators.

Not having conversion ops from basic integer types is the key
that I had missed.

Perhaps typedefs should have been called typealiases.  They sure
don't seem to define a new type, rather just provide an alias for
an existing one.

Thanks to the private email respondants (ascent, steven and
wilson).  They all agreed that either enums (if they would meet
my other needs) or custom classes with int-like behaviours were
needed to provide type checking here.

Wilson's idea of providing a base class of Integer with derived
i1_t and i2_t classes (but avoid certain conversion ops) seems
worth persuing.

|> It is certainly a pity that the type equivalence rules in C and
|> C++ are so weak.

yes.

-- 

				I won't rest till it's the best ...
				Software Production Engineer
				Paul Jackson (pj@sgi.com), x1373
From: ren@miles.mps.ohio-state.edu (Liming Ren)
Newsgroups: comp.lang.c++
Subject: What cout has done to my code?
Date: 26 Sep 1992 16:40:01 -0400
Organization: Department of Mathematics, The Ohio State University
Distribution: usa
NNTP-Posting-Host: miles.mps.ohio-state.edu

	I am working on code handling bitvector. I can't figure out what 
cout has done to cause the following: If I comment out the line

 cout<<wordWidth<<" "<<sizeof(*(tmp+i))<<endl;

I get result as 
	 4294967295
	 875706676	
The first is the value of a unsigned int with all bits set to 1. I verify
this and it is correct. The second is supposed to be 0, i.e, the 
bitwise NOT of the first one. I have no idea what this number means.

BUT if I include this line in the code. I get correct result:
	1 4   // the output of cout line 
         4294967295
	 0

What is wrong? I am sure my machine has sizeof(int)=4 bytes=32 bits.
The following is the code.


#define WORDSIZE 32
typedef unsigned int *BitVec;

class BitVector{
 public:
  BitVector(int=WORDSIZE, int=0);
  ~BitVector(){delete [] bv;};
  BitVector operator~() const;  
  //~ return the complement of the bitvector;
  show();
 private:
  BitVec bv;
  unsigned short size; //bit length of the bitvector;
  short wordWidth; // wordlength of the bitvector;
  };

BitVector BitVector::operator~() const
{
  //bitwise negation operation;
  BitVector result(size, 0);
  BitVec tmp=result.bv;
  for(int i=0; i<wordWidth; i++)
    {
      *(tmp+i)=~(*(bv+i));
    }
  cout<<wordWidth<<" "<<sizeof(*(tmp+i))<<endl;
  //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^;
  //*************the above line causes the problem**********
  return result;
}

//default constructor;
 BitVector::BitVector(int sz, int init)
{
  assert(sz>0);
  size=sz;
  wordWidth=(size+WORDSIZE-1)/WORDSIZE;
  bv=new unsigned int[wordWidth];
  assert(bv!=0);
  //now initilize bv to either all 0's or 1's; 
  if(init!=0)
    init=~0;  
  
  //assign 0 or -1 to each word of bv;
  for(int i=0; i<wordWidth; i++)
    *(bv+i)=init;
}
  
 BitVector::show()
{
  cout<<*bv<<endl;
  return *bv;
}


main()
{
  BitVector bb(32, 1);
  BitVector bc=~bb;
  bb.show();
  bc.show();
}



Thanks for your help!
Newsgroups: comp.lang.c++,comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Conceptual Constness
Keywords: const, const member, lazy
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 29 Sep 1992 15:29:28 GMT

brennan@hal.com (Dave Brennan) writes:

>I write a lot of C++ classes that are optimized to not do anything any
>sooner than they have to.  Here's a contrived example:
>
>class Foo;
>
>class FooList
>{
>  public:
>  FooList ()
>    : foo_list (NULL) { }
>  // ...
>  foo operator [](int);
>  // ...
>
>  protected:
>  foo **foo_list;
>
>  void create_foo_list ();
>};
>
>foo &
>foo_list::operator [] (int index)
>{
>  if (foo_list == NULL)
>    create_foo_list ();
>
>  // [ error checking ommited ]
>
>  return (*foo_list[i]);
>}
>
>
>The list of Foo objects doesn't exist until a user of a FooList tries to
>access an element of the list.  Conceptually accessing an element is an
>operation that I would be like to be able to perform on a const object
>because conceptually it does not modify the FooList.
>
>My complaint is that C++ doesn't provide a way to indicate this conceputal
>"constness."  I really want to have a const FooList and be able to call a
>conceptually const function.  The current alternatives are either don't use
>const or do some ugly casting with "this" in conceptually const member
>functions.  The first solution makes it harder to insure conceptual const
>correctness, while the second is just plain ugly.

One approach which makes your intentions clear is to declare all operations
that are conceptually constant but not actually constant as "conceptual_const":

	#include "conceptual_const.h"
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	>class FooList
	>{
	>  public:
	>  FooList ()
	>    : foo_list (NULL) { }
	>  // ...
	   foo operator [](int) conceptual_const;
				^^^^^^^^^^^^^^^^
	>  // ...
	>
	>  protected:
	>  foo **foo_list;
	>
	>  void create_foo_list ();
	>};

The contents of the "conceptual_const.h" header file are left as an
excercise for the reader ;-)

--
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! P.S. The above was a *joke*, OK?
-- 
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++