mkb@rover.ri.cmu.edu (Mike Blackwell) (09/28/90)
I'm a vetran Mac C programmer, but I'm just getting in to using MacApp and
C++. Lots of fun, as long as I have plenty of reading material during
compiles... Which leads me to some questions:
Is there ANY way to speed things along besides turning on the RAM disk
cache? It looks like most of the time is spent in CFront processing all
those .h files. Will the dump/load mechanism work here, and if so, can you
give me a quick tutorial?
Why oh why can't I compile in the background? I have gobs of real memory,
and I'd even spring for another disk for swap space. Sigh. Will Sys7 solve
this?
A basic C++ question: I'd like to define some class specific constants
inside the class - it makes sense, and develop_2 C++ style guide tells me
it's a good idea. But how? The obvious way (to me) doesn't work:
class TMyView : public TView {
public:
static const short kMyConst = 42;
... blah blah ...
}
CFront complains about the assignment. Where should the assignment go? The
constructor?
Mike Blackwell mkb@rover.ri.cmu.edullama@eleazar.dartmouth.edu (Joe Francis) (09/28/90)
In article <10594@pt.cs.cmu.edu> mkb@rover.ri.cmu.edu (Mike Blackwell) writes: >Why oh why can't I compile in the background? I have gobs of real memory, >and I'd even spring for another disk for swap space. Sigh. Will Sys7 solve >this? Actually, you CAN compile in the background. I'm am while I write this note (and while I read yours). Perhaps you mean you want to be able to continue to use MPW while it's compiling, to edit source, etc.? Picky, picky.... Seriously though, I second Mike's request for MPW to retain some functionality during compiles. With the ammount of memory CFront eats, though, I realize that I wouldn't really be able to take advantage of this without virtual memory. Any plans for (post system 7.0) MPW 3.x to allow this? Cheers, Joe
lsr@Apple.COM (Larry Rosenstein) (09/28/90)
mkb@rover.ri.cmu.edu (Mike Blackwell) writes: >Is there ANY way to speed things along besides turning on the RAM disk >cache? It looks like most of the time is spent in CFront processing all >those .h files. Will the dump/load mechanism work here, and if so, can you There is a dump-load mechanism for C++. But that version of C++ is currently only available on the ETO CD-ROM. The MacApp make files support dump/load (for the MacApp headers) automatically. Another way to speed up compiles is to put the temporary files on a RAM disk. C++ really consists of 2 parts. CFront converts the C++ code into C, and the MPW C compiler compiles it. Putting the intermediate file on a RAM disk can make things go faster. (Take a look at the CPlus script; I think there is a shell variable that indicates where to put the temp files.) >Why oh why can't I compile in the background? I have gobs of real memory, MPW 3.x does compile in the background. Another feature of C++ 3.1b4 is that it will use MultiFinder temporary memory, which means you can set the MPW Shell partition size to a smaller number (e.g. 2500-3000K) and still be able to compile large programs when necessary. This doesn't mean C++ will take less RAM. It does mean that the available RAM will be better utilized. (If you aren't using C++, for example, the RAM isn't premanently assigned to MPW.) >A basic C++ question: I'd like to define some class specific constants >inside the class - it makes sense, and develop_2 C++ style guide tells me >it's a good idea. But how? The obvious way (to me) doesn't work: There are 2 ways, depending on your situation: (1) static data member: class TFoo { static const short kMyConst; ... }; In a .c file you need to write: const TFoo::kMyConst = 42; This is contant only in that C++ won't let you change it. The compiler won't be able to evaluate it at compile-time, in most (if not all) cases. (2) use an enum: class TBar { enum {kMyConst=42}; ... }; This will be a constant constant. You can also give the enum a type name, and use that type. You would refer to the type as TBar::<typename>. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
dorner@pequod.cso.uiuc.edu (Steve Dorner) (09/28/90)
In article <24751@dartvax.Dartmouth.EDU> llama@eleazar.dartmouth.edu (Joe Francis) writes: >In article <10594@pt.cs.cmu.edu> mkb@rover.ri.cmu.edu (Mike Blackwell) writes: >>Why oh why can't I compile in the background? >Actually, you CAN compile in the background. Indeed. Except that you have to have the patience of a saint and the typing speed of a near-sighted elephant to use your mac. I find it practically impossible to get anything done on my SE/30 with a compiler running in the background. And heaven help me once the linker starts up ("Open files? YOU don't need to open files, I, the Great Linker, want them ALL!"). Of the two machines I have, the black one with the geometric shape does much the better job at multitasking. And System 7 isn't going to fix THAT. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
llama@eleazar.dartmouth.edu (Joe Francis) (09/28/90)
In article <1990Sep28.130509.22350@ux1.cso.uiuc.edu> Steve Dorner writes: >I find it practically >impossible to get anything done on my SE/30 with a compiler running in >the background. And heaven help me once the linker starts up ("Open files? >YOU don't need to open files, I, the Great Linker, want them ALL!"). I too had this latter problem, but it can be fixed by editing the boot block of your startup volume. Fedit+ does this nicely, or you can use any of a variety of shareware goodies. >Of the two machines I have, the black one with the geometric shape does much >the better job at multitasking. And System 7 isn't going to fix THAT. Maybe timeslicing is better, but cooperative multitasking will always be NEAT-O! ----------------------------------------------------------------------------- "Read My Lips: No Nude Texans!" - George Bush clearing up a misunderstanding
murat@farcomp.UUCP (Murat Konar) (09/30/90)
In article <10594@pt.cs.cmu.edu> mkb@rover.ri.cmu.edu (Mike Blackwell) writes: [on using C++ and MacApp under MPW] >Is there ANY way to speed things along besides turning on the RAM disk >cache? It looks like most of the time is spent in CFront processing all >those .h files. Will the dump/load mechanism work here, and if so, can you >give me a quick tutorial? We are using fx's and IIx's with 50 mHz accelerators and still run out of stuff to read. I think that I'd probably be a lot more productive if we were using THINK Pascal and MacApp on a ci instead of C++ on an fx. There is a bright side, though. I have learned how to juggle during compiles. You can too! ( I don't want to start any flame fests over the relative merits of C++ and Object Pascal. It's just that the THINK environments are so much faster than MPW, and THINK C just doesn't support MacApp). >Why oh why can't I compile in the background? I have gobs of real memory, >and I'd even spring for another disk for swap space. Sigh. Will Sys7 solve >this? We have no problems compiling in the background with 8 megs (except occasionally the compile or link will fail because it can't get enough memory). -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com
marc@Apple.COM (Mark Dawson) (10/01/90)
In article <242@farcomp.UUCP> murat@farcomp.UUCP (Murat Konar) writes: >In article <10594@pt.cs.cmu.edu> mkb@rover.ri.cmu.edu (Mike Blackwell) writes: >[on using C++ and MacApp under MPW] >>Is there ANY way to speed things along besides turning on the RAM disk >>cache? It looks like most of the time is spent in CFront processing all >>those .h files. Will the dump/load mechanism work here, and if so, can you >>give me a quick tutorial? I noticed roughly a 40% speed improvement using the dump/load mechanisim with the C++/MacApp stuff (compiling our user interface code used to take 16min, now it takes 9). Also note that a bigger RAM cache does NOT always speed up compiling time--if you've made it too big, it will actually slow it down (when it flushes the cache, it has to write that stuff out to the disk--so a big cache will have lots of stuff to write out (read:much slower)). For my work, (8mb fx, 4mb MPW partion size) I've found that a 96K is the biggest I can use before performance starts to degrade. Here is a short "tutorial" on using C++, load & dump, && MacApp (1) Make a file (I'll call it "MyMacAppDump.h") that includes all of the files that your program wants to include: // C++ dump header file #ifndef _MyMacAppDump_ #define _MyMacAppDump_ // system header files that this program uses #include <resources.h> #include <files.h> ... // MacApp header files #include <UMacApp.h> #include <UDialog.h> ... // your own header files #include "myapp1.h" #include "myapp2.h" #endif (2) Go into each of your .cp files, erase all #includes for the .h files, and replace them with: #ifndef _MyMacAppDump_ #include <mymacappdump.h> #endif >> if you are using load/dump, _MyMacApDump_ will be defined, so the loading in of the headers won't occur (and this will allow it to work in the case that you AREN't using load/dump--it won't be defined). (3) Edit your macapp make file (prg.mamake): Add in: CPlusLoadOptions = -load MyMacAppDump.h.dump MyMacAppDump.h.o F (option-f) "myapp1.h" "myapp2.h" ... <<I don't add the system or MacApp headers...I assume they won't change>> CPlus -mf MyMacAppDump.h -dumpc MyMacAppDump.h.dump -o MyMacAppDump.h.o {CPlusOptions} {OtherCPlusOptions} add to: OtherLinkFiles: MyMacAppDump.h.o (4) Now you can build your program: Mabuild -cplusload MyPrg -debug note: I've never been able to get -cplusload -debug and -sym to work... the linker complains. Also the .dump file produced can be BIG (mine is 1.2mb). > >We are using fx's and IIx's with 50 mHz accelerators and still run out of >stuff to read. I think that I'd probably be a lot more productive if we >were using THINK Pascal and MacApp on a ci instead of C++ on an fx. There >is a bright side, though. I have learned how to juggle during compiles. >You can too! > Yep, I've gone through my share of books, too. >>Why oh why can't I compile in the background? I have gobs of real memory, >>and I'd even spring for another disk for swap space. Sigh. Will Sys7 solve >>this? > >We have no problems compiling in the background with 8 megs (except >occasionally the compile or link will fail because it can't get enough memory) I've had no problems compiling in the background, either (using MPW 3.1 & 3.2). Mark -- --------------------------------- Mark Dawson Service Diagnostic Engineering AppleLink: Dawson.M Apple says what it says; I say what I say. We're different ---------------------------------
andyp@treehouse.UUCP (Andy Peterman) (10/03/90)
In article <45290@apple.Apple.COM> marc@Apple.COM (Mark Dawson) writes: >.............. Also note that a bigger RAM cache does NOT always speed up >compiling time--if you've made it too big, it will actually slow it down (when >it flushes the cache, it has to write that stuff out to the disk--so a big >cache will have lots of stuff to write out (read:much slower)). For my work, >(8mb fx, 4mb MPW partion size) I've found that a 96K is the biggest I can use >before performance starts to degrade. I thought I'd check this out since I normally use 1024K cache and do intensive MPW compiles. The table below shows the results of compiling one C module (about 1000 lines) of an application and linking it using the time results from BuildProgram. The entire program is about 30,000 lines and generates a 160K application. Most of the time is spent linking. I did these tests on an 8 Meg IIcx with MultiFinder turned off. The second time shown is a repeat build just after the first, which is improved due to the caching action: Cache Size Time 2nd Time (in seconds) Off 50 --- 32K 33 31 64K 32 29 96K 31 28 128K 31 29 256K 30 27 384K 32 27 512K 32 28 1024K 37 29 From this, it seems that a 256K cache gives the best results. I've always been use to using a large cache since it seems to improve performance for most other tasks on the Mac, but I guess I'm going to lower it when in MPW. I sure wish the linker would take more advantage of available RAM and reduce the disk I/O! Andy Peterman treehouse!andyp@gvgpsa.gvg.tek.com
cory@howtek.UUCP (Cory Kempf) (10/03/90)
In article <24751@dartvax.Dartmouth.EDU> llama@eleazar.dartmouth.edu (Joe Francis) writes: >In article <10594@pt.cs.cmu.edu> mkb@rover.ri.cmu.edu (Mike Blackwell) writes: > >>Why oh why can't I compile in the background? I have gobs of real memory, >>and I'd even spring for another disk for swap space. Sigh. Will Sys7 solve >>this? You can. > Perhaps you mean you want to be able to >continue to use MPW while it's compiling, to edit source, etc.? Picky, >picky.... Actually, you can do this also. In the docs that came with my copy of MPW 3.1, there were explicit directions for how to do this. They involve making a second copy of the MPW Shell and start up files in a second directory. The second copy can be used to edit, etc, while the first is compiling. Not the most elegant solution though. Personally, I would prefer to see some form of Job Control (cf csh(1)) implimented. The impression that I got was "not in my lifetime" (actually, to be fair, there are some problems that need to be worked out first) +C
cory@howtek.UUCP (Cory Kempf) (10/03/90)
In article <10594@pt.cs.cmu.edu> mkb@rover.ri.cmu.edu (Mike Blackwell) writes: >Is there ANY way to speed things along besides turning on the RAM disk >cache? It looks like most of the time is spent in CFront processing all >those .h files. Will the dump/load mechanism work here, and if so, can you >give me a quick tutorial? load/dump is a godsend!!!! I am also in process of trying to learn MacApp from C++... I got the ETO disk with C++ beta 4 (you need beta 4 to do load/dump). I tried compiling the Nothing program on my IIx... the first time, it was 4-5 minutes. I made a small change (changed the size of the boarder)... compile time dropped to about a minute. To use it, you need to mod your makefile... the release notes explain how, and I don't have them in front of me. Basically you add in a line to compile the headers, and a compiler option will cause this to dump. then all other compiles have an option added to do a load. You also need to add a line to link a .o file that the dump generates. >Why oh why can't I compile in the background? I have gobs of real memory, >and I'd even spring for another disk for swap space. Sigh. Will Sys7 solve >this? You can. Just put MPW in the background. It will keep chugging along. If you want to play in MPW while it is compiling, you need to make a new copy and run two copies of the shell (see the docs for v. 3.1) +C
ml27192@uxa.cso.uiuc.edu (10/06/90)
/* Written 1:00 pm Sep 28, 1990 by optadm7@watserv1.waterloo.edu in uxa.cso.uiuc.edu:comp.sys.mac.programmer */
>Is MPW C++ the only C++ compiler available for the MAC?
Yes. There's Think's C 4, but its only object oriented in a limited way.
No multiple inheritance, virtual const/destructors, MacApp compatibility.