Write Portable Code 397
Simon P. Chappell writes "Much as a certain large software company located in the North-West of the United States of America might wish otherwise, there are many different operating systems and platforms in use in the world today. Software these days needs to able to operate in a disparate environment, either by communicating with these other platforms or by running on them or, increasingly, doing both. The Information Systems industry is making good progress with the communication half of the problem (even if a lot of it seems to involve large amounts of XML), but it is still struggling with the issues inherent with writing portable code. Brian Hook's contribution to all of this is Write Portable Code , which according to it's subtitle is an introduction to developing software for multiple platforms." Read on for the rest of Simon's review.
| Write Portable Code | |
| author | Brian Hook |
| pages | 248 (14 page index) |
| publisher | No Starch Press |
| rating | 8/10 |
| reviewer | Simon P. Chappell |
| ISBN | 1593270569 |
| summary | I recommend this book to anyone working with portable code. |
This is a book for computer programmers who write software designed to run on multiple platforms. It's also for programmers who suspect that their software may need to run on different platforms. This brings the book onto the radar for free and open source software authors, as they seek to create software that does not trap their end users into using specific operating systems. The Structure
There is a good progression shown in the eighteen chapters of the book. The first couple of chapters introduce the reader to portability concepts and then to some of the specific portability features of ANSI C and C++ that are used throughout the rest of the book.
The middle chapters of the book, cover individual portability topics. Some of these topics are the obvious ones, like Floating Point numbers, Networking, Operating System, File System and Dynamic Libraries. Other topics are less intuitively associated with portability, but when you read the chapter, it's inclusion is both obvious and necessary. These subjects include Source Code Management, Compilers, Scalability and Data. There is more to portability than many of us might suspect.
The last two chapters look at some alternative ways of getting portability. Scripting languages are discussed and the pros and cons of each ones portability is weighed. Lastly the use of cross-platform libraries and toolkits is addressed. Quite apropos given that the book's author is also the author of a cross platform library.
As an example of the thoughtful approach taken in this book, lets' take a look at the chapter on scripting languages. It's about the shortest chapter in the book, but representative of the approach that Mr. Hook brings to his work. This chapter takes a very honest look at the portability and cross-platform aspects of using scripting languages. There are advantages and disadvantages to the use of scripting languages. The advantages include everything that is a disadvantage of low-level languages like C/C++. Scripting languages do not require you to worry about about memory allocation, bindings, System API calls or any of the other bugbears of a low-level language programmer's life. The disadvantages of scripting languages naturally include performance, given their interpreted natures, a general lack of tools, such as development environments or IDEs and their tendency to sit high above the operating system with a corresponding detachment from low-level facilities and services of that same operating system. Mr. Hook's choice of scripting languages to consider was interesting. I expected Ruby and Python; both popular and capable in their own right. The inclusion of JavaScript/ECMAScript was also not too unexpected, now that standalone versions are bubbling up and becoming available. The real surprise, albeit a pleasant one, was the inclusion of Lua; a scripting language designed for platform portability and which seems to have managed to fully mature without making a blip on most geeks radar screens.
I like that Mr. Hook has experience writing portable software. This matched with his authorship of the Portable Open Source Harness (POSH) portability library and his contributions to the Simple Audio Library (SAL) gives a great deal of credence to his writing.
This is a solid "doing" book. Mr. Hook is under no illusion that he's writing an introduction to programming. This book has a consistent purpose to take experienced programmers and fully equip them to deal with portability and it does not deviate from this in the slightest.
The layout of the book is first rate, with clear typography, comfortable spacing, clear diagrams and tables and nicely highlighted callouts. I did not notice any obvious typos or glitches in the book. While the look of a book is not the author's fault if it is below par, a well presented book can enhance the reading and learning experience.
The examples are as realistic as possible. While some of the examples to teach principles might be simpler, they are typically backed up with examples from either the POSH or SAL projects, showing real world portability coding. The level of C/C++ required to understand the examples is higher than many books that I've read. That's not to say that the code seems obfuscated, but it's code that is taking into account aspects of the real world and is, by necessity, not simple. A further positive quality of the code examples is that they're very well explained; well enough that an inexperienced programmer with determination could follow them and come to an understanding.
Appendix B contains a summary of all of the portability rules presented through the book. There are twenty rules and each is reprised with a small explanation/reminder of it's application. An example: Rule 4 - "Never read or write structures monolithically from or to memory. Always read and write structures one element at a time, so that endian, alignment, and size differences are factored out."
If you're looking for more of a fluffy "about" book, then this is not it. This is not a complaint, rather I offer it as something to consider, before you buy what you might otherwise think is a beginner's book.
I must reiterate the non-trivial C/C++ example code the book contains. This book is for serious programmers and is not afraid to role up it's sleeves and cut real code.
This is a very well written and very readable book. There are many aspects to the subject matter of portability and Mr. Hook addresses more of them than many of us had previously suspected existed and addresses them with firm authority. I recommend this book to anyone working with portable code."
You can purchase Write Portable Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Scripting (Score:1, Informative)
It may take a performance hit because it is interpreted but for the stuff I write that isn't usually a problem. It is relatively easy to distribute applications. I just burn a CD with python and the application. I write in a Linux environment and distribute to a Windows environment. I'm glad I chose Python because I get a lot more work done that if I were coding in Java.
Re:C++ is cross-platform, dont know what your smok (Score:4, Informative)
The net effect is that no matter how you change your code, or even if you template it over a range of types, everything always gets written out and read back in properly without having to resort to constantly changing special case read/write functions or having to know what is in every structure and how to write it. It keeps it very simple indeed. You could have a structure nested twenty levels deep containing arrays (vectors) and associative arrays (maps), and go in and change a dozen datatypes at different levels, and not have to modify a single piece of reading/writing code.
A few, simple rules (Score:2, Informative)
2. Stick to POSIX. The POSIX standard convers almost all the functionality needed for the internals of any application.
3. Separate the GUI from the business end of the application. Use IPC to communicate between the parts.
4. Avoid threads. Threads are the source of some of the hardest errors to debug; plus threads are NOT the same kind of fish on all platform, even when they are called 'POSIC threads'.
Re:Portable Mac apps? (Score:3, Informative)
http://www.gnustep.org/ [gnustep.org]
It'll allow you to deploy on Linux, Windows, and possibly even the Sharp Zaurus depending on your project.
They even have a web page up clarifying a mention of it in Aaron Hillegass' _Cocoa Programming on Mac OS X, Second Edition_
http://www.gnustep.org/resources/BookClarificatio
It's licensed under the LGPL, so should be usable for most tasks.
William
instructive (Score:2, Informative)
Re:Portable Code (Score:3, Informative)
I've got just one thing to say: (Score:3, Informative)
Apache Portable Runtime.
td
Re:Unfortunate (Score:2, Informative)
Re:but'cept (Score:1, Informative)
No its not, peruse a few of the benchmarks here http://shootout.alioth.debian.org/ [debian.org]
Re:Unfortunate (Score:3, Informative)
What Java has going over C and C++ is a useful large standard library framework. But heck, if you use say Qt, Mozilla's NSPR, Apache's APR, Glib, or something else as your C/C++ platform you'd have many of the same advantages that the Java library gives you.
Re:Why Java doesn't work (Score:3, Informative)
Developing Portable Code, without buying a book (Score:4, Informative)
The second module deals with all the user interface stuff and nothing else. Any event handling is done in this module and nowhere else. That way, the rest of your code doesn't need to worry about what type of execution model is being used. It'll just work as you would expect. If there is no user interface, you don't need this module.
To make the UI truly portable is hard. No specific capability is guaranteed. eg: GUIs don't guarantee a text console, and text consoles don't guarantee a GUI. My advice would be to split the module into two sub-modules. The first sub-module handles what you want to do, but contains nothing specific on how. For example, it might be filled with commands for selecting fonts, drawing lines, etc. However, it would not contain any calls to an underlying system. It should assume some abstract, theoretical, idealized user interface.
The second sub-module (which may be a third-party library and not something you need to program at all) would then convert these commands into actual interface calls. If you're writing this yourself, I'd suggest starting with interfaces that are already fairly portable (eg: Qt, Gtk+, Ascii Art Library) where possible. If you can't, then you'll need to write alternative versions for different types of interface. But at least it's all in one place and squished down to the routine level, not entire screens.
The third sub-module (again, third-party if available) would do the same as above but for file I/O. Again, the upper levels should make no assumptions at all. "Anything is possible in the next half hour", as Gerry Anderson would say. The lower levels then convert the "ideal" into what the system can actually do. Here, there are at least some standards. Use them. But then write special case code for platforms that can do better. Portable need not mean sub-optimal, it merely means sub-optimal (but guaranteed to work) until tuned.
The fourth would do the same for networking. There is absolutely no reason why an application should know if you're using sockets, MPI message passing, IPv4, IPv6, DECNet or a guy waving two flags. At the application level, data comes in and goes out. The other end should be of no consequence, and the method of getting there should matter even less. High level networking should be abstract connections, using some sort of token to identify which connection is being referred to. There needs to be a middle layer here, to turn the abstract connection into a real networking protocol. The lowest level then handles the network calls required.
You need the three layers, because you've two levels of abstraction (the network protocol and the network hardware) and therefore you need two levels of reification to turn the abstract into something usable. As network protocols can work over multiple mechanisms, the protocols are resolved first and the mechanisms second.
Coding styles for ALL abstract components AND the first module should emphasize portability. There should be nothing system-specific there, so you should be able to use the absolutely vanilla ANSI specification of a language (where one exists). For C, if you want to cover ancient or obscure systems as well, you should duplicate all function declarations and external declarations, using a #ifdef to distinguish between ANSI C and K&R. There are probably other languages you need to support multiple variants of, just keep the areas where you need to have compile-time or interpret-time selection kept to a minimum.
The low-level routines are only going to work on a limited range of systems, no matter what. Therefore, anything valid for that subset is fair
Re:What About UI? (Score:3, Informative)
I program mainly in Java and C++, and if you are looking just at desktop machines (which is what I work with) then it's really not a big deal either way since you are mainly looking at *nix, Windows and maybe OS X. Swing is pretty much write-once for all three platforms- though you have to do some funkyness to get mac programs to look like mac programs under OS X. Qt is available for all three platforms as well. Athough I've never developed with it, AFAIK GTK+ is also available on OS X, as well as *nix and Windows.
The thing is, it's no longer unreasonable to expect to write an application and have it run on a desktop system, a cell phone, and a PDA. Since most cellphones support at least a subset of Java, whereas I do not know of any that support Qt or GTK+, it seems that in these instances Java is the way to go.
Re:Why Java doesn't work (Score:4, Informative)
I'm sorry folks. Such people have never done real cross-platform programming. Java simply isn't an option on MANY platforms. If all you do is x86 platforms, and perhaps some Motorola workstation-class platforms, hey, you're fine.
But that's not the real world.
Might not be your real world, but in mine (enterprise-scale apps for a multinational financial company), we have no problem with portable Java (usually developed on Windows, mostly run in test/production on HP-UX, with the occasional Solaris and now Redhat Linux, and even a little running on our IBM mainframes).
It's true that for some uses, such as certain embedded devices, Java is almost certainly not a sensible (or even possible) option, but in much of the industry it's a perfectly sensible choice for cross-platform development.
Re:Why Java doesn't work (Score:2, Informative)
But you still need to support the rest in software. And then you need to get the java libraries, and write the native code that the java libraries end up talking to to touch the screen/filesystem/etc So you still need a JVM, even if most of the instructions run natively. And even if the API is the same, you are still running on a machine with either a tiny screen or none at all, not much CPU power, RAM or disk space and so on. And no hardware floating point, so any FP code will run like molasses. Oh, and the DRAM access is really slow.
So you end up writing applications from scratch - its not as if something like Eclipse or Azureus or any desktop Java app will run on a mobile phone. And if you're going to do that, you might as well write them in C/C++ which is still quicker than Java, even with the Jazelle instructions.
E.g. write some integer code. Look at what comes out of a decent ARM C compiler. It's tiny and it fits in the L1 cache. You can hoist all the CRT calls out of the loop to where they aren't time critical. The compiler can do a great job using the ARM instruction set to keep things quick. Now look at the Java equivalent. It's more instructions and because Java is stack based it needs to do much more loads from memory. And it needs to check all the array accesses, usually with calls into library code. So the footprint of the loop when it runs is too big to fit in the L1 cache.
Plus you need to have flash memory space to store the java libs, native code and so on. If you JIT for performance, you need RAM for the native code and RAM or flash for the java, whereas for C you can run code out of flash. The C code will tend to use smaller libraries too.
If you don't believe me, here's what John Carmack said
http://www.armadilloaerospace.com/n.x/johnc/Recen
The biggest problem is that Java is really slow. On a pure cpu / memory /
display / communications level, most modern cell phones should be
considerably better gaming platforms than a Game Boy Advanced. With Java,
on most phones you are left with about the CPU power of an original 4.77
mhz IBM PC, and lousy control over everything.