Boost logo

Boost :

Subject: Re: [boost] [Hana] Formal Review
From: Krzysztof Jusiak (krzysztof_at_[hidden])
Date: 2015-06-19 09:53:23


> 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.

Sure, will send with the other example above. Can't find it right now :/

> 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
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.cpp

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 <ldionne.2_at_[hidden]> wrote:

> Edward Diener <eldiener <at> tropicsoft.com> 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
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk