For the record, Hana's Map is not optimized right now. This is the subject of my GSoC project for this summer. So the performance should be pretty bad.
Fair point. I will compare tuple then ;)
Actually, I think it is very good. Indeed, the current Map implementation is very dumb and lookup is done by doing a linear search inside a tuple. Doing a short-circuiting linear search in a 1k element Tuple without busting the recursion limit is, I think, an achievement by itself. Actually, I have to check why it works :-). Of course, this does not mean that the Map should not be optimized: it will, and I expect to match roughly the performance of a hand-written Map.
Actually it did reach the recursion limit. Had to add -ftemplate-depth=1100 or sth along them lines.
I think this call stack is desirable, since it allows you to see where things blew up. Of course, there are a couple of levels of Hana-stuff in there, but you'll get the exact same thing if you instantiate a STL algorithm with an improper predicate. The only way to reduce the number of in-between steps would be to inline Hana's functions by-hand. I think language support would be needed to get significantly better diagnostics.
Also, if you'll notice, there are only two errors here. One is the actual error you made in the code, and the other one refers to a call to some deleted function `apply`. Usually, the compiler would explode and give a truck of error messages because it tries to continue compiling even after the error occurs. However, Hana will disable the next call when an error happens to make these useless messages disappear. That's where the call to a deleted function comes from.
Yea, but from recursive algorithms the call stack may never finish. Imagine fold in fold in fold and error somewhere there. Will try to provide proper example later on.
Can you share a link to that example? It would be helpful for me to see the exact thing so I can try to find a solution.
I would like to modularize the test suite. However, I have two main issues: - I want to avoid code duplication as much as possible - I want to reduce the compile-time of the test suite. It is already very long to compile, and putting more stuff in the same file helps to reduce
Sure, will send with the other example above. Can't find it right now :/ this. Totally understand. Had the same issue with my library. Ended up with silly framework with no run-time overhead. I tried Boost.Test/Google.Test/Catch before, but the overhead was quite big. My approach: struct test { template<class Test> test(const Test& test) { test(); } }; and I'm writing tests like that: test my_test_case_name = [] { // test }; You can find example here: https://github.com/krzysztof-jusiak/di/blob/cpp14/test/ft/di_scope_exposed.c... With a bit of effort you can get XML output with test case name and error message as well. The good bit is, it compiles very fast and you don't have to register anything, which is always annoying.
It should now link on GCC trunk, but other errors will pop up. Will try to fix this. Also, is Clang available on Windows? How so?
You can find clang-cl for Windows here:
http://llvm.org/releases/3.6.0/LLVM-3.6.0-win32.exe
http://clang.llvm.org/docs/UsersManual.html#clang-cl
Cheers, Kris
On Fri, Jun 19, 2015 at 2:30 PM, Louis Dionne
Edward Diener
writes: On 6/18/2015 4:11 PM, Louis Dionne wrote:
[...]
It should now link on GCC trunk, but other errors will pop up. Will
try to
fix this. Also, is Clang available on Windows? How so?
If you build clang targeted for gcc RTL ( not MSVC ) on Windows you can use Boost Build with the current clang.jam file by just specifying toolset=clang. If you need help doing this just ask.
Thanks for the pointer. I don't have access to a Windows machine, but it might be useful to test on Appveyor with Clang. I'll have a look.
Louis
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost