> Date: Sat, 14 Jun 2008 18:28:15 -0700 (PDT) > From: "Curt, WE7U" <[EMAIL PROTECTED]> > Subject: Re: [Xastir-dev] Topic: Supported Platforms, Xastir-NG >
Bob, KD7NM mentioned Xastir-NG to me today over lunch. Ah well, better late to the party than never :-) Since I've been on a project at work for the past year involving porting a personal navigation device (PND) that was originally written in C++ on WinCE to embedded Linux, I'd like to think I've learned something (in a painful way) about the issues involved in making this kind of software more portable. I apologize if I've been preaching to the choir, but I'd hate to see anyone have to put up with what I've been for the last year... > So it looks like we've got two votes for C/C++ so far. OO would > make things a lot cleaner, so so far C++ is the winner. > > I don't have a lot of experience with C++, but it's close enough to > C that I've been able to do some C++ hacking here and there. I > wouldn't object to going with C++. C++ _can_ be a good thing. Used unwisely, it _will_ bite you. The pertinent question will be: How will you enforce enough discipline to keep it getting out of control? Perhaps a C++ subset like embedded C++ could be used? As has been mentioned elsewhere, there will also be issues with availability and portability of middleware and frameworks. Check out Boost (http://www.boost.org), it's the future of standard C++. OO can be very powerful, but only if it applied carefully and properly during design. You can implement a sane OO design in almost any language if you are careful. The design is what makes the system OO, not the implementation language and/or tools. Using C++ does _not_ make your system OO, but it _can_ make it unmaintainable. > > More votes? I'd be cautious about trying to support too many platforms/development environments too soon. It's going to be almost impossible to satisfy every developer's/user's wishes in one shot. Avoid the second system syndrome: In the second system you try and do everything you wished you'd done in the first version of the project, resulting in code bloat, and the eventual emergence of the third system :-) The biggest lessons I've learned are: - Partitioning of the system into modules is the most important design decision - Modules should do one thing, and do it well, independent of the rest of the system (is it reusable?) - Modules should be able to be built independent of one another - Instrumentation and debug support should be designed in at the start - Graphics middleware should be common to all platforms (i.e. OpenGL, Qt, GTK) - Configuration data storage and manipulation should be common to all platforms (i.e. XML) - Abstract away platform dependencies when possible (i.e. POSIX, STL) - Model/emulate the design before implementing it if possible - Separate engine/data source from user interface - Design reviews (and code reviews to a lesser extent) provide the most improvement in quality for the least investment One more point about supported platforms: Keep in mind that it is quite possible that part of Microsoft's business plan is making sure that you _can't_ run your software on non-MS platforms. > > -- > Curt, WE7U. archer at eskimo dot com > http://www.eskimo.com/~archer > Cheers, -- Larry Gadallah, VE6VQ/W7 lgadallah AT gmail DOT com PGP Sig: 917E DDB7 C911 9EC1 0CD9 C06B 06C4 835F 0BB8 7336 _______________________________________________ Xastir-dev mailing list Xastir-dev@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir-dev
