Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 15:06

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 24 07:47

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 23 02:04
    pthom commented #432
  • Jan 18 12:46

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 16 22:27
    ricejasonf commented #434
  • Jan 05 06:22
    ricejasonf commented #330
  • Jan 03 11:40

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 02 00:33
    ricejasonf closed #434
  • Jan 02 00:33
    ricejasonf commented #434
  • Jan 02 00:04
    ricejasonf opened #434
  • Dec 27 2018 13:11

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Dec 22 2018 11:56
    pthom commented #432
  • Dec 22 2018 11:55
    pthom commented #432
  • Dec 21 2018 15:48
    pthom synchronize #432
  • Dec 21 2018 09:19
    sdebionne opened #433
  • Dec 21 2018 00:08
    ricejasonf commented #432
  • Dec 21 2018 00:03
    ricejasonf commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:13
    ricejasonf commented #432
Manu Sánchez
@Manu343726
I noticed a little typo on the docs. At the quickstart, just after the template_ lifter definition:

and it also provides a generic lifter for MPL metafunction classes names metafunction_class.

It's "named" right?

Louis Dionne
@ldionne
@Manu343726 Thanks; fixed
Manu Sánchez
@Manu343726
Hi Louis, I'm playing with Concepts TS using gcc trunk and it looks very promising. It supports auto unconstrained type in function parameters and constraints in lambda parameters. Also finally error messages are self-explanatory. Sadly the Integral trick above still doesn't work, constraints are applied to types only, seems not to have value template parameters in mind.
Louis Dionne
@ldionne
That’s sad, but at the same time I can understand that concepts only apply to types, at least conceptually. It would be a nice hack to be able to apply them to compile-time values, but that’s really just an abuse.
Louis Dionne
@ldionne
@Manu343726 At any rate, I’m currently looking at the possibility of converting Hana’s concepts to constexpr bool functions, and getting rid of the models<> metafunction. This way, one could write something like:
template <hana::Sequence S>
void my_function(S const& s) {
    // works with std::tuple, hana::tuple and anything which satisfies the concept
}
When Concepts are there, of course.
gnzlbg
@gnzlbg

@ldionne hi louis, do you happen to know how to enable automatic pushing of documentation to github pages?

I can figure out from your travis build script that I need to have a gh-pages branch in my repo, and a github token, do I have to do something specific the first time I initialize it?

Manu Sánchez
@Manu343726
@ldionne I'm currently working on this. Send me PRs with snippets you want to test if you like, or (easier), use the docker image to run tests on a concepts lite dedicated branch.
Louis Dionne
@ldionne
@gnzlbg Sorry for the late answer. You can see how I'm doing it in my doc/CMakeLists.txt. file. First, I clone the gh-pages branch using an url of the form https://github_username:github_token@github.com/github_username/project, which automatically gives me push access. Then, I just need to push normally using git push origin gh-pages.
gnzlbg
@gnzlbg
@ldionne thanks! I managed to get it going!
Louis Dionne
@ldionne
Test message after transferring the repository to boostorg.
Andreas Pokorny
@APokorny
@ldionne: I have been struggling with having user defined types as keys in boost::hana::map - I run into a static_assert saying that the comparison must be possible at compile time. I did implement constexpr bool operator== for combintations of (I believe) all of them.
Louis Dionne
@ldionne
@APokorny You must return an integral_constant<bool, …> from your comparison operator, not a constexpr bool.
Louis Dionne
@ldionne
#include <boost/hana.hpp>
namespace hana = boost::hana;

template <int i>
struct _int {
    template <int a, int b>
    friend constexpr auto operator==(_int<a>, _int<b>) {
        return hana::bool_c<a == b>;
    }

    template <int a, int b>
    friend constexpr auto operator!=(_int<a>, _int<b>) {
        return hana::bool_c<a != b>;
    }
};

auto m = hana::make_map(
    hana::make_pair(_int<0>{}, 0),
    hana::make_pair(_int<1>{}, 1)
);

auto zero = m[_int<0>{}];
This works for me.
Also note that making the operator== and operator!= constexpr is not necessary, as long as they return IntegralConstants.
Andreas Pokorny
@APokorny
Oh why not bool if the value could be picked at ct - will switch those to IntegralConstants..
Andreas Pokorny
@APokorny
Btw due to abi issues in Ubuntu 15.10 i use gcc again 5.2.1 seems to be fine fort hana
Louis Dionne
@ldionne
GCC 5.2.1 might be able to compile some of it, but I’m pretty sure that some tests will break. Can you please run make check and let me know if that works?
Also, regarding your question, do you mind if I turn it into a StackOverflow answer so that everybody can benefit?
Louis Dionne
@ldionne
@APokorny I went ahead and answered your question here. Let me know if that solves your problem.
Jason Rice
@ricejasonf
Is there a reason that BOOST_HANA_STRING is not constexpr? I see that it uses a lambda.
I don't even know if I need it to be constexpr. I'm just curious.
Louis Dionne
@ldionne
Lambdas can’t appear in constant expressions. That’s a restriction of the language that will most likely be lifted in C++17.
Jason Rice
@ricejasonf
yeah i was just curious why it's used in the string macro
Louis Dionne
@ldionne
@ricejasonf You mean why a lambda is used?
Jason Rice
@ricejasonf
yes
Louis Dionne
@ldionne
Because there’s no (known) way of doing it otherwise.
Jason Rice
@ricejasonf
aha
Louis Dionne
@ldionne
Creating compile-time strings without the GNU extension (the one with the _s user-defined literal) is only possible with this technique. Or you can also spell-out your compile-time string manually: hana::string<‘h’, ‘e’, ‘l’, ‘l’, ‘o’>.
Jason Rice
@ricejasonf
ty. cool project btw
Louis Dionne
@ldionne
No problem. Thanks for your interest in it!
Jason Rice
@ricejasonf
Hello again. It would be cool if map had a default constructor. I added a simple one, and it passes all of the tests.
without it I was passing around tuple of pairs and calling unpack/make_map at the point of instantiation
Louis Dionne
@ldionne
@ricejasonf How would you even default-construct a map? According to the documentation, hana::map<…> is implementation-defined. Thus, you can’t even write hana::map<hana::pair<…>, han::pair<…>> map{}, because you don’t know what the template arguments of hana::map<…> can be.
Jason Rice
@ricejasonf
something like decltype(hana::make_map(...))
i export it as a type that i pass as a parameter to a template where the class would have a member like MyMap mymap;
Louis Dionne
@ldionne
I’ll think about this and the implications that it might have. Off the top of my head, I’d be tempted to say that your decltype(…) shouldn’t be allowed by the library. However, I don’t have a clear argument right now and I also know it would be much more convenient to have the right to say hana::map<hana::pair<…>, …>. I’ll follow up later in boostorg/hana#197, as I can’t look into it right now.
It would also be helpful if you could comment on that issue and provide a bit of context surrounding your issue.
Jason Rice
@ricejasonf
i will.. i'll try to make an example use case
Louis Dionne
@ldionne
Thanks a lot.
Peter Shih
@peter50216
This message was deleted
In http://boostorg.github.io/hana/#tutorial-performance, it says "the cost of creating a std::array is constant and essentially inexistent.", but it doesn't feels "inexistent" in the chart. Am I missing something?
Louis Dionne
@ldionne
@peter50216 The “cost” you see is the cost for including <array>.
@peter50216 I’ll confirm this, just a sec.
std_array_include.jpeg
Louis Dionne
@ldionne
@peter50216 I confirm. If you look at the above chart, you can see that just including <array> has basically the same compile-time overhead as creating a std::array.
Peter Shih
@peter50216
@ldionne Oh ok. Maybe we should add this explanation to the tutorial, to avoid confusion.
Louis Dionne
@ldionne
@peter50216 Done in boostorg/hana@e9b9a00.