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
Ok, in hana::partial(f, foo{}), hana::partial would store a rvalue-reference to the foo{} temporary. Of course, this reference is valid exactly until the temporary is destructed. However, the lifetime of a temporary is until the end of the enclosing expression. So, for example, consider some_algorithm(sequence, hana::partial(f, foo{})). hana::partial holds a rvalue reference to the foo{} temporary. Then, this partial is used by some_algorithm, which is fine because the temporary is still in scope. Then, the algorithm returns and the temporary goes out of scope, which is fine.
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.