On Wed, Jan 12, 2011 at 10:37:34PM +0200, Elazar Leibovich wrote: > On Wed, Jan 12, 2011 at 4:52 PM, Shachar Shemesh <shac...@shemesh.biz>wrote: > > > > fakeroot-ng prefers to use std::unordered_map, if it's available. If not, > > __fnu_cxx::hash_map would do. If even that's not available, it would > > grudgingly use std::map, even though that one has worse performance > > characteristics. > > > > The test in its configure.ac is rather largish (not huge, mind you - 50 > > lines including the test for what flags are required to actually make gcc > > support C++0x), config.h has the following lines (or similar): > > > >> /* The type for the map class */ > >> #define MAP_CLASS std::unordered_map > >> > >> /* The file to include in order to get the map class */ > >> #define MAP_INCLUDE <unordered_map> > >> > > > > > This is an excellent example to explain the preferred approach for software > portability. > > The basic philosophy here is, program to the interface and not to the > implementation, and the autosuite encourage you to build a fragile ad-hoc > duck-type-like interface instead of building a robust one. > > What we're lacking here, is an efficient map implementation that conforms to > the std::map interface. So what I would do in the order of preference in > this situation is: > > 1) Just use std::map, and ignore the performance penalty, no one will > probably notice.
People do notice. This does not work in real life (in too many cases). > 2) Copy an efficient map implementation from somewhere (as in copy-paste), > eg strinx.sf.net, and use it. This leads you to having duplicated useless code in your tree. > 3) Have a project in a separate directory which implements an efficient map > in a siusing existing map implementation. For this project, it makes sense > to use autotools. But this project will provide a solid testable interface > (ie .hpp file) for this map. So how can I pass parameters to the configure script? (And yes, automake has something for that) > > This way, my main project have a straightforward build system, and the > portability layer is isolated from the project, testable and more portable > (what if we'll have a platform with buggy std::map implementation we can't > use? In case of (3) we can easily borrow one, and change the portability > layer only. What would the ng-fakeroot project do for such a system?). > > In the described project, the portability layer (efficient map conforming > std::map interface) is coupled with the project who uses it (fakeroot-ng), > and it is not IMHO a desirable design. Even if we can't design around > autotools, we need to minimize isolate the piece of code which must use it. This means you'll spend much work on a portability layer. Which you were trying to avoid. But hey, you don't use autohell. > > Recommending the usage of autotools in every project (and not, say, in > project whose only goal are to be used as portability layer etc.) encourage > you to program to the implementation. > > What about the case of inotify/Linux fragmented audio system, etc, etc.? > Again, the autosuite won't save the day here. If I want to write a portable > program which uses inotify (which is kind of oxymoron, as inotify is a Linux > specific API), what I really want is to program to a layer of abstraction > above inotify, which is portable to as many system as possible. If I don't > have anything like pnotify [*] - the autosuite won't really help me. It > would encourage me to write an ad-hoc half-broken portability layer with m4, > which is an invitation for troubles. It will certainly won't help me being > portable. If I must write a portable software which uses diverse API such as > inotify, and there's no known portability layer, then I should implement my > own portability layer as a separate project, test it on it's own, and then I > can be safe and avoid any autotools in my main project. What you described above is an ad-hoc portability layer written in shell scripts and Makefiles. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il | | a Mutt's tzaf...@cohens.org.il | | best tzaf...@debian.org | | friend _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
