March 2011 - Boost-users - lists.preview.boost.org

Re: [Boost-users] Boost-users Digest, Vol 2650, Issue 4
by Robert Lupton the Good 27 Apr '11

27 Apr '11

> Sorry for the slow response. I simply defined the following: > > typedef boost::gil::pixel<float, boost::gil::gray_layout_t> gray_float_pixel_t; > typedef boost::gil::image<gray_float_pixel_t, false> gray_float_image_t; > typedef gray_float_image_t::view_t gray_float_view_t; > typedef gray_float_image_t::const_view_t gray_float_const_view_t; > > As Dr. Bourdev advised, I do not use with these typedefs any of the color conversion operations offered by GIL. Apparently those rely on the scaling properties of the float wrapper type. > > So far, all I have done with these typedefs is ... > > 1. construct views using interleaved_view and pixel data pointed to by [const] float*, as illustrated near the beginning of the GIL tutorial > 2. create x- and y- iterators for the views to apply row- and column-oriented algorithms? Sorry for _my_ slow response (I was in Japan). I don't care about colour conversions, but I think that these types will convert to integral types with scaling unless you add more boilerplate. I added the following -- but it may not all have been needed; this was quite a while ago and I was new to gil. I also have some remaining conversion problems where I have to rewrite expressions to make them compile, but this may be something else. Anyway, I'd really like to see native gil support for a complete set of NON-scaling types. namespace boost { namespace gil { /* * Define a type that's a pure float, without scaling into [0, 1] */ typedef float bits32f_noscale; GIL_DEFINE_BASE_TYPEDEFS(32f_noscale, gray) GIL_DEFINE_ALL_TYPEDEFS_INTERNAL(32f_noscale, dev2n, devicen_t<2>, devicen_layout_t<2>) template<> struct channel_multiplier<bits32f_noscale> : public std::binary_function<bits32f_noscale,bits32f_noscale,bits32f_noscale> { bits32f_noscale operator()(bits32f_noscale a, bits32f_noscale b) const { return a*b; } }; template <typename DstChannelV> struct channel_converter<bits32f_noscale, DstChannelV> : public std::unary_function<bits32f_noscale,DstChannelV> { DstChannelV operator()(bits32f_noscale x) const { return DstChannelV(x + 0.5f); } }; template <typename SrcChannelV> struct channel_converter<SrcChannelV,bits32f_noscale> : public std::unary_function<SrcChannelV,bits32f_noscale> { bits32f_noscale operator()(SrcChannelV x) const { return bits32f_noscale(x); } }; // // Totally specialised templates to resolve ambiguities // #define CONVERT_NOOP(T1, T2) \ template <> \ struct channel_converter<T1, T2> : public std::unary_function<T1, T2> { \ T2 operator()(T1 x) const { return static_cast<T2>(x); } \ }; \ \ template <> \ struct channel_converter<T2, T1> : public std::unary_function<T2, T1> { \ T1 operator()(T2 x) const { return static_cast<T1>(x); } \ } CONVERT_NOOP(unsigned char, short); CONVERT_NOOP(unsigned char, unsigned short); CONVERT_NOOP(unsigned char, int); CONVERT_NOOP(unsigned short, short); CONVERT_NOOP(unsigned short, int); CONVERT_NOOP(short, int); #undef CONVERT_NOOP

3 2

How to handle blank space in parsing??
by Ramon F Herrera 24 Apr '11

24 Apr '11

Hello all, Boost::regex has been a Godsent to me. Before it, I performed any parsing with Perl. Now I am becoming comfortable with the regex package. (a million thanks to the folks responsible for it, and for Boost in general, btw) My only problem is spaces. I design typical mini computer language syntaxes, for example: Table[1, 4] = Value AND Array[8, 4] My initial approach was to get rid of all spaces before parsing (I recall being taught ages ago that the FORTRAN compiler does just that). Such strategy works in some cases, but the above line would become: Table[1,4]=ValueANDArray[8,4] Which is obviously bad news. I solved this particular case with this syntax: Table[1, 4] = Value && Array[8, 4] My latest "language" looks like this and has the same problem described above: Table rows [1758, 1904, 2053, 2201, 2345, 2497] Table cols [372, 880, 1336, 1756, 2083, 2439] I guess I could insert a colon or something between the first two words, but I am sure there has to be a better way. TIA, -RFH

3 2

[Review] Type Traits Extension by Frederic Bron - Review summary and decision
by Joel Falcou 20 Apr '11

20 Apr '11

Hello all, Frederic Bron's type traits extension proposal review ended up last week. In so far, we received SEVEN reviews which are all voting YES for the inclusion of Type Traits extension in Boost. So the result is that the Type Traits Extension is ACCEPTED into Boost. Suggestions include: - some clean-up in the implementation like "Renam[ing] the detail classes inside the specific namespace without using number, i.e. with a clear meaning. The use of tag, tag 2 could be renamed check_pass, check_fail or something like that." - Sensibility on cv-ref qualifiers in traits call is important. This is being addressed by Frederic. - Frederic is OK to keep the detection of void as a valid return type by using some dont_check type as default. - small comprehensive example of some of the traits like a "maybe_print function, which prints a value if the appropriate operator<< ostream overload exists, else prints "<NOT PRINTABLE>". [...] a small example like this would show a practical use of the library, and how to make use of enable_if, or some other overload method." - The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. This topic is still hot and alive. An alternative to the naming scheme consensus was proposed in the form of alias of commonly used operator traits. This issue is I think beyond bikeshed-color argumentation and I think it is a good point if Frederic could step up and provide a definite and rationalized answer to this point. The current status is : * the namespace options is out casue the standard didnt choose this way; * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open * the std:: like naming seems limited as not all operators are there. Thanks to all reviewers and people participating to the discussions. Thanks to Frederic for his work.

5 6

[Floating Point Utilities] where is the "nonfinite_num_facets.hpp"
by François Mauger 13 Apr '11

13 Apr '11

Hi As far as I understood, the Floating Point Utilities vault contribution by Johan R°ade has been integrated in the Boost official release. I've been using the "nonfinite_num_facets.hpp" header file for a few years within old Boost versions, directly extracted from the vault ZIP file released by Johan. Now, I can use the "fpclassify.hpp" file directly from the "boost/spirit/home/support/detail/math/" directory. Unfortunately I cannot find the "nonfinite_num_facets.hpp" file. Where can I find the "nonfinite_num_put/get" template class in say Boost 1.44 ? Maybe it has not been renamed in some other file or even not accepted at all... It is very useful for making my text and xml archives protable with NaNs and infinity support. Thanks for any hint or help. frc -- François Mauger Groupe "Interactions Fondamentales et Nature du Neutrino" NEMO-3/SuperNEMO Collaboration LPC Caen-CNRS/IN2P3-UCBN-ENSICAEN Département de Physique -- Université de Caen Basse-Normandie Adresse/address: Laboratoire de Physique Corpusculaire de Caen (UMR 6534) ENSICAEN 6, Boulevard du Marechal Juin 14050 CAEN Cedex FRANCE Courriel/e-mail: mauger(a)lpccaen.in2p3.fr Tél./phone: 02 31 45 25 12 / (+33) 2 31 45 25 12 Fax: 02 31 45 25 49 / (+33) 2 31 45 25 49

2 8

[Asio] Socket Read/Write Thread-Safety
by Timothy Liang 06 Apr '11

06 Apr '11

Hi, I'm implementing a full-duplex protocol over TCP/IP using Boost.Asio. Multiple threads will be calling 'io_service::run_one()', so I have to serialize my completion handlers. Since I need to be reading and writing on a socket at the same time, can I use the 'boost::asio::async_read(...)' and 'boost::asio::async_write(...)' functions? The documentation states that these are implemented in terms of calls to the stream's async_read_some and async_write_some functions, and the 'basic_stream_socket' class isn't thread-safe. Thanks, Timothy

4 15

[threads] Deadlock?
by The Novice Coder 05 Apr '11

05 Apr '11

I'm working with boost:threads, and am having what appears to be a deadlock issue. I'm not sure if the lock is something I'm doing, or if it's my lack of understanding of boost::condition_variable. The code deadlocks on this snippit: if( wait) { // lock the condition, add the event, wait for the condition, and get the return value! boost::mutex::scoped_lock lk(serviceMutex_); clearException(); returnValue_ = 0; qApp->postEvent(temp_this, temp_event, Qt::HighEventPriority); serviceCondition_.wait(lk); } Where wait is specified by the caller to wait for the other thread to return. In the service request thread has this snippet: { boost::mutex::scoped_lock lk( serviceMutex_); returnValue_ = qtService(s->getCommand()); serviceCondition_.notify_one(); } I tried it with and without the lock (in the 2nd snippet) but the 2nd snippet code is never getting called and just seems to vanish when wait is specified. When wait isn't specified, it all works. (Non-wait is just the same thing without any of the locks/conditions.) Any thoughts on where to look to proceed or what documents to read ? Thanks, and apologies for the inexperience. New to boost..

3 3

[MPL] initialization of member that might be non-copyable
by Noah Roberts 04 Apr '11

04 Apr '11

I'm working on something similar to the construct devised in the MPL book Section 9.5 (class composition). Some objects in the composed type might require initialization. I've solved this problem. However, in solving that problem I've now required that any type going into the composition must be copyable. However, since the original composition code doesn't make this requirement I've been trying to find a way to retain the ability to contain types that are non-copyable. Here's some code: template < typename Field > struct field_value { typedef Field field; typedef typename Field::type ftype; ftype value; field_value(ftype const& t) : value(t) {} field_value() : value() {} }; template < typename Field, typename ParamFields, typename Enable = void > struct initializer { template < typename Params > static typename Field::type apply(Params &) { return Field::type(); } }; template < typename Field, typename ParamFields > struct initializer<Field,ParamFields, typename boost::enable_if< boost::mpl::contains<typename Params::fields, typename FieldValue::field> >::type > { template < typename Params > static typename Field::type apply(Params & params) { return get<Field>(params); } }; template < typename FieldValue, typename Params > FieldValue init_field(Params & pars) { return initializer<typename FieldValue::field, typename Params::fields >::apply(pars); } template < typename FieldValue, typename More > struct record_base : FieldValue, More { template < typename Params > record_base(Params & pars) : FieldValue(init_field<FieldValue>(pars)) , More(pars) {} record_base() : FieldValue(), More() {} }; struct empty_record_base { template < typename Ignored > empty_record_base(Ignored&){} empty_record_base() {} }; template < typename MplSequence > struct build_record { typedef boost::mpl::placeholders::_1 _1; typedef boost::mpl::placeholders::_2 _2; typedef typename boost::mpl::fold < MplSequence , empty_record_base , record_base< field_value<_2>, _1 > >::type type; // type should be record_base< field_value<field0> // , record_base< field_value<field1> // , ... record_base<field_value<fieldN>, empty_record_base> // > ... // > }; It's at this point: template < typename Params > record_base(Params & pars) : FieldValue(init_field<FieldValue>(pars)) , More(pars) {} That I need to apply something, I know not what, to correctly initialize the field with either a parameter argument or nothing. I can't think of any construct that would make that possible but I don't necessarily know everything. Is there some way that this can be accomplished?

2 5

Copy-on-write STL containers
by Alexandr Sterligov 03 Apr '11

03 Apr '11

Is there any interest in a library of STL-compilant containers (vector, deque, map, set, list) with copy-on-write? -- Best regards, Alexander Sterligov

2 1

[MPL] no invoke<T>?
by Noah Roberts 03 Apr '11

03 Apr '11

I had to write an invoke metafunction because I couldn't seem to find one that looked like it was what I needed: template < typename MF > struct invoke { typedef typename MF::type type; }; I've looked through the documentation TOC: http://www.boost.org/doc/libs/1_42_0/libs/mpl/doc/refmanual/refmanual_toc.h… Is there something I'm missing?

4 8

VS2010+boost 1.44 - error in move.hpp
by archie14 02 Apr '11

02 Apr '11

While compiling the project in VS2010 previously built without errors in VS2008 I am getting following error: c:\libraries\boost\boost_1_44_0\boost\interprocess\detail\move.hpp(342): error C2440: 'return' : cannot convert from 'boost::interprocess::file_mapping' to 'boost::interprocess::file_mapping &&' You cannot bind an lvalue to an rvalue reference c:\libraries\boost\boost_1_44_0\boost\interprocess\file_mapping.hpp (62) : see reference to function template instantiation 'boost::interprocess::file_mapping &&boost::interprocess::move<boost::interprocess::file_mapping&>(T)' being compiled with [ T=boost::interprocess::file_mapping & ] I tried to search the forum for the reports on this error and did not find anything. I'll appreciate any help in this matter.

2 3