HDTenEightyP/NetNews huggingface dataset:
From: lewis@sophists.com (Lewis G. Pringle)
Subject: Re: ios::iword, ios::pword, ios::xalloc
Date: Mon, 12 Oct 1992 18:14:26 GMT
Organization: Sophist Solutions

In article <1992Oct8.234902.12170@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>These functions are intended to support extension of stream types
>without requiring derivation.  My claim is that this is useful because
>the actual type of a stream is lost in an expression involving insertions
>or extractions.  That is
>
>	mystream m ;
>	m << y << mymanipulator ;
>
>You can't declare
>
>	mystream& mymanipulator(mystream&) ;
>
>because it's argument is an ostream&, not a mystream&.  However mymanipulator
>can look into the infinite arrays  for any useful information put there
>by the mystream constructor.

Could you please elaborate even further.

A long standing problem with the isotream library, from my point of view,
was that roughly half the time I wanted the interpretation of inserters
to be that it inserted a "pretty" form of the item, and the other half
of the time I wanted the interpretation to be to insert an EXTRACTABLE
represenation of the item. This "pretty" form is most often useful when
preparing to display some object, or when writting out debug info. The
EXTRACTABLE version is most useful when saving and restoring to a file.

I've experimented with hacks like global variables, etc, but what I really
wanted was the ability to "add a boolean" into the iostream so that each
inserter could write things out appropriately. Ideally I would want the
predefiend inserters and extractors (eg int) to also pay attention to
this boolean.

Could the iword/pword mechanism be used to achieve this? Do you know of
some better mechanism to achieve this? How are you supposed to actually
use the iword/pword mechanism? Where is it documented?

			Lewis.
-- 
Reading peoples signatures is a real waste of time.

lewis@sophists.com                                  (Lewis Gordon Pringle, Jr.)
Newsgroups: comp.std.c++,comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: The concept of templates considered ill designed
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 11 Oct 1992 13:37:04 GMT

In article <Eep9xSi00Vp_4391Iw@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
>
>Every advance in languages has been associated with an increased overhead:
>from assembler to C, from C to C++: every time you switch to a higher level
>language you lose some speed. 
>

	Not true! Consider a language with assertion facilities,
the assertions get included as run-time checks. The program is
now 'correct', although you only get to catch errors at run-time.

	Now add an inference engine to the compiler. It might now
PROVE certain assertions, thus eliminating the run-time checks,
the result is faster and smaller. Further more is may show certain
assertions FALSE, thus improving the chances of catching errors
in parts of the code that are not exercised often.

	This would be a major advance IMHO, and it results
in faster code as well as earlier error detection.

	Now consider virtual functions. If you are losing
speed, dont use a virtual. But you need a virtual? Well,
then virtuals are surely faster than an equivalent handcoded
indirect call.

	There are FORTRAN compiler around for which it is claimed
that they produce better code than hand coded assembler. So I think
you have overgeneralised a bit in your claim that advances have
run-time speed costs.

-- 
;----------------------------------------------------------------------
        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.std.c++,comp.lang.c++
From: sdm@cs.brown.edu (Scott Meyers)
Subject: Re: Exponentiation operator proposal
Organization: Brown University Department of Computer Science
Date: Thu, 15 Oct 1992 03:02:29 GMT

In article <1992Oct14.225725.16486@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
| I just ran a quick measurement on a convenient sample of 85,000 lines of
| C and C++ code.  Based on this sample "**" appears on average about once
| per every 200 lines of code.  This is a pretty high occurance.  For comparison
| "^" [XOR] appears on average once per 3000 lines of code!  

How many of these are in declarations versus in expressions?  After all,
"&" already has different semantics depending on whether it's in a
declaration or an expression.  If we could do the same thing with "**", it
would improve the language considerably, because one of the biggest
drawbacks to C++ as it currently stands is that it's too easy to
understand.

:-)

Scott

-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."
Xref: sparky comp.std.c++:1395 comp.lang.c++:15069
From: myersn@hobo.ECE.ORST.EDU (Nathan Myers)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: Exponentiation operator proposal
Date: 16 Oct 92 19:05:38 GMT
Article-I.D.: news.Bw8ADK.144
Organization: ECE Dept.,OSU,Corvallis


I have long ignored "exponentiation proposal" notes, but it seems
time to point out that there is no operator~(T,T) defined yet.
Simply allowing it to be defined would permit experimentation,
without committing anybody to a bigger language if the use didn't
"catch on".

Nathan Myers
myersn@roguewave.com
Newsgroups: comp.std.c++
From: Tachen Ni <tcnyyf@caen.engin.umich.edu>
Subject: Q: How to change the byte length of type "double" in g++?
Date: Thu, 08 Oct 92 13:28:29 EDT
Organization: Bioengineering, Univ. of Mich.
X-Useragent: Nuntius v1.1.1d9
X-Xxmessage-Id: <A6F9E8AC0405343C@no-name-medsci2.med.umich.edu>
X-Xxdate: Thu, 8 Oct 92 18:31:24 GMT


Recently I found that the default g++ (Version 1.37.1 on Unix
machine) byte length for data type "double" (8 bytes) is not 
enough for my project.  Is there any way that I can change it 
to 12 bytes?  

Reply by e-mail preferably.  Thanks for the help.  


Tachen Ni, Bioengineering Program, Univ. of Mich.
e-mail: tcnyyf@caen.engin.umich.edu
From: checker@f1.n100.z60.wlink.nl (checker)
Newsgroups: comp.std.c++
Subject: pointers to class functions
Date: Mon, 12 Oct 1992 03:53:42 -0100

Organization: New York University

bilan@acs.ucalgary.ca (Bohdan Jens Bilan) writes:
>Can anyone tell me how I can assign a function pointer to a
>function, (ie. fptr=&foo()) when the assignment happens within a
>member function of the same class?

If you mean, what do pointers to members look like, see C++PL2 p. 166.

Followups directed to comp.lang.c++.

Chris

Xref: sparky comp.std.c++:1365 comp.lang.c++:14781
From: pete@genghis.borland.com (Pete Becker)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: The concept of templates considered ill designed
Date: 9 Oct 92 17:38:21 GMT
Organization: Borland International
Originator: pete@genghis.borland.com

In article <Eep9xSi00Vp_4391Iw@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
>>
>> 	I think the argument in favor of compiling templates on their own has
>> to focus on this point.  What do you get out of it that you cannot get by
>> simply using pointers?  Easier coding, sure.  But are there significant
>> differences in the kind of things you can do with them?  Or is this a solution
>> in search of a problem?
>> 	-- Pete
>
>
>Who said there was no drawbacks ?
>
>Of course it may add some overhead (although development will be nicer cause
>of typechecking and FASTER turn around time (though precompiled template
>libraries))
>
>Every advance in languages has been associated with an increased overhead:
>from assembler to C, from C to C++: every time you switch to a higher level
>language you lose some speed. 
>
>I don't think particular change will add a big overhead. that's why I
>think it's useful !
>
>	Stefan

	I'll repeat my question: what do you get out of it that you cannot get
by simply using pointers?  Simply asserting that it won't add big overhead does
not establish that it is useful.
	-- PEte
Newsgroups: comp.std.c++
From: arthur@solomon.technet.sg (Arthur Sombrito)
Subject: friend declaration scope
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 7 Oct 1992 09:42:48 GMT



--


Hi,

I'd like to ask some rules regarding the scope of a friend declaration
which are not discussed (as far as I could tell) in the ARM.  
Given the ff. code:

  class B { protected : enum A {}; };
  class C : public B {
    friend class A;   // According to the scoping rules, A refers to B::A.
                      // Since B::A is not a class, should we flag an error
                      // or do we declare a new class A since there is no
                      // existing type symbol in the scope of class C?
  };

Thanks for any replies.
From: bilan@acs.ucalgary.ca (Bohdan Jens Bilan)
Newsgroups: comp.std.c++
Subject: pointers to class functions
Date: 11 Oct 92 16:50:51 GMT
Organization: The University of Calgary, Alberta

Can anyone tell me how I can assign a function pointer to a
function, (ie. fptr=&foo()) when the assignment happens within a
member function of the same class?
Xref: sparky comp.std.c++:1355 comp.lang.c++:14746
From: osoelgaultier+@CMU.EDU (Stefan Monnier)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: The concept of templates considered ill designed
Date: 8 Oct 92 12:51:42 GMT
Article-I.D.: andrew.Eep9xSi00Vp_4391Iw
	<1992Oct7.170351.16316@genghis.borland.com>
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.lang.c++: 7-Oct-92 Re: The concept of
template.. Pete Becker@genghis.borl (2093)
> 	Constrained parameters alone do not make it possible to compile a
> template without regard to how it will be instantiated.

> 	class Parameter
> 	{
> 	public:
> 	    virtual void f( long );
> 	};

> 	template <class T : Parameter>
> 	class DoSomething
> 	{
> 	};

> 	class SmartParameter : public Parameter
> 	{
> 	public:
> 	    void f( long );
> 	    void f( int );
> 	};

> Presumably, SmartParameter adds f(int) because it can handle small values
> in a more efficient manner.  If DoSomething is compiled without knowledge of
> the actual template parameter being used, this smarter interface is lost.
> 	As I mentioned earlier, the other place where you pay for this is that
> all uses of the template parameter must be through pointers.
> 	Being able to compile a template without knowing how it is in fact
> being used may well be useful, but it comes at a price.  The resulting code
> will be less efficient.
> 	I think the argument in favor of compiling templates on their own has
> to focus on this point.  What do you get out of it that you cannot get by
> simply using pointers?  Easier coding, sure.  But are there significant
> differences in the kind of things you can do with them?  Or is this a solution
> in search of a problem?
> 	-- Pete


Who said there was no drawbacks ?

Of course it may add some overhead (although development will be nicer cause
of typechecking and FASTER turn around time (though precompiled template
libraries))

Every advance in languages has been associated with an increased overhead:
from assembler to C, from C to C++: every time you switch to a higher level
language you lose some speed. 

I don't think particular change will add a big overhead. that's why I
think it's useful !

	Stefan

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
Newsgroups: comp.std.c
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: Static function prototypes and definitions
Organization: Twin Sun, Inc
Date: Wed, 14 Oct 1992 19:06:09 GMT

To answer Miller's question, the program

       void f(void) { void g(void); g(); }
       static void g(void) { }

has undefined behavior because g has both external and internal linkage.
See ANSI C 3.1.2.2 (Linkages of Identifiers).
From: "chris.perkins"@f1.n100.z60.wlink.nl ("chris perkins")
Newsgroups: comp.std.c
Subject: file *yyin=stdin; not
Date: Mon, 12 Oct 1992 12:10:43 -0100

Organization: Canada Remote Systems

TO:emmerik@utwente.nl

EP>The following looks to me perfectly legal ANSI-C code.

EP>sgi-cad> cat test.c
EP># include <stdio.h>
EP>FILE *yyin = {stdin}, *yyout = {stdout};
EP>main()
EP>{
EP>}

EP>Nevertheless i get the following results when compiling on a
EP>Silicon Graphics workstation:

EP>sgi-cad> cc -cckr test.c
EP>sgi-cad> cc -ansi test.c
EP>accom: Error: test.c, line 2: integer constant expected
EP>       FILE *yyin = {   (__stdin) }, *yyout = { (__stdout) };
EP>       ---------------------------^

The problem is that stdin and stdout are not constant pointers, but
are macros which get replaced by function calls (it may be compiler
dependant, I'm not sure of the standard).  I think the following
would work:

#include <stdio.h>
FILE *yyin, *yyout;
main()
{
   ...
   yyin = stdin;
   yyout = stdout;
   ...
}

Check your stdio.h to see how stdin and stdout are defined.

Regards,

Chris
  DeLuxe/386 1.25 #9629  Best wishes,         Chris Perkins
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044

Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Aggregate Initialization   **NOT**
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 15 Oct 1992 02:57:36 GMT

In article <1992Oct14.171711.1655@lub001.lamar.edu> wagner@lub001.lamar.edu writes:
>In my code I have a statment similar to the following:
>	int array_name[] = {value,value,value,...};
>Now, this statement is correct in every reference I can find, but when I
>compile it the compiler returns an error and says that aggregate
>initialization is not allowed.

If you're using a pre-ANSI compiler, then the reference you should look in
is K&R's first edition.  Initialization of AUTO aggregates (defined inside
a block, without "static" or "extern" storage class) was not allowed in
those days.

If your declaration is at file scope (not inside a block), and/or if it
DOES say "static" or "extern", then get a refund for your compiler.
Regardless of where your declaration is, if you're using a compiler that
is claimed to be ANSI conforming, then get a refund.  [Personal opinions only.]

Otherwise, try it with an ANSI conforming compiler.  There are two conforming
or "almost" conforming implementations for your platform.  (There's no such
thing as "almost" conforming, but my personal opinion is that one comes
pretty close, and I don't have enough experience with the other.)

>My question is: Is this a bug with my compiler or is it just a sucky compiler!

If it's a pre-ANSI compiler, then it's just a sucky language, and maybe
user who chooses to use a pre-ANSI compiler.  If the compiler is asserted
(by its vendor) to be ANSI conforming, then it's a sucky compiler.
[Personal opinions only.]
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
Newsgroups: comp.std.c
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: Static function prototypes and definitions
Organization: Twin Sun, Inc
Date: Thu, 15 Oct 1992 01:53:56 GMT

lmiller@aero.org (Lawrence H. Miller) writes:

>	If the declarator or type
>	specifier...appears outside of any block or list of
>	parameters, the identifier has file scope, which terminates
>	at the end of the translation unit.

>Now I interpret this to mean what it says: a function definition has
>FILE SCOPE, i.e., from the START to the END of the file.

It doesn't say that: it says only that file scope goes to the end of the file.
C is very much a declare-before-use language:
in C, file scope is from the declaration to the end of the file.
To quote chapter and verse, ANSI C 3.1.2.1 says a normal identifier
``has scope that begins just after the completion of its declarator.''
Newsgroups: comp.std.c
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.std.c
Subject: Re: Static function prototypes and definitions
Date: 16 Oct 92 15:40:25 GMT
Organization: Department of Computer Science, U of Copenhagen

lmiller@aero.org (Lawrence H. Miller) writes:
>	void f(void){static void g(void);}

>	is invalid via 3.5.1 lines 19 and 20.
>	[Note, though, that this is under Semantics, while it should
>	clearly be under Constraints.]

Nope, that would force all vendors to make their compilers reject it.
As it is now, each vendor can define the effect of declaring a
function at block level with storage class static; if that effect in
many cases turns out to be the same as with the vendor's pre-ANSI
compiler, I shall not be surprised.

Clearly, this would never have come to pass in an ideal world.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
From: prato@qut.edu.au
Newsgroups: comp.std.c
Subject: BC Code to Print Barcode on HPLJIII
Date: 8 Oct 92 09:49:53 EST
Organization: Queensland University of Technology


Would anybody know where I may obtain a copy of Borland C 
routines that would print barcodes on a HP Laserjet III?

If anybody has experience/knowledge in this area,
please let me know.

Your assistance would be greatly appreciated.

James Prato,
Computer Systems Officer,
MIS Section,
Queelnsland University of Technology,
Brisbane. Qld
Australia.
email:J.PRATO@qut.edu.au
Newsgroups: comp.std.c
From: Tachen Ni <tcnyyf@caen.engin.umich.edu>
Subject: Q: How to change the byte length of type "double" in g++?
Date: Thu, 08 Oct 92 13:27:21 EDT
Organization: Bioengineering, Univ. of Mich.
X-Useragent: Nuntius v1.1.1d9
X-Xxmessage-Id: <A6F9E8364004343C@no-name-medsci2.med.umich.edu>
X-Xxdate: Thu, 8 Oct 92 18:29:26 GMT


Recently I found that the default g++ (Version 1.37.1 on Unix
machine) byte length for data type "double" (8 bytes) is not 
enough for my project.  Is there any way that I can change it 
to 12 bytes?  

Reply by e-mail preferably.  Thanks for the help.  


Tachen Ni, Bioengineering Program, Univ. of Mich.
e-mail: tcnyyf@caen.engin.umich.edu
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: string literal initializers
Date: 15 Oct 92 21:32:32 GMT

In article <1992Oct14.200405.6014@athena.mit.edu>, scs@adam.mit.edu (Steve Summit) writes:
> However, the only statement that suggests a strict identity
> of the two forms appears in an example [sec. 3.5.7, p. 75,
> lines 24-29], and is thus not part of the standard.

Nonetheless, this clearly shows the committee's intent.  As much as we
all wish that the standard were complete, concise, and correct, those
of us who wrote it are only human and suffer from oversights,
confusion, and mistaken beliefs from time to time.  In particular, when
you know how something is supposed to work, it is very difficult to
describe it in such complete detail that someone who is being
intentionally perverse can't misunderstand it (try it some time). 
Unfortunately, sometimes the misunderstanding is caused not by
intentional perversity, but by simple naivete; this is a much more
serious problem.  Interpretations are intended to address both of these
cases (although, frankly, the committee is not very sympathetic to the
first).

In general, if the standard implies something, then that is what it
means, even if it doesn't come right out and say so.  If you want to
ensure that your interpretation matches the committee's intent, then by
all means send in a Request For Interpretation -- if nothing else, it
lets us know where we should make changes in the next revision of the
standard (although that won't be happening for a few years, yet).  And,
if you think you know what we mean, by all means include that in your
RFI along with pointers to the relevant parts of the standard -- the
less work the committee has to do, the sooner you'll get a response. 
But please don't assume that just because we neglected to explicitly
state something we strongly implied that we intended to leave it
unspecified or undefined.

> These questions seem worthy of an interpretation ruling, if
> anyone really cares.  The abridged list of interpretation rulings
> Chris Volpe posted last August does not appear to cover them.
> (Speaking of lists of interpretations, someone should re-post the
> full list, of which Chris had and posted only the index.  Or have
> I missed that, too?)

I haven't seen anything since then.  ANSI is supposed to be publishing a
Technical Information Bulletin containing all of the responses to RFIs
so far, but I haven't heard anything about it recently.  I'll try to
find out what the status is and I'll see if I can get the text posted
here or if ANSI has one of its usual rules disallowing it.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
Domain: lawrence.jones@sdrc.com               IBMMAIL: USSDR7DR at IBMMAIL
I suppose if I had two X chromosomes, I'd feel hostile too. -- Calvin
From: ravikm@austin.ibm.com (Ravi K Mandava)
Newsgroups: comp.std.c
Subject: Re: order of sequence points in subexpressions
Keywords: sequence points
Date: 8 Oct 92 19:16:37 GMT
Reply-To: piobe!ravikm@ibmpa.awdpa.ibm.com
Organization: IBM Austin
Originator: ravikm@piobe.austin.ibm.com


In article <1992Sep29.222521.9221@kai.com>, david@kai.com (David Nelson) writes:
> We all know that "x = y[++i] + z[++i];" is asking for trouble. But what
> about: "a = b[i+=1,i] + c[i+=1,i];". The comma operators have introduced
> sequence points.
> 
> From ANSI 3.3 Expressions
>      Between the previous and next sequence point an object shall have its
>  stored value modified at most once by the evaluation of an expression. 
>  ...
> My interpretation would be that the sequence point only affects the
> subexpression of the operation that introduced the sequence point. Anyone
> care to confirm or reject this interpretation.

	IMHO, your interpretation is correct, in the sense, each sequence
	point introduced by the comma operator only affects that subexpression.
	In the second example, scope (if I may call it) of each comma operator
	is limited to its subexpression, that is, the expression in the array
	index.  Hence, basically, the second example boils down to be the same
	as the first example after evaluating individual comma-scoped sequence
	points.  And since, the ANSI rule stated above prohibits the case of
	a value of an object being modified twice between two sequence points,
	the second example breaks the rule causing undefined results and thus
	illegal (and shall be incarcerated promptly :-8).

	Out of curiosity, I tried the following code on our compiler, and
	as expected, the executable generated undefined results.

#include <stdio.h>
main(void)
{
   int i = 0, c;
   int a[3] = {1,2,3};

   c = a[i++,i] + a[i++,i];
   (void) printf("c = %d;i = %d\n",c,i);

   return 0;
}

	Its output was 			'c = 6;i = 2'
	After inserting a sequence point between the two operands of '+',
	the result was as expected:	'c = 5;i = 2'

	Hopefully, this proves the point.

Rest my case,
-- 
*******************************************************************************
Ravi K Mandava		email:	piobe!ravikm@ibmpa.awdpa.ibm.com
*******************************************************************************
Newsgroups: comp.std.c