Sorry, but ... there should be some requirements (or concepts :-)) on the Buffer typename....
Base pointer ? void * sh.. ??
Size ? (of chars ??)
Of Chars ?
... ?\

Or simply follows the rules of allocator_traits ??

Use spoiler flag next time please. Your post was visible in the homepage.

New to Haskell, how does this work?

Needs more extensive testing: my first solution had a typo and yet still passes the tests. The tests are definitely too simple to test out a lot of typo-related edge cases.

Also, there should definitely be random tests.

Thanks

What I called a misaligned buffer here is a buffer that doesn't start at the address that its type alignment advertises. For example if a type is aligned at 8, you'd expect it's address to be a multiple of 8. If it isn't, it's misaligned. In the test, I build a buffer that has some arbitrary alignment, then break it to make it start at an incorrect address before calling your function.

This is the most difficult kata that I have solved, but it is due to the lack of information. I think it's useful to face similar difficulties sometimes. My code passes almost all tests except tests with 'misaligned buffers', what does misaligned buffers mean? can someone give me an example of such a buffer? I think it is similar to vector

very clean version using the generic programming! would not have thought this up myself very easily.

Dude! :D

It's not about size. In point-free version cycle "10" will most likely be evaluated only once (even if you don't really need it in this case)

I actually changed the prototype in my own solution to const Parameters& after I realized my mistake, but I apparently forgot to change the initial solution. Thank you for pointing it out!

Right, I wrote a solution for 1 object first, so I didn't really think about that at the time.
Also things like Parameters&& (instead of possible const Parameters&) usually just ask for forward... I guess there could be use cases for non-const lvalue parameters, but if it's not within the scope of the kata, then maybe const Parameters& would be better?

I had std::forward in my initial solution as well but after further reflexion I think it's incorrect. Since we're in a loop every subsequent call to the ctor is moving from objects in an undefined state which is probably not what we want. I could most likely write a test that breaks on such code but I don't think it's within the scope of the kata.

Thank you for reminding me of destructuring assignment though! I had completely forgotten that it's part of C++ now ^_^