From: Frans S. <fra...@gm...> - 2014-01-23 14:59:21
|
Hello all, I see that Richard has merged his branch qucs_namespace, I am now building a snapshot for Ubuntu / source / windows, so we can test a few things. There are also a few open bugs that may need some attention. When hear people talk about qucs, I often get the question "doesn't qucs deserve a version number higher than 0.0.x?" What do you think about this, shouldn't we at least go to version 0.1.0 or something? Frans On 01/10/2014 11:18 AM, Richard Crozier wrote: > On 10/01/2014 06:56, Bastien ROUCARIES wrote: >> Le 9 janv. 2014 11:06, "Richard" <r.c...@ed... >> <mailto:r.c...@ed...>> a écrit : >> > >> > On 08/01/2014 18:55, Guilherme Brondani Torri wrote: >> >> Yes and no. These function are part of internal qucs ABI if we export it >> (using some refinement and.libtool export script we would render non >> exportable to other binaries) >> >> Moreover I add it to std only if this function are part of the std on >> the norm. I locally render conformant a non conformant implementation. >> > > Shouldn't the rule should be: Do not add *anything* to the standard > namespace? There is a high risk of causing problems by adding things to > the std namespace and the standard itself advises against this apart > from a few exceptions. > > Also it is not just about conformant/nonconformant, it is also about > backwards compatibility, and not absolutely requiring C++11. > > >> So yes it is a problem now but it work for our case. >> > Instead I have used things like this: >> > >> > namespace qucs { >> > >> > .... other stuff >> > >> > >> > #ifndef HAVE_CXX_COMPLEX_ACOSH >> > nr_complex_t acosh (const nr_complex_t); >> > #else >> > inline nr_complex_t acosh (const nr_complex_t z) { >> > return std::acosh (z); >> > } >> > #endif >> >> And we polute global namespace for no gain. Standard say std:: acosh is >> math acosh. Why should I call it qucs acosh for please of broken >> (windows) implementation? Let the optimize the common case (consider c++ >> well implemented) and implement kludge for broken implementation. >> > > I don't understand, how am I polluting the global namespace with this? > The new function is in the qucs namespace, not the global namespace. > > Also again, it is not just about broken implementations, it is also > about backwards compatibility with older compilers, by which I mean, the > older standard. > > As to why we should call qucs::acosh, well, isn't this because we are > not using the standard complex class, we have our own special > implementation of complex. Obviously it would be better if we were using > std::complex, and did not have our own implementation, but we are not, > so it makes sense to call qucs::acosh since we are using our own > implementation. If nothing else, it also warns that it may not be the > std implementation throughout the sources. When std::complex does > everything we want, we can simply find and replace qucs::funcname with > std::funcname everywhere and delete our complex class. > > Do you mind if I merge my version to master for now? > > Richard > |