HDTenEightyP/NetNews huggingface dataset:
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: zero-length datatype
Date: 12 Sep 92 01:23:37 GMT
	<HAYDENS.92Sep9215705@bullwinkle.juliet.ll.mit.edu>
	<TMB.92Sep10120206@arolla.idiap.ch>
	<HAYDENS.92Sep10103208@bullwinkle.juliet.ll.mit.edu>
Reply-To: tmb@idiap.ch
Distribution: comp
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: haydens@bullwinkle.juliet.ll.mit.edu's message of 10 Sep 92 17:32:08 GMT

In article <HAYDENS.92Sep10103208@bullwinkle.juliet.ll.mit.edu> haydens@bullwinkle.juliet.ll.mit.edu (Hayden Schultz x3685 g42) writes:

   I'm still not convinced that you can't use existing language features
   to solve (or maybe just avoid) this problem. If a legitimate subset of
   the hash table problem is hash tables with just keys, then this sounds
   like a basis for a class heirarchy. [... example deleted ...]

   I think that this meets your intuitive criterion. Whenever you don't
   care what the values are, you use the KeyHash class. You don't have to
   make a special class to make a simple HashTable<int,int>. The Key and
   Value types are as explicit as your original example. You don't even
   have to modify any existing code which uses the HashTable class, since
   the public interface hasn't changed.

The number of classes you need might be large. Consider the following:

	template <class A,class B,class C>
	class XYZ { ... }

Now, you already need 7 different versions of XYZ, depending on which
of "A", "B", "C" are "void" (assuming not all of them are "void"
simultaneously), and it is not clear that every such class can be
decomposed neatly into a class hierarchy, even with multiple
inheritance.

So, sure, you can reorganize your code and introduce several classes
(there are other, less object-oriented and more general approaches as
well). However, why bother? "void" can be a perfectly good data type,
and it has proven its utility in other languages. It's no big deal, it
is simply that the restrictions on it in C++ seem arbitrary.

					Thomas.
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Comma operator for stream I/O (was: Answers on a postcard...)
Organization: TauMetric Corporation
Date: Tue, 15 Sep 1992 17:46:44 GMT

jbn@lulea.trab.se (Johan Bengtsson) writes:

>Since I am also in search of an example where the comma operator would be
>a good choice:

>Would the comma operator have been a good choice for stream I/O?
>I.e. instead of the rather hard-to-read expression

>  cout << "The value is " << value << endl;

>you would write

>  cout, "The value is", value, endl;

>The precedence is just right (very low).

The reason why << and >> are used is historical.  Stroustrup explains
that of the available operators, they seemed to be the best choice.
At that time (1985), the comma operator could not be overloaded, so
was not a possibility.  Perhaps comma would have been used otherwise.

I've been using << and >> for so long now that I find them easier
to read than the comma example.  I must admit, though, that when I
started in C++ I found << and >> quite bizarre and unreadable.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: johnrp@well.sf.ca.us (John Panzer)
Subject: More on C++ yacc grammar
Organization: Whole Earth 'Lectronic Link
Date: Sun, 13 Sep 1992 01:58:45 GMT


I'm interested in finding a Yacc-able C++ grammar as well - even a
partial grammar would be useful to me.  However, the archie server
doesn't seem to know about C++ grammars (only C grammars show up
on my searches).  Also, an earlier posting about an anonymous ftp
site was incorrect - there ain't no grammars there!

So, does anybody have any further information on this?  As I said,
even a partial implementation (or partially correct implementation)
would be fine for my purposes (an autodocumenting tool).

John Panzer
johnrp@well.sf.ca.us
From: silvia@rcf.rsmas.miami.edu
Newsgroups: comp.lang.c++
Subject: Re: Comma operator for stream I/O (was: Answers on a postcard...)
Date: 15 Sep 92 20:35:44 GMT
Reply-To: silvia@rcf.rsmas.miami.edu
Organization: RSMAS

In article <4958@holden.lulea.trab.se>, jbn@lulea.trab.se (Johan Bengtsson) writes:
>This is a side-track from the previous discussion.  Below I propose
>an alternate syntax for stream I/O (futile, I know).  I'd be curious
>to know what the net thinks about it.
>
>steve@taumet.com (Steve Clamage) writes:
>: 
>: Personally, I've never seen any example of code
>: which was improved by using an overloaded comma (which of course
>: doesn't mean there is no such code).
>
>Since I am also in search of an example where the comma operator would be
>a good choice:
>
>Would the comma operator have been a good choice for stream I/O?
>I.e. instead of the rather hard-to-read expression
>
>  cout << "The value is " << value << endl;
>
>you would write
>
>  cout, "The value is", value, endl;
>
>The precedence is just right (very low).
>
>The comma operator could be used for input as well:
>
>  int i; float f; char c;
>  cin, i, f, c;
>
>Finally, for iostreams, you would invoke the methods
>
>  istream& iostream::in();
>  ostream& iostream::out();
>
>to select input or output, like this
>
>  iostream io(...);
>  io.out(), "The value is", value, endl;
>  io.in(), i, f, c;
>
>Is this technique commonly used in MI classes (base class selector methods,
>to do controlled up-casting)?  Just curious...
>
>-- 
>--------------------------------------------------------------------------
>| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
>| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
>--------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: scottm@intime.intime.COM (Scott Michel)
Subject: Re: zero-length datatype
Organization: IntelliMED Corporation, Santa Monica, CA
Distribution: comp
Date: Sat, 12 Sep 1992 00:50:52 GMT

In article <1992Sep11.185505.17536@cadsun.corp.mot.com> shang@corp.mot.com writes:
>In article <23654@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:
>> In article <1992Sep10.181836.9929@cadsun.corp.mot.com> shang@corp.mot.com  
>writes:
[ ... truncated ... ]
>
>But I don't see the reason why we can't have zero-size objects. Don't 
>say that the standard explicitly says that. I want to know why it says 
>that. So far, I haven't heard any convincing argument.

What it seems that people are getting at is the fundamental issue of
a class that consists only of methods, devoid of attributes. Is such
a class useful? IMNSHO, it is if you are abstracting a library object
which has no state information but passes control solely to active
methods. Whether this is a good idea conceptually or not is subject to
other threads. It is nonetheless a valid example of where you might
have a zero length class:

	class Gateway {
	public:
	  void gate_entry_1(int arg1, const char *arg2);
	  int gate_entry_2(const char *arg);
	}

However, it's clear that the reason why C++ doesn't allow one to have
a zero length object is that all instances of objects must be unique.
This is a Reasonable Thing, otherwise you'd end up with real confusion
in the language as to whether or not an object is really a stand-in or
alias for another, and whether or not the object exists in the first
place. Is one zero-length object itself or a meta object for another?
According to Aristotle's theory of classes (and his philosophy as a whole)
you'd force yourself into a situation where something can be itself and
not itself similtaneously. The only place where an object may have a
useful zero length is in a base class, and it would only be logical that
it is illegal to use a zero length object in any other sense.

The discussion regarding problems of promoting void to a real datatype
a non sequitor: How can a void thing have substance? (e.g being itself
and not itself problem)

>
>David Shang

There's my $0.02. 'Nuf said yet?

-scottm
Newsgroups: comp.lang.c++
From: johnrp@well.sf.ca.us (John Panzer)
Subject: Re: Answers on a postcard...
Organization: Whole Earth 'Lectronic Link
Date: Fri, 11 Sep 1992 06:17:15 GMT

In article <1992Sep10.174914.838@taumet.com> steve@taumet.com (Steve Clamage) writes:
>Karl Keyte <KKEYTE@ESOC.BITNET> writes:

(Class X which defines operator,() )

>|   X x;
>|   cout << "Value is " << (x=1, x+1) << endl;

(General surprise that order of evaluation of x=1, x+1 is undefined)

>
>In the expression in parens, it is unspecified whether "x=1" or
>"x+1" is evaluated first.  They are arguments to the "operator,()"
>function, not the left and right side of a comma-expression.  If
>"x+1" is evaluated first, which is legal, it will use an
>uninitialized "x.value".
>
>Don't write code which depends on unspecified order of evaluation.
>
>If there were no "op,()", the "," would mark a comma-expression,
>and the "x=1" would have to be evaluated first; in that case the
>whole expression would be well-defined.

Wow.  So this means (for example) that if you define && for a class, 
chained && expressions no longer have a defined order of evaluation.
I subconsciously expected the object to be evaluated first in calls
like Expr1.operator&&(Expr2).  I might even propose this as a new
constraint, except that there are too many darn proposals already. :^)

John Panzer
johnrp@well.sf.ca.us
 

Newsgroups: comp.lang.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: Default assignment semantics
Date: Tue, 15 Sep 1992 02:55:50 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

John Matthews <jm@vcd.hp.com> writes:
|It seems to me that a more robust default assignment operator would
|have the following semantics:
|
|  1) Invoke the destructor of the object being assigned to.
|  2) Invoke the copy constructor on the object being assigned
|      to, taking as an argument the object being assigned from.

|Thus what I want to do in most of my assignment operators is
|explicitly invoke the corresponding destructor and copy constructor.

|        X& X::operator=( const X& from )
|        {
|                  this->~X();               // invoke destructor.
|                  new(this) X(from);        // invoke copy constructor.
|                  return( *this );
|        }


First, there's a small bug in your assignment operator -
consider what happens if this == &from.


More importantly, I would suggest that, while many specific assignment
operators can be safely implemented this way, doing it as a general
rule would not be a good idea.  Consider, for example,

   class X {
   public:
      X& operator=(const X& from);   // implemented as above
      virtual foo();
   };

So far, so good.  Now someone derives a new class:

   class Y : public X {
   public:
      Y& operator=(const Y& from);
      virtual foo();
   };

   Y& Y::operator=(const Y& from) {
      if (this != &from) {
         X::operator=(from);      // Copy the X part
         // Do some customized copying of the Y stuff
      }
   }

   void g(Y& y1, Y& y2) {
      y1 = y2;
      y1.foo();
   }

What does the call to y1.foo() inside g() do?  Quite probably, it
will call X::foo()!

The problem is that Y's assignment operator calls X's assignment
operator, which calls the destructor for y1 (and calls the wrong
destructor, unless X's destructor is virtual), and then creates
a new X object on top of y1.  Not quite what the programmer intended!

So if you use this style of assignment operator in a class X,
then all(*) classes derived from X should avoid calling X's assignment
operator inside their own assignment operators (or anywhere else,
for that matter).  In general, I'd think it would be worth a bit
of extra coding to avoid this restriction.

footnote:
(*) Maybe you don't need to impose this restriction if X has no
virtual functions and no virtual base classes.  But that would
depend on the implementation.

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Newsgroups: comp.lang.c++
From: bytor@grumpy.bellcore.com (Ross Huitt)
Subject: Re: C++ gdb
Organization: Bellcore
Date: Fri, 11 Sep 92 17:38:52 GMT

In article <1992Sep11.044450.18071@csis.dit.csiro.au>, dave@csis.dit.csiro.au (David Campbell) writes:
|> Hi,
|> 
|> Does anyboyd have a port of the GNU debugger (gdb) that works with
|> AT&T C++'s mangling scheme?

gdb 4.6 apparently supports AT&Ts scheme. I haven't tried it. I do know that
there are at least 2 different commercial vendors of C++ debuggers/environments
that use gdb as their base debugger, so the interface has been done.

|> Thanks,
|> Dave Campbell
|> dave@csis.dit.csiro.au
|

Ross Huitt
bytor@ctt.bellcore.com
Newsgroups: comp.lang.c++
From: kaykit@iti.gov.sg (Chan Kay Kit)
Subject: Help needed on extended memory management
 
Reply-To: kaykit@iti.gov.sg
Organization: Information Technology Institute, National Computer Board, S'pore
Date: Mon, 14 Sep 1992 03:16:00 GMT

Hello everyone!

	I have programmed for DOS for a fairly long time but recently I ran 
into memory management difficulties. 

	My program requires a lot of memory for dynamic data (eg. a 1.2 MB 
contiguous block) and thus needs to access extended memory. However, since I 
am only producing a prototype to show concepts, I do not wish to get entangled
in Windows programming. In other words, it would be best if I could just program 
as per normal as possible, with much of the work of managing the extended memory 
done by the compiler or some DOS extender. I am running MS-DOS 3.3.

	I would appreciate it very much if anyone can supply helpful tips to
satisfying the above requirements, and/or answers to the questions below:


(i) Does anyone know if Borland C++ or Zortech C++ allows one to write
and compile DOS programs that automatically use extended memory if 
necessary? What work must be done by the programmer, if any, to manage the 
extended memory? Is the extra work required so much that a switch to the
Windows environment would be more productive instead?

(ii) Any other C language products that come with extended memory management
facilities? 


	Please email replies to kaykit@iti.gov.sg. Thanks in advance!



Kay Kit



---
Kay-Kit CHAN    			| Internet: kaykit@iti.gov.sg
Knowledge Systems Lab			| Bitnet:   kaykit@itivax
Information Technology Institute	| Tel:      (65) 772-0920
National Computer Board of Singapore    | Fax:      (65) 770-3043

From: kevinl@tisdec.tis.tandy.com
Date: 08 Sep 92 09:22 CDT
Newsgroups: comp.lang.c++
Subject: Ctrl, Alt, keys in BC+
Message-ID: <6800008@tisdec.tis.tandy.com>
Nf-ID: #N:tisdec.tis.tandy.com:6800008:000:245
Nf-From: tisdec.tis.tandy.com!kevinl    Sep  8 09:22:00 1992


	Can anyone tell me how to parse Ctrl, Alt, etc, key presses in
Borland C++?

	I know you can identify them with the isctrl or sum such function,
but I need to know if there is an easy way to parse them all.

	Help is very much appreciated. 8-)

Newsgroups: comp.lang.c++
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: Template class self-reference problem (gcc 2.2.2/libg++ 2.2)
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia
Distribution: usa
Date: Sun, 6 Sep 1992 22:23:57 GMT

rwang@absolut.Berkeley.EDU (Robert Wang) writes:

|> I ran into some trouble with template class self references.
|> Referring to the code below, it seems that g++ doesn't like 
|> "const foo<bar>&" inside the definition of "template<class bar> class foo".
|> g++ dies with the statement "parse error before >" at the line:
|> 
|>    "int operator==(const foo<bar>& rhs) const { return _data == rhs._data; }"
|>    "int operator!=(const foo<bar>& rhs) const { return _data != rhs._data; }"
|> template<class bar> class foo
|>    {
|> private:
|>    bar _data;
|> public:
|>    foo(bar data) : _data(data) {}
|> 
|>    int operator==(const foo<bar>& rhs) const { return _data == rhs._data; }
|>    int operator!=(const foo<bar>& rhs) const { return _data != rhs._data; }
|>    };

This is definitely a bug in gcc 2.2.2.
However, there is a work around. Try

 int operator==(const foo& rhs) const { return _data == rhs._data; }
 int operator!=(const foo& rhs) const { return _data != rhs._data; }

-Sekar
Newsgroups: comp.lang.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: zero-length datatype
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Distribution: comp
Date: Mon, 14 Sep 92 14:17:56 GMT

In article <TMB.92Sep12212903@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M.  
Breuel) writes:
> In article <23659@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:
> 
>    In article <1992Sep11.185505.17536@cadsun.corp.mot.com> shang@corp.mot.com  
writes:

>    > But I don't see the reason why we can't have zero-size objects. Don't 
>    > say that the standard explicitly says that. I want to know why it says 
>    > that. So far, I haven't heard any convincing argument.
> 
>    I don't really know why.  What I do know is that the presence of
>    that requirement in the C standard makes it hard to avoid the same
>    requirement in the C++ standard.
> 
> Well, it might be good to remain compatible, in the sense that every
> object that has non-zero size in ISO C also have a non-zero size in
> C++. However, since there are no objects of type "void" (or of some
> other, newly introduced, distinguished type with zero size) in ISO C,
> there can't be any harm in letting objects of this new type have zero
> size: the behavior of existing code would not be affected.
> 

My question is that why the standard disallows zero-size object. 
Therefore, compatibility to the standard is not the reason.

If we did not mix up class and struct, we could make C++ 
compatible with C while letting empty class zero-sized but empty 
struct non-zero-sized.

I'd like to have struct as a sealed class, i.e. it cannot be used to 
derived other classes or structures. If a struct is derived from an 
empty class, it's size becomes non-zero.

David Shang
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Answers on a postcard...
Date: 12 Sep 92 01:28:46 GMT
	<92255.112151KKEYTE@ESOC.BITNET>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: KKEYTE@ESOC.BITNET's message of 11 Sep 92 18:52:30 GMT

In article <92255.112151KKEYTE@ESOC.BITNET> KKEYTE@ESOC.BITNET (Karl Keyte) writes:

   >In the expression in parens, it is unspecified whether "x=1" or
   >"x+1" is evaluated first.  They are arguments to the "operator,()"
   >function, not the left and right side of a comma-expression.  If
   >"x+1" is evaluated first, which is legal, it will use an
   >uninitialized "x.value".
   >
   >Don't write code which depends on unspecified order of evaluation.

   The implication of what you say is that it is not possible to overload
   operators maintaining the correct functionality of the operator.  This
   indeed means that precedence in overloaded operators cannot be maintained
   if all operands are simply passed as arguments to the function implementing
   the operator functionality and evaluated in a language independent order.
   Imagine commonly used "chain" operators such as && and ::.

   If what is described above is correct, and Mr.Clamage clearly has much
   experience in the area, then I think we have justification for pressing
   for a change in this area.  If not, I would ask: How does one overload
   the comma operator while maintaining its attibutes as an operator?

The problem is that ",", "&&", and "||" are not operators, they are
"special forms" or "syntax". In an eager language without Lisp-like
macros, there is no way to let users define constructs like this.

The mistake was probably letting the user overload these constructs as
operators in the first place. In particular, overloading "," is highly
questionable, given the amount of work this symbol has to do in the
language already.

					Thomas.
Newsgroups: comp.lang.c++
From: pkturner@world.std.com (Prescott K Turner)
Subject: Re: ARM code don't work
Organization: The World Public Access UNIX, Brookline, MA
Date: Tue, 15 Sep 1992 03:18:33 GMT

> I tried the code from pages 292 and 293 of the ARM on various C++ compilers.
>
> I found that cfront 2.1, cfront 3.0, GNU 1.39, GNU 222 all got the same answer.
>
> Unfortunately, not the same answer as the ARM.
>
> Can anyone tell me which is right ?

The ARM.  Pages 292 and 293 have been generally accepted as the norm for a
couple of years, regarding the order of construction of base classes.
Some compilers such as LPI C++ and Oregon C++ follow the ARM and agree with
its answer to your program.
--
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: steve@taumet.com (Steve Clamage)
Subject: Re: >>>>>> Novice Question on Wierd class definition
Organization: TauMetric Corporation
Date: Fri, 11 Sep 1992 18:17:52 GMT

ssimmons@convex.com (Steve Simmons) writes:


|> class B(type) {
|>        type** C;
|> .more defs...
|> }
|> 
|> Is B a template class, or what its it? Is it an anachronism?

|It is a template class... Templates are available with ATT V3.0... 

This is not the standard syntax for templates, and this won't work
with (most) current compilers which implement templates.  It may have
been written for use with some template preprocessor.  (Or maybe
g++ used or uses this syntax.)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: mcgrant@rascals.stanford.edu (Michael C. Grant)
Subject: Re: APIs across Sun, Mac, and PC?
Organization: Information Systems Laboratory, Stanford University
Date: 14 Sep 92 12:45:15


   In article <1992Sep10.175657.13369@parc.xerox.com>,
        fromherz@parc.xerox.com (Markus Fromherz) writes:
   > What development environments, class libraries, application frameworks
   > or APIs exist that allow to write programs portable across Suns, Macs
   > and PCs?

I believe the Galaxy environment by Visix allows such portability...
It supports the Open Look, Motif, Microsoft Windows, and Macintosh
environments (but I'm not sure if the Mac version is quite finished yet).

I received some helpful information by contacting them... here is what's
printed on the title page of the report:

Visix Software Inc.
11440 Commerce Park Drive
Reston VA 22091
1-800-832-8668

Let's see... I don't want to type in the whole thing (!) but one
interesting portion is the list of standards that Galaxy supposedly
conforms to (on the appropriate platforms):

OSF/Motif         Unicode        POSIX P1003.1
OPEN LOOK         ISO 10646      PostScript
CUA (Windows/PM)  ANSI C         X/Open NLS
X Window ICCCM    RTF Doc format

From the looks of the above list it might seem that it is mainly
a GUI spec but there are quite a lot of other useful components
as well, such as network communication, inter-application communication,
file system i/o, sound i/o, etc.

I haven't purchased it yet though so I can't give a personal testimonial.

Michael C. Grant
Newsgroups: comp.lang.c++