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
Jason Rice
@ricejasonf
If it was Orderable it could be sorted too
Pramod Srinivasan
@domarps
hey everyone, I just posted my issue about a boost python issue here : https://stackoverflow.com/questions/45576378/boost-python-importerror-undefined-symbol. It would be great if I can get feedback on how to resolve this issue.
Jason Rice
@ricejasonf
This is just a stab in the dark, but it appears that you are not actually linking the library. -L merely adds a directory for the compiler driver to search for libraries (I think).
gcc file1.c -Llibs -lmylib -o outfile
@domarps ^
Pramod Srinivasan
@domarps
I didn't understand that comment @ricejasonf. I believe it is an issue with conflicting linkages between different versions of python
Jason Rice
@ricejasonf
I think you need -lboost_python-py34. The -l option is used for linking but you don't have that which explains the undefined reference.
err.. just -lboost_python
Louis Dionne
@ldionne
@domarps Please note this is a channel for Hana, not for general Boost questions. Please direct such questions to the boost-users mailing list.
Jason Rice
@ricejasonf
Searchable does not refine Foldable
Louis Dionne
@ldionne
Sorry, I know I’m a ghost. I’ll try to reply to the issues within a few days, but I’ve been rushing to prepare a talk for tonight.
Jason Rice
@ricejasonf
I figured you are very busy. Sorry if I am being spammy. I found some other stuff to occupy me while that stuff ferments. :D
Post a link to the video of your talk if there will be one.
I'm sure it would be interesting
Louis Dionne
@ldionne
No you’re not spammy at all, I really appreciate the help and involvement.
Jason Rice
@ricejasonf
:+1:
Louis Dionne
@ldionne
There won’t be a video of the talk since this is a local C++ meetup. It’s my CppCon talk basically.
Jason Rice
@ricejasonf
static_assert(sizeof(hana::tuple<hana::int_<42>>) == 1); Is that expected?
Louis Dionne
@ldionne
Yes. What would you expect? That’s the smallest size it can have, right?
An object can’t have 0 bytes in C++.
Jason Rice
@ricejasonf

Ah, that's right. How about this then:

  static_assert(std::is_empty<hana::tuple<>>{});
  static_assert(!std::is_empty<hana::tuple<hana::int_<42>>>{});

Intuitively, I was expecting the latter to be empty because of ebo. Perhaps I need my own has_runtime_state<T> thing.

Louis Dionne
@ldionne
Ehm, I would expect it to be empty.
I think this would be fixed by boostorg/hana#333
Jason Rice
@ricejasonf
Oh, maybe it's not using ebo. ??
    template <typename ...Xn>
    struct tuple
        : detail::operators::adl<tuple<Xn...>>
        , detail::iterable_operators<tuple<Xn...>>
    {
        basic_tuple<Xn...> storage_;
        using hana_tag = tuple_tag;
Louis Dionne
@ldionne
basic_tuple is using EBO, but it’s missing some opportunities for it. I forgot the exact details since it’s been a while.
Jason Rice
@ricejasonf
Would it make sense to put basic_tuple in a storage wrapper and derive from that in tuple?
Also, would promoting basic_tuple to Sequence be a welcome as a PR?
Jason Rice
@ricejasonf
err not sure if that would be very valuable
Louis Dionne
@ldionne

Also, would promoting basic_tuple to Sequence be a welcome as a PR?

It already is.

Would it make sense to put basic_tuple in a storage wrapper and derive from that in tuple?

Hmm. Interactions with EBO are extremely complex due to the conversions they suddenly enable. I’ll have to dive into it again to fix the issue properly.

If, however, you can make the test cases added in #333 pass with a simpler implementation, I think I’d be happy.
Alastair Rankine
@randomphrase
Hi I have a possibly newbie question, hope someone can help.
So I want to do type manipulation on a std::tuple. Let’s just say that the std::tuple is defined elsewhere and I don’t want to change it to a hana::tuple. However I do want to do type transformations/filters on this - and I don’t mind outputting a hana::tuple.
IIUC a std::tuple can be used as a hana-conformant sequence, with the #inclusion of the appropriate adaptor. However, I can’t see a way to ‘lift’ (?) the std::tuple so that it can do type manipulations.
For instance, if I want to use std::tuple<int, char> with hana::transform (for example with hana::add_pointer), I first need to convert the std::tuple to std::tuple<hana::type_c<int>, hana::type_c<char>> - is this correct? In which case I can’t see an obvious way to do this. Does such a facility exist in Hana and if so how do I use it? Thanks.
Alastair Rankine
@randomphrase
Oops of course I need to convert std::tuple<int, char> to std::tuple<hana::type<int>, hana::type<char>>.
As it turns out I also need to convert the result (a hana::tuple<hana::type<int *>, hana::type<char *>> for example) into an MPL-conformant sequence of types such as hana::tuple<int *, char *>. Seems like a similar transformation and also seems like something that should exist in Hana already?
Maybe I’m overlooking something, FWIW I am using Hana 1.0.1 from boost 1.62.
Andreas Pokorny
@APokorny
sounds like a one liner taking a std tuple <Args...> and returing a hana::tuple<type_c<Args>...>
Alastair Rankine
@randomphrase
Sure. Something like:
template <typename ... Args>
constexpr auto to_hana_types(std::tuple<Args...>) { return hana::tuple<hana::type<Args> ...>{}; }
Seems like it should be part of hana though?
Alastair Rankine
@randomphrase
Actually I think the above ‘one-liner’ is oversimplified. In the general case (eg reference types) it may not be easy to instantiate this type, in order to call the function in the first place. Hence I think this may need to be a pure type transformation, using (for example) a partially specialized template class and traditional metaprogramming. Perhaps this is why it is not part of hana?
Jason Rice
@ricejasonf
You could do hana::transform(xs, hana::typeid_) which would yield a std::tuple<hana::type<T>...>
Jason Rice
@ricejasonf
... and types can be passed in to a hana::Metafunction like this hana::unpack(my_types, hana::template_<hana::tuple>) which would return a hana::type<hana::tuple<T...>>
There is also hana::experimental::types which is a just a list of types represented like types<T...> instead of wrapping everything in type like hana::tuple<hana::type<T>...>
Alastair Rankine
@randomphrase
@ricejasonf interesting, thanks! I’m assuming that I could also unpack into an MPL container like mpl::vector?
Alastair Rankine
@randomphrase
Also can confirm your solution works for me - including unpacking into an MPL container, nice! However, I did try it with a reference type in the input std::tuple, and sure enough I could not instantiate it to pass into hana::transform. Not sure what the generic answer would be here.
Jason Rice
@ricejasonf
Do you have a minimal code example? When dealing with types you typically want to keep it wrapped in hana::type so you don't instantiate it.
Jason Rice
@ricejasonf
boostorg/hana#326
Alastair Rankine
@randomphrase
The problem is with the first argument to hana::transform. I want to do type manipulations on a std::tuple (which as I described is generated upstream, and can’t easily be changed to a hana tuple). Currently I can call hana::transform(my_tuple{}, hana::typeid_) as you suggested above.
However this is predicated on my_tuple being default constructible, which is not necessarily the case for all tuples. Changing the default constructor to hana::type_c<my_tuple> does not work.
Jason Rice
@ricejasonf
If you just want to convert all the types to references perhaps a simple mpl style metafunction would be the most efficient.
like template <typename ...T> struct to_refs<std::tuple<T...>> { using type = std::tuple<T&...>; };
That way you don't instantiate stuff for every T
... or consider the code snippet in the top of the issue 326
Alastair Rankine
@randomphrase
Got it, sounds like #326 might be the more generic solution. Thanks for your help.