Adam Wulkiewicz wrote:
The formal review of Emil Dotchevski's QVM library begins today on 7th Dec and ends on 16th Dec. Full documentation is also viewable on Github: http://zajo.github.io/boost-qvm/
Following are some comments about the docs and syntax. This is based on an earlier look at the library when it was first announced and a quick look recently to see what has changed. I've not looked at the source code or tried to use the library. I wish that the docs started with a page showing how to use the library's built-in types. Currently, the first code that is presented shows how to define traits to make a user-supplied type work with the library. This is too advanced for the first page of the tutorial. The docs should start by showing how to do some high-school vector algebra using the built-in vector and matrix types. I find most of the identifiers too short. To give just a couple of examples: "transp" is used to mean "transpose". You save typing three letters, and get confusion with transparent, transport, etc. Then look at the names of some traits classes; elsewhere we have type_traits, allocator_traits, iterator_traits etc. all spelt out in full, but in qvm we have q_traits, v_traits and m_traits. I could go on but really almost every identifier is too short for my tastes. I had a quick think about how a struct with x,y,z members could be adapted. Am I right in thinking that it would be necessary to write accessors like this inside the traits specialisation: float ir(int i, xyz_vec const & v) { switch (i) { case 0: return v.x; case 1: return v.y; case 2: return v.z; } } ? If so, do we think that a compiler would successfully optimise that when it realised that x, y and z were in contiguous memory? (I guess you could also have an array of member pointers; would that work any better?) I'm really not a fan of the old operator% and now operator, syntax. To me, (v,XY) looks like you're forming a row-vector with two elements. Is there a reason why these accessors can't be written with function syntax, i.e. XY(v) ? Or, for matrices, something like element<4,2>(m) rather than (m,A<4,2>) ? I guess that what we'd really like to be able to do is to override operator. and write v.XY. There are proposals for adding operator. to the core language. Would those proposals support what is needed here? Actually, maybe this is closer to another proposal - the unified call syntax, which would make v.XY() equivalent to XY(v). I'll be interested to see what others think about these and other aspects of the proposal. Regards, Phil.