The Symbian OS (779886), страница 95
Текст из файла (страница 95)
Butproviding alternative language environments for application developments does not address the fundamental problem, that for those systemprogrammers who must use C++ (whether they are porting the operatingsystem or extending it), Symbian OS C++ sometimes appears arcane andwillfully difficult in a world where standards rule.
Symbian C++ idiomsinclude its Leave() mechanism and cleanup stack, Active Objects ratherthan explicit multithreading, descriptors rather than C++ string classes,ordinal-based function calling into DLLs rather than more conventionalname-based calling, and so on.David Wood:We did our own implementation of exception handling, because we tookthe view that exception handling was insufficiently standard, which at thetime it was, and insufficiently efficient. As it happens that efficiency conditionwas borne out to be correct too, because when we eventually we turned thecompiler flag that said ‘Right, enable native exception handling of C++’ inSymbian OS v9, something like 10% or more in bulk was added to the code.Not only does the native mechanism require more code, it’s also slower tounwind the stack.
We did various things in Symbian C++ where we wouldunwind the stack in one whole lot just by calling User::Leave(). So weavoided going up the stack layer by layer by layer, unlike the correspondingfunction inside native C++ – I think it is throw(). When you throw(), itdoesn’t jump up all at once, it goes up layer by layer of the stack.Standard C++ error handling also requires memory allocation, which,of course, fails if the error being handled is an out-of-memory error.David Wood:There is occasional memory allocation needed by our cleanup stack as well,but it’s done in such a way that each individual call to the cleanup stack willsucceed, although if it’s going to run out of memory for the next allocation itthen unwinds.
But whatever you push onto the cleanup stack is guaranteed tostill be there. So that was very carefully designed in.448SYSTEM EVOLUTION AND RENEWALIt is easy enough now to look at these mechanisms and condemn themas idiosyncratic, quirky, and frustrating.
However, the fact is that at thetime there was no C++ standard and there were no standard mechanisms.While memory leakage on desktop systems is still frequently taken forgranted as part of the programming context, that approach was simplynot acceptable in the context in which Symbian OS emerged, and noris it for the mobile-phone market as it exists today. Power, memoryand CPU cycles remain scarce resources in mobile devices and desktopassumptions do not hold.Andrew Thoelke:Memory allocation and out of memory was very important on the Series 3 andit was going to continue to be a big deal on Series 5 and it still is a big dealon any mobile device, even though some of the assumptions have changed.So we assumed that the operating system had to run for days or months oryears without memory leakage or failure resulting from managing memorybecause you never switched off a Series 5.
C++ isn’t a garbage-collectedlanguage, so a lot of the rules actually came about from asking, ‘How do wehelp programmers write code and review code to make sure that it is memorycorrect?’It also predated exception handling in C++, so the cleanup stack, whichis an idea from Series 3, was brought across, as was the actual exceptionmechanism for error propagation. This was followed by the naming conventiontoo, basically to say this is a class that you should only ever allocate on theheap (or sometimes as an embedded member of another object on the heap)and this is a class you can safely have as a stack item, but if you’ve got to closeit you need to make sure that you always close it, or you have to find someway of ensuring that it can be closed as part of an exception propagation.Martin Tasker argues that while the detailed rationale may havechanged as Symbian OS has evolved for new classes of device, the designchoices were sound, and remain sound.
But there is no doubting thebarrier they pose for entry for developers coming to Symbian OS for thefirst time.Martin Tasker:There are barriers to entry, and there are what you might call ongoing costs.What happens in a lot of programming is that people assume that clean up iseither an issue that you never have to handle, or that you can terminate yourprogram if ever a resource is unavailable. It’s very easy to write that kind ofcode.
But what gets difficult is if exceptions can occur pretty much in everyfunction you call and then the old-style programming gets cumbersome. Atthis point you have got to invest some thought in asking ‘What happens ifany of the functions you are about to call fail? Should you set up some kindMOVING TOWARDS STANDARD C++449of trap?’ Whatever system you have, you’ve got some thinking to do whichdoesn’t come quite so naturally.
I think the solution we chose was actuallyquite simple compared to other solutions for the same problem. However,from the perspective of a third-party application programmer or a developerwithin a Symbian OS licensee, that is one of the more tricky areas. But we hadto do this and our design choices were actually pretty good.On this argument, discounting the high initial cost of the Symbian OSidiom against the resulting low ongoing costs may be a better option fordevelopers than the opposite choice, that of using a standard mechanismwhich is immediately familiar but which is not optimized for the deviceclass. Like it or not, the reality is that programming for small devices, andfor phones in particular, is a specialist discipline, whether at applicationlevel (working with the different UI considerations imposed by mobility,the small footprint constraints, and so on) or at system level (ROM-baseddriveless devices, hardware with awkward properties such as NANDflash memory and intermittent connections).
Desktop assumptions andtechniques do not carry across.Bob Dewolf:I quite like the Symbian OS programming culture. Of course it seemed odd atthe beginning because you had to learn all these strange new ways of working,like two-stage construction and the cleanup stack, but I’m quite a fan of thatnow; I quite like it. And I don’t think that’s held us back, I think that’s beena good story, because it gives clear rules about how to deal with memoryallocations.
It’s also a very strong OO-design pattern, which I also think isgood in general.Nonetheless, the pressure to standardize is being responded to.Andrew Thoelke:In some cases, our constraints go beyond the advisory, ‘This is advisablebecause of the way the system’s written’, and become, ‘If you don’t do it likethis your code won’t work’. We definitely intend to move away from this now,and try to support a much more mainstream C++ programming environment.This is partly because there is such a thing now, which there wasn’t when westarted, but also because it will aid more programmers to get onto the platformand it will allow them to take code that already exists outside the platform andmore easily to deploy on the platform.The investment in already-written software has often proved decisivein relation to whether new systems succeed or not.
Ease of porting is450SYSTEM EVOLUTION AND RENEWALan essential requirement for an operating system which aims to becomethe standard in its market. To enable Symbian OS to continue to growas a software platform requires providing better options to those lookingto port existing code from other operating systems, whether at system orapplication level.
Requirements have been framed and the changes willcome.Of course, it is an open question how much existing Unix or Windowscode would make suitable candidates for running on a phone. The portingmarket is almost certainly not for standard third-party code, except forgames perhaps, so much as for proprietary solutions. Languages may turnout to be as significant as mechanisms.The company’s language strategy has not always been consistent.While there has always been a commitment to native C++ development,at times Java seems to have been promoted as the programming language‘for the rest of us’ working on Symbian OS as a platform.
Martin Taskertakes some pains to explain the truth.Martin Tasker:It was always assumed that C++ would be used externally and there wereconscious design decisions around that. In fact, Colly Myers used to feel quitestrongly about it. He would say, ‘We can’t assume that everybody understandsoperating systems and we cannot expose an API in such-and-such a categoryto people who don’t understand operating systems’. That was because theC++ APIs were exposed. And, if you look at active objects, if you look at theC and T types which offer a very very simple guide to the programmer as tohow to use these types operationally, as simple as Java objects and built-ins,then in some ways we are as simple as Java. We don’t do garbage collection,because C++ doesn’t do it, so programmers have to do that stuff manually.
Butotherwise we’re as simple as Java.For application developers, languages such as Java, Visual Basic andPython are obvious options for enabling cross-platform portability, rapiddevelopment and improved productivity on Symbian OS.David Wood:Java is only one option. There are now other run-time environments as well,including Visual Basic from AppForge and the run-time environment theycall Crossfire. They also support a.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
