<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 10, 2013 at 5:41 AM, Glynn Clements <span dir="ltr"><<a href="mailto:glynn@gclements.plus.com" target="_blank">glynn@gclements.plus.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
Vaclav Petras wrote:<br>
<br>
> So my question is, was this fixed in the time of [1]? It is not clear from<br>
> the discussion.<br>
<br>
</div>No.<br>
<div class="im"><br>
> If not, what is the right fix?<br>
<br>
</div>The right fix is to remove all occurrences of "using namespace std;",<br>
then fix the (probably hundreds) of errors which arise, either by<br>
using qualified names (e.g. std::vector) or by adding "using"<br>
statements for individual names (e.g. "using std::vector;").<br>
<br></blockquote><div>I tried to delete all "using namespace std;" but the error "<span style="font-family:arial,sans-serif;font-size:13px">reference...ambiguous"</span> was still there in slightly different form (unfortunately I lost them, so I cannot cite them). I decided that I will rename the functions in r58434. It seemed better than putting them into namespace because the namespace would be just for those particular functions or it would cause a lot of changes or "using yyy::xxx;" if it would be applied to more functions/classes.</div>

<div><br></div><div>[r58434] <a href="https://trac.osgeo.org/grass/changeset/58434">https://trac.osgeo.org/grass/changeset/58434</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


[Note that iostream uses templates, so it might matter which approach<br>
is taken. A qualified name forces the use of a specific function (or<br>
type, etc), whereas a "using" statement adds the name as a fallback<br>
but argument-dependent lookup takes priority.]<br>
<br></blockquote><div>I was afraid that removing of overloading will cause some problems but it compiles, runs and results seems ok (but I actually don't know what to test except for the example in manual).</div><div>

 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
A more comprehensive fix would be to simply not accept code written in<br>
C++. It's a deceptively complex language, and writing portable C++<br>
code is significantly harder than writing "works-on-my-system" code.<br>
Consequently, a very large proportion of C++ code falls into the<br>
latter category.<br>
<br>
That isn't a problem if you're writing something for your personal use<br>
and you're willing to abandon it once it no longer compiles on current<br>
systems. OTOH, it is a problem for a project like GRASS, which aims to<br>
support multiple platforms over the long term.<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div>If you think that this is an issue it should be discussed and resulting policy should go to submitting rules.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<span class=""><font color="#888888">
--<br>
Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
</font></span></blockquote></div><br></div></div>