[QVM] Boost.QVM formal review is ongoing
Dear Boost community, It seems that there are some problems with gmane.org related to handling of messages sent to many mailing lists at once. Therefore I'm reposting the information about the formal review. I appologize those of you who recieve this message for the second time. The formal review of Emil Dotchevski's QVM library begined on 7th Dec and it ends on 16th Dec. Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size with the emphasis on 2, 3 and 4-dimensional operations needed in graphics, video games and simulation applications. While it provides its own quaternion, matrix and vector types, it is designed to work primarily with user-defined types through user specializations of the q_traits, v_traits and m_traits templates. QVM's source code is available on Github: https://github.com/zajo/boost-qvm Full documentation is also viewable on Github: http://zajo.github.io/boost-qvm/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here: http://www.boost.org/community/reviews.html We await your feedback! Best regards, Adam Wulkiewicz
Le 09/12/2015 04:22, Adam Wulkiewicz a écrit :
Full documentation is also viewable on Github: http://zajo.github.io/boost-qvm/
Hi, there is a broken link on the TOC http://zajo.github.io/boost-qvm/SFINAE.html Vicente
Thank you, I'll fix it later -- the correct URL for that page is http://zajo.github.io/boost-qvm/sfinae.html. Emil On Tue, Dec 8, 2015 at 10:25 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 09/12/2015 04:22, Adam Wulkiewicz a écrit :
Full documentation is also viewable on Github: http://zajo.github.io/boost-qvm/
Hi, there is a broken link on the TOC
http://zajo.github.io/boost-qvm/SFINAE.html
Vicente
This is my formal review of Boost.QVM. My name is Rainer Deyke. I have a fair amount of experience in the problem domain. It's not exactly my area of specialization, but I have written similar code, I have worked with similar libraries (glm in particular), and I have written GLSL shaders that work with vectors and matrices. I believe that Boost.QVM should be accepted into Boost on these conditions: The library in general should be made more verbose. The terseness is not a problem when writing code, but it can greatly hinder readability, especially when reading code written by someone else where the reader is not familiar with Boost.QVM. It also makes it harder to search through both code and documentation. The various instances of 'q', 'v', and 'm' should at least be expanded to 'quat', 'vec', and 'mat', if not fully spelled out. The documentation should be improved. In particular: - The tutorial section should start with some simple uses of the library. - It's not immediately obvious which functions are classified as "operations" and which are "view proxies". Usually this can be regarded as an implementation detail. Either the distinction should be made clear (e.g. "all unary operations return view proxies"), or the operations and view proxies should be grouped together in the documentation. I also strongly feel that the comma operator should be replaced with function call syntax, i.e. X(v) instead of (v,X). However, I realize that this is bikeshedding on my part, so I am not making this a condition of Boost.QVM's acceptance into Boost.
- What is your evaluation of the library's: * Design
Seems solid. I especially like the use of view proxies to lazily evaluate certain operations.
* Implementation
I've only taken a cursory look, but I haven't noticed any particular problems.
* Documentation
Could use more work, see above.
* Tests
I've only taken a cursory look, but it looks reasonably complete.
* Usefulness
Very useful. I intend to start using this in production code the moment it appears in an official Boost release.
- Did you attempt to use the library? If so:
No.
- How much effort did you put into your evaluation of the review?
A few hours of work. -- Rainer Deyke (rainerd@eldwood.com)
Rainer, thank you for the thoughtful review! Just one comment below: On Thu, Dec 17, 2015 at 8:37 AM, Rainer Deyke <rainerd@eldwood.com> wrote:
I also strongly feel that the comma operator should be replaced with function call syntax, i.e. X(v) instead of (v,X).
A friend of mine came up with the idea to implement swizzling and member access as a function call syntax, then in a separate header define that (v,XYZ) is equivalent to XYZ(v). This seems doable. Do you think that this is a reasonable compromise? Thanks! Emil
On 17.12.2015 20:10, Emil Dotchevski wrote:
Rainer, thank you for the thoughtful review! Just one comment below:
On Thu, Dec 17, 2015 at 8:37 AM, Rainer Deyke <rainerd@eldwood.com> wrote:
I also strongly feel that the comma operator should be replaced with function call syntax, i.e. X(v) instead of (v,X).
A friend of mine came up with the idea to implement swizzling and member access as a function call syntax, then in a separate header define that (v,XYZ) is equivalent to XYZ(v). This seems doable. Do you think that this is a reasonable compromise?
Yes. -- Rainer Deyke (rainerd@eldwood.com)
On Thu, Dec 17, 2015 at 10:46 PM, Rainer Deyke <rainerd@eldwood.com> wrote:
Rainer, thank you for the thoughtful review! Just one comment below:
On Thu, Dec 17, 2015 at 8:37 AM, Rainer Deyke <rainerd@eldwood.com> wrote:
I also strongly feel that the comma operator should be replaced with function call syntax, i.e. X(v) instead of (v,X).
A friend of mine came up with the idea to implement swizzling and member access as a function call syntax, then in a separate header define that (v,XYZ) is equivalent to XYZ(v). This seems doable. Do you think that
On 17.12.2015 20:10, Emil Dotchevski wrote: this
is a reasonable compromise?
Yes.
Thanks. I'll wait for the review process to finish before making this change. Emil
participants (4)
-
Adam Wulkiewicz -
Emil Dotchevski -
Rainer Deyke -
Vicente J. Botet Escriba