On Tue, Dec 10, 2013 at 5:41 AM, Glynn Clements <gl...@gclements.plus.com>wrote:
> > Vaclav Petras wrote: > > > So my question is, was this fixed in the time of [1]? It is not clear > from > > the discussion. > > No. > > > If not, what is the right fix? > > The right fix is to remove all occurrences of "using namespace std;", > then fix the (probably hundreds) of errors which arise, either by > using qualified names (e.g. std::vector) or by adding "using" > statements for individual names (e.g. "using std::vector;"). > > I tried to delete all "using namespace std;" but the error " reference...ambiguous" 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. [r58434] https://trac.osgeo.org/grass/changeset/58434 [Note that iostream uses templates, so it might matter which approach > is taken. A qualified name forces the use of a specific function (or > type, etc), whereas a "using" statement adds the name as a fallback > but argument-dependent lookup takes priority.] > > 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). > A more comprehensive fix would be to simply not accept code written in > C++. It's a deceptively complex language, and writing portable C++ > code is significantly harder than writing "works-on-my-system" code. > Consequently, a very large proportion of C++ code falls into the > latter category. > > That isn't a problem if you're writing something for your personal use > and you're willing to abandon it once it no longer compiles on current > systems. OTOH, it is a problem for a project like GRASS, which aims to > support multiple platforms over the long term. > > If you think that this is an issue it should be discussed and resulting policy should go to submitting rules. -- > Glynn Clements <gl...@gclements.plus.com> >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
