HDTenEightyP/NetNews huggingface dataset:
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: C for loop
Date: 20 Nov 92 18:12:34 GMT
Organization: AND Software BV Rotterdam

In article <1992Nov20.134343.4978@magnus.acs.ohio-state.edu> ckkoo@magnus.acs.ohio-state.edu (Chee K Koo) writes:
|I am new to C programming, while i was doing a numerical analysis
|program which uses many for loop
|here is the loop looks like
|
|for(i=1;i<=n;i++);
|{
|}
|
|i put the ";" after the loop header, when the program is excuted, the loop
|is skipped, however, it works fine when the ";" is removed.
|
|I just want to find out why the compiler does not catch it during
|compilation. It is compiled with UNIX gcc.

The compiler can't complain, because your code is perfectly legal 
(syntactically speaking that is.) What the compiler actually `sees'
is this: `for(i=1;i<=n;i++)<<empty statement expression>>;' followed
by a block of code. The <<empty statement expression>> is allowed in C.
In this situation it might seem silly to allow this, but have a look 
at a naive example implementation of strlen:

size_t strlen(char *s) {

	size_t len;

	for (len= 0; *s; len++, s++);

	return len;

}

See? All the necessary actions are done _within_ the for loop part, i.e.
no other statements are necessary here. Isn't C wonderful! ;-)

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.lang.c,comp.software-eng
From: wells@cdsmn.mn.org (Rich Wells)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: Dicomed, Inc
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 16 Nov 1992 16:42:36 GMT

Duane Murphy (damurphy@wc.novell.com) wrote:
: I believe that we are not teaching programmers analysis before design.  
: We teach them syntax and pretend that this is analysis.  Analysis is real 
: and important.  How can you design a program that you cannot read!

I wholeheartedly agree.  How can one design when one has never seen
a good design from someone else?

Example: in my first real-world job, I was given the task of writing
a display system based (loosely!) on the GKS standard.  Reading that
standard - a generic design for a graphics package - taught me more
about software design than any amount of hacking experience ever could.  
It taught orthogonality, how to separate software into layers,
information hiding, abstraction, and even the rudiments of object-
oriented programming.

Likewise, I've learned a lot by reading some of the original Bell
Labs articles about Unix.

In short, I think Duane has a good point.  An important and almost
always entirely neglected part of a software engineering education
(by whatever name you give it) is the study, analysis, and criticism
of past designs.  After all, the best way to see where we're going
is to see where we've been.  Software engineers, as a whole, have
little sense of history.

BTW: Let's not get into a discussion of GKS here; such discussion would
belong on comp.graphics, and given how outdated GKS is now, probably
wouldn't even be welcome there.  Suffice it to say that GKS was by
no means perfect, but had a well enough written standard that I was
able to learn a lot of valuable lessons from it.
-- 

Richard Wells  wells@cdsmn.mn.org  or  ...!tcnet!cdsmn!wells
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: Pascal as C prelude?
Date: 21 Nov 92 15:38:27 GMT
Organization: AND Software BV Rotterdam

In article <forb0004.94.722315425@student.tc.umn.edu> forb0004@student.tc.umn.edu (Eric Forbis) writes:
|The U of Mn suggests, but does not require, taking a quarter of Pascal 
|before taking C. I have no experience with pascal, but have read that the 
|two languages utilize similar concepts and structures couched in different 
|terms. Is pascal really a useful introduction to C- should I be taking 
|that class after all? It's not my intent to start a C vs pascal flame war 
|here... It seems to me that, if pascal is that similar to C, you might as 
|well forego pascal and hop right into C. 

Yes, you could do that, but if you're new to _programming_, you would
hop right into a slimey can of worms. The C programming language allows
a programmer to do about anything s/he can come up with, using his/her
perverted mind ;-) The compiler doesn't really care what you're doing,
there's no rigid runtime system linked with your code to protect you
against small errors you accidentally included in your code. On the
other hand a Pascal compiler (and runtime system) take you by the hand
and lead you through all twisty passages called programming. 

My advice is: study Pascal first and when you think you've got a firm
notion of pointers, pointer arithmetic, dynamic memory allocation and
all sorts of wonderful stuff, switch to C. 

#define SILLY_MODE
#ifdef SILLY_MODE

There's just one drawback, when you do this: you'll end up writing
ugly formatted code like:

if (condition)
	{
	statement1;
	statement2;
	}

instead of the proper:

if (condition) {
	statement1;
	statement2;
}

#endif

;-)

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.lang.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: fwrite & fread
Date: Mon, 23 Nov 1992 12:58:27 GMT
Organization: D'Arcy Cain Consulting

<U17868@uicvm.uic.edu> writes:
>I am using write & fread to read and write to a file. The structure that I
>am writing has 194 bytes. After executing fwrite I check the value, in vari
> [...]
>typedef struct activity{
>   [...]
>	char note[300];

How can a structure with this entry in it be only 194 bytes?

-- 
D'Arcy J.M. Cain (darcy@druid.com)  |
D'Arcy Cain Consulting              |   There's no government
Toronto, Ontario, Canada            |   like no government!
+1 416 424 2871          DoD#0082   |
Newsgroups: comp.lang.c
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: The Correct Way To Write C if-Statements
Organization: McGill Research Centre for Intelligent Machines
Date: Sun, 15 Nov 92 20:06:37 GMT

In article <craigh.721691551@cserver>, craigh@cserver.plexus.com (Craig Heilman) writes:
> [M]y style manual (Webster's Standard American Style Manual) says:
> "In typewritten material, two spaces follow a period that ends a
> sentence. ... In typeset material, only one space follows this
> period."

In typeset material, spaces don't occur in nice integer units, so "one
space" versus "two spaces" makes no sense.  (Unless it's being typeset
monospaced, of course.)  The space after a period (or more precisely,
at the end of a sentence - not all periods end sentences) *is*
generally wider than the space between words in that sentence, though.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Newsgroups: comp.lang.c
From: eager@eagercon.com (Michael J. Eager)
Subject: Re: Include file directory search path
Reply-To: eager@eagercon.com
Organization: Eager Consulting
Date: Thu, 19 Nov 1992 17:17:58 GMT

In article 92Nov18151448@mdtf14.fnal.gov, sim@mdtf14.fnal.gov (Jim Sim) writes:
>Is there a way to force the C preprocessor to use the same search path to
>locate nested include files (files included by another include file) 
>that it uses to locate non-nested include files. My motivation for doing 
>this is to allow developers to make "test" changes to nested include files 
>that don't affect "official" versions of those include files. Consider the 
>following:

The compiler uses the same directory search path for all included files.

I think that what you want to do (if I can understand it) is to create two
(or more) include directories.  Search them in sequence, with the testing
directory first:

	cc -c main.c -Imy/testing -I/usr/local/official 

If someone makes a change in stuff.h, it is placed in my/testing and will
be used instead of .../official

Any nested includes in stuff.h will be resolved in the same way, first from
my/testing then from .../official.

(As an aside, you have to be sure that when you make changes to one include
file that you recompile all files which include that file, either directly
or indirectly.)

You may also want to look at VPATH in make.

---
Michael J. Eager		Michael.Eager@eagercon.com
Eager Consulting		(415) 325-8077 
1960 Park Boulevard, Palo Alto, CA 94306-1141
Newsgroups: comp.lang.c
Subject: Re: Reasons for using C vs. Fortran or vice/versa
From: alanb@sdl.mdcbbs.com (Alan Braggins)
Date: 17 Nov 92 12:07:27 GMT
Distribution: usa
Organization: Shape Data (Division of EDS), Cambridge UK
In-reply-to: steve@taumet.com's message of Fri, 13 Nov 1992 17:15:42 GMT

>>>>> On Fri, 13 Nov 1992 17:15:42 GMT, steve@taumet.com (Steve Clamage) said:

> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes:

>>     It is easier to write Fortran that a compiler will properly optimize
>>than it is to write optimizable C.

> This is a trifle ingenuous, or perhaps just incomplete.
[gives more complete explanation]

>  This is the
> "aliasing" problem, and dramatically affects the efficiency of
> mathematical code in C compared to Fortran.

What happened to the proposed "noalias" type qualifier?
--
     Alan Braggins, alanb@sdl.mdcbbs.com, abraggins@cix.compulink.co.uk
Shape Data - A division of EDS-Scicon Limited.   Cambridge, UK +44-223-316673
   "Any technology distinguishable from magic is insufficiently advanced."
 "My employer does not necessarily share my views - but I'm working on it."
Newsgroups: comp.lang.objective-c,comp.sys.amiga.programmer
From: belk@dxcern.cern.ch (Andy Belk)
Subject: Re: GNU Objective C questions
Organization: CERN European Lab for Particle Physics
Date: Mon, 16 Nov 1992 10:28:20 GMT

Unless I'm much mistaken, GNU Objective C, like the NeXT implementation
thereof, is a direct code to assembler compiler, i.e. it doesn't go
through a C translation stage.

I couldn't reply by mail for some reason.

Andy
-- 
					    ...   Anyd   ...
From: lozinski@cup.portal.com (Christopher A Lozinski)
Newsgroups: comp.lang.objective-c
Subject: DOS, Borland and Objective-C
Date: Sun, 15 Nov 92 17:27:03 PST
Organization: The Portal System (TM)
Distribution: world

There have been two recent questions about Objective-C running under DOS.

>Who are the vendors of Objective-C on DOS.

Stepstone (203) 426-1875 sells the Objective-C Translator.  This converts 
Objective-C into ANSII C.

Berkeley Productivity Group (510) 795-6086 sells the Borland
Extensions to Objective-C.  This allows the Stepstone translator to
be used with the Borland Compiler.

Creative Computing Solutions (805) 962-6151 is about to release
Objective-C Views a class library for building Graphical User
Interfaces under Microsoft Windows.  

>Is Borland C 3.1 shipped with an obj-c extension, really?  

No.  The Borland Extensions to Objective-C are a third party product
which allow the Stepstone Translator to be used with the Borland
Compiler.

If you would like more information about the Borland Extensions to 
Objective-C, please send your postal address and telephone number to:

Berkeley Productivity Group
35032 Maidstone Court
Newark, CA 94560, USA
Tel:(510) 795-6086  
Fax:(510) 795-8077
CompuServe:71201,1175  
Internet:lozinski@cup.portal.com
Newsgroups: comp.lang.objective-c,comp.sys.next.programmer
From: sailer@hpuerca.atl.hp.com (Lee Sailer)
Subject: Re: Seeking Objective-c prettifier
Date: Fri, 20 Nov 1992 00:24:02 GMT
Organization: Hewlett-Packard NARC Atlanta
X-Newsreader: Tin 1.1.3 PL5

: 
: >> "Anyone have or know of an Objective-C prettifier?"
: >> 
: >> man indent. It's actually not too bad...
: >> 
: >> -g
: 
: > Well, it's better than cb, but not much, for one big reason:
: 
: >    BUGS
: >       Indent doesn't accept Objective-C style (//) comments.

Another solution would be to write a filter that changes // comments
to /* */ comments.

However, on my NeXT, I've never gotton indent to behave properly.  It
always seems to garble some part of the pretty print, even when no //
are involved.

Thus, perhaps the final solution is to get the source to indent
and fix it. 8-)

lee

Newsgroups: comp.lang.objective-c,comp.sys.next.programmer
From: Michael_Pizolato@afs.com (Michael Pizolato)
Subject: Re: Proper way to access superclass instance variables
Followup-To: comp.lang.objective-c
Reply-To: Michael_Pizolato@afs.com
Date: Fri, 20 Nov 1992 14:55:15 GMT

In article <1992Nov18.213742.493@afs.com> Michael_Pizolato@afs.com (Michael  
Pizolato) writes:
> A question of philosophy.  Consider the following classes:
> [discussion of direct vs. method access of ivars removed]

I'd like to add to the original by suggesting that even within a class one should only refer to that class' instance variables via methods designated for that purpose, execpt of course in the ivar access methods themselves.  For example:

@interface Mumble:Object
   {
   int value;
   }
- (int)value;
- setValue:(int)number;
- (int)doSometingWith:anotherNumber;
- (int)doSometingWrongWith:anotherNumber;
@end

@implementation Mumble
- (int)value
   {
   return value;
   }

- setValue:(int)number
   {
   value = number;
   return self;
   }

- (int)doSometingWith:anotherNumber
   {
   return [self value] * anotherNumber;
   }

- (int)doSometingWrongWith:anotherNumber
   {
   return value * anotherNumber;
   }
@end

This leads to something of a "class within a class" idea, where there is an inner layer of methods designed to provide access to the instance variables, and other methods that use these access methods to get the values they need.  There can be, however, a blurring of the lines between these two types of methods, for example if methods are implemented that appear to the user of a class to provide access to an instance variable, but which in fact cover a data representation that is implicit in other ivar val
ues.  This kind of method is really neither an ivar access method nor one which does "actual work."

I know this isn't very heavy stuff, but it can become an important consideration when implementing data representations.

-Michael

--
Michael_Pizolato@afs.com
~18 kyu
Q16
NeXTMail appreciated
From: carsten@pizza.fb10.tu-berlin.de (Carsten Schultz)
Newsgroups: comp.lang.objective-c
Subject: Re: Proper way to access superclass instance variables
Date: 22 Nov 1992 11:58:24 GMT
Organization: ZRZ/TU-Berlin
Distribution: world
Reply-To: carsten@pizza.fb10.tu-berlin.de (Carsten Schultz)
NNTP-Posting-Host: pizza.fb10.tu-berlin.de

In article <1992Nov18.213742.493@afs.com> Michael_Pizolato@afs.com  
(Michael Pizolato) writes:
> A question of philosophy.  Consider the following classes:
> 
[...]
> I can't think of any good reason to access 'value' directly unless I  
have complete control over the implementation of the Foo class.  Even if I  
do, it's painful to change every subclass of Foo that might use 'value'  
directly if I change Foo as above. 
> Any thoughts?

Of course, there's a reason to use the variables directly: it's faster.  
But of course it's dangerous to do so, for the reasons you mentioned. In  
case of classes you didn't implement yourself, you should only directly  
acces variables, if it seems necessary and they're documented. Maybe  
someone who doesn't want the variables to be used should declare them  
private.

> 
> Thanx,
> Michael
> 
> P.S.  Given the conclusion that ivars should only ever be accessed  
through methods, it seems wrong that they appear in the @interface  
section.  Of course we can't change it now, but does anyone know why  
they're there?

I always thought, that this is, because the compiler sometimes needs to  
know the size of the object; but now that I think about it, I can't think  
of an example (at least not with nice Objective-C code).

> 
> --
> Michael_Pizolato@afs.com
> ~18 kyu
> Q16
> NeXTMail appreciated

Carsten
Newsgroups: comp.lang.postscript
From: yann@dagobah.fdn.org (Yann Lechelle)
Subject: DRIVER Postscript for Windows 3.1
Keywords: driver, windows
Reply-To: yann@dagobah.fdn.org
Organization: Individual
Date: Sun, 22 Nov 1992 15:24:31 GMT

Hi !

who knows where I can find a driver for printing into a file from Windows  
3.1 for use on a Postscript device later on... the file would have a .ps  
extension for example...

Thanks.


-- 

Yann Lechelle			  (Paris, FRANCE)
yann@dagobah.fdn.org		   Email/NeXTmail
			  ~
From: clewis@ferret.ocunix.on.ca (Chris Lewis)
Newsgroups: comp.lang.postscript
Subject: Re: Postscript Font Scaling & Reduction
Date: 18 Nov 92 23:40:36 GMT
Distribution: na
Organization: Elegant Communications Inc., Ottawa, Canada

In article <1992Nov18.181137.25836@adobe.com> delahunt@adobe.com (Jim DeLaHunt) writes:
>In article <1992Nov18.045514.4005@oucsace.cs.ohiou.edu> 
>carlip@oucsace.cs.ohiou.edu (Walter C3arlip) writes:

>>... As I understand it, a given style of type will
>>have a different design depending upon the point size it is to be printed
>>at, e.g., Times Roman at 12pt will have lines that are wider and darker
>>relative to the hight of the letter than Times Roman at 20pt.

>PostScript technology preserved this linear scaling.  The glyph outline
>is described in bezier curves, and the PostScript interpreter scales the
>outline linearly to the desired size.  Therefore, most PostScript typefaces
>have a single design which is used for all sizes.

I was under the impression that the "hints" allow the font machinery
to do adjustments based on target point size.  From my experiments, linear
font scaling doesn't look that great.

Psroff 3.0 has a HP Laserjet bitmap font scaling program.  It's strictly
linear.  When you scale up, the stroke relative widths stay constant.  But
what started being a reasonable Roman font starts looking bold, and bold starts
looking very fat.  (this is with relatively large magnifications.  Eg:
10pt -> 36pt)  Quite useable within my range of sizes, but still noticable.
-- 
Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff 3.0 info: psroff-request@ferret.ocunix.on.ca
Ferret list: ferret-request@ferret.ocunix.on.ca
Newsgroups: comp.lang.postscript
From: ab@nova.cc.purdue.edu (Allen B)
Subject: Re: Postscript Font Scaling & Reduction
Keywords: linear seems OK
Organization: Purdue University
Distribution: na
Date: Thu, 19 Nov 1992 21:39:09 GMT

In article <zisk-191192111648@macne006.boston.us.adobe.com> zisk@adobe.com  
(Stephen Zisk) writes:
> In response to what Chris Lewis and Walter C3arlip wrote, and amplifying
> what Jim Delahunt said, I want to add my $.02. As a caveat, let me say
> I am not a type designer or expert, just an interested amateur.

Same here, but I am trying to get into type design now.

>     4.) The reasons for different designs at different sizes in hot type
>         (and Multiple Master Fonts) are complex and subtle:

As far as I've seen, in most cases it was for mechanical
reasons (as the poster said).  Trouble is, some people
expect it now.  "Hysterical raisins." :-) 

>     6.) There is no reason "linear scaling" should look bad within a
>         common-sense range of sizes.

I'll second that.  I've been messing with Type 1 fonts and
scaling and have been very happy.  Eventually, you get
little black smudges, but in general if I could read it, it
looked pretty good.


Does text look funny to you if you get a little closer or
farther (assuming you can still read it)?  Seems like the
same perceptual problem to me.  Getting farther from or
closer to text basically linearly scales it until you hit
resolution limitations. 

Of course, if I take my glasses off, I can't read anything. :-)

I >would< like to hear any suggestions people have for
modifying fonts at different sizes and the reasoning
behind them so I could experiment a bit and see what I
think.  Always looking for more information. :-)

---
save /- 1 string def[331 64 779242 46 396 46 871217102 46 14782 10]{dup
99 lt{- 0 3 -1 roll put -}{32 =string cvrs}ifelse print} forall restore
Newsgroups: comp.lang.postscript
From: zisk@adobe.com (Stephen Zisk)
Subject: Re: Lev 2 Image Dictionary Question
Followup-To: comp.lang.postscript
Organization: Adobe Systems Incorporated
Date: Tue, 17 Nov 1992 17:26:35 GMT

In article <1992Nov16.231218.16989@infonode.ingr.com>,
dave@maven.b29.ingr.com (Dave Bradford) wrote:
> 
> I am trying to write a color raster level 2 PostScript driver
> <some lines removed>
> /rline currentfile /ASCIIHexDecode filter def
> /gline currentfile /ASCIIHexDecode filter def
> /bline currentfile /ASCIIHexDecode filter def
> <more lines removed>
> /DataSource [rline gline bline]
> <more lines removed>

The problem here is simple: Your three data sources are not truly
independent.
You are making a presumption about the order in which the interpreter calls
your data sources. In order to use three separate data sources, you would
have
to have three files (or strings, or whatever) which could be accessed in
any
order, without regard to interrelationships. See the Red Book (2nd
edition):
 p. 214 (last paragraph) - "The three sources... must actually be
independent"
 p. 215 (diagram) - Note the bracketed "independent"
 p. 225 (first paragraph under "Color Image with Single Source.") -
        "The first organization is the only one that is useful for images
         whose data are provided in-line in a PostScript language program.
         The second organization is limited to situations in which the
         separate components are stored elsewhere, such as in separate
         files that can be read in parallel."

If the image data were small enough to be stored in strings, you could pre-
define the individual strings and use them in the image operator. The fact
that your code worked on some Level 1 implementations is, unfortunately,
device-dependent. You were depending on the device reading all the red
data,
then all the green, then the blue. Many devices did just this when allowed,
but this is not a standard. That is why the "independent" was stressed so
much in the new Red Book. Sorry!

Stephen Zisk (zisk@adobe.com)  Disclaimer: These are my personal opinions
and
Adobe Systems Incorporated     do not represent the views of Adobe Systems
Eastern Regional Office        Incorporated.
24 New England Exec. Park
Burlington, MA 01803           They pay me but they don't muzzle me!