August 2010 - Boost - lists.boost.org

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

[parameter] std proposal
by Lorenzo Caminiti 07 Jan '13

07 Jan '13

Hello all, Is there a C++ standard proposal for named parameter addition? I am looking for an "N-paper" for named parameters similar to N2081 for concepts, or N1962 for contracts. Thank you. -- Sent from my mobile device Lorenzo

6 8

[#pragma once]
by Sid Sacek 18 Nov '12

18 Nov '12

I've worked with the MSVC, Sun and GCC compilers. Each one of them supports #pragma once. Is there any reason to wrap this pragma within #ifdefs? Are there any compilers out there today that don't support this #pragma? #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Could we change this coding pattern so that it no longer looks like MSVC is being selfish? -Sid Sacek

17 20

[config] explicit call of operator templates / msvc bug workaround
by Stefan Strasser 10 Oct '12

10 Oct '12

Hi, is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it? struct functor{ template<class T> void operator()(); }; template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC } this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions. (instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.) thanks, Stefan

6 10

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

[serialization] or [spirit] JSON Archives
by Fernando Pelliccioni 08 Sep '11

08 Sep '11

Hi, After experimenting with Spirit.Qi to make a JSON parser, I had the need for a serializer. First, I thought I could serialize my model of JSON (json:: value, json: object, etc.), but that was not compatible with boost::serialization. I am currently writing a ARCHIVE for Boost Serialization, but I'm finding some problems in order to implement JSON correctly. The question is, does anyone know about some files to Boost Serialization already finished? I've seen the Archive made by Esteve Fernandez, but do not serve my purpose, because I just need JSON. I would like to develop a JSON parser which in turn is a compatible Boost Serialization serializer . Any ideas? Thanks and regards, Fernando Pelliccioni.

5 6

[Opaque] Request for interest in Opaque typedefs library emulation
by vicente.botet 27 Jul '11

27 Jul '11

Hi, I have started to play with a class to define opaque typedefs on funcdamental types. It is based on the C++ proposal " Progress toward Opaque Typedefs for C++0X" by Walter E. Brown http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1706.pdf Please take a look on the preceding links to understand the motivation. Boost.Sericalization provide a BOOST_STRONG_TYPEDEF already, but in my opinon the implementation is not complete,as only the order operators are defined (But maybe I'm wrong). Evidently it can not provide everything we can have with a language approach, but IMO this could yet be useful. The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT An opaque type (OT) is a new type, different from the underlying type (UT) and other OT. It defines explicit constructor from the UT, and defines all the operators the UT support but this time applied to the OT. To define a new OT with this mixin classes struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); }; struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); }; In addition, defines macros that make this simpler BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score); Next follows the definition of the public_opaque_type template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > > { protected: T val_; typedef public_opaque_type opaque_type; public: typedef T underlying_type; explicit public_opaque_type(const T v) : val_(v) {}; public_opaque_type() {}; public_opaque_type(const opaque_type & rhs) : val_(rhs.val_) {} public_opaque_type & operator=(const opaque_type & rhs) { val_ = rhs.val_; return *this; } public_opaque_type & operator=(const T rhs) { val_ = rhs; return *this; } T const& underlying() const { return val_; } T& underlying() { return val_; } operator const T & () const { return val_; } operator T & () { return val_; } #if 0 bool operator==(const opaque_type & rhs) const { return val_ == rhs.val_; } #endif bool operator<(const Final & rhs) const { return val_ < rhs.val_; } Final& operator+=(const Final & rhs) { val_ += rhs.val_; return static_cast<Final&>(*this); } Final& operator-=(const Final & rhs) { val_ -= rhs.val_; return static_cast<Final&>(*this); } ... }; I have started to make some tests and it works well for the moment. Limitations: * As we can not specialize the behaviour of static_cast/dynamic_cast the library sould provide two specific casts opaque_static_cast and opaque_dynamic_static_cast (Not yet implemented). * As operator.() can not be overloaded, it works transparently only for underlying types that don't defines member functions (C++ fundamental types, as int, char, ...). For the others an explicit use of the underlying() member function is needed :( * Others I have not catched yet :( Do you think it is worth continuing? Please, let me know if you see a error on the design. _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 8

[mpl] string to type conversion
by Bartosz Marcinkiewicz 19 Jun '11

19 Jun '11

Hello, I would like to have a macro which could be used like this: STRING_TO_TYPE( MyType ) which would yield: typedef mpl::string<'M','y','T','y','p','e'> MyType_id_t; Any ideas how to implement something like that? Thanks for any help, bma. -- Bartosz Marcinkiewicz tel. (+48) 516 034 243 e-mail: bma(a)epcon.pl, bartosz.marcinkiewicz(a)epcon.pl EPCON Sp. z o.o. www.epcon.pl adres: 53-407 Wrocław, ul. Gajowicka 114/116 tel. (+48) 71 361 75 55 ext.36 fax (+48) 71 361 74 44 NIP PL 899-24-92-498 KRS 0000190187 REGON 932963731 Kapitał zakładowy: 500 000 PLN

4 4

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 25 May '11

25 May '11

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? > I'm fine with incorporating a *nix only solution because what your > suggesting will be a nice solution for *nix platforms, but it will need to > be clear that it's not portable. I don't see why it wouldn't be possible to deploy the (big-endian) binary files to any platform. Getting it into this binary form (using zone info compiler zic) may be harder to do cross-platform, but cygwin may help here. [snip] > As the primary maintainer of Boost date-time I can say with certainty that > there is interest in this functionality -- it's long been on my todo list > and I haven't had time to get to it. You can email me privately and we > can discuss all the details of how to get your code incorporated. I'll do! Regards, Rutger

5 9