WWDC2001 Session 704

Transcript

Kind: captions Language: en thank you and thank you for it for coming this morning we're on the fourth day at WWDC I imagine a lot of you are beginning to hit information overload I hope you still have a lot of energy because we have a lot to present in this session compilers and compilers are such an essential part of development tools were all affected by their performance we have a lot of things to say about that we'd be interested to know how many people in the audience have downloaded the Darwin the darwin source set just raise your hands how about half two thirds okay how many people actually contribute to the Darwin repositories a lot fewer okay with no further ado I'd like to introduce John Graziano the manager of the compiler team so today we're going to be talking about Mac OS 10 compiler technologies and I just wanted to say a little bit about what those are on my team we handle the compiler which is GCC the assembler the linker the dynamic loader which is responsible for starting up your application and a lot of utilities like strip nm o'toole and a few others the point that we want to make throughout this talk is that while all of these are usable as command-line tools the recommended way that we want for people to use GCC is through project builder we've got a lot of nice things in project builder to integrate with it so we're not going to cover all of these things today but what we will talk about is how to use GCC and give you a little overview of the architecture touch a little bit on dynamic linking and pre binding popular subject and also talk about some of the upcoming features Thanks okay there's two slides on upcoming features they don't get too excited so the the GNU C compiler this is this the main compiler for Mac OS 10 and for those of you that are curious looking for it it's a basically user bin CC for UNIX heads in the audience it's free software by the free software foundation if you're curious about that you can go to the new org on the web and look around there it supports ANSI C C++ and Objective C it's got a very robust C++ implementation very robust C++ front-end it's got many years of work and testing compiles for tons and tons of platforms it's basically the reference compiler for many developers it's used in education all over the place and the most important thing is it compiles all of Mac OS 10 every piece of source code that runs on Mac OS 10 goes through GCC so a little overview of GCC for those of you that aren't familiar with it it is a command-line tool and it basically takes C files for and puts out dot o files or object files which we then send to the linker but behind the scenes which actually going on is GCC is a driver that first invokes there we go it's the only graphic I have today I want it to work if first invokes a preprocessor which outputs pre-process source code that then is fed into the compiler which outputs assembler code it then invokes the link the assembler which outputs object code and finally that goes to the linker which binds everything together and creates your application or your library or whatever your you're making all this happens behind the scenes but the important thing to keep in mind is that there are a lot of switches if you look at the documentation that can be sent to any portion of these these sub processes to control a lot of what goes on during this process so what we've done at Apple is we've taken C see and we've extended it in a few ways we've added project builder integration we've added objective-c this has been added for a while but now I'd like to I'm happy to say that we are the owners of Objective C for the Free Software Foundation we're the maintainer --zz we support our frameworks we support our version of precompiled headers we have support in for the velocity engine which most of the compiler people in the audience know is altivec and of course we support our Mach ole object file format there's a few differences that you have to be that you have to keep in mind for GCC the first one is that we have some stricter an C C++ compliance so if you're used to compiling on Mac OS 9 you may find out that you get a few more warnings and maybe a few more errors compiling your source code on Mac OS 10 mostly in the area of C++ syntax and especially type checking another thing to keep in mind that will bite a few people rarely is that our static initializers will execute possibly in a different order from mac os9 because of the way that we link because of the fact that we have pre binding which I'll talk about a little bit later if you have static initializers which have implicit reliance on one another's not explicit if you have a dependency graph that we can follow we get that right but if you have implicit dependencies through global variables or something you may find out that the behavior will be a little different when you build and run on Mac OS 10 so that's something to be careful about so since public beta we've added a few things and done a lot of work on GCC the first thing is we're fully based now on GCC tu-95 2 we used to be running then think the driver and the preprocessor from 272 and now we're running everything in the 295 to code base we've also added a lot of C++ improvements coalesce symbols zero overhead exceptions and we've made pre comps usable from C++ which has a dramatic effect on compile time for C++ the first thing we added is coalesce symbols what this does is removes multiple copies of functions that has been created through inlining and templates what we've seen is a finder binary went down about 300k from two megabytes to 1.7 megabytes and we've seen similar reductions in other C++ programs especially power client programs and this is giving us an overall reduction in the system memory footprint and you're going to hear this theme return - over and over through this talk the most important thing you can do to optimize your application on Mac os10 to make it run really fast is to reduce the system memory footprint reduce the working set in memory because you know you can optimize the CPU uses as much as you want but as soon as your app starts paging in and out through the virtual memory system you're gonna get slower so another thing we've done along this route is added zero overhead exceptions before what we do is put a set jump in a system call when you'd have a try block now we've removed that so tribe locks are basically free as free is you know any code that's not inside of a try block the common case is very fast so we've seen in about 2x improvement in some real-world apps for leaf functions we've actually seen about a 20x improvement if it's just a barely function that has a try block in it we've also seen size reduction we knocked the finder size down by an additional 400 K when we added zero overhead exceptions the big thing to keep in mind though is for throws this will add a memory penalty and a speed penalty especially for the first time you throw because we do page in a lot of code to unwind the stack at that point so what would our basic policy is we treat exceptions as exceptional conditions for error messages if you have something that's in your main line of processing that uses C++ exceptions you may see a slight performance lose with zero overhead exceptions but the vast majority of people are going to see a big win what we've also added our precompiled headers usable from C++ what we've seen in here is a compile times improve as much as 5x four-carbon applications good so the way that we did this is pre comps can be accessed from C++ now we have an extra C++ aware precompiled header and all of our umbrella frameworks but they cannot contain C++ syntax due to a limitation on the way that we do precompiled headers and the other thing is is that macros and compiler flags have to match as with most as with most precompiled headers if you change a macro setting the precompiled header will not be able to be used we'll have to go back to the the standard text header so I'd like to talk a little bit about how we use GCC on Mac OS 10 so in some of the things I'm going to cover just project builder integration how you can use and take advantage of precompiled headers optimization and I'll touch a little bit on altivec as well so GCC and project builder have been designed for a while to work very well together project builder is our preferred way to use GCC on Mac OS 10 it's got a lot of nice integration for you it handles most of the command-line switches with with gooeys most of the most common command line switches and there's also ways to access some of the uncommon pan alliance which is directly from project builder it has integrated error messages so that when GCC has an error syntax error it comes up in project builder and those of you have been at the project builder session how many of you have been at the project builder session so we didn't you know call that out this year just because it's been around for a while now but basically GCC actually sends a message up to project builder and project builder will display the error message and jump to the jump to the line and source code GCC also provides source code indexing information to project builder so for any reference information that you need doing global searches or running the new class browser that we have in project builder all of that comes off of information that the compiler supplies let's talk a little bit about the pre compiler the pre compiler creates a file of pre process and tokenized headers so it basically takes the the group of headers that we have for say carbon or cocoa and it token eise's them and puts them all into one big file that we can then access the big thing for us is that it not only does this which reduces some of our I o costs and reduces some of our lexing costs but it also at compile time selectively unpark own what's used some of our measurements when we're working on compile time we see that 174 thousand lines of declarations get brought in from carbon so not everyone uses obviously even even a small fraction of that so the big win and the pre compiler is it can selectively pull in those declarations that you're using what this does is it reduces the size of that pre processed file that we generate and reduces the overall memory footprint of the compiler itself so it doesn't have to push out the IDE to make room for for the parsing that it has to do so when we're using precompiled headers we already supply you with precompiled headers for the frameworks that we ship for the major umbrella frameworks so carbon and cocoa already have their precompiled headers if you if anybody's gone nosing around inside of the the framework you'll see a dot P file living in there and now a dot PP file which is the C++ version of those precompiled headers project builder also supports creating your own set of precompiled headers you can actually have more than one precompiled header and in a minute I'll bring dabangg up to show how we do that and the preprocessor will automatically find these precompiled headers so you don't have to worry about you know telling project builder or telling the preprocessor where these headers are it will look for them if they're in same spot as the dot H that was created from so again there are some limitations to precompiled headers the macro settings compiler settings and the time stamps that they were built on have to match if there's a change in them we have a fallback position where we go to using the text-based header which is going to slow down your compile times they can be included from C++ files but they cannot contain C++ syntax so now I'd like to bring up the vein patel and we're going to go through how you create your own precompiled header with project builder [Applause] my demo script here so can we have demo 2 up on both of the screens here great so what we have is just the example project appearance sample and we brought it up in project builder and the first thing we've done is we've precooked a small header and if those of you can read this what devane's gone in and done is set set a macro to be debug level 2 what this is going to do is basically break the relationship between this project and the precompiled header that we ship with the carbon framework so the compiler will fall back on using the text base header and bring in all 174,000 lines and declarations so let's see what that looks like we've basically just tweaked one file and let's go ahead and build that so we're going ahead and building that and you're seeing as this happens that we get a lot of warnings saying that we can't use the precompiled header and there we're done and that was one file just to compile all of those declarations so what to look for if you're seeing slow compile times with C++ is definitely look for those warnings make sure that you're using the precompiled header now what we're going to do is go to the the build settings for this target and actually make our own precompiled header now the first thing that's done that's a new feature in project builder is that you can actually add an implicitly included header so that every header comes into the project so that every source file in the project uses this header some people are softly clapping this is a good thing the other thing that we have is we've got a switch that you can just click and you can pre-compile this a turn you can obviously add you know as many of these as you want to this table and you can pre compile all of them so well what dabangg has done is he's actually clicked that he's going to pre compile this and what we'll go do is go back and click build again and you'll see that in addition to doing some of the prep work what it's saying now is it's running pre-compile header and it's actually creating the two pre comps that we use that we'll use in this project so that's done so now let's go back and run the same build again so debating is just going to tweak this a little bit and command s and there we go so what we're seeing is on average about 5x improvement in your compile times when you're using a precompiled header and this is you know the the sort of preferred way that a lot of ideas get to compile times up is by building precompiled headers and the big thing for you is getting getting out the the you know the huge amount of declarations we have in carbon and and and cocoa and being able to get those in a tokenized fashion you can selectively use them and and speed up your compile time significantly now the other thing that Devane is highlighting because we didn't have a slide on this is for those of you that are interested there's a there is a command line tool called P dump if you're not able to use your precompiled header for some reason you can't figure it out or if you just want to poke around inside of the pre-comp and see what's in there you can use you can use P dump and P dump - help - - help which will give you a lot of information on what you can pull out of there so it might be an interesting exercise just to poke around inside the pre-comp and see what's in there and how this stuff is is recorded so that's it for the demo thanks to bang [Applause] let's talk about optimization so the two things I want to talk about here are controlling the compiler optimization levels and actually what they do so I'll warn you this will descend a little bit into compiler D curry but not not much so the first one is optimization level 0 it's basically the default for GCC if you pass no optimization flag on the command line you get no optimization you can also pass - oh is zero the reason they have that is allows you to override a previous previously passed optimization flag it does no optimization so what you get is slower and bigger code but code that you can easily follow in the debugger it also gives you the fastest turnaround time but compared to something like using a precompiled header versus not using precompiled header it's basically in the noise and it's a default setting for a project builder deployment build so our project builder development build so when you set the build style and project builder to be the development build what you get is unoptimized code so optimization level 1 basically - code or - oh 1 on the command line turns on a bunch of basic optimizations it turns on register allocation turns on data flow analysis dead code elimination some jump optimizations and also peephole optimization I won't get into for those of you that don't know what that is don't worry about it basically turns on some sort of basic level of statement level optimization the key point here is it it results in much smaller and faster code than level 0 so for those of you that can read the bottom the bottom line here it says a binary sizes can reduce as much as 50% we did some initial testing on the finder front-end and a couple other things we built them unoptimized we built them with - o1 and the size of the binary I went down by 50% and you should expect that your code execution just raw CPU throughput will will go up by about a factor of 2 between unoptimized code and optimizing it at - oh 1 for optimization level 2 this provides a sort of function level optimizations it brings in common sub-expression elimination loop optimization strength reduction and it turns on the instruction scheduler it produces faster they're not necessarily smaller code than - oh 1 so we'll see some benchmarks that rely on these optimizations going up by about 10 to 15% but the code will not get that much smaller and in fact in some cases if you have a lot of loop unrolling going on the code actually grows by a little bit the other thing is because we're doing doing statement level optimization at this point we're doing things which which will move statements around will move variable settings outside of loops to it what you'll see in the debugger is that sometimes as you're stepping you may not go exactly where you think the source code is going to go you also may have trouble finding variables that have been hoisted into registers so the other optimization level that we support inside of GCC is optimization level 3 which turns on the inline ER so this is automatic function inlining not just when you say inline inside of C++ so in some cases this can result in faster code but the thing to keep in mind is it might increase your binary size so you may get faster code on a benchmark or faster code when you test one particular piece of of your application but overall you may bloat your binary enough that you start paging a little more and cancel out the results of getting this extra inlining so profiling is very important measuring this is very important to see what kind of performance you're getting if you're using - oh 3 just to make sure that you do doing the right thing for your particular application and I'll point you to a session that's happening in here at five o'clock today on the performance tools or Robert voltage is going to get up and talk about some of the tools you can use to measure your application and of course when we're talking about doing automatic inlining debugging we'll get again a little more difficult for you when you're tracing through inside of the debugger so some recommendations are for optimization we always use internally no optimization when we're building when we're just doing development builds this lets us get access to all the stuff in the debugger there's no statement movement or anything that confuses us it gives us the the best turnaround time and it's it's generally you know what we recommend for external developers as well our build style gives you - oh 0 when you choose the development build style we also recommend for deployment builds for most people to use - OH - it doesn't have it doesn't have a big effect on the size of your binary but what it does do is decides your binary / - l1 but turning on any optimization is a big win turning on - OH - gives it a extra 10 to 15% again it has that trade-off that if you're using - oh - and then trying to debug it you may run into a couple confusing situations and again - oh three when you have CPU critical cases when you're trying to get you know that last ounce of performance out of it but definitely make sure that you're not loading your binary to the point where it's not it's it's cancelling out the results of the change so just a little bit on altivec in GCC the big thing to keep keep in mind is that we support all of the altivec intrinsics and GCC so if you're used to using altivec through Cold War the same thing applies you'll be able to use that same code inside a project builder inside of GCC and again it requires though that you pass a - a fault of that flag - project builder which we can show you how to do if I can bring the van back up here so we're going to do a quick demo now on compiler settings inside a project village so sending those optimization flags how you would set the ultimate flag how you would set up some of the other flags that you used to setting from the command line on GCC or for those of you that are not using GCC how you can avoid having to access the command line or having to worry about the command line so what devane's done is brought up again the target editor and he's clicked on the build settings pane of the target editor and we've got a lot of things in here to control the compiler settings you can just look there's a big section labeled compiler settings the first thing that we can control is optimization so you basically can just go to this pop-up and set no optimization which of course is the default for development builds all the way up to optimization level three for the particular thing that you're building you can turn on and off debugging information if you want to generate debugging information if you don't want to generate debugging information for though for those of you that are looking at deployment binaries and wondering why they're so big you might want to checks that flag because there's a lot of debugging information that goes into a binary if you turn this on you definitely want to make sure that that's off for the binaries that you're deploying we also again have whoa we also again have the the implicitly included headers and again you can add as many of those as you want and you can pre compile them and also to set some of the preprocessor flags what are the search paths where we look for headers and you can set all that up so down here in there's a sort of a general table called build settings and for the compiler flags that aren't represented inside of GUI you can actually get at these through this table this is sort of an expert view for people but all these flags basically correspond all of these uppercase variables on the left hand side correspond to variables that get passed into our build system and expanded some of the stuff that you're going to be interested in looking at our other C flags and other LD flags and then optimization C Flags what you can do there is basically set here dabangg is setting the dash F altivec flag for those of you that can can see the font the other thing that's nice if you really if you're really a gearhead is you can pass in flags that turn on and off any of the individual optimization passes that GCC does so if you want to turn on loop unrolling but you don't want to have strength reduction for example you can pass in the individual flags inside of these C flags for those of you that are wondering where are all these things documented in the in the project builder release notes there's a build a CH tml file and if you go and look at that the settings that are listed here are all documented so you know what's going to happen when you set some of these different some of these different settings again this is just basically an expert view but if there are flags that you want to get at that aren't represented in the GUI this is where you go and you should be able to basically you know for people who are used to using GCC from the command-line this gives you access to all the flags that you want to use so thanks to me so I want to say a couple things on dynamic linking this is something that happens outside of the compiler this happens with our dynamic linking process called D yld and this is how your app starts up basically when your app is compiled the references are not resolved and this is how we actually use shared libraries basically if you compile your app that has dynamic references into shared libraries when your app starts up what happens is we first bind the references to functions and data at startup time the function references allow us to do lazy initialization so in the basic case when you start up your application the function references are not resolved until you actually call through to those functions the thing to keep in mind is that any data references if you're referencing global data those references have to be resolved at startup time before you hit main because we have no way to trap on first use and go and run any initialization routines that have to happen so if you're accessing data some library and it routines may have to be run before main actually starts up so the reason we're talking about this is because I also want to mention this thing we have called pre binding what pre binding does is it actually sets the dynamic link addresses at static link time so if you're running against a shared library the linker will actually go out and grab those addresses and set them up at static link time this can give you a dramatic improvement in launch times because you're not having to search through the symbol tables of the libraries at all and most importantly again getting back to the memory theme you're not having to page in those symbol tables to do the search the trade-off is this gives you no lazy initialization all this stuff has to be set up at compile time so we're just going out through addresses at that point so we can't trap on first use so we have to actually initialize the libraries and the modules before before the app actually hits main in in a lot of cases this doesn't give your dramatic slowdown it's still a big win to do pre binding but that's definitely something that is a trade off applications are built by default pre bound in project builder so this will give you pre binding if you're building application that links against the system libraries this will give you a pre-bout application but the big thing to keep in mind is that binaries which are pre bound have to be updated when the libraries change so for those of you that have been poking around the web and seeing this thing on what is all the system optimization that's going on I just downloaded the developer package and it's optimizing my system again it's basically happening is it's going through and it's reprimanding those binaries so it goes through it looks for binaries on the system and it basically fixes up the addresses to the libraries as they've been updated so you know once that's been run the libraries are pre bound the Mac OS 10 GM ship free bond so running that on a stock Mac OS 10 GM system isn't going to get you anything but when libraries are updated going through and reap rebinding this actually is a way that helps us fix up our binaries so that they run as fast as possible let's talk a little bit about upcoming features in the compiler and in the compiler tool chain so the first thing we're going to talk about is GCC 3 what's coming with that we'll talk about a feature in the linker called two-level namespace which most of you who have worked in the CFM world are already used to and of course what a lot of you are here to hear about is Objective C plus plus and then we'll talk about some things that are coming further down the running soft applause for Objective C plus plus so GCC 3 is what we're currently working on we've got a building some of Mac OS 10 but not all of it right away what this gives us is an integrated preprocessor it gives us some better C++ support better C++ compliance it has a lot of cogent improvements especially for the PowerPC and something keep in mind for people as we're rolling this out is it does give you C++ ABI changes so if you're using a shared library that contains exported C++ calls exported C++ classes or anything like that there will be ABI changes you'll have to ship a new binary for that if you compile it with GCC 3.0 the other thing we've added is two level namespace before what we had on Mac OS 10 public beta and on GM is a flat namespace so all of your libraries and all of your and all your application just basically all the symbols went up into a big pool and if there were any name collisions you basically lost at that point the thing to keep in mind is that if you're loading bundles if you're loading plugins we actually have a two-level namespace implemented for plugins so things like QuickTime and other applications with load plugins already can take advantage of this what we're doing is having is expanding this feature to the rest of your binary the way that it works on Mac OS 9 so we linked now by symbol name and library name what this does is it protects against name collisions in modules so if we add a new API to our libraries that conflicts with a function that you call in your application it doesn't break your applicationnow so as we update libraries moving forward it won't mess up the applications that you already have this also speeds dynamic linking for non pre bound applications because instead of having to search the entire set of symbol tables we go right to the library and we look for it there the thing to keep in mind for people who are used to compiling and the flat namespace coming over from Mac os10 server or having done some other unix applications there is one restriction that you have to keep in mind that if you reference a symbol now out of a library you have to explicitly include it on the link line so in case you're wondering about compatibility Mac OS 10 GM apps work just fine on the GNU system so we'll have a two-level namespace system things that have shipped for Mac OS 10 GM will work just fine two level apps will also work just fine on GM system so you build your app for two-level namespace when this is rolled out and it'll run fine on Mac OS 10 GM and any combination of flat and two-level libraries will work as well so you can have a two-level app the links against a flat library that links against another you know our system libraries which will be two-level at that point and that will all work just just fine so Kevin under B is the engineer that that that worked on this and you did a really good job making sure that all these corner cases got covered he'll be on stage later so you can ask him some questions about this so now what I'd like to do is bring up zem Lasky who is the responsible engineer for objective C++ and he's going to walk you through what we've been doing our objective C++ and what some of the details are there so welcome Sam thank you well as John mentioned I did do most of the work so at least for the initial release if things break you can blame me so basically what I'd like to do is just give you a really broad a really quick overview of what objective C++ is and what it is not so the most important thing to remember actually are two very important things the first one is that it's really just a combination of C++ and Objective C or perhaps more accurately it's a superimposition of objective-c on C++ with C++ sort of being the senior partner and the reason we did this is is very simple we would like to allow C++ programmers to utilize the numerous objective-c frameworks that we have on the system most notably cocoa in conjunction with this rollout we concocted a new file extension dot mm which should be used for objective C++ source code there's a timer here some of you who are coming over from the next days might also have seen that dot cap M as an extension but we hereby declare this to be no longer politically correct the HFS file system is case preserving but not case-sensitive there are also other issues so we certainly encourage you to move away from dot cap am a few words about the implementation as it currently exists it is a separate compiler a separate front-end that I was working on which is separate from the C++ front-end and the other ones and now I come to the second important point the first one being the combination of the two languages the second important point is that an object for C++ program once you compile and run it interacts with two runtimes the C++ runtime and the objective-c runtime now I'm not sure how much you're a way of one or the other which direction you're coming from if you're coming from this plus plus world then you probably know more about the person one if you're coming from the coco slash next step world we probably know a bit more about the second one but the important thing here is that these two runtimes are separate they are different they have different semantics at at least at present they are mutually unaware of one another or as I like to say nutri oblivious of one another syntactically the the objective-c constructs and C++ constructs are also separate in the sense that you can easily tell just by looking at a construct which languages belongs to which is of course makes life a lot easier for us and implementing it and also for you in terms of figuring out what is what and what semantics go with it so first off I'd like to give you sort of the good news the ways and you can mix C++ and Objective C code so first of all you can declare an instance of an objective-c object which is really a reference or a pointer to that object like in Java you can declare that anywhere you have a C++ declaration so wherever you can declare C++ variable you can declare the objective-c variables secondly Objective C classes the declarations of the classes themselves may contain within them C++ classes or c structs there are some exceptions to that which I will get into later Objective C message sense which you see in the square bracket notation there if you haven't seen this before this really is a typed expression so you can use that anywhere you have C++ expressions in your code and an examples forthcoming and finally objective C++ relies on the C++ type checking semantics for some of the lower-level type checking and the reason I bring this up is that if you're used to objective-c coding it relies on C type checking so for instance if you have a sign character and you assign it to an unsigned character in C that's usually fine the C compiler would not complain what you'll find here is that the seat you know the C++ part of objective C++ will you know raise its head and complain in other words some objective some code that is valid Objective C code might not necessarily be valid objective C++ code because of the increased C++ strictness so here I I concocted sort of a too slight example showing you what an objective C++ program looks like and for ease of understanding I've color-coded it so that the Objective C part of it is in blue and the C++ part is in yellow so you see first off we you know we call this hello world as we always should then we import cocoa cocoa that H that's a typical Objective C thing and by the way John mentioned before that you can use precompiled headers with c++ now you will also be able to use it with objective c++ so you know there will be a cocoa PP on your system and this whole thing is released so this will go very fast Danny in yellow you see a four word declaration of a c++ class then we get to a declaration of an objective-c class which we called print log we derive it from Anna's object which is sort of the root of the cocoa object hierarchy and we have a pointer to the C++ class we previously mentioned and then we you know declare prototypes for two methods in Objective C then here this is the second part of the example first we you know flash out the C++ class so you have fellow world here we have an ID and you know a member variable of type ID which is sort of analogous to java.lang object if you've used java it's sort of a generic pointer that can point to any objective-c object and we define any now I can structure an instructor so you can see in a constructor for this c++ class we actually allocate an init the corresponding objective-c class and that is by the way how you usually create an objective-c object to this alloc init idiom and then we sort of you know we you know we say hi so we call printf which is a standard C function of course then you have say hello which basically caught you know turns around and folks a method called say hi in the objective-c class and then below we have a an implementation of the projective c-class which is in blue so you can sort of see the notation here you know NS log is also a standard Cocoa function it's actually a C function if you look at it so it basically prints hello world on the screen and the example is sort of silly as all examples are but it kind of shows you how you can mix and match so you can see within the Objective C we actually use P arrow say hi to call the C++ method and vice-versa on CL from a C++ class you can invoke an objective-c method right okay and now we get to the sort of the important part of this talk in the sense that we'd like to sort of emphasize why certain things cannot be done in Objective C plus plus and the reason most of these things cannot be done is what I mentioned at the outset is that the runtimes are separate because they are separate they do not know of one another and therefore certain things really cannot happen so you know the number one obviously you can't do is mix up class hierarchies if you have a you know higher gifts you've got class objects that's fine if you have a you know a hierarchy of objective-c objects that's fine too you cannot mix them because it will just be very confusing for the compiler in the runtime as far as exception handling we really encourage you to use the C++ runtime for this the you know the try throw catch paradigm objective-c does have some set some long jump based exceptions which are basically macros that expand and we really do not discourage you from using this because C++ just won't know what's going on when you when you do this and one thing to keep in mind is that when you use C++ exceptions you have to clean up any objective-c objects that you have flying around so here you have a try block where we you know instantiate an objective-c object and then we have a catch clause which frees it and then you re throw the C++ exception to be possibly caught by some other handler in an enclosing scope or you know in your in your stack you have to do this because again the C++ runtime will not know about my objects that it's an objective-c class or what to do with it this is a recurring theme C++ classes cannot receive objective-c messages or vice-versa this is fairly trivial I mean you cannot the functions in c++ that you call an object and the methods in the objective-c land are really semantically different you cannot treat one as if it were the other did this but reckon ISM is different it's it they do not mix so I mean and the compiler will diagnose this correctly so you shouldn't run into any problems there you cannot statically allocate new or delete Objective C objects and actually the UN delete keyword should be in yellow because that's in C++ construct and the reason again is if you if you create an object in you have to initialize the Objective C object which the C++ runtime wouldn't know how to do if you're familiar with virtual functions in c++ there is always sort of a v table pointer at the beginning of your object Objective C has something analogous that needs to be initialized and C++ you know wouldn't know what to do with that I believe this is my final restriction type slide I mentioned earlier that you can embed C++ classes within Objective C classes but there is a there is a catch you may not do this if you have any virtual functions again this is because you would have a V table pointer and and in this case the objective-c runtime wouldn't know what to do with the v table pointer so this really goes both ways if you have a non-virtual constructor like in the struct class two example there we will let it slide however we will give you a warning because that constructor won't be called so if you're expecting to have the class two member initialized that won't happen and the reason we allow this is because in the objective-c you can put C structs in like this and of course that's fine because you don't expect any initialization semantics and C is this my final example I believe so so this is the most important slide probably how you get your hands on this stuff we are really very close to starting seeding this thing having people try it out and if you're interested in being one of our early victims and I'm really joking it's actually quite stable at this point we've used it as a C++ compiler on our system very successfully so it's it's you know I'm really proud of it anyway if you're interested in becoming a seek partner with us please approach Godfrey our session manager at the end of our session here after the Q&A and now I'll hand it back to John for some closing thoughts thanks to them I I just want to say that we brought them on in February and he started on this in March basically using the old crufty 2.72 objective C++ implementation crufty because the 2.72 C++ implementation in GCC was pretty pretty bad and he actually got this up and running and just last week we were able to compile the the full finder codebase which is all powerplant as well with this compiler so it's not only compiling all of our objective C++ code but it's also a real honest-to-god C++ compiler so zem did a great job and I think we should give him a hand for a cream so all of you who are who are interested in those guys like you too so all of you that are interested in bringing your C++ applications your c++ UNIX tools and putting a cocoa front-end on them this is your path to success this will get you there and it's a very nice thing I personally have written a lot of objective C++ code using the old compiler and I'm really looking forward to being able to use this at this new compiler it's gonna be really great so just a couple notes on what we're still going to be working on the biggest thing on our player right now is still reducing compile time so I think the C++ pre comps have been huge they've done a lot of good to getting removing most of the pain involved with doing you know a full carbon C++ build but again you saw that restriction where we currently cannot handle C++ code in there so if you want to have your power plant pre comp we can't do that right now in GCC so the first thing we're working on is getting that capability into GCC so you can have precompiled compile times with large C++ code bases the next thing is we're continuing to work on code quality improvements GCC 300 will get us there some of the way but we're also working on just bringing GCC up into more of a you know getting it up to the commercial quality that people have come to expect on Mac OS 9 for all of the code gen it's pretty good in most cases but there's some cases where we leave a little bit on the table and we're still working on that and finally we were working again on tighter and tighter project builder integration being able to semantically browse through different language constructs and basically using GCC especially the front end of GCC to supply as much of the semantic information the cross-referencing information that you need in project builder and having project builder take advantage of that so just to wind it up GCC is our road tested open compiler for Mac OS 10 you can go on and get the sources today if you want them it works from the command line it's a usable command-line tool it works even better from project builder we have a lot of support in there that is actually difficult to access from the command line where we take advantage of a lot of the things that the IDE provides and really use the features in GCC and the big thing to keep in mind is that Apple is fully committed to GCC as our main line compiler we run all of Mac OS 10 through GCC every binary that you bring up when you install the Mac OS 10 GM has been run through the good new compiler it does everything all of our Objective C C++ C and now it's going to be doing all of our objective C++ as well so with that turn it back over to Goffe thank you very much Jeff a big hand for the team I think they've done a fantastic job some information resources as usual information pages for all the Mac os10 tools are available at the Apple developer website under the tools area we also for this scene because GCC is an open source project we wanted to give you the pointer for open source at the Apple webpages and the new project web sources well since they're the is their the the baseline for all the new stuff and another pointer also to our mailing list main server we have several mailing lists that are germane to the to the development development tasks project building users is the one that has been very heavily used got over over 500 subscribers now cocoa dev and carbon to over a thousand thank you Dave cocoa dev and carbon dev are also getting populated very rapidly as well roadmap for more tool sessions a very important session this afternoon at 5:00 robber bondage in 705 will show you how to use the performance tools that we're supplying on disk this has tremendous benefit for everyone tomorrow 7:06 in the main hall at nine o'clock debugging on Mac OS 10 using gdb the darwin documentation project and also the feedback form tomorrow afternoon are also very good opportunities for you to for you to talk to the development team and get more questions and answers with that and especially for the objective c++ seeding this is my contact information on top I would ask again as we put in the slide if you're looking to be a candidate for as an objective-c e C and Objective C + + seed site that's a mouthful please put that in the subject line so that I can identify them easily and manage the seed program my group technology management does all the management of a seeding for Apple Computer the Mac OS 10 tools feedback address sends your email directly to the Keith key personnel in the development teams in our tools groups as a good way to get feature enhancements ideas Express directly to us and the URL at the bottom of the screen which reappears on the on the QA slide is a master page of all the URLs organized by session for the show so if there's one URL that you should write down you should write down the last one because that will allow you to get to all the all the URLs and all the information resources that we distribute throughout the entire show you