[GiNaC-devel] new tinfos

Jens Vollinga vollinga at physik.uni-wuppertal.de
Tue Nov 22 16:53:27 CET 2005


Hi,

Richard B. Kreckel wrote:
>> 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, 

... the more I think about it the more I like my proposal no.3.

Maybe GiNaC shouldn't read the programmer's mind and try to "fix" the 
ambiguities. In C++ grammar school they always warn you about using
using namespace std;
using namespace cmath;
and the like. They tell you something about avoiding evil errors by 
sacrificing some additional key strokes in order to put std:: or GiNaC:: 
in front of names. While I hate typing such extra I do appreciate the 
argument:
If some user really needs to include cmath AND ginac AND wants to have 
"using namespace std;" at the top (and not locally in some function ...) 
of his file (does anybody know this user?!?), HE should make clear which 
sin or log from which library he actually wants.

I will prepare a small code example during the next days to offer a 
better foundation for the discussion. Maybe I see the problems with 
"class sin : public classfunc {}" clearer then.

Regards,
Jens





More information about the GiNaC-devel mailing list