August 2010 - Boost - lists.preview.boost.org

[preprocessor] check if a token is a keyword (was "BOOST_PP_IS_UNARY()")
by Lorenzo Caminiti 17 Aug '10

17 Aug '10

Hello all, I asked this question before but received no answer: Is there any problem in using `BOOST_PP_UNARY()` to check if a token matches a predefined keyword as indicated by the code below? The following `IS_PUBLIC(token)` macro expands to 1 if `token` is `public`, to 0 otherwise: #define PUBLIC_public (1) #define IS_PUBLIC(token) BOOST_PP_IS_UNARY(BOOST_PP_CAT(PUBLIC_, token)) IS_PUBLIC(public) // Expand to 1. IS_PUBLIC(abc) // Expand to 0. This works just fine on both GCC and MSVC. However, `BOOST_PP_UNARY()` is only part of Boost.Preprocessor private API because: Paul Mensonides mentioned in http://lists.boost.org/Archives/boost/2004/08/70238.php > Paul Mensonides wrote: > I know. They (and other types of detection macros) are very useful. Right now, > the Borland configuration is used by the IBM preprocessor and the Sun > preprocessor also. I'd like to know whether or not those macro definitions work > correctly on those preprocessors before I add it. Though those macros aren't > part of the public interface, they are part of the internal interface. I.e. > they are used internally as if they were a public interface (though they are > used carefully on some preprocessors). They are stable, and the worst thing > that might happen in the future is that they will be moved to a different > directory. Thus, you can use them, but beware of VC and versions of MWCW prior > to v9. They in particular have severe problems with expansion order. E.g. VC > will even fail this test: (Boost.Preprocessor, Boost.Typeof, and Boost.Spirit already use `BOOST_PP_UNARY()` internally.) Thank you very much. -- Lorenzo

3 5

[DateTime] Converting ptime to real POSIX Time
by Artyom 17 Aug '10

17 Aug '10

Hello, I want to provide some integration between boost::posix_time::ptime and boost::locale::date_time - make transparent conversion between two. I have following point I either miss in ptime design or it has design flaws: 1. POSIX Time (see http://en.wikipedia.org/wiki/Unix_time) is always considered Time in seconds from 1970-JAN-1 00:00:00 UTC not including leap seconds. However ptime can be constructed from "local_time" which is totally contradicts a well known definition of POSIX time. 2. I can't find any way to convert it to "number" POSIX time. I can convert it to time_t and from time_t but if I need a better accuracy -milli-seconds, nano-seconds etc. it seems to be impossible according to docs. How can I convert it to more accurate representation? Is there any way to get a notice about how ptime was created, with universal time scale or local time scale, also I there a way to get UTC POSIX time from ptime even if it was created from local time. Artyom

2 1

WCHAR_MAX not defined on openbsd
by Nick Owens 17 Aug '10

17 Aug '10

hi there, i'm using openbsd 4.7 with g++ 4.2.4 installed from openbsd packages. i've tried building both boost 1.43 and 1.44rc, and both have several libraries fail due to WCHAR_MAX not being defined. this appears to be because __STDC_LIMIT_MACROS is not defined while processing /usr/include/stdint.h. i built boost with ./bjam cxxflags='-D__STDC_LIMIT_MACROS' and there are no more errors about WCHAR_MAX not being defined. perhaps this define should be added to boost/cstdint.hpp, or is there a deeper reason why WCHAR_MAX is not being defined correctly?

4 7

[DateTime] Cannot handle 64bit seconds
by Roland Bock 16 Aug '10

16 Aug '10

Hi, when transforming a unix time into a boost::posix_time::ptime, the value of the unix time is truncated to long in for method boost::posix_time::from_time_t. As a result, -4260211200 is represented by some ptime in the year 1971, but it should be 1835. Or, in other words Boost.DateTime has the year 2038 problem. Regards, Roland

2 2

[filesystem][lexical_cast] Lexical cast of filenames containing spaces
by Daniel James 16 Aug '10

16 Aug '10

Hi, An issue has come up in program options. With filesystem v3, this throws: lexical_cast<boost::filesystem::path>("file name") The problem is that filesystem v3's stream extractor treats spaces as separators (which is the right thing to do IMO), so it only extracts "file", which causes lexical cast to throw an exception - because the whole string hasn't been extracted. Would it be possible to create a special case in lexical_cast to deal with this? How does it deal with this problem for strings? Daniel

3 6

outer class `this` in local classes
by Lorenzo Caminiti 16 Aug '10

16 Aug '10

Hello all, Is there a way to access the outer class `this` from a local class but without using inheritance? Let me explain with an example: class x { // outer class public: void g() {} void f() { this->g(); // (1) struct y: x { // local class *** using inheritance *** y(x* super): x(*super) {} // (2) void h() { this->g(); // (3) } }; y(this).h(); } }; *** Is there a way to do this but without inheriting `y` from `x`? *** At line (3), the local class `y` can access the outer class `x::g()` simply using `this` because `y` inherits from `x`. However, this inheritance requires to construct another object `x` when `y` is constructed as in line (2) adding runtime overhead and requiring `x` to have an accessible copy constructor. In my application, I need line (3) to essentially look like line (1) so you can program code inside `y` members as if it were inside `x` members. A part from that, the local class `y` could look as it is needed to solve this problem -- with some member variables, other member functions, etc. (For example, I tried to redefine `y::operator->()`/`y::operator*()` to return a pointer/reference to `x` but this does not work because `this->`/`*this` always retain its pointer semantics and they do not use the user defined operators...) Thank you very much. -- Lorenzo

2 3

Re: [boost] [exception] ostringstream like
by fabien.castan＠free.fr 16 Aug '10

16 Aug '10

> exception are just here to gather and carry diagnostic info, not full fledged error message If you throw a bad_alloc, you don't need to add a full fledged error message, I agree that the localization and the exception type is sufficient. When you throw a logic_error, more the message is clear, precise and detailed better it is. > may fail to allocate the needed memory for the string and stream, thus maskign the initial exception with some bad_alloc. I agree for bad_alloc exception, but as before you don't really need a message in this particular case. If you throw a logic_error, you don't have more chance to encounter a bad_alloc than everywhere in your application.

2 1

Re: [boost] [chrono] [dependence of common_type on Boost.TypeOf]
by Adam Merz 16 Aug '10

16 Aug '10

vicente.botet <vicente.botet <at> wanadoo.fr> writes: > Hi again, > I have reached to manage with the ambiguous overloads and all the tests works > as before. > I have do it as follows: <snip code> That doesn't seem very robust in the case that there is no common type (in terms of the compiler error anyway). Maybe I'm missing something regarding the required semantics, but couldn't something like the following be used, so at least you get a reasonable static assertion error instead? #include <boost/mpl/if.hpp> #include <boost/type_traits/is_base_of.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/static_assert.hpp> template<typename T1, typename T2> struct common_type { typedef typename boost::mpl::if_< boost::is_base_of<T1, T2>, T1, typename boost::mpl::if_< std::is_base_of<T2, T1>, T2, void >::type >::type type; // no common type BOOST_STATIC_ASSERT((!boost::is_same<type, void>::value)); }; template<typename T1> struct common_type<T1, void> { // void is not a valid type BOOST_STATIC_ASSERT(sizeof(T1) != sizeof(T1)); }; template<typename T2> struct common_type<void, T2> { // void is not a valid type BOOST_STATIC_ASSERT(sizeof(T2) != sizeof(T2)); }; (Apologies for messing up the message threading. I post via Gmane, and this thread isn't showing up there, presumably because of the encoding issues in the message subject.)

3 4

Detection of 64bit using macro
by Kim Kuen Tang 16 Aug '10

16 Aug '10

Hi all, the question might be not directly related to boost. But i just want to be sure that i am not reventing the wheel. I am searching for a macro that is able to detect that a system is 32bit or 64bit no matter what compiler is used. Is there something similar already implemented in boost? Perhaps some background about this feature. Template specialization for std::size_t is not needed, when the specialization already exists for unsigned int. But on a 64bit system this is not true. So you need explicitly added the specialization whenever a 64bit compiler is used. See the following example. # include <cstddef> template<typename T> struct Null; template<> struct Null<unsigned int> {}; template<> struct Null<std::size_t> {}; // compile only on a 64bit compiler int main() { return 0; }; Thx for any comments, help or suggestions Kim

5 6

[chrono] v0.4.5 Documentation update + warnings removal + bug fixes
by vicente.botet 16 Aug '10

16 Aug '10

Hi, I have made some minor modifications to the Boost.Chrono library as requested on these mailing lists. The implementaton is stable. Waiting for the review I plan to add yet a lightweight stopwatch, as suggested by Tom Tan on a personal mail, which stores a reference to a generalization of the Clock duration or an accumulator of the Clock duration. I'll concentrate also in improving the documentation and the tests. Anthony Williams will be the review manager and I hope we could find a date soon. Even if the review's date is not annonced yet, it will be great if some of you make a pre-review, so the conflicting issues are managed before the review. The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht…. New Features since v0.4.3: Version 0.4.5, July 6, 2010 Documentation update Documentation a.. Overview rewriting b.. Added missing thread_clock reference. c.. How to implement a thread_clock tutorial removed. d.. References section renamed to External Resources. e.. Added links to source examples. f.. Added links between Models and Concepts. g.. Added macros descriptions. h.. Cleanup. Bug Fixes a.. Valgrind fixes: "Conditional jump or move depends on uninitialised value(s)" b.. Take care of Boost.System break on version 1.44 c.. gcc.4.4 "warning: suggest parentheses around '&&' within '||' " removal. Version 0.4.4, February 22, 2010 Warning fixes Bug Fixes a.. scoped_suspend warning removal b.. error_code management completed _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

5 20