Fit

Library Submission

Note: you must be a logged in registered user in order to submit a library!
  • logo_linkweb_linkcomment 
    Add a row
Display Statistics
Reviews There are 0 reviews
There are 5 comments

Comment on This Page

  • Robert Ramey says:

    Looking over the documentation I had a couple of questions:

    a) In your documentation – you specify requirements on type parameters (yaw!) but I don’t see anywhere where the concepts are defined. I would like to see a Conceps section. If the concepts you are using are from STL you say that. or better yet make a reference to http://en.cppreference.com/w/cpp/utility/functional .

    b) I don’t see that the type requirements are enforced in the code so that if a user mis-uses a function he gets a useful error message rather than a couple page error stack. http://rrsd.com/blincubator.com/advice_concepts/ describes my views on the subject in more detail.

    c) I’m a little bit puzzled by the requirements of MoveConstructible on all the type parameters. Is this really a requirement? If I pass a const ref to another function object, will I get a compilation error? Does this support lazy evaluation? More information on this would be interesting – perhaps in a “Rationale” section common in boost libraries.

    I just took a look at Boost Phoenix. You library might do what Phoenix does, but it’s certainly not clear to me from looking at the Phoenix documentation. The purpose and usage of your library is fairly apparent to me from a cursory examination of the documentation. So I could easily see many people finding this useful. It would be a lot more useful with better introduction and motivation.

    • Paul Fultz II says:

      > a) In your documentation – you specify requirements on type parameters (yaw!) but I don’t see anywhere where the concepts are defined. I would like to see a Conceps section. If the concepts you are using are from STL you say that. or better yet make a reference to http://en.cppreference.com/w/cpp/utility/functional .

      Yes, I am planning on adding a Concepts page, however, most of the concepts come from STL.

      > b) I don’t see that the type requirements are enforced in the code so that if a user mis-uses a function he gets a useful error message rather than a couple page error stack. http://rrsd.com/blincubator.com/advice_concepts/ describes my views on the subject in more detail.

      Well, concepts like `FunctionObject` can’t be check by the compiler unfortunately. Also, the other requirements such as `MoveConstructible` is not checked directly. Instead, the constructors to the adaptors check if the function can be constructed with the type parameters. This seems to be more robust, since the adaptors take on the construtibility of the functions. Also, in addition, all the adaptors that are called are constrained by the callability of the functions(using `FIT_RETURNS`)

      > c) I’m a little bit puzzled by the requirements of MoveConstructible on all the type parameters. Is this really a requirement? If I pass a const ref to another function object, will I get a compilation error? Does this support lazy evaluation? More information on this would be interesting – perhaps in a “Rationale” section common in boost libraries.

      MoveConstructible is the minimum requirement, and doesn’t exclude CopyConstructible. From [cppreference](http://en.cppreference.com/w/cpp/concept/MoveConstructible):

      A class does not have to implement a move constructor to satisfy this type requirement: a copy constructor that takes a const T& argument can bind rvalue expressions.

      Also, thanks for the feedback, I’ll be working on adding these to the documentation.

  • akrzemi1 says:

    Hi Paul,
    Encouraged by the recent Boost mailing, I wanted to attempt to make a review of the library, but I was stopped at the level of reading the documentation. I was not able to conclude what I will need it for. This is the question that Boost libraries were usually able to answer in the first pages of the documentation. What is it that is hard to do today and will be easier with your library? How will I benefit from using it? From the one-sentence introduction (a header-only C++11 library that provides utilities for functions and function objects) I gather that you want to make functional programming easier. I may be wrong though, this is how I understand your statement. But if this is the case, we already have Boost.Phoenix (http://www.boost.org/doc/libs/1_57_0/libs/phoenix/doc/html/index.html). There appears to be some overlap on scope. I would expect a sentence saying why someone should prefer FIT over Boost.Phoenix. IOW, I would expect a short comparison. Without it my first impression is that the author is reinventing the wheel. I am pretty sure this is not the case: I am just saying that the lack of comparison with at least Boost.Phoenix makes this impression.

    I like some ideas inside, e.g., the pipes syntax. But without the general instructions on what this library is good for, I am a bit reluctant to invest more time in it. Is it ONLY about this pipe syntax and infix notation?

    • Robert Ramey says:

      Interesting comment – a common observation which I often agree with. Actually had a whole session at CPP dedicated to this. It was called “How you can make a Boost C++ Library”. But it should have been called “How to lose a user in 105 minutes. https://www.youtube.com/watch?v=ACeNgqBKL7E When I saw the library I had a similar question – Boost used to have a component for function object composition. This was deprecated with the comment “user boost bind instead” which I always found a little cryptic. I’ve heard of Phoenix but haven’t used it. akrezimits question didn’t occur to me -but it seems a good question though.

      Fortunately, theres an easy fix – you can just add more information to the documentation as akrzemit suggests. It’s not that hard and would help a lot. I’m guessing that his concerns could be addressed by better introductory material – motivational examples would help. That is – examples of problems which your library makes simple.

      Finally, I found you documentation more or less complete. At least as a minimum. That’s why I accepted it here. I would have preferred that it have a more Boost like look – but for now this is fine.

    • Paul Fultz II says:

      Thanks for the feedback.

      > What is it that is hard to do today and will be easier with your library? How will I benefit from using it? From the one-sentence introduction (a header-only C++11 library that provides utilities for functions and function objects) I gather that you want to make functional programming easier

      Well the goal is to help make dealing with functions and function objects(even lambdas) easier. I tried to avoid saying functional since it has a much broader scope and goal, but no doubt, it does share many things with functional constructs.

      > But if this is the case, we already have Boost.Phoenix (http://www.boost.org/doc/libs/1_57_0/libs/phoenix/doc/html/index.html). There appears to be some overlap on scope.

      There is actually very little overlap. Boost.Phoenix has a strong focus on its template-based lambda expressions, which it uses to implement many of the functional programming constructs. Fit does provide a limited form of template-based lambda expressions through the lazy adaptor, but it is mainly to aid in creating simple `constexpr` lambdas, and it is not the main focus of the library.

      > I would expect a sentence saying why someone should prefer FIT over Boost.Phoenix. IOW, I would expect a short comparison.

      I’ll work on writing something up.

      > I like some ideas inside, e.g., the pipes syntax. But without the general instructions on what this library is good for, I am a bit reluctant to invest more time in it. Is it ONLY about this pipe syntax and infix notation?

      Well the quick start went over more than just the pipe syntax and infix notation. It also went over initialization, overloading, and recursion, which are the three big areas that I find the library good for, especially in C++14. Perhaps the examples didn’t make clear enough case, and maybe I should show some comparisons of the more “traditional” way of solving these problems to get a better picture.