Hi! Jens Vollinga wrote:
I don't know how to solve the problem of namespace collision/ambiguity with built-in function like sin,cos,... yet. But even in the current implementation a get an ambiguity for stuff like cout << sin(1) << endl; when both cmath and GiNaC are included and all their namespace members are us'ing'ed.
just to fill the void:
1. We could rename the functions: tan->Tan,... etc. (I don't like this. It's cowardice.)
2. We could write some pre-processor definitions like #define sin GiNaC::sin ... (Well, maybe. These definition could be packed in a convenience header for the user like #include <GiNaC/GiNaC_with_cmath>. But better not to include this header multiple times ...)
I fear this will cause even more problems.
3. Don't avoid the ambiguities and force the user to explicitly write the namespace for such functions (and make lots of comments about it in the manual/tutorial). (Yes, use the force! Maybe give the user some extra header like in 2. to ease the situation).
This is a patch to the wrong location, since function.h is generated. But doesn't it resolve the worst ambiguities where there is a conflict with cmath's template<typename _Tp> typename __enable_if<double, __is_integer<_Tp>::__value>::__type sin(_Tp)? --- function.h.old 2005-11-21 21:43:16.063691034 +0100 +++ function.h 2005-11-21 21:42:19.964061214 +0100 @@ -39,6 +39,15 @@ #define DECLARE_FUNCTION_1P(NAME) \ class NAME##_SERIAL { public: static unsigned serial; }; \ const unsigned NAME##_NPARAMS = 1; \ +const GiNaC::function NAME(const ex & p1) { \ + return GiNaC::function(NAME##_SERIAL::serial, p1); \ +} \ +const GiNaC::function NAME(int p1) { \ + return GiNaC::function(NAME##_SERIAL::serial, GiNaC::ex(p1)); \ +} \ template<typename T1> const GiNaC::function NAME(const T1 & p1) { \ return GiNaC::function(NAME##_SERIAL::serial, GiNaC::ex(p1)); \ } Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>