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.
Write and test on three different platforms (Score:5, Interesting)
"If you haven't ported your code, it isn't portable."
Sticking to the libraries and (subsets of) languages that are really portable helps, too, like this book appears to cover, but if you just start off on a small mix of platforms, it becomes usually quite trivial to port to others. My Ostiary program runs on (at least) Linux, *BSD, OSX, Solaris, HP-UX, AIX, Tru64, IRIX, and Cygwin. I've written commercial code that runs on all of those plus Windows, NetWare, and OpenVMS, though that requires a few more #ifdefs.
From id? (Score:3, Interesting)
Unfortunate (Score:5, Interesting)
Small and efficient beats portable (Score:5, Interesting)
I abstract math and models to generic C++. I tie the rest as tightly as possible to the target API and focus on being fast and bug free. In my career so far, the only code I have ever ported for business reasons ($$) has been mathmatical algorithm related.
YMMV.
Re:but'cept (Score:5, Interesting)
2) Only if it is programmed that way... a developer can force a specific Look and Feel.
3) If by forever you mean 4) Again, only if it is programmed that way.
5) From a purist perspective, I'll grant you this one. But from a practical perspective, it's just not a big deal. Lots of JVM's out there, source code is available (although it's not Free).
Re:blah (Score:2, Interesting)
My experiments with portability (Score:3, Interesting)
The class went thru umpteen strategies to write portable code & culminated in a portability project, where you wrote a "Quiz Program" in C, that ran on Solaris, Windows & the Mac with minimum code changes.
All code changes had to be confided to the stdio.h & other header libraries. I see these days he has added Java [wvu.edu] to the mix.
My own experience has been that it has very limited utility in real-life ie. corporate IT. All the jobs I held since I graduated did not require an ounce of thinking portable. They were all about writing proprietary code to be run off the web, and for some 10 years, Java was the only option until C# came along. So I practised portability by default, since that was the nature of my employment in the industry. But I can see how this might be useful for somebody doing systems level programming (assuming there are still such jobs in the IT industry in the US, of course...)
Re:Java ??? (Score:3, Interesting)
Most people seem to be doing server side development with it. Works fine.
i am sorry but without inter proccess comunication it is usless to me.
You mean like TCP/IP, CORBA, RMI, SOAP, XML-RPC, etc.? You need to be more specific if you're going to complain. BTW, there are libraries for SMB Remote IPC [samba.org] and POSIX IPC [bmsi.com], but using either of them won't result in very portable code under ANY language.
Which raises the question, what exactly are you doing that you need native IPC?
Some points based only on the review. (Score:4, Interesting)
> 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.
I think enough software is written in languages other than C and C++ that any serious author should put C or C++ in the title when the book is C or C++ specific.
It's not wrong that the author or publisher chose to call the book "Write Portable Code" instead of "Write Portable Code in ANSI C". But it does make me question if the author's knowledge is limited by a single-language bias.
> 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.
Given that scripting is limited to one chapter, wouldn't it have been better to refer the reader to other works with more detail and value, and only give a paragraph or so? Particularly since the book is not trying to be about portable code in general, but portability in ANSI C, and discusses nothing (AFAIK) about higher-level compiled languages.
The book's about C. Why clutter it with a chapter on Ruby, Python, and JavaScript/ECMAScript and say nothing about Java, Lisp, SmallTalk, etc? Writing a chapter on scripting languages strikes me as gratuitous filler.
And any non-trivial cross-platform C application is likely to use some sort of cross-platform toolkit. So why only a chapter?
> 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."
Writing structures one element at a time is a -minimum- required for portability. It doesn't completely address byte-order issues, variable internal data representations, or data element size issues. It just ensures that structure packing and alignment issues that might change based on compiler flags are covered. But change the compiler or platform and all these issues are still there even if you write the data elements singly. They are all unspecified or incompletely specified in ANSI C.
It's better to design a complete data representation format, including embedded version information, or just use a higher level data store engine.
My concern is that many of the other rules in the book might be similarly too "low-level" and incompletely specified. Rather than teaching inherently better, more portable coding techniques, they might just be teaching how to work around the low-level nature of C.
Not for me (Score:3, Interesting)
Sun makes the Java install process on FreeBSD so complex that I've given up. Therefore any Java program instantly cannot run on my computers. So far I haven't seen any loss either. Java is mostly used for long running server processes (where JVM start up time is irrelevant and the JIT compiler can speed things to just as fast as C++), so I don't need it anyway.
I find that cross platform C++ is not hard if your code is properly modular. Libraries like QT or wxWidgets take care of most issues these days anyway.
Re:Java ??? (Score:1, Interesting)
Re:Portable Mac apps? (Score:4, Interesting)
Let's say that you have a Windows app that relies on DirectX for some stuff, OpenGL for other stuff, some POSIX functions for yet others. Each one of those APIs represent a possibly different porting problem: move to a different platform, and one of the libraries might be missing or poorly implemented.
So, if your code intermixes calls to all three libraries, you are going to have a hell of a time porting it over. Example: you move to IRIX and now you problably have a good GL implementation, but too bad, it's mixed up with DirectX code, and now you have to rewrite all that code, even though the GL calls would work.
Portability is in the eye of the beholder. X code is mostly portable, but, you need an X server on the other side. So writing portable X code isn't going to help you make your native Mac UI application. Once you take the view that X is just another external API, and you wall it off appropriately, you've done you work.
Now, you can group APIs - if you're on windows, you are pretty much assured that, say, Win32 GDI calls and DirectX are going to be there, so no need to go overboard and factor them out separately.
The devil is choosing your abstractions. You can't over-abstract, otherwise the application will be too alient and never be completed. You almost have to have a sense of where the project will go in the future and what the most critical components are.
Re:Portable code... again! (Score:3, Interesting)
> we'll never attain
If you're willing to accept the limitations that go along with writing to the least common denominator, Inform comes *really* close to true universal portability -- compile once, run anywhere that has the VM, which is *almost* anywhere. You can, for instance, use the same z3 module on the PDP10, Palm and Psion handhelds, Nintendo Gameboy, Atari ST, TRS80, the BBC micro, Acorn/Archimedes/RiscOS, and a *wide* assortment of other systems (including, of course, all the major ones: DOS, Windows, Mac, Apple II, Amiga, pretty much any POSIX system, anything with Perl5 or a Java vm, Emacs, Mozilla (with XUL),
If you need the extra memory afforded by z5, the list shortens a little; if you need graphics (z6) or even more memory (z8), the list shortens rather more, but is still fairly impressive.
Re:Portable Mac apps? (Score:2, Interesting)
Re:Portable code... again! (Score:3, Interesting)
Yet it's still perfectly possible (and really not that hard) to write portable Java.
At my organisation, Java development is done almost entirely on peoples' local Windows boxes, before being transfered over to the HP-UX boxes for the test/production environments. To the best of my knowledge, in the past 5 years, we'e had one single bug has ever been found that was down to a difference between Windows and HP-UX environments (and than was a bug in the specific HP-UX JVM that we were running - it was fixed with an upgrade to the latest version).
Re:lua a "suprise"? (Score:4, Interesting)