- Boost - lists.preview.boost.org

QVM formal review update
by Adam Wulkiewicz 15 Dec '15

15 Dec '15

Dear Boost Community! We're near the end of the QVM formal review period, it ends on 16th Dec. So far 11 people participated in discussions (not taking Emil nor me into account) and 2 reviews were sent. Do anyone of you need more time to ask questions, discuss, think, familiarize with QVM before sending a review? Are there people who would like to participate but haven't found enough free time so far? Basically I'm asking if anyone thinks that a review period should be extended? We appreciate your time and effort and of course kindly ask for sending reviews whenever you're ready. <TL;DR> -----The original announcement----- The formal review of Emil Dotchevski's QVM library is ongoing, it started 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

1 0

safe integer library -- the scope
by Andrzej Krzemienski 14 Dec '15

14 Dec '15

Hi Robert, It is great to see this library getting into Boost. It fills an important gap, but it is only after a long while that I realized that, because the introductory part of the documentation does not stress it enough, and in fact it misled me a bit. My understanding is that safe<int> represents a high level abstraction of an integral number from mathematics: unlike raw type int, which represents a set of allowed operations on the underlying processor. You could say that raw type 'int' is only needed to efficiently implement higher level abstractions, like BigInt or safe<int> -- the two only differ in trade-offs between efficiency and the range of values they can represent. I was missing this in the introduction. Instead I got a somewhat negative impression that the goal of the library is to turn any UB into throwing exceptions (and thereby prevent any UB-based static analysis from detecting programmer errors). I would like to see the library in Boost, although I must admit the other parts do not sound that compelling as safe<int>. Regards, &rzej

6 27

Query About Boost Soc2016
by Arafat Khan 14 Dec '15

14 Dec '15

Respected Sir/Mam I am Arafat Dad Khan, I am a second year undergraduate student at Indian Institute of Technology Kharagpur. I wish to contribute to the Boost Library. I have decent *knowledge of Algorithms and Data Structures *and have consistently taken part in algorithmic competitions on websites such as Codechef and Spoj(Sphere online Judge ) You can view my profiles here http://www.spoj.com/SPOJ/users/adk/ and here https://www.codechef.com/users/adkcodeme I am *looking for potential mentors for Gsoc 2016* so that i start contributing by working on a small tasks first.I want develop requirements for my proposal by doing *initial background research on the topic*, and interact with the mentors and community to help identify expectations for projects . Regards Arafat Dad Khan Indian Institute of Technology Kharagpur

1 0

Reminder - Master branch closes for release on Sunday night
by Marshall Clow 11 Dec '15

11 Dec '15

I will be making the RC for the 1.60 release Monday morning. Changes that are not merged into master before then will NOT be in the 1.60 release. -- Marshall

1 0

[qvm] Terseness of syntax etc.
by Phil Endecott 11 Dec '15

11 Dec '15

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.

11 26

[QVM] Help with small example
by Rajaditya Mukherjee 10 Dec '15

10 Dec '15

I am trying to run boost::qvm on my machine. I am using MS Visual Studio 2013 with Boost 1.59 as the backend. #include <boost/qvm/all.hpp> #include <iostream> class float4 { public: float4(float a, float b, float c, float d) { container[0] = a; container[1] = b; container[2] = c; container[3] = d; } float container[4]; }; namespace boost { namespace qvm { template<> struct v_traits<float4> { static int const dim = 3; typedef float scalar_type; template <int I> static inline scalar_type &w(float4 & v) { return v.container[I]; } template <int I> static inline scalar_type r(float4 const & v) { return v.container[I]; } static inline scalar_type &iw(int i, float4 &v) { return v.container[i]; } static inline scalar_type ir(int i, float4 const & v) { return v.container[i]; } }; } } int main() { float4 vec(11.0,0.0,5.0,-6.0); std::cout << boost::qvm::mag(vec); (vec,boost::qvm::A<1>) = 112.0; std::cout << boost::qvm::mag(vec); } In the line *(vec,boost::qvm::A<1>) = 112.0, *I am getting an compiler error that says error C2563: mismatch in formal parameter list error C2568: ',' : unable to resolve function overload 1> d:\dropbox\programs\boost_qvm\include\boost\qvm\v_access.hpp(79): could be 'boost::qvm::vector_access_tag<I> boost::qvm::A(void)' 1> d:\dropbox\programs\boost_qvm\include\boost\qvm\m_access.hpp(78): or 'boost::qvm::matrix_access_tag<R,C> boost::qvm::A(void)' Any help ? Maybe I am doing something stupid ? Any help by Emil or anyone else is appreciated. *Rajaditya Mukherjee * *3rd Year Graduate Student* Dept. of Computer Science and Engineering The Ohio State University Columbus, Ohio Tel :- +1-(614)-271-4439 email :- rajaditya.mukherjee(a)gmail.com <mukherjee.62(a)osu.edu>, raj(a)rajaditya.com <mukherjr(a)cse.ohio-state.edu>

3 4

Master branch is open for merging
by Marshall Clow 10 Dec '15

10 Dec '15

Thanks to everyone for their patience; the master branch is now open for merging. Remember, we're coming up to a release, so please, no breaking changes. Thanks! -- Marshall

3 4

[Property_tree] error with ptree_serialization in 1.59
by David Bernstein 10 Dec '15

10 Dec '15

Hi Everyone, This is my first post here, hopefully I’m at the right place but if not please let me know where I should go. I have a C++ class which uses boost::property_tree and also includes <boost/property_tree/ptree_serialization.hpp>. This has been working nicely until I upgraded to V1.59 today and now I’m getting the compile error below. Any help with this would be greatly appreciated! Thanks, Dave /usr/local/include/boost/property_tree/ptree_serialization.hpp:66:24: error: no type named 'library_version_type' in namespace 'boost::archive' const bsa::library_version_type library_version( ~~~~~^ /usr/local/include/boost/property_tree/ptree_serialization.hpp:69:21: error: no member named 'library_version_type' in namespace 'boost::archive' if(bsa::library_version_type(3) < library_version){ I This e-mail is covered by the Electronic Communication Privacy Act, 18 U.S.C. Section 2510-2521 and may be legally privileged. If you have received this transmission in error, please notify the original sender immediately by return e-mail or by telephone at the telephone number provided above and delete/trash the original message from your system. Thank you for your assistance. The information contained herein is confidential information provided only for the use of the individual or entity for whom it was intended. If the reader of this message received it in error, is not the intended recipient, or if an attachment is made in error, the reader is hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

1 1

Using BOOST_AUTO_TEST_CASE_TEMPLATE but passing a list of test values too
by Paul A. Bristow 10 Dec '15

10 Dec '15

I want to test a (quite large) variety of user-defined types using Boost.Test. As a very contrived example, suppose I wanted to check numeric_limits digits for integer types I'd like to avoid a tediously long list like this BOOST_CHECK_EQUAL(std::numeric_limits<char>::digits, 8); BOOST_CHECK_EQUAL(std::numeric_limits<char>::digits, 16); BOOST_CHECK_EQUAL(std::numeric_limits<char>::digits, 32); ... and follow the example of BOOST_AUTO_TEST_CASE_TEMPLATE but allow a test value to be passed too, something like this: typedef boost::mpl::list<char, int, long> test_types; and a list of test values, perhaps like this typedef list_c<int, 8, 32, 64> test_values; (However it would be *far* more useful to be able to test strings and floats and User-defined types too). BOOST_AUTO_TEST_CASE_TEMPLATE_????(digits_test, T, test_types, test_values) { BOOST_CHECK_EQUAL(std::numeric_limits<T>::digits, test_values); } Has any Macro Guru produced a BOOST_AUTO_TEST_CASE_TEMPLATE_? that includes a list of test values? Or other suggestions. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

1 1

[qvn] Why doesn't QVM use [] or () to access vector and matrix elements?
by Vicente J. Botet Escriba 10 Dec '15

10 Dec '15

Hi, These operators could be used for views So instead of (m, <http://zajo.github.io/boost-qvm/operator_mod_rationale.html>A42) *= 42; we could have in C++11 ref(m)(4,2) *= 42; ref(m)[4][2) *= 42; In C++98 these could be less efficient than e.g. value<4,2>(m) *= 42; Best, Vicente

2 2