Mike_G_Newman@cup.portal.com (07/22/88)
I may have missed something in the past, but the following
puzzles me:
In 'How to Write Macintosh Software', Scott Knaster says that I
can do something like this:
errCode := FSRead(fileRefNum,count,thisMemberHdl^);
However, Borland's Turbo Pascal wants me to do this:
errCode := FSRead(fileRefNum,count,@thisMember);
Can someone explain this to me? Who's right? Are there other
problems with the Turbo compiler?
What is the Pascal compiler of choice these days? (I know
everyone likes LSP, but I'm afraid I abandoned it out of sloth --
I didn't want to rewrite a lot of code that I had written in
MacPascal that was full of 'exit' statements.)
Finally, is this the place where one can turn to ask basic
questions about programming? I live on a little island (Saipan)
and no one else here seems to write code. So, I have no where to
turn to ask my probably-very-stupid questions. (I know, the only
stupid question is one you don't ask. However, I would hate to
breach etiquette here by asking questions at an inappropriate
level....)
E-Mail replies are just fine.
=================================================================
* Michael G Newman | mike_g_newman@cup.portal.com *
* Now or Never | MCI: mnewman (333-1196) *
* P.O. Box 1510 | voice: 670-234-7726 *
* Saipan MP 96950 USA | *
=================================================================singer@endor.harvard.edu (Rich Siegel) (07/24/88)
In article <7536@cup.portal.com> Mike_G_Newman@cup.portal.com writes: >everyone likes LSP, but I'm afraid I abandoned it out of sloth -- >I didn't want to rewrite a lot of code that I had written in >MacPascal that was full of 'exit' statements.) Macintosh Pascal doesn't have an Exit statement, last I checked. In fact, if you wrote code in Macintosh Pascal, Lightspeed Pascal is an ideal upgrade, since the two are one hundred percent source-compatible. --Rich Rich Siegel THINK Technologies Rich Siegel Quality Assurance Technician THINK Technologies Division, Symantec Corp. Internet: singer@endor.harvard.edu UUCP: ..harvard!endor!singer Phone: (617) 275-4800 x305
Mike_G_Newman@cup.portal.com (07/25/88)
In a reply to my request for help with Turbo Pascal, someone thoughtfully pointed out my error in stating that MacPascal has an exit statement. (I had said that I didn't want to use LS Pascal because of difficulty in converting code I had written in Mac Pascal using the 'exit' statement.) Of course, the code I was referring to had been written under TML Pascal, which does have an exit statement. BTW, I love the LSP environment, but having purchased both TML and Turbo, I have trouble justifying another purchase of a Pascal compiler unless, of course, Lightspeed has plans for a new release . . . . ? Any comments? ================================================================= * Michael G Newman | mike_g_newman@cup.portal.com * * Now or Never | MCI: mnewman (333-1196) * * P.O. Box 1510 | voice: 670-234-7726 * * Saipan MP 96950 USA | * =================================================================
ags@s.cc.purdue.edu (Dave Seaman) (07/25/88)
In article <7536@cup.portal.com> Mike_G_Newman@cup.portal.com writes: >In 'How to Write Macintosh Software', Scott Knaster says that I >can do something like this: > > errCode := FSRead(fileRefNum,count,thisMemberHdl^); > >However, Borland's Turbo Pascal wants me to do this: > > errCode := FSRead(fileRefNum,count,@thisMember); > >Can someone explain this to me? Who's right? Are there other >problems with the Turbo compiler? I think you will find that both methods work just fine with Turbo. I assume your declarations are something like type aMemberHdl = ^aMemberPtr; aMemberPtr = ^aMember; aMember = ... something or other ... var thisMemberHdl : aMemberHdl; thisMember : aMember; so that the expressions ``thisMemberHdl^'' and ``@thisMember'' are both the same type (i.e. aMemberPtr) and therefore interchangeable so far as the rules of Pascal are concerned. The ``@'' sign in Turbo, unlike standard Pascal, is an ``address-of'' operator (similar to ``&'' in C). As long as you remembered to allocate the handle before the call, it should make no particular difference which way you do it. There is sometimes an advantage in allocating structures on the stack rather than the heap so as to avoid heap fragmentation. -- Dave Seaman ags@j.cc.purdue.edu
singer@endor.harvard.edu (Rich Siegel) (07/26/88)
In article <7652@cup.portal.com> Mike_G_Newman@cup.portal.com writes: >Lightspeed has plans for a new release . . . . ?> >Any comments? Yeah. :-) We're not Lightspeed - they do page layout, not compilers - but we do plan another release of Lightspeed Pascal; it's in the works now. Lightspeed Pascal will provide language features for complete MPW Pascal source compatibility, including the standard goodies like constant expressions, UNIV parameters, LHS typecasting ("HandleType(h)^^ := foo") EXIT, CYCLE, and LEAVE, and unrivaled code-generation quality. (Of course, the last isn't a language feature - sorry.) There will also be Object Pascal support, complete enough to do MacApp. Coming third quarter... --Rich Rich Siegel Quality Assurance Technician THINK Technologies Division, Symantec Corp. Internet: singer@endor.harvard.edu UUCP: ..harvard!endor!singer Phone: (617) 275-4800 x305
erik_selberg@pedro.UUCP (Erik Selberg) (07/30/88)
<7652@cup.portal.com>
Michael--
well, lucky for you, Symantec (those wonderful people who did a really
patchy job on LSC 3.0) are supposed to be releasing LSP 2.0. I haven't
seen it yet, and Leonard Rosenthol says it's a long way off, but an
add for it was in Aug. MacUser. Anyhow, I would definately recommend getting
LSP, but first look at it to make sure that it doesn't take 3 megs and a hard
disk to get started... (LSC haters unite!)
Erik
Selberg
Delphi: LORDERIK
CIS: 71470,2127
GEnie: E.SELBERG
Mac at Night:
(801) 581-1823
10p-7a
3/12
everyday
don't you love weird signatures?
PS--Delphi and CIS are for looks... I usually don't call them! spector@vx2.GBA.NYU.EDU (David HM Spector) (08/04/88)
LSC Haters? "Patchy Job"...wha? Huh? Like...umm, err....
_What_ are you talking about? THINK C is one of the best thought out, best
running products (and certainly the best C compiler) yet written for a personal
computer! Bar none. I have been using 3.0 for a few weeks, and I have
used the original (LSC Classic?) since day one. I do most of my development
in it...
Can you name (seriously) a better development package for the Macintosh?
'ever used Mac C from Consulair? How about the wonderful support and
timely updates from Aztec...?
I have used _almost_ every C compiler made for _almost_ every micro made.. and
no where will you find a better made, better integrated system. In fact,
just about the only thing that would make THINK C and even better product
would be a source code control system, for silly people like me who sometimes
make radical changes to routines without backing them up first
If your complaint is about the 2Mb memory requirement, then write your
congress-critter, tell [her|him|it] to do something about that gawd-awful
anti-dumping agreement that has created an artificial shortage of DRAMs...
don't get upset with THINK because they create a good product that needs memory
in order to make your debuging easier...
... Or, stick to using MacsBug.. its still a perfectly good debugger.
Hmph! So There!
No flames...I'm up to my ears in adb in another window..I couldn't take it. :-)
David
-------------------------------------------------------------------------------
David HM Spector New York University
Senior Systems Programmer Graduate School of Business
Arpa: SPECTOR@GBA.NYU.EDU Academic Computing Center
UUCP:...!{allegra,rocky,harvard}!cmcl2!spector 90 Trinity Place, Rm C-4
HamRadio: N2BCA MCIMail: DSpector New York, New York 10006
AppleLink: D1161 CompuServe: 71260,1410 (212) 285-6080
"What computer puts out work like this?" "Hire us and we'll tell you."
XYZZYGLORPlippin@skippy.berkeley.edu (The Apathist) (08/04/88)
Recently spector@vx2.GBA.NYU.EDU (David HM Spector) wrote: >In fact, >just about the only thing that would make THINK C and even better product >would be a source code control system, for silly people like me who sometimes >make radical changes to routines without backing them up first Have Macintosh programmers forgotten about lint? I've been wondering why I have to find my mistakes when the computer could be doing it for me. But, last I heard, even MPW doesn't have lint. On the other hand, I'll choose LSC (TC?) over any system I've used that has lint. I just don't understand why I can't have both. --Tom Lippincott ..ucbvax!math!lippin "Why worry when you can have someone else worry for you?"
spector@vx2.GBA.NYU.EDU (David HM Spector) (08/04/88)
Well, OK....lint would be nice. I agree... but lint isn't going to correct
your (programming) mistakes,...only tell you about questionable syntax, et al.
THINK C already does an OK job of informing me when I do something really
silly..
Now, if you have a program that will point out bad impmementations and design
decisions and then make suggestions, now there's a nice extension for
THINK C...
(tounge in cheek ON)
Computer: No, no, no! David... bTrees are sooo Passe, why don't you
try those news xyzzy trees from the July 1992 CALGO supplement.....
Me: Um, errr... well, OK, if you really think it'll help...
:-)
DHMS
-------------------------------------------------------------------------------
David HM Spector New York University
Senior Systems Programmer Graduate School of Business
Arpa: SPECTOR@GBA.NYU.EDU Academic Computing Center
UUCP:...!{allegra,rocky,harvard}!cmcl2!spector 90 Trinity Place, Rm C-4
HamRadio: N2BCA MCIMail: DSpector New York, New York 10006
AppleLink: D1161 CompuServe: 71260,1410 (212) 285-6080
"What computer puts out work like this?" "Hire us and we'll tell you."
XYZZYGLORPwetter@tybalt.caltech.edu (Pierce T. Wetter) (08/05/88)
>Have Macintosh programmers forgotten about lint? I've been wondering >why I have to find my mistakes when the computer could be doing it for >me. But, last I heard, even MPW doesn't have lint. > Rumor has it that the new 3.0 C compiler has lint like features. Personally, I would rather it were a seperate tool instead of being enabled disabled by the -w flag, but at least its there. ---------------------------------------------------------------- wetter@tybalt.caltech.edu Race For Space Grand Prize Winner. ----------------------------------------------------------------- Useless Advice #986: Never sit on a Tack.
suitti@haddock.ISC.COM (Steve Uitti) (08/06/88)
>Have Macintosh programmers forgotten about lint? I've been wondering >why I have to find my mistakes when the computer could be doing it for >me. >On the other hand, I'll choose LSC (TC?) over any system I've used >that has lint. I just don't understand why I can't have both. I use lint *all the time* on UNIX. I've yet to find a lint that matched the native C compiler very well lately. For example, the PDP-11 lint was based on pcc, not Ritchie's C - the native version. On BSD systems or Sys V systems that have flexnames C compilers, lint is still limited to 8 chararcters. Further, I've yet to see a lint library for libc that resembles reality. For all of this, lint is typically useful. Under TurboC, for the PC, one can turn on all sorts of additional error checking. It performs as well or better than the best lints I've used. It doesn't seem to slow down compilation significantly. Therefore, I turn on everything, and use it all the time. If you turn on required prototypes, you find all sorts of things (even though it is a pain to get it all right - once). Porting old highly ported stuff to TurboC from UNIX has actually pointed out undiscovered bugs! Amazing. LSC has an option for required prototypes, which I've only just started to use. So far, it does everything I'd want lint to do. You want to avoid int/long or int/pointer cast portability problems? LSC has smaller ints than long or char *, thus complains bitterly. In summary, having lint be seperate from the C compiler is a bad idea. Having lint libraries that are not used for production is bad. Having prototypes in header files that are used for all compilations is infinitly better. The bugs are caught and found early, rather than never (I don't have time to fix this obvious lint library bug... it doesn't prevent the code from working...). Stephen Uitti