Alan_Cote.DlosLV-Comm@Xerox.COM (06/25/87)
PEBRBV writes, >Henry Spencer <henry@utzoo.uucp> suggests (assuming a and b have >no side effects) >>#define STREQ(a, b) (*(a) == *(b) && strcmp((a), (b)) == 0) >>This makes a considerable speed difference in programs that use strings >>a lot, since string comparisons usually fail on the very first character. >Except that the compiler is free to do the strcmp call before the >comparison *(a)==*(b), or even do both tests and AND the results. >But a good optimizer should do it efficiently. Kernighan and Ritchie specifies (Appendix A, clause 7.11), "Unlike &, && guarantees left-to-right evaluation; moreover, the second operand is not evaluated if the first operand is 0." Therefore, the compiler is NOT free to do both tests! However, STREQ may have only minimal value, as any good strcmp() implementation will return immediately upon discovering that the first bytes of its arguments do not match. - Alan T. Cote'
PEPRBV@cfaamp.bitnet (06/27/87)
Oops, you caught me not reading the fine print. With all the past discussion about C's freedom to re-order and re-group expressions, I just assumed that the same thing applied to &&.
herndon@umn-cs.UUCP (Robert Herndon) (07/07/87)
In article <8011@brl-adm.ARPA>, Alan_Cote.DlosLV-Comm@Xerox.COM writes: > >Henry Spencer <henry@utzoo.uucp> suggests (assuming a and b have > >no side effects) > >>#define STREQ(a, b) (*(a) == *(b) && strcmp((a), (b)) == 0) > >>This makes a considerable speed difference in programs that use strings > >>a lot, since string comparisons usually fail on the very first character. This will also greatly slow a good many programs down on machines that do not support byte addressing. Unless there are good reasons to do this for a particular application, restraint should be used in applying this "optimization". Like many other optimizations, this is a pessimization for many machines. -- Robert Herndon Dept. of Computer Science, ...!ihnp4!umn-cs!herndon Univ. of Minnesota, herndon@umn-cs.ARPA 136 Lind Hall, 207 Church St. SE herndon.umn-cs@csnet-relay.ARPA Minneapolis, MN 55455
czmurek@drunivac.drew.edu (04/11/90)
hello all: could someone please tell me how i can subscribe to this list directly... thankyou -christine
norm@oglvee.UUCP (Norman Joseph) (07/16/90)
In <1990Jul11.230014.25608@arcturus.uucp> evil@arcturus.uucp (Wade Guthrie) writes: >While we're on the subject of technical journals, how does one >get a subscription to the Journal of C Language Translation? I believe you can contact Rex Jaeschke at uunet!aussie!rex. -- Norm Joseph cgh!amanue!oglvee!norm@dsi.com Oglevee Computer Systems, Inc. {pitt,cgh}!amanue!oglvee!norm "Shucking Usenet oysters in search of a pearl." -- Bill Kennedy
kjm100@csc.anu.oz (08/01/90)
-- --------------------------------------+---------------------------------------- Kenneth John Mighell | Mount Stromlo Observatory | INTERNET: MIGHELL@MSO.ANU.OZ.AU Private Bag | Post Office Weston Creek, ACT 2611 | Telephone: +61-6-2490230 or 2490234 AUSTRALIA | Telefax: +61-6-2490233 --------------------------------------+----------------------------------------
rankin@airgpx.caltech.edu (08/26/90)
In newsgroup comp.lang.c, article <3204@dftsrv.gsfc.nasa.gov>,\ vander@nssdcb.gsfc.nasa.gov (John Vanderpool) writes: > a few days ago someone asked for the "magic" offset using VAXC I/O file > pointers to the RMS structures - i didn't see anyone reply and was wondering > if anybody replied to him personally if they could e-mail me the info. I didn't notice the original request; here's an answer though. This intro is condensed from the V5.2 fiche for module VAXCIO: ;.sbttl _fstat - return FAB and NAM and RAB block address ; FSTAT needs to use some fields in the FAB, so this routine returns the ; address of the FAB and NAM and RAB block address. [074] ; Inputs: 4(ap) file descriptor number ; 8(ap) address to receive FAB address ; 12(ap) address to receive NAM block address ; [074] 16(ap) address to receive RAB block address ; Outputs: R0 < 0 => error, >= 0 => success If you'd prefer that in C, here's a usage example: #include <stdio.h> #include <rms.h> extern int _fstat(int, struct FAB **, struct NAM **, struct RAB **); .. FILE *fp; struct FAB *fab_p; struct NAM *nam_p; struct RAB *rab_p; int result = _fstat(fileno(fp), &fab_p, &nam_p, &rab_p); if ( result >= 0 ) { /* do something with one or more of the RMS blocks */ } This routine is not accessible in the shareable image version of VAXCRTL. You'll have to link with the object library (vaxcrtl.olb). Since this isn't documented or intended for use by mere mortals, they can change or eliminate it without any qualms. Use at your own risk. (I don't--and won't--use it; simpler just use RMS directly if one needs the file attributes, fully parsed filename, or whatever). Pat Rankin, rankin@eql.caltech.edu
phils@athena.mit.edu (Philip R. Thompson) (10/21/90)
Here's function that has annoying round-off errors.
Does anyone know of a better way to do this decimal
degree conversion?
I've tried lots of work arounds without much success,
so I'm now posting it here. Any solutions are welcome.
This has been tried on a vax, dec and ibm/rt.
Thanks,
Philip
--------------
/* Convert Degrees, Minutes, Seconds number to decimal degrees */
/* Note: 38.30 degrees doesn't work. */
#include <stdio.h>
main()
{
double value, DMSToDecimal();
printf("Enter value (+-dd.mmss): ");
while (scanf("%lf", &value)) {
printf("dec: %lf\n", DMSToDecimal(value));
printf("Another value (+-dd.mmss): ");
}
exit(0);
}
double DMSToDecimal(deg)
double deg;
{
double ideg, frac, minutes, seconds;
double modf();
frac = modf(deg, &ideg) * 100.0;
seconds = modf(frac, &minutes) * 100.0;
if ((minutes > 60.0) || (seconds > 60.0) || (minutes < 0.0) ||
(seconds < 0.0)) {
fprintf(stderr,
"Bad input: %f degs %f minutes %f secs\n", ideg,
minutes, seconds);
return(0.0);
}
fprintf(stderr, "%G = %G degs %G minutes %G secs\n", deg,
ideg, minutes, seconds);
return (ideg + minutes / 60.0 + seconds / 3600.0);
}
--
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> Philip R. Thompson (phils@athena.mit.edu) <
> Computer Resource Laboratory <
> Department of Architecture and Urban Planning <
> M.I.T., Rm 9-526 <
> Cambridge, MA 02139 (617) 253-0782 <
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (10/22/90)
In article <1990Oct20.215718.15519@athena.mit.edu>, phils@athena.mit.edu (Philip R. Thompson) writes: > Here's function that has annoying round-off errors. Step 1. If we have Degrees, Minutes, and Seconds as integers: double degrees(int Degrees, int Minutes, int Seconds) { return ((Degrees*60.0 + Minutes)*60.0 + Seconds)/3600.0; } Things to note about this: the floating-point constants here can be represented *exactly*, as can the values of Degrees, Minutes, and Seconds; the multiplications yield integral values (in floating-point format), so are likely to be exact (and in IEEE arithmetic *must* be); so the only place that error can creep in is the division (don't convert that division to multiplication by the reciprocal). In IEEE arithmetic, then, this will be out by 1 ULP at most. Step 2. The problem with the original code was that it read in the angle . DD MM' SS" in the form DD.MMSS (as a floating-point number) and then tried to extract DD, MM, and SS from that. It's best to read them as integers. If you want to read that format, do scanf("%d.%2d%2d", &Degrees, &Minutes, &Seconds); I would actually recommend a different input format, perhaps DD.MM'SS" read using scanf("%d.%d'%d\"") as 120.12'30" is rather more obviously degrees.minutes'seconds" than 120.1230, which looks more like 120.1230 degrees. It's also easier to get the zeros right: 120.0'15" is unlikely to be a mistake, but 120.015 is a likely mistake in the other format. -- Fear most of all to be in error. -- Kierkegaard, quoting Socrates.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/24/90)
In article <4035@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: [ on controlling round-off errors ] > double degrees(int Degrees, int Minutes, int Seconds) > return ((Degrees*60.0 + Minutes)*60.0 + Seconds)/3600.0; Some machines (e.g., Convex) have a 64-bit integer, the ``long long'' type. It's better to do the base conversion in that than in 48-bit floating point. > It's best to read them as > integers. It's best to stick to integers entirely, if there's no worry of overflow. ---Dan
browns@iccgcc.decnet.ab.com (Stan Brown) (02/02/91)
In article <BEVAN.91Jan30084205@rhino.cs.man.ac.uk>, bevan@cs.man.ac.uk (Stephen J Bevan) writes: > ``Recommended C Coding Standards''(v5.3) mentions them in section 11, but How can I get a copy of this? (I have no ftp access.) Hey--this is all my opinion, nobody else's. Rely on it at your peril. email: browns@ab.com -or- browns@iccgcc.decnet.ab.com Stan Brown, Oak Road Systems, Cleveland, Ohio, USA +1 216 371 0043
stx1374@uoft02.utoledo.edu (03/27/91)
bangell%hellgate.utah.edu@cs.utah.edu (Bob Angell) (04/11/91)
Try saving the files before you start compiling, etc. BTW, I believe if the files do pass the litmus test, they are saved automatically. -Bob-