HDTenEightyP/NetNews huggingface dataset:
Organisation: European Space Operation Centre (E.S.O.C)
Date: Thursday, 10 Sep 1992 10:40:02 CET
From: Karl Keyte <KKEYTE@ESOC.BITNET>
Newsgroups: comp.lang.c++
Subject: Answers on a postcard...


What does your compiler do with this one using the comma operator?  I've
had different results (and a very surprising order for calling operator
members) from different compilers.  Let me know 1) what you THINK (by
looking at it) it should produce and 2) what you actually get?

Karl


#include <iostream.h>

class X {
   private:    int           value;
   public:     int           operator , (int i) { return i+10; };
               int           operator + (int i) { return value+i; };
               X &           operator = (int i) { value=i; return *this; };
};


void main()
{
   X         x;

   cout << "Value is " << (x=1, x+1) << endl;
}
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Newsgroups: comp.lang.c++
Subject: Re: C++ Grammar
Date: 14 Sep 92 15:10:52 GMT
Organization: SAS Institute Inc.
Originator: sasghm@theseus.unx.sas.com


In article <1992Sep12.021515.23609@cs.brown.edu>, ted@cs.brown.edu (Tony Davis) writes:
|> 
|> Another common approach to parsing C++ with yacc is to make
|> the lexicl analyzer more powerful.  With this approach yacc
|> can indeed be used to parse non-LR(k) languages.  Granted,
|> this might be called cheating since the lexical analyzer is
|> doing enough parsing so that the language that the yacc portion
|> of the system must parse IS now LR(k).  Strictly speaking
|> yacc does not parse a non-LR(k) language, but the parser as
|> a whole does.

This is either inaccurate or misleading (touche!).  The lexical
analyzer of course doesn't do the parsing.  It does the lexical
analysis -- which in this case means, among other things, the
determination/insertion of artificial tokens.  It may call a
parser in order to make this determination.

|> A C++ parser that one of my advisors has recently produced takes
|> this approach.  The lexer does look ahead to produce artificial
|> tokens which yacc uses as ques to yield a correct parse (modulo
|> any bugs that remain in the system).  Soon I will be making that
|> parser available for ftp.  When it becomes available I will
|> announce it here.

I'm sure we all use basically the same technique here (whether
the underlying parser is yacc-based or recursive descent).  I do,
nonethless, look forward to seeing how someone else has done this.
Note, however, that in any case -- if the parsing is ultimately
done correctly -- then either yyparse() must be called recursively
as part of the lookahead process or some other method (recursive
descent, for example) must be used in the "local" or "trial" parses
necessary to determine what (if any) artificial token to insert.
My changes to yacc include the recursive callability of yyparse(),
a distinction between conditional and unconditional actions, a
simple type of reduction tracking, and optimized dynamically allocated
parser stacks.  These are all relatively simple modifications to
the code.  Actually, quite a bit of work needs to go into the
buffering of tokens and into error detection/recovery and diagnostics.

Again, after going through this, I would advise anyone starting
from scratch to use a recursive descent parser since I feel that
it offers advantages in the areas of diagnostics, recovery, and
maintainability.
-- 
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
Newsgroups: comp.lang.c++
From: daniel@epx.cis.umn.edu ()
Subject: Borland C++ Classlib
Organization: University of Minnesota
Date: Sat, 12 Sep 1992 20:46:22 GMT

I'm using the DoubleList and DoubleListIterator objects, and I'm wondering
if anyone knows the difference between an iterator created like this:
 
  DoubleListIterator	foo(listToIterate);

and one created using the initIterator member of the DoubleList object.  Any
ideas?

Daniel A. Torrey
daniel@bauhaus.micro.umn.edu
Newsgroups: comp.lang.c++
From: rad2r@uvacs.cs.Virginia.EDU (Robert DeLine)
Subject: Style of writing container classes
Organization: University of Virginia Computer Science Department
Date: Sun, 13 Sep 1992 19:44:22 GMT


Today I was bitten by a bug in a container class I wrote, a general
linked list.  I had used a reference to actually implement the
containment, e.g.

	template <class TYPE>
	struct LinkedListNode
	{
	    TYPE& data;
	    LinkedListNode* prev;
	    LinkedListNode* next;
	};

This worked fine for things like LinkedList<String> or
LinkedList<double> but when I did LinkedList<MyClass*>, I ran into the
bug.  I has written a seemingly innocent loop:

	LinkedList<MyClass*> list;
	for (blah; blah; blah) {
	    MyClass* mptr = new MyClass(whatever);
	    list.append(mptr);
	}

But because I was storing a *reference* to the data (to a pointer in
this case), I ended up with a linked list which contained n copies of
the last thing added.  This is because the reference in this case was a
reference to a *pointer* that kept changing.  Sigh.  Live and learn.

My solution was to change the declaration to

		TYPE data;

In other words, I copy the data.  This means (1) the user could be
copying large amounts of data and (2) any class you use *must* have a
copy operator defined.  I don't think this is so bad, since you can
always declare a linked list of pointers to your data type, which
elleviates both problems.

My question is (bet you were beginning to wonder if there was a
question): is this the way most people write their container classes?
Do you usually copy, knowing the user can give you a pointer?  Or do
you use a pointer, knowing the user can call new by himself?  Are
references just a bad idea in this case, or did I use them incorrectly?

Your thoughts, experience and advice greatly appreciated.

-- 
Rob DeLine
Computer Science, University of Virginia
deline@Virginia.EDU
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
ReplyTo: nikki@trmphrst.demon.co.uk
Subject: Re: Default assignment semantics
Distribution: world
X-Mailer: cppnews $Revision: 1.16 $
Organization: Trumphurst Ltd.
Date: Tue, 15 Sep 1992 11:43:17 +0000


In article <BuJs8K.Hzr@vcd.hp.com> jm@vcd.hp.com (John Matthews) writes:

> As I understand it, if a class does not have an explicitly defined
> assignment operator, a default assignment operator is generated
> by the compiler. This default operator simply does a member-wise
> assignment. As has been pointed out many times, these semantics
> are dangerous for classes that have pointers to dynamically created
> objects as fields.
> 
> 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.
> 
The problem with this is that it introduces the most common assignment 
operator bug. Try it with ...

String a"(Hello");

a = a;
---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
From: dlarsson@aut.abb.se (Daniel Larsson)
Newsgroups: comp.lang.c++
Subject: Re: Renaming
Date: 8 Sep 92 18:37:45 GMT
Distribution: comp
Organization: ABB Automation AB, Vasteras, Sweden

In article <ETNKNA.92Sep7212951@hisoy2.etn.ericsson.se> etnkna@hisoy2.etn.ericsson.se (Aksnes Knut-Havard) writes:
>
>...
>
>ARM Section 10.11c suggest  a renaming mechanism to be used when two
>class hierarchies are merged by a common derived class, where the same
>name is used in both hierarchies, but with different semantics. 
>
>Such a renaming scheme is of interest in another situation too;
>sometimes you want to inherit the same class twice, the classical
>example is an implementation of a sparse matrix using linked lists,
>each element shall be in one row list and one column list. Deriving
>linked list twice is not allowed; There are no way to access the
>members of the two parent classes in a unambiguous way.
>

A relevant question to ask here is whether a matrix *is* two lists or
*contains* two lists. I would answer it consists of two list, i.e. we
have an aggregate relationship rather than a subtype ditto.

>A kludge around this problem is to generate a dummy class inherited
>from the parent class and derive both the parent class and the dummy.
>The problem with this kludge is that it clobbers the global name
>space.
>

Why not simply have two members of type list?




-- 
---------------------------------------------------------------------------
Daniel Larsson          Email:	   dlarsson@aut.abb.se
ABB Automation AB	Telefax:   +46 21 34 25 25
V{ster}s, Sweden	Telephone: +46 21 34 30 29
From: jxd7299@hertz.njit.edu (Jing X Ding)
Newsgroups: comp.lang.c++
Subject: help
Date: 4 Sep 92 18:28:41 GMT
Organization: New Jersey Institute of Technology, Newark, N.J.
  Class A {
   private:
    int var1;
    char* var2;
   public:
    A(int ovar1,char* ovar2) {
	var1 = ovar1;
        var2 = ovar2;
	printf("the value of var2:%s\n",var2);//The result of this stmt is OK
	}

Jing Ding(jxd7299@hertz.njit.edu)
Newsgroups: comp.lang.c++
From: joslyn@kong.gsfc.nasa.gov (Cliff Joslyn)
Subject: Best BC++ general class library?
Organization: Goddard Space Flight Center
Date: Tue, 8 Sep 92 13:51:16 GMT


I've read the FAQ and the C++ products list, and gotten a bunch of
literature from folks. I'd like to check my percpetions against the
net.

First, I want a forest-oriented structure (i.e. not a NIHCL style
monolith) which has templates.

The new Tools.h++ from Rogue Wave seems to be the hands-down winner,
especially with all the little goodies you get (e.g. persistence).

I've also looked at COOL, but is it easily ported to BC++? It helps
that it's free.

I've tried to look at LEDA, but can't get through to ftp.cs.uni-sb.de.

Any comments would be appreciated.

O----------------------------------------------------------------------------->
| Cliff Joslyn, Cybernetician at Large, 327 Spring St #2 Portland ME 04102 USA
| Systems Science, SUNY Binghamton      NASA Goddard Space Flight Center
| cjoslyn@bingsuns.cc.binghamton.edu    joslyn@kong.gsfc.nasa.gov
V All the world is biscuit shaped. . .
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Comma operator for stream I/O (was: Answers on a postcard...)
Date: 14 Sep 92 15:26:50 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

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: eric@tfs.com (Eric Smith)
Subject: Re: Problems with constructor in C++
Organization: TFS
Distribution: na
Date: Tue, 15 Sep 1992 08:31:00 GMT

In article <1992Sep15.030705.13864@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
>In <1992Sep14.225041.15692@access.usask.ca> srikant@skorpio.usask.ca (Srikant Subramaniam) writes:
>
>>Hello Netters:
>
>>I have a rather peculiar problem with constructors in C++. In the code
>>fragment below, the constructor for AtomicInt is not executed at all.
>
>>File chore.h
>>------------
>
>>Class Chore : public DLINK {
>
>>	......
>>	.......
>
>>	AtomicInt numworkers;
>>public: Chore ( .......) {
>>	
>>	}
>>} // Class Chore
>
>>File atomic_int.h
>>------------------
>
>>Class AtomicInt {
>
>>	...........
>
>>	AtomicInt() { .......}
>>	AtomicInt(int x) { ......}
>>	AtomicInt(AtomicInt& x) { .......}
>>}
>
>>When the code is executed, the constructor for AtomicInt doesn't get executed
>>at all. My understanding of C++ was that when the initialization is done as
>>in AtomicInt numworkers, the constructor is automatically executed. I hope I'm
>>not wrong :-(
>
>>Could somebody out in net.land  clarify this ?
>
>*****>	You are correct.  The default constructor will (should) be called.
>	(BTW, I assume you meant "class" not "Class"?)  Why doesn't it
>	work then....don't know.
>-- 
>	- Paul J. Lucas				University of Illinois	
>	  AT&T Bell Laboratories		at Urbana-Champaign
>	  Naperville, IL			pjl@cs.uiuc.edu


Maybe no Chore object ever gets constructed, because no Chore objects
are declared or allocated?  And maybe AtomicInt is only used in
Chore.  Thus it would be correct for no constructors to be invoked.
Unless we see the actual code, we can only guess.  (And the typos prove
this isn't the actual code.)
Newsgroups: comp.lang.c++
From: jeh@cs.rit.edu (James E Heliotis;;;)
Subject: Re: Reference to a pointer??
Reply-To: jeh@cs.rit.edu
Organization: Rochester Institute of Technology, Rochester, NY
Date: Fri, 11 Sep 1992 16:36:03 GMT

In article 716157377@mcl, ucosmo@mcl.ucsb.edu (Boris Burtin) writes:
> :
> :
> 
> So why can't you do this:
> 
> void f(int& *p)
> {
> 	p = 0;
> }
> 

I did this once.  I believe it would be "int * & p", since it is a ref to
a pointer to an int.  Too bad about reference syntax; overall interpretation
of declarations in C/C++ follows rather consistent rules, but the overloaded
'&' makes it a bit confusing.


---
				Jim Heliotis
				Rochester Institute of Technology
				Rochester, NY 14623-0887
				jeh@CS.RIT.EDU
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Answers on a postcard...
Date: 14 Sep 92 19:17:36 GMT
	<92255.112151KKEYTE@ESOC.BITNET> <1992Sep11.174716.3699@taumet.com>
	<92256.150512KKEYTE@ESOC.BITNET> <1992Sep13.160033.7735@taumet.com>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: steve@taumet.com's message of 13 Sep 92 16:00:33 GMT

In article <1992Sep13.160033.7735@taumet.com> steve@taumet.com (Steve Clamage) writes:

   It would be possible to change the rules so that order of evaluation
   was preserved for overloaded versions of operators "&&", "||", and ",".
   Any proposal to do so would have to show some good reason why the
   change is needed.  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).

Well, one way to view the "," operator is not in its use as a sequence
operator, but in its use as something that "builds argument lists".

I could imagine writing an RPC package which might use function calls
that look like:

	rfun f1 = get_remote_function("...f1");
	rfun f2 = get_remote_function("...f2");
	promise p = (f1,arg1,(f2,arg2),arg3);

I haven't tried this though, and I generally don't like too much
syntactic gadgetry. But, once you have added a feature, people are
going to find a use for it...

					Thomas.
Newsgroups: comp.lang.c++
From: maffeis@ifi.unizh.ch (Silvano Maffeis)
Subject: Convert C headers for C++
Organization: University of Zurich, Department of Computer Science
Distribution: comp.lang.c++
Date: Mon, 14 Sep 92 09:08:16 GMT

Hello!

I'm looking for a tool (something like protoize) to automagically
convert C headers for C++ (by including extern "C" declarations etc.)

Any hint is appreciated!
Please e-mail directly. I'll post a summary...

Thanks!
silvano maffeis

-- 
Silvano Maffeis       CS Dept. University of Zurich, Switzerland
   RFC822: maffeis@ifi.unizh.ch            voice: +411 257 43 27
   X.400: /S=maffeis/OU=ifi/O=unizh/PRMD=SWITCH/ADMD=ARCOM/C=CH/
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: zero-length datatype
Date: 7 Sep 92 21:13:55 GMT
Reply-To: tmb@idiap.ch
Distribution: comp
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)

C++ seems to be lacking in a data type that is guaranteed to be zero
length.  For example, a variable cannot be declared to be of type
"void":

	struct Foo {
		int x;
		void y;
	};

Why would you want such a thing? With template classes, it happens not
infrequently that some general class (e.g., a hash table) is useful
when one of the types (for "dictionary-like" types, that is usually
the "value" part) is unused. In that case, it would be nice if I could
specify that that part should not take up any space.

Consider, for example, the following template class definition:
	
	template <class A,class B>
	struct Bar {
		A x;
		B y;
	};
	

Now, the straightforward declaration obviously fails.

	Bar<int,void> s;

The following one compiles, but, unfortunately, "sizeof t" turns out
to be 8, not 4 (I believe the C++ definition makes an effort to ensure
that this is so):

	struct nothing {};
	Bar<int,nothing> t;
	
The non-existence of a zero length type is somewhat of a nuisance.
One fix might be to allow definitions of objects of type "void", give
them zero length, and introduce a single value for objects of type
"void", denoted "void()". Of course, there would be some minor
conflicts with the "function(void)" syntax, but those could be
resolved compatibly. Alternatively, another built-in special type
could be introduced, say, called "unit", that would be available
(only) after "#include <unit.h>".

					Thomas.
Newsgroups: comp.lang.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: zero-length datatype
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Distribution: comp
Date: Thu, 10 Sep 92 00:37:26 GMT

In article <TMB.92Sep7171355@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
|> C++ seems to be lacking in a data type that is guaranteed to be zero
|> length.


This understates the situation.  C++ guarantees that no object
will have size 0.  For example 

	struct Z { } ;

may not have size 0.

One reason for this constraint is to ensure that no two objects
have the same address.  In particular the elements of an array
are always at different addresses.

	Z a[10] ;

Without that constrain a[0],...,a[10] would all compare equal.
(I know a[10] isn't a real member, but ANSI C guarantees that
it is legal to take its address).

Another is that  new Z will never return the same adddress.
Of course you could add this as an additional constraint on
operator new if you wanted to.

The constraint predates templates. Maybe it should be reconsidered.
However that would require some consideration of the effect 
on existing code, and on common programming idioms.  For example
something like

	Z a[10] ;
	... 
	count = sizeof(a)/sizeof(Z)

suddenly becomes a divde by zero.

  -- Jerry Schwarz
From: acanter@sdcc3.ucsd.edu (Adriaan Canter)
Newsgroups: comp.lang.c++
Subject: C++ Variable Argument Lists (,...)
Keywords: Ellipse, Variable Argument
Date: 9 Sep 92 04:47:36 GMT
Distribution: ca


Hi there, kind 'o novice question...

Is there any way that a function with a variable argument list
(as indicated by ellipses) can tell how many variable arguments have
been passed to it? I'd like to use the va_arg macros in the called
function to extract values from a variable argument list. These macros
return a pointer to the location on the stack where the arguments were
pushed by the calling program. There doesn't seem to be any way to tell
how many of them were passed, however, since with va_arg you can index
as far as you want into the stack. I'd like to get around passing the
number of arguments passed, or terminating the list with a special code.
Is this possible? Thanks - Adriaan Canter.
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 5 Sep 92 19:57:05 GMT
	<DAVEG.92Aug27002517@synaptx.synaptics.com> <4116@seti.UUCP>
	<boehm.715019515@siria>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: boehm@parc.xerox.com's message of 28 Aug 92 16:31:55 GMT

In article <boehm.715019515@siria> boehm@parc.xerox.com (Hans Boehm) writes:

   This touches on another serious issue with garbage collection in
   C++ that I haven't seen discussed - namely that of programming
   style. [...]

   My standard example is a list implementation that consists of a
   "linkable elements" class from which one can inherit (possibly
   multiple times) to get a link field added to one's data structure.
   [...]  if you draw some pictures, you can convince yourself that if
   you do enough of this, you are likely to eventually connect
   everything to everything. [...]

   I don't think this is an insurmountable problem, since the overhead
   of using cons-cells is probably pretty minimal in reality (and may
   be negative, since you probably didn't really need all those link
   fields at once).  But there is a problem with some existing code
   and programming styles here.  Interestingly, this seems to be more
   of a problem with C++ code than with C code.

I think this is not a serious problem for two reasons:

(1) Existing code that uses such techniques also contains explicit
    memory management code (i.e., calls to "delete"), so it would
    continue to run as it always did.

(2) Making some data structure into a linked list by inheriting from
    something is rarely "the right thing". I think it was used
    primarily because C++ lacked better type-safe mechanisms.  With
    the addition of templates to the language, collection classes will
    be implemented differently and in a more "GC-friendly" way.

					Thomas.
From: jeanh@ERE.UMontreal.CA (Jean Hugues)
Newsgroups: comp.lang.c++
Subject: Problems with the cout function and \f escape sequence
Keywords: Turbo C++, cout, formfeed
Date: 15 Sep 92 01:17:06 GMT
Organization: Universite de Montreal


I am unable to perform a formfeed wihtin Turbo C++ v.3.0 using the simple 
command : cout << '\f';
All it does is printing ASCII caracter #12 witch I can't post here.
I also tried to print ASCII caracters using cout << '\xHHH; replacing HHH
by the hex value but it doesn't correspond with those in the ASCII table.

I am a new user (in fact, I buy the compiler today) so I would appreciate if 
somebody could give me a hint. Thanks in advance!
Newsgroups: comp.lang.c++,comp.std.c++