<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Jan 12, 2011 at 4:52 PM, Shachar Shemesh <span dir="ltr"><<a href="mailto:shachar@shemesh.biz">shachar@shemesh.biz</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
<br>
The test in its <a href="http://configure.ac" target="_blank">configure.ac</a> 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):<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
/* The type for the map class */<br>
#define MAP_CLASS std::unordered_map<br>
<br>
/* The file to include in order to get the map class */<br>
#define MAP_INCLUDE <unordered_map><br>
</blockquote><div class="im"><br></div></blockquote><div><br></div><div>This is an excellent example to explain the preferred approach for software portability.</div><div><br></div><div>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.</div>
<div><br></div><div>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:</div><div><br></div><div>1) Just use std::map, and ignore the performance penalty, no one will probably notice.</div>
<div>2) Copy an efficient map implementation from somewhere (as in copy-paste), eg <a href="http://strinx.sf.net">strinx.sf.net</a>, and use it.</div><div>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.</div>
<div><br></div><div>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?).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div>
<div>What about the case of inotify/Linux fragmented audio system, etc, etc.?</div><div>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.</div>
</div></div>