These are chat archives for boostorg/hana

19th
Jan 2016
Maik Klein
@MaikKlein
Jan 19 2016 00:01
It currently compiles
The main idea was that I could do the "filtering" of an entity component system at compile time instead of runtime.
But I may need to switch to D if I really want to do something similar.
Louis Dionne
@ldionne
Jan 19 2016 00:03
I love to think it should be possible in C++, otherwise the purpose of Hana is somewhat defeated, lol.
Maik Klein
@MaikKlein
Jan 19 2016 00:07
Oh I totally missed that you have written your own version of get_range, looked so similar. Interesting that makes my transform_with_index kinda useless.
I don't know maybe I could have designed it differently or maybe the biggest mistake was to use rangev3, probably gets better once it is in the stl, I don't know.
Louis Dionne
@ldionne
Jan 19 2016 00:13
I can’t setup Breeze, it says breeze/dependencies/glad/GL/src/glad.c is missing.
I did init the submodules. I’m curious to see the compile-time bottleneck by myself.
Maik Klein
@MaikKlein
Jan 19 2016 00:15
oh yeah, I didn't really intend to make it usable for everyone yet
let me check you needed to generate the opengl version yourself with glad
you have to go into dependencies/glad
and generate it with python main.py --generator=c --extensions=GL_EXT_framebuffer_multisample,GL_EXT_texture_filter_anisotropic --out-path=GL
sorry about the mess
Maik Klein
@MaikKlein
Jan 19 2016 00:24
You can probably leave out the extensions because I don't use them.
Louis Dionne
@ldionne
Jan 19 2016 00:30
Which target is taking a while to compile?
Maik Klein
@MaikKlein
Jan 19 2016 00:30
ecs
It's depends on how many component_groups and systems there are
The example has only two component_groups and two systems.
Louis Dionne
@ldionne
Jan 19 2016 00:32
Right.
I still get a compile-time of 8s for ecs/main.cpp
Maik Klein
@MaikKlein
Jan 19 2016 00:33
yeah that is roughly what I have for that example aswell
adding another system with a different "query/filter" will bump it to 10
and so on
My major concern is that it doesn't scale very well
When I have 30 component_groups and 100 systems for example
Maik Klein
@MaikKlein
Jan 19 2016 00:39
  using entity = component_group_handle<position, velocity, name>;
  entity eg{};
  eg.get_range<position>();
  eg.get_range<position,velocity>();
  eg.get_range<position,velocity,name>();
Something like this is probably enough to "stresstest" it
Louis Dionne
@ldionne
Jan 19 2016 00:43
I get 5s with the above.
Maik Klein
@MaikKlein
Jan 19 2016 00:47

I think I also get around 6 second but once I add more queries,ordered differently it gets worse.

I also thought about generating something like using entity = component_group_handle<T0, T1, ... , TN>;

and then generate all possible calls to get_range<..>

I just haven't written a bigger example yet. I wanted to implement something simple like bomberman with it.
Louis Dionne
@ldionne
Jan 19 2016 00:52
Ok. Well, do let me know if you implement a larger example that shows prohibitive compile-times, even with your updated get_range() function.
Maik Klein
@MaikKlein
Jan 19 2016 00:53
I will
Louis Dionne
@ldionne
Jan 19 2016 00:53
Thanks!
Maik Klein
@MaikKlein
Jan 19 2016 00:53
No problem
henrique-almeida
@henrique-almeida
Jan 19 2016 00:57
hello louis
regarding issue #240, overflow happens for all integrals types
unsigned types are more well behaved, seeing as, for example, arithmetic with 'int's is actually mod 2^32 arithmetic
and according to wikipedia "The ring of integers modulo n is a finite field if and only if n is prime. If n is a non-prime prime power, there exists a unique (up to isomorphism) finite field GF(n) with n elements"
my math is very rusty tho, so i wouldnt know anything about that :p
henrique-almeida
@henrique-almeida
Jan 19 2016 01:03
correction: arithmetic with 'unsigned int's*
Louis Dionne
@ldionne
Jan 19 2016 01:05
@henrique-almeida I need to go now, I’ll read this tomorrow.
henrique-almeida
@henrique-almeida
Jan 19 2016 01:12
ok
henrique-almeida
@henrique-almeida
Jan 19 2016 01:26
youre right, signed types dont wrap on overflow
Louis Dionne
@ldionne
Jan 19 2016 12:57
@henrique-almeida You’re right that overflow happens for all integral types. But for signed integer types, the result of overflow is undefined behavior, whereas for unsigned types it is wrapping.
So the laws are respected for signed integral types, but not for unsigned ones, because there is a well-defined value for (1u << 31) * 2, and that value is 0u. This is what you point out in your comment of the issue.
henrique-almeida
@henrique-almeida
Jan 19 2016 15:50
well, seeing as they dont wrap, i dont think signed integers respect even the group rules: take for instance -std::numeric_limits<int>::lowest()
it doesnt have an additive inverse
in fact i got some very weird behavior, its negative is equal to itself, when printed with std::cout, but it cant be used inside a static_assert (says its value is outside the range of representable values)
henrique-almeida
@henrique-almeida
Jan 19 2016 16:02
also not closed under addition, so not a monoid
signed types are nasty =x
unsigned types are at least commutative rings
henrique-almeida
@henrique-almeida
Jan 19 2016 20:39
@ldionne have you considered Constant big_ints?
i understand this might be outside of hana's scope