Posted by
Luigi Ballabio on
URL: http://quantlib.414.s1.nabble.com/Null-class-bug-on-x64-targets-tp9091p9096.html
On Thu, 2010-08-12 at 17:00 -0500, Kakhkhor Abdijalilov wrote:
> >Again u just need to set the correct macro, then the error should disappear.
> And that is the problem. It means more work for the users. The
> implementation from my previous e-mail could free the users from
> dealing with macros. It will not overwrite any other specialization.
The two of you are arguing the same thing, I think. The users should't
even need to know there's a macro, or any other mechanism. That used to
be the case, but a macro needs to be maintained across compilers and
means more work for the library writers. Your solution puts the burden
on the Boost type-traits maintainers, which is fine with me...
As for Kim's worry about non-builtins, I though of that too, because I
remembered that we had Null<Date> and Null<Array> in the code---but I
had forgotten that somewhere along the way we removed the old catch-all
template and added explicit specializations for Null<Date> etc.
So Kakhkhor's template is going to cover integer and floating-point
types, and specializations will take care of the other classes.
I guess I'll go and check that the proposed implementation works on my
compilers, now. Kakhkhor, a question: you report that your file doesn't
work with the Intel 11.1 compiler. But the current version (the one in
the official QuantLib) doesn't work either, right?
Luigi
--
Any software problem can be solved by adding another layer of
indirection.
-- David J. Wheeler
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev