[comp.sys.mac.programmer] CommToolbox & LSC

mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) (08/11/89)

I just received my second purchase from APDA (even though I haven't yet
received my membership materials): the Communications Toolbox.  I have
successfully installed it and used it, but now I am wanting to try the
programming.

I converted the library and the .h files successfully (I think).  I couldn't
figure out how to fix the different ProcPtr types, so I altered the prototypes
to accect generic ProcPtrs.  Will this cause a problem (type checking is not
one of my major concerns)?  Also, various routines had "const Str255" in their
prototypes.  LSC doesn't seem to like this.  I removed the "const".  Will this
work?

As for what I have seen so far:  Some parts are really good, others still need
work.  But what do you expect from a beta version.  It does show promise.

-Michael

p.s.  Reading the documentation makes me hungry.  All that talk about breakfast
      cereals and magic deserts :-)

-- 
Michael Niehaus        UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!mithomas
Apple Student Rep      ARPA:  mithomas@bsu-cs.bsu.edu
Ball State University  AppleLink: ST0374 (from UUCP: st0374@applelink.apple.com)

siegel@endor.harvard.edu (Rich Siegel) (08/11/89)

In article <10011@bsu-cs.bsu.edu> mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) writes:

>prototypes.  LSC doesn't seem to like this.  I removed the "const".  Will this
>work?

	"const" is an ANSI-ism not supported by THINK C.



~~~~~~~~~~~~~~~
 Rich Siegel
 Staff Software Developer
 Symantec Corporation, Language Products Group
 Internet: siegel@endor.harvard.edu
 UUCP: ..harvard!endor!siegel

"When it comes to my health, I think of my body as a temple - or at least
a moderately well-managed Presbyterian youth center." - Emo Phillips

~~~~~~~~~~~~~~~

awd@dbase.UUCP (Alastair Dallas) (08/14/89)

In article <2419@husc6.harvard.edu>, siegel@endor.harvard.edu (Rich Siegel):
> In article <10011@bsu-cs.bsu.edu> mithomas@bsu-cs.bsu.edu (Michael Niehaus):
> 
> >prototypes.  LSC doesn't seem to like this.  I removed the "const".  Will 
> >this work?
> 
> 	"const" is an ANSI-ism not supported by THINK C.

THINK C thoughtfully provides a predefined symbol, "THINK_C," so that you
can write a simple header file:

#ifdef THINK_C
#define const
#define volatile
#define class struct
#endif

and this way pretty much get around any slight incompatibilities.  In case
you're not aware, 'const' brings very little to party.  The compiler is
supposed to check to make sure you do what you said you'd do and not let
you write to a const object.  (C Chauvinist Pig voice:) If you want that
kind of hand-holding, boy, better code in Pascal.

/alastair/

pete@ics.uci.edu (Peter Miguel Oleary) (08/15/89)

In article <197@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes:
>and this way pretty much get around any slight incompatibilities.  In case
>you're not aware, 'const' brings very little to party.  The compiler is
>supposed to check to make sure you do what you said you'd do and not let
>you write to a const object.  (C Chauvinist Pig voice:) If you want that
>kind of hand-holding, boy, better code in Pascal.

'const' is also supposed to tell an intelligent compiler that the constant
is eligible for certain optimizations, such as inline substitution.

Pete O'Leary.

jimc@iscuva.ISCS.COM (Jim Cathey) (08/15/89)

In article <197@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes:
>...  In case
>you're not aware, 'const' brings very little to party.  The compiler is
>supposed to check to make sure you do what you said you'd do and not let
>you write to a const object.  (C Chauvinist Pig voice:) If you want that
>kind of hand-holding, boy, better code in Pascal.

However, in MMU protected environments the compiler can place const objects
into the TEXT space where it actually is write protected (no big deal there),
but in most of these environments (Unix-oids) the TEXT space can also be
shared among multiple invocations.  This is the big win for the const
modifier in my mind (especially for strings and constant tables).

In the Mac environment, the const objects could be placed into the CODE
resources so they didn't take up any of the 32K globals data space.  LSC
probably puts the strings elsewhere anyway, but _I_ couldn't tell you that.

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!iscuva!jimc (jimc@iscuva.iscs.com)
! II      CCCCCC !  (509) 927-5757
+----------------+
			"With excitement like this, who is needing enemas?"

duggie@Jessica.stanford.edu (Doug Felt) (08/16/89)

In article <197@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes:

[discussion of how to get around lack of 'const' and some other proposed
 ansi features deleted]

>...and this way pretty much get around any slight incompatibilities.  In case
>you're not aware, 'const' brings very little to party.  The compiler is
>supposed to check to make sure you do what you said you'd do and not let
>you write to a const object.  (C Chauvinist Pig voice:) If you want that
>kind of hand-holding, boy, better code in Pascal.
>
>/alastair/

I thought part of the purpose of const (and volatile) was to assist
the compiler to make optimizations that would be difficult (or
impossible) otherwise.  Am I mistaken?

Seems a lot of people want the hand-holding that protected memory
would provide.  Guess if anyone wants that kind of hand-holding,
they'd better use a NeXT. :-)

Doug Felt
Courseware Authoring Tools Project
duggie@jessica.stanford.edu