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
Louis Dionne
@ldionne
Basically, what you couldn’t do if we stored rvalue references in partial is the following: auto p = hana::partial(f, foo{}); use(p);. This is because by the time p is used (and hence the rvalue reference to foo{} accessed), foo{} has gone out of scope.
Barrett Adair
@badair
Ok, that's what I thought. So you just wouldn't keep the partial object around. Got it
Louis Dionne
@ldionne
Right.
That is, at least, my understanding of temporary lifetime.
But I could be wrong. C++ is complicated :)
Barrett Adair
@badair
Indeed. I wasn't sure if it was expression-level or scope-level for prvalues.
Louis Dionne
@ldionne
I’m pretty sure it’s expression-level.
Barrett Adair
@badair
I wonder whether it would be nice to enable the use to specify the forward semantics with a wrapper function. Such as hana::partial(f, hana::move_then_copy(foo{})); Or even a generic function taking a template tag. Verbose, but granular, and could be specialized over the existing impl.
*the user
That allows for customization over "copy only" partial/"ref only" partial. Just an idea
Barrett Adair
@badair
Users who happen to need more granularity than the existing implementation will probably appreciate that
Louis Dionne
@ldionne
I have one thing in mind. We could allow hana::partial(f, std::ref(x)) to store a reference instead of a reference_wrapper. If we supported the special semantics for make_xxx(std::ref(…)) discussed in boostorg/hana#176, it would be very easy to implement this in hana::partial (because hana::partial stores the arguments in a tuple). However, this hits the same wall as #176, which is storing references in containers at all.
Jason Rice
@ricejasonf
Wouldn't it also be a problem if f was actually expecting an std::ref(x)?
Barrett Adair
@badair
I would be tempted to file that in the "too bad" folder :)
Jason Rice
@ricejasonf
I guess you could do hana::partial(hana::make_pair, hana::dont_unwrap_me(std::ref(x))) :P
Louis Dionne
@ldionne
Well, you can construct a std::reference_wrapper<T> from a T&, so it would work.
Jason Rice
@ricejasonf
ahh
Barrett Adair
@badair
I didn't realize the conversion worked both ways
Jason Rice
@ricejasonf
are you saying that f would do that?
Louis Dionne
@ldionne
Yes, it does. And both are implicit.
@ricejasonf I’m just saying that if f takes a reference_wrapper, and partial turns reference_wrappers into actual refs, then f would be called with actual refs.
But it would be fine, since (what I said).
Maik Klein
@MaikKlein
Is it possible to get compile time timers for code blocks?
START_CT_TIMER
//some code
END_CT_TIMER
No idea how I should profile my code. I have a function that takes up 2 sec and I compile it several times :(.
Maik Klein
@MaikKlein
Actually I don't think the thing I am trying to do is feasible in C++ at all, which makes me quite sad.
Barrett Adair
@badair
Not without compiler hooks
AFAIK
Louis Dionne
@ldionne
@MaikKlein No, that’s impossible. You have to try and isolate what is taking up compile-time, and then fix this.
Basically, just reduce the example until you have a small amount of code that shows the 2s compile-time.
Jason Rice
@ricejasonf
I've read in places that it is best practice to not pass primitive types by const& and instead just pass by value. If that is correct, does that mean the same should be done for empty or near empty types like hana::type?
http://stackoverflow.com/questions/10770410/reasons-to-not-pass-simple-types-by-reference?lq=1
Jason Rice
@ricejasonf
If I use const& it allocates 8 bytes instead of 1
Jason Rice
@ricejasonf
Sorry, please disregard all of that. It appears to be pretty trivial. (though unpacking a tuple of 100 types does call alloc align 8 100 times, but there is not noticeable difference)
Louis Dionne
@ldionne
Technically, you’re right that it would be better to pass them by value. But when you trip on a expensive-to-copy type, then you really want to pass by const&. So it’s kind of a tradeof. However, I would be tempted to think that empty objects should be easily optimized away. Could be wrong, in which case it might be worth a LLVM bugreport.
Jason Rice
@ricejasonf
Do you think it should be optimized away even when compiling -O1?
I noticed hana::equal_impl<type_tag, type_tag> uses const&, but I failed to see any difference when I tried benchmarking a bunch of type comparisons.
Jason Rice
@ricejasonf
or even unpacking a large tuple
Louis Dionne
@ldionne

Do you think it should be optimized away even when compiling -O1?

Hard to tell without looking at the assembly. I would probably say "no".

I noticed hana::equal_impl<type_tag, type_tag> uses const&, but I failed to see any difference when I tried benchmarking a bunch of type comparisons.

There is one issue with taking by value. Consider:

int main() {
    auto t = hana::type_c<int>; // not constexpr
    constexpr auto result = hana::equal(t, t); // should work, right?
}

If we make a copy of t, then it does not work anymore, because we're reading from a non-constexpr variable inside a constexpr context. So we have to take by const&, and not read what this (runtime) reference points to.

Jason Rice
@ricejasonf
that does work
Louis Dionne
@ldionne
I know, but if you change T const& to T in equal_impl<type_tag, type_tag>, it shouldn’t work anymore.
Jason Rice
@ricejasonf
It appears to be working.
Louis Dionne
@ldionne
Wai
Wait*
Jason Rice
@ricejasonf
#include<boost/hana.hpp>

namespace hana = boost::hana;

int main() {
  auto t = hana::type_c<int>;
  constexpr auto result = hana::equal(t, t);
  BOOST_HANA_CONSTANT_ASSERT(result);
}
Louis Dionne
@ldionne

If you change the definition of equal_impl to

template <>
struct equal_impl<type_tag, type_tag> {
    template <typename T, typename U>
    static constexpr auto apply(basic_type<T>, basic_type<U>)
    { return hana::false_c; }

    template <typename T>
    static constexpr auto apply(basic_type<T>, basic_type<T>)
    { return hana::true_c; }
};

then you get this error:

FAILED: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++   -DBOOST_HANA_CONFIG_ENABLE_DEBUG_MODE -DBOOST_HANA_CONFIG_ENABLE_STRING_UDL -I../include -I/usr/local/include -I../test/_support -Wno-gnu-string-literal-operator-template -ftemplate-backtrace-limit=0 -pedantic -std=c++1y -Qunused-arguments -W -Wall -Wextra -Wwrite-strings -MMD -MT test/CMakeFiles/test.worksheet.dir/worksheet.cpp.o -MF test/CMakeFiles/test.worksheet.dir/worksheet.cpp.o.d -o test/CMakeFiles/test.worksheet.dir/worksheet.cpp.o -c ../test/worksheet.cpp
../test/worksheet.cpp:1204:20: error: constexpr variable 'result' must be initialized by a constant expression
    constexpr auto result = hana::equal(t, t); // should work, right?
                   ^        ~~~~~~~~~~~~~~~~~
../include/boost/hana/equal.hpp:51:29: note: read of non-constexpr variable 't' is not allowed in a constant expression
        return Equal::apply(static_cast<X&&>(x), static_cast<Y&&>(y));
                            ^
../include/boost/hana/equal.hpp:51:29: note: in call to 'basic_type(t)'
../test/worksheet.cpp:1204:29: note: in call to '&equal->operator()(t, t)'
    constexpr auto result = hana::equal(t, t); // should work, right?
                            ^
../test/worksheet.cpp:1203:10: note: declared here
    auto t = hana::type_c<int>; // not constexpr
         ^
1 error generated.
Jason Rice
@ricejasonf
super weird.. it is not doing that for me
I even changed both copies of hana on my box just to be sure.
Louis Dionne
@ldionne
Strange, what compiler?
Jason Rice
@ricejasonf
Though I get why it 'should' fail because it should try to make a copy of a nonconstexpr.
Louis Dionne
@ldionne
I need to go right away, I’ll brb in ~1 hour.
Jason Rice
@ricejasonf
cool