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
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
clang version 3.8.0 (http://llvm.org/git/clang.git eb6222eaad7aaec5d9ec0ddd8d1f09e506e689bf) (http://llvm.org/git/llvm.git 08bd0b92116468b52776a55e1fb9dcd479c4a42d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/llvm/bin
Louis Dionne
@ldionne
Precisely, it’s reading to a place in memory whose content is runtime, so it cannot do so at compiel-time
I’ll check later, but that might be a bug in Clang trunk
Maik Klein
@MaikKlein
template <typename Iterable, typename T>
constexpr auto index_of(Iterable const& iterable, T const& element) {
  auto size = hana::size(iterable);
  auto dropped = decltype(
      hana::size(hana::drop_while(iterable, hana::not_equal.to(element)))){};
  return size - dropped;
}
template <typename Iterable, typename ...Ts>
constexpr auto indices_of(Iterable const& iterable, const Ts&...  elements) {
  return std::index_sequence<(index_of(iterable, elements)::value)...>{};
}

The problem is this line

  return std::index_sequence<(index_of(iterable, elements)::value)...>{};

Does :: not work with fold expressions?

Maik Klein
@MaikKlein
oh nvm it actually returns std::size_t, thought it would return hana::size_t
Jason Rice
@ricejasonf
hana::size returns an hana::integral_constant. To get the value from a size_c you can use hana::value(foo) or decltype(foo)::value.
Maik Klein
@MaikKlein
error: non-type template argument is not a constant expression
  return std::index_sequence<hana::value(index_of(iterable, elements))...>{};
                                                                                                      ^
Could it be possible that I can not use constexpr functions inside templates?
Jason Rice
@ricejasonf
wrap it in decltype
probably just better to decltype()::value in that case
Maik Klein
@MaikKlein
lol okay
Jason Rice
@ricejasonf
oh wait
Maik Klein
@MaikKlein
yeah it works that way
not quite sure why C++ can't figure that out by itself.
Jason Rice
@ricejasonf
hana::value should return the contained std::size_tso I would think that would work