<div dir="ltr"><div class="gmail_quote">On Thu, Jan 13, 2011 at 12:03 AM, Tzafrir Cohen <span dir="ltr"><<a href="mailto:tzafrir@cohens.org.il">tzafrir@cohens.org.il</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> 1) Just use std::map, and ignore the performance penalty, no one will<br>
> probably notice.<br>
<br>
</div>People do notice. This does not work in real life (in too many cases).<br></blockquote><div><br></div><div>I really think that in most cases CPU is not the bottleneck, but of course it can be false for a specific application. This is not the main point here.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> 2) Copy an efficient map implementation from somewhere (as in copy-paste),<br>
> eg <a href="http://strinx.sf.net" target="_blank">strinx.sf.net</a>, and use it.<br>
<br>
</div>This leads you to having duplicated useless code in your tree.<br></blockquote><div><br></div><div>Again, from a purity POV this is bad, since you could add this duplicated code as a library and it would be more sound. However from practical POV, it'll work, it's reduce dependencies of the project, it makes it more portable, and it's good enough.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> 3) Have a project in a separate directory which implements an efficient map<br>
> in a siusing existing map implementation. For this project, it makes sense<br>
> to use autotools. But this project will provide a solid testable interface<br>
> (ie .hpp file) for this map.<br>
<br>
</div>So how can I pass parameters to the configure script?<br></blockquote><div><br></div><div>You don't. That's the whole point. In 99.9% of the cases, you don't want to pass parameters to the configure script. A portable efficient std::map implementation is an example where you should design your program so that no parameters would be needed. the autosuite will figure out which platform are you in, and will compile the appropriate files for this platform. But your main logic wouldn't need the autosuite at all, the main logic of your code would only depend on the portability layer.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">This means you'll spend much work on a portability layer. Which you were<br>
trying to avoid. But hey, you don't use autohell.<br></blockquote><div><br></div><div>I'm not sure I follow you here:</div><div>1) I'm not sure why moving the platform dependent code to a small separate project will make you waste more time on it, than building it inside your main project.</div>
<div>2) I tried to make clear that when writing a portability layer it makes sense to use the autosuite in order to figure out where you are, so I'm not sure I follow your last (cynical?) comment involving the term "autohell".</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">What you described above is an ad-hoc portability layer written in shell<br>
scripts and Makefiles.<br></blockquote><div><br></div><div>Again, I'm still not sure I follow you. I didn't recommend using shell scripts and makefiles in order to write the portability layer, the autosuite makes perfect sense there. My point it, it shouldn't appear in any other code than the portability layer, where the autotools configuration is a part of the logic.</div>
<div>(Indeed, if you don't have something like pnotify, you have to write it (or at least part of it) yourself for your portable inotify project, but this is true regardless of your usage of the autosuite).</div></div>
</div>