Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!usc!apple!shebanow
From: shebanow@Apple.COM (Andrew Shebanow)
Newsgroups: comp.sys.mac.programmer
Subject: Re: C++ and MacApp
Message-ID: <5051@internal.Apple.COM>
Date: 4 Nov 89 22:46:18 GMT
References: <UZIS0k600iLO0Gw1go@andrew.cmu.edu> <4418@ncsuvx.ncsu.edu>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 125

As the person who wrote those release notes, and as a DTS
engineer, I could explain to you all Apple's reasons for
sending out the MacApp headers, and give you the latest
information on fixing the problems with them as shipped.

You are right that they were included as a last minute
thing. The original plan was for the headers to be
released as part of MacApp 2.0 Final along with a set of
samples, real release notes, etc etc. However, Tim
Swihart, the C++ Product Manager, and Steve Burbeck,
the MacApp Product Manager, both realized that having
the headers could be of immense value to C++ users,
so they released them even though they had never undergone
any official testing and they were never intended to be
part of the C++ product. I think they both deserve a
lot of credit for going beyond official policy to do
"the right thing" for our developers.

Where things went slightly wrong is that everyone who used the
headers here did so using a prerelease version of MPW
3.1 (coming soon to an APDA near you). MPW 3.1 includes
a new version of Types.h, and people who tried the headers
using MPW 3.0 have been having a lot of difficulty.
The headers themselves aren't buggy (as yet, we haven't gotten
any bug reports from the field that weren't related to
the Types.h problem), its just that the C++ headers
depend on a missing C include file. If we had done the
official testing, we would have caught this bug, but that
would have either a) delayed the C++ product by weeks (or
months) or b) forced C++ users to wait weeks (or months)
for MacApp 2.0 final to be released. Neither of these
choices seems particularly attractive to me.

So the question is, which would you rather have:
slightly buggy headers, or no headers at all?

Anyhow, here is a release note that is being sent to
everyone who bought MPW 3.1b1 C++ from APDA (and they
aren't even charging for it!!!).

Have fun,

Andy Shebanow
MacDTS

----------------------------------------------------------------------
Release Notes for the MacApp 2.0b9 C++ Headers - The Sequel
October 20, 1989

Due to an unfortunate oversight, there are some problems
with the MacApp 2.0b9 C++ Headers - must have been the
earthquake. 

Types.h Problem

The MacApp 2.0b9 C++ Headers distributed with MPW C++ 3.1b1
depend on the Types.h file from the as-yet-unreleased MPW
3.1. Fortunately, you can fix this by adding the following
lines to the Types.h included with MPW 3.0: 

enum {v,h};
typedef unsigned char VHSelect;

typedef unsigned char Byte;
typedef char SignedByte;

You should also replace the definition of the Length macro with:

#ifdef __cplusplus
inline int Length(const StringPtr string) { return (*string); };
#else
#define Length(string) (*(unsigned char *)(string))
#endif

Your MacApp/C++ programs will now compile much more happily.

Speedup Hints

Your MacApp/C++ compiles will be a lot faster if you use a
global file to include all of your source files. About
80-90% of a typical compile is spent reading the MacApp
header files, so reading them once for all source files
instead of once for each source file is a big win. Your
global file would look something like this: 

// All.cp

#include "MMyProgram.cp"
#include "UMyProgram.cp"
#include "UUtilities.cp"

In your individual source files, bracket your MacApp
includes so that they don't get read more than once: 

// UUtilities.cp

#ifndef __UMacApp__
#include <UMacApp.h>
#endif __UMacApp__

#ifndef __UMacAppUtilities__
#include <UMacAppUtilities.h>
#endif __UMacAppUtilities__

#ifndef __UUtilities__
#include "UUtilities.h"
#endif __UUtilities__

// code....

Of course, you also need to put bracketing into your local
include files so that things don't go haywire if you do
include the same file twice: 

// UUtilities.h

#ifndef __UUtilities__

#define __UUtilities__ 1

// definitions

#endif __UUtilities__

----------------------------------------------------------------------