- Boost - lists.preview.boost.org

[geometry] distance on multiline with spherical coordinates
by Karsten Ahnert 01 Jul '12

01 Jul '12

Hi, the following code produces some strange results: typedef cs::spherical_equatorial< boost::geometry::degree > cs_type; typedef model::point< double , 2, cs_type > point_type; typedef model::linestring< point_type > linestring_type; point_type p( 1.0 , 1.0 ); linestring_type l; l.push_back( point_type( 0.0 , 2.0 ) ); l.push_back( point_type( 2.0 , 2.0 ) ); l.push_back( point_type( 4.0 , 2.0 ) ); cout << "Distance : " << boost::geometry::distance( p , l ) << endl; for( size_t i=1 ; i<l.size() ; ++i ) { linestring_type l_tmp; l_tmp.push_back( l[i-1] ); l_tmp.push_back( l[i] ); cout << "Point distance : " << boost::geometry::distance( p , l_tmp ) << endl; } The output is Distance : 0.0174373 Point distance : 0.0174586 Point distance : 0.0174373 This looks like a bug. The distance to the second segment can not be smaller than that to the first one. If I change the coordinate system to cartesian coordinates everything works as expected. Do I miss some major points?

2 7

boost::locale throw exception std::bad_cast
by Alex Ivanov 01 Jul '12

01 Jul '12

Here is code sample: boost::locale::generator gen; std::string text="To be or not to be, that is the question." ssegment_index map(word,text.begin(),text.end(),gen("en_US.UTF-8")); last line throw exception std::bad_cast The tests was made on tthe hosts: Darwin mac-os 10.4.0 Darwin Kernel Version 10.4.0 (gcc version 4.2.1) Linux fedora 2.6.34.9-69.fc13.x86_64 (gcc version 4.8.0 ) Linux fedora 2.6.34.7-66.fc13.x86_64 (gcc version 4.4.5) Linux debian 2.6.32-5-amd64 (gcc version 4.7.0) with boost_1_50_0_beta1 How can I handle this? -- реклама ----------------------------------------------------------- Распродажа % модной одежды. Скидки до 70%. Количество ограниченно! Подробнее на сайте Bonprix http://goo.gl/1qLK1

2 1

Formal Review Request: TypeErasure
by Steven Watanabe 30 Jun '12

30 Jun '12

AMDG I'd like to request a formal review of the TypeErasure library that I've posted about several times before here. The TypeErasure library is a generalization of boost::any and boost::function. It allows easy composition of arbitrary type erased operators. As an example of basic usage, we can simulate Boost.Any: any<mpl::vector<copy_constructible<>, typeid_<> > > x(10); int i = any_cast<int>(x); // i == 10 The library is available in the Boost Sandbox at http://svn.boost.org/svn/boost/sandbox/type_erasure/ You can download archives with pre-built documentation from http://sourceforge.net/projects/steven-watanabe.u/files/ Online documentation can be found here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ In Christ, Steven Watanabe

26 118

[exception] Boost.Exception and the C++11 standard
by Vicente J. Botet Escriba 30 Jun '12

30 Jun '12

Hi, I was wondering how Boost.Exception works on compilers supporting 18.8.5 Exception propagation. Can an exception thrown by a 3pp library by retrieved by boost::current_exception() by another library or application code? BTW, what is the degree of compliance of Boost.Exception respect to 18.8.5 Exception propagation and 18.8.6 nested_exception sections of the standard? Do you have a plan towards been C++11 compliant? Best, Vicente P.S. I know that I can ask myself the same kind of questions respect to Boost.Ratio/Chrono/Thread, but this should be covered on a separate thread ;-)

2 1

Re: [boost] A GUI Library
by jinhao 30 Jun '12

30 Jun '12

On 2012/6/27 16:24, Klaim - Joël Lamotte wrote: > Hi, > > On Wed, Jun 27, 2012 at 2:55 PM, jinhao<cnjinhao(a)hotmail.com> wrote: > >> Is there any interest in this library? > > > My current understanding is that both Boost and the Standard C++ commitee > are interested in fully C++ library. > > However, the subject is complex and no library until now gathered > enough consensus to even get to the review stage of the boost process > (from memory). > You have to be ready for tons of feedback pointing problems. > > Now, I just read the websites but I have some questions: > > 1. can you write somewhere a big comparison between your library and other > popular GUI C++ libraries? Nana library is written though standard C++, this is a big difference between other libraries, as the brief mentioned, C++ idioms should works with a C++ library, and this is why the other popular GUI C++ libraries are not really C++ style at all. Secondly, this library can be work with a thread pool, it reduces the difficulty for threadization. > 2. if you want to submit your library to Boost, I think it would need to > be compatible (or maybe just use) boost.thread instead of your own solution I recognize that many ideas of my own solutions come from boost, not only boost.thread, there are boost.function, boost.any and so on, this is why I try to submit this library to boost and erase all my own solutions. > 3. the STR macro is a big problem, I think it will be a big source of > negative feedback. Now that we have boost.locale, would it be possible to > work with it instead? Somebody told me the problem before, I left the problem and searched a solution, I found many problem can be fixed by boost, and I rethink, can't keep on stealing ideas from boost. This is also why I try to submit this library to boost. > 4. I understand how you can build a GUI application in a way that is > mostly a list of statements. Does it means that you'd better organize your > windows/forms "types" as constructor functions? (ok found this that > partially answer my question: > http://nanaproject.wordpress.com/2012/01/31/idioms-and-insights-for-a-good-…) > 5. It is said that Nana is cross-platform, but I don't see any > demonstration of this (nevermind, I just found this: > http://nanaproject.wordpress.com/2012/05/16/tutorial-of-release-0-2-3/ ) > What are the target platforms? Target platforms should be Windows, Linux and Mac OS X, but now, it only works under Windows(GDI) and Linux(X11), the next is ready for Linux(framebuffer). A friend of mine asks for the support of framebuffer, so I leave the Mac OS X now. > 6. Should it work in non-graphic contexts like command-line only display? > (I'm thinking about GUI working in bash for example) Yes, like ncurses. But now it is not able to work in such environment. > 7. Is it thought to be easily extendable? For example, can I write myself > a new front-end implementation and plug it in? The library provide a general method to implement a customer widget, and supports external image-processing algorithm implementation (http://nanaproject.wordpress.com/2012/04/17/an-introduction-to-the-image-pr…) > 8. do you have an available example of complex application being built > with this library? Yes, but its language is Chinese, it is a stock software, a screenshot at http://sourceforge.net/projects/stdex The status of this library I give is alpha and the so library is not used widely. Best Regards! Jinhao

5 6

Meeting C++ - Call for Papers
by Jens Weller 30 Jun '12

30 Jun '12

Dear C++/boost community! I'm proud to announce the call for papers for the Meeting C++ conference! After having talked to some people in Aspen about the plans for a C++ conference in Germany, I've decided to give it a try. Meeting C++ will take place in November in Germany, as a 2 Day C++ conference. We are looking for speakers and possible talks at our conference in fall! Possible topics could include: * (modern) C++ * C++11 * boost * C++ Frameworks like Qt, wxWidgets, Ogre, ... * other C++ related topics You'll find more information and updates at the webpage http://meetingcpp.com Tickets will be available from July at our website. regards, Jens Weller -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

2 2

[config] request for BOOST_NO_CXX11_HDR_ATOMIC
by Tim Blechmann 30 Jun '12

30 Jun '12

preparing boost.lockfree for trunk, i need a good way to figure out if the <atomic> header is available. would it be possible to add a macro to detect that? BOOST_NO_CXX11_HDR_ATOMIC or the like? thanks, tim

3 6

[smart_ptr] Patch for #6824
by Brent Lewis 30 Jun '12

30 Jun '12

Regarding bug report: https://svn.boost.org/trac/boost/ticket/6824 I've attached a diff file

3 2

[nowide] Updates and Standalone Version
by Artyom Beilis 30 Jun '12

30 Jun '12

Hello all Booster, Boost.Nowide updates: The library provides an implementation of standard C and C++ library functions such that their inputs are UTF-8 aware on Windows without requiring using Wide API to make program work on Windows. --------------------------------- I had updated the library: - Changed boost::nowide::convert to boost::nowide::widen, boost::nowide::narrow - Changed boost::nowide::args to restore an original values in destructor - Updated the docs. Also I had created a stand-alone version of the nowide library such that it does not require boost and can be build with CMake - the use is the same just change: #include <boost/nowide/foo.hpp> ... boost::nowide::fstream To #include <nowide/foo.hpp> ... nowide::fstream ------------ Looking forward for more comments on a library that I want to submit for a formal review. Library: Boost.Nowide Download: http://cppcms.com/files/nowide/nowide.zip Documents: http://cppcms.com/files/nowide/html/ Non-Boost: http://cppcms.com/files/nowide/nowide_standalone.zip Git Repo: git://cppcms.git.sourceforge.net/gitroot/cppcms/nowide Tested On: OS: Windows 7 32/64 bit, Linux Compilers: GCC-4.6, MSVC-10 Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

3 7

[make_shared]
by Yuriy Zubritsky 30 Jun '12

30 Jun '12

Regarding https://svn.boost.org/trac/boost/ticket/6829 (make_shared is slower than shared_ptr(new) in MSVC) Does anyone want to apply it? It contains patch inside. Thanks

1 0

[BGL] How can I measure the memory used by a Boost graph ?
by ShNaYkHs ShNaYkHs 29 Jun '12

29 Jun '12

Hi, I have a graph defined as follow: struct NodeData{ /*...*/ }; struct EdgeData{ /*...*/ }; typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> MyGraph; MyGraph G; This graph is updated iteratively (by adding/deleting some edges/vertices). At each iteration, I want to evaluate the memory space occupied by this graph G. How can I do that ?

2 1

Tickets 6123 an 7023
by Luke Camden 29 Jun '12

29 Jun '12

Hi, Is anyone willing to commit these patches for me? If the process is not too involved I don't mind rtfm & DIY as an answer. Cheers, Luke

2 1

[1.50.0] Boost release 1.50.0 available
by Beman Dawes 29 Jun '12

29 Jun '12

Release 1.50.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains four new libraries (Algorithm, Functional/OverloadedFunction, LocalFunction and Utility/IdentityType) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_50_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.50.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

3 4

Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION
by Brian Wood 29 Jun '12

29 Jun '12

Emil Dotchevski: >On Wed, Jun 27, 2012 at 7:46 AM, Brian Wood <woodbrian77(a)gmail.com> wrote: >> Emil Dotchevski: >> >> > >> > There are 3 aspects of boost::throw_exception: >> > >> > 1) it enables libraries to support BOOST_NO_EXCEPTIONS configurations, >> > 2) it enables boost::error_info, and >> > 3) it enables boost::exception_ptr. >> > >> > 1) and 2) have nothing to do with threads; 3) implements >> > std::exception_ptr, which mostly benefits multi-thread programs (until >> > compilers catch up with std::exception_ptr support.) >> > >> > The cost imposed by libraries that use boost::throw_exception to programs >> > that don't use boost::exception_ptr or boost::error_info is that sizeof() >> > the exception object grows a little. >> >> I'd appreciate a way at compile time to let Boost Exception know >> I'm using it in a single threaded application and it wouldn't add stuff >> to the exception object that isn't needed. Also MSDN says, >> "Most applications do not have to transport exceptions between threads." >> > > There are exception_ptr use cases for single threaded programs. I'm not asking for this to be the default even for single threaded programs. I'd like it to be something that a user could opt out of if they want to. (This is all based on the possibilty that Boost Exception could become required. If that doesn't happen, this request wouldn't be very pressing from my perspective.) I haven't found much on use cases in single threaded programs. Do you have any links? I did find the following comment in some code that uses exception_ptr. "The reason here is that construction/destruction of an exception_ptr are not "cheap"" Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

4 5

Exact Decimal library
by Andrew Robb 29 Jun '12

29 Jun '12

Introduction C++ needs UTF-8 text (Boost.Locale) and exact decimal types support. Together they allow full processing of modern business text. Normal existing binary exponent types (float, double and long double) are not suitable for exact decimal numbers. The IEEE 754-2008 decimal exponent types should be allowed in binary files. Most processors already use IEEE 754-1985 for binary exponent types. IBM processors already support IEEE 754-2008 decimal exponent types in hardware and can used for optimization for exact decimal. Other processors may use fixed-point exact decimal. Exact Decimal Exact decimal numbers indicate not only the value but also the precision. Thus 0.3 and 0.30 indicate the same value but with different precisions. With rounding, the value 0.3 indicates a value between 0.25 and 0.35 but the value 0.30 indicates a value between 0.295 and 0.305. These are different ranges albeit different around the same centres but must be considered different because of their precisions. Currency values are ‘exact’ as there is no legal or commercial meaning in between the smallest adjacent values defined precision. Even when the GBP went decimal with a halfpenny coin, most banks would only keep values to the penny. A lot of normal commercial exact decimal values can be held in 32-bit with fixed-point decimal to 2 places (USD, EUR and GBP currencies) up to about 20,000.00 - more than enough for weekly groceries. As such, they are as quick as 32-bit integers for addition and subtraction an nearly as fast for multiplying too. Exact decimal processing would not require IEEE 754-2008 decimal exponent types and could use decimal fixed-point indest. Indeed, the range of significand could be more than used by IEEE 754-2008 decimal exponent types (e.g. java.math.BigDecimal). Embedded processors can support fast exact decimal their own way (floating or fixed). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf Extensions to support embedded processors must not give a general range decimal fixed-points. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1176.pdf Extension for the programming language C to support decimal floating-point arithmetic. Again, from IBM and not for decimal fixed-point type. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2849.pdf Extension for the programming language C++ to support decimal floating-point arithmetic. Unfortunately the paper looks only at the IEEE 754-2008 hardware implementation rather than using decimal fixed-point implementation. The proposed solution might be enough for high-end database servers but not would helpful for x86 and ARM type embedded processors, where power savings for would be allowed by turning off the binary exponential processor as well as improved accuracy. For existing binary exponent types (float, double and long double), I think there should be new format string type (e.g “-123U-12”). This has a signed integer significand and a signed integer binary exponent. The significand cannot have decimals (no decimal point). Those IEEE 754 formats can indicate “Inf” and “NaN” as well (numeric_limits::is_iec559). There is no conversion error from binary exponent to decimal as is suffered currently. The new decimal types use a opaque arrangement. This allows each platform to use its own hardware to best effect. Each value is defined as a fixed number of decimal points. The significand grows or shrinks opaquely to take any value and can change how it works for each type. The fixed number of decimal points can be over the thousands before or after the decimal point. Thus the range of the decimal fixed points will be the same or more than those for decimal exponent types (-6143..6144). The significand has a least maximum 34 digits, again to match for decimal exponent - probably at least 38.23 for 128-bit significand. The method of keeping the significand can change with size and processor. For instance, 32-bit binary is fast on 32-bit processors (or 64-bit native binary). 30-bit (9 digit) or 10-bit (3 digit) decimal can grow (BigDecimal) for thousands of digits. IEEE 754 2008 decimal exponent types for IBM processors (also 10-bit groups of 3 digits) but slow without hardware support. Much of the work of exact decimal are similar to the SQL-92 types for NUMERIC (variable decimal places) and DECIMAL (fixed-point decimal) differ by variable or fixed decimal point. The NUMERIC type is similar to decimal exponent. The DECIMAL fixed-point decimal can be set by template or constructor. Only run-time decimal places available for NUMERIC. We don’t limit the number of decimal places but the SQL-92 types limit decimal places to 0 and number of digits (MySQL 5.0.3 supports 65 digits for NUMERIC and DECIMAL and DB2 supports 31 digits.) Accumulators There should be _Accum that can opaquely contain several decimal fixed-point accumulators of all different sizes (with the same fixed number of decimal points). Thus small efficient accumulators are used with small values. Whereas a _Decimal has a union defining the value, a _Accum might have a structure with similar members. If a overflow comes, its old accumulator value is added the to a slower bigger accumulator and reset the small accumulator. The small accumulator receives small values again. When the values are accumulated, the small accumulators are combined into the largest used accumulator for the final answer. Such a complicated behaviors arrangement needs compilation rather than C++ coding. For instance, using the overflow flag uses information from to the compiler. Operations We are only interested in (commercial) safe exact decimal operations for the following types: _Numeric: decimal exponent _Decimal: decimal fixed-point _Accum: several sized decimal fixed-point accumulators Multiply The exact decimal can be multiplied by other exact decimals and integers. The resulting decimal places are the sum of the right hand side. lhs = one * two; lhs *= integer; // or 0 decimal place Divide We can only divide by integers (or exact decimal with 0 place). The results have the same number of decimals. A divisor of zero will be thrown (no infinity). lhs = rhs / integer; lhs /= integer; Modulo There will be a remainder from a divide. Again with the same number decimals. lhs = rhs % integer; lhs %= integer; Add and Subtract We can add/subtract with other exact decimals with the same number of decimal places. Mixing values with different decimal places may cause problems for exact values (different truncation for instance). lhs = rhs + val; lhs = rhs - val; lhs += val; lhs -= val; Where values with different decimal places need combining explicitly we use trunc() to match the decimal places first. This can increase as well as decrease decimal places. It also allows tracks of errors. Comparison <, <=, ==, !=, >= and > between exact decimals with the same number of decimal places. Collections Any _Decimal collection can be limited to values with the same decimal fixed-point places. Truncation The binary exponent values float, double and long double have separate approximate values 1.3f, 1.3 or 1.3L for different sizes. I propose another exact decimal value, for example 1.300d for three decimal places. Alternatively use exact decimal exponent 1300e-3d version (using integer significand). Value Approximation 1.3f - 1.2999999523162841796875.. 1.3 - 1.3000000000000000444089209850062616169452.. 1.3L - 1.3000000000000000000000000000000000385185.. 1.300d or 1300e-3d - 1.300 (exact) Where a value is not the precision, we must expand or truncate to required decimals places and should choose a method of truncation (matched to IEEE 754-2008): ceil - the most negative answer not less than the original floor - the most positive answer not greater than the original zero - the answer furthest from zero not further than the original (the usual C method) round - the answer nearest the original choosing the most positive in case of a tie bank# - like round but choosing the even last digit in case of a tie expand - not truncation (zero padding) and the error should be zero As well as tructaton is then required value, there were be a leftover (similar in % value with a /). By keeping a record of truncation we can assess of errors. template <typename T> _Decimal & _Decimal::trunc(TRUNC, T const &source, T *error = 0); This will be a preferred way to convert binary exponent types into a decimal value for printing. Formatting For place 0 decimal format like integer and between places 1 and 9, the format will be decimal and trailing zeros are significant. Otherwise with the default format will be a exponent (matched to the decimal) with a integer significand. They will resemble binary float types, except that they are accurate and avoid decimals in the significand. 123 (0 decimal place so no decimal point) -0.012340 (6 decimal places) -12340e-12 (12 decimal places or decimal exponent -12) Final number formatting will be up to Boost.Locale using Unicode.

2 1

Range notation grammar
by Dave Abrahams 29 Jun '12

29 Jun '12

This ship has undoubtedly sailed, but I'd like to register my displeasure with names like "uniqued," "taken," and "strided" et. al. The effect (subjectively of course) is to take a beautiful, minimal abstract notation that reflects a common practice (seriously, it's "grep," which is a verb, not "grepped") and mess it up with unconventional and awkward linguistic insurance against misunderstanding. this-has-been-a-test-of-the-emergency-nattering-system-ly y'rs, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 3

date_time bug.
by GAURAV GUPTA 29 Jun '12

29 Jun '12

Hi All, I have reported one bug: Ticket No:7022. (Link is https://svn.boost.org/trac/boost/ticket/7022 ) As I have tracked. the owner (you can see it on ticket information) assigned to my ticket is not active. I have not found any posts by him newer that year 2007. So, could anyone help in verifying my patch for the reported bug?. I found this bug using some tool. Please reffer the ticket No. 7022 -- Regards, Gaurav

2 4

[review] status of Boost.Conversion?
by Nathan Ridge 29 Jun '12

29 Jun '12

Hi, I am wondering, what is the status of the Boost.Conversion library? On the Review Schedule page, it indicates that a review had taken place in August 2011 and the results of the review are "pending". Does anyone when the results will be forthcoming? Thanks, Nate

4 7

JNI library
by Felipe Magno de Almeida 28 Jun '12

28 Jun '12

Hello Boosters, I'm developing a JNI library for writing native code in C++ for Java and calling Java code within C++, using JNI as interface to the JVM. Is there any interest in this library? Regards, -- Felipe Magno de Almeida

3 10

[Survey] utf8_codecvt_facet::do_length parameter
by Marshall Clow 28 Jun '12

28 Jun '12

There's some confusion in boost (and in various standard libraries) as to the declaration of std::codecvt<>::do_length The '03 and '11 standards say: > template <class internT, class externT, class stateT> > class codecvt : public locale::facet, public codecvt_base { > // blah blah blah > virtual int do_length(stateT&, const externT* from, const externT* end, size_t max) const; > }; But some standard libraries (notably older Dinkumware libraries, and Visual C++ before Visual Studio11) say: > virtual int do_length(const stateT&, const externT* from, const externT* end, size_t max) const; (the first parameter is a const reference) There's some preprocessor stuff to deal with this in boost/detail/utf8_codecvt_facet.hpp, but it's wrong: > #if !defined(__MSL_CPP__) && !defined(__LIBCOMO__) \ > && !defined(_LIBCPP_VERSION) > #define BOOST_CODECVT_DO_LENGTH_CONST const > #else > #define BOOST_CODECVT_DO_LENGTH_CONST > #endif > > virtual int do_length( > BOOST_CODECVT_DO_LENGTH_CONST std::mbstate_t &, > const char * from, > const char * from_end, > std::size_t max_limit > #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) > ) const throw(); > #else > ) const; > #endif I'm happy to fix this, but I'd like to be sure which systems actually have const parameters. I've checked gcc and libc++, and they match the standard. STL assures me that all versions of Visual Studio before VS11 do not match, but VS11 does. The #defines above suggest to me that LibCOMO has this problem as well. Does anyone have access to such an install? And if anyone's standard library (that I haven't listed) does define the first parameter to std::codecvt<>::do_length as a const reference, please let me know. Thanks! -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[1.50.0] Release candidate 2 available for testing
by Beman Dawes 28 Jun '12

28 Jun '12

Release candidate 2 files for 1.50.0 are available at http://boost.cowic.de/rc/ RC 2 is supposed to fix the --layout build problems reported for RC 1. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

7 7

[chrono] chrono/config.hpp enforces that time.h defines CLOCK_REALTIME; should it?
by Krzysztof Czainski 28 Jun '12

28 Jun '12

Hello, Suppose I want to use durations, and time_points with a user defined clock. I don't want to use any clocks provided by Boost.Chrono. My compiler provides a <time.h>, which doesn't define CLOCK_REALTIME, which chrono/config.hpp reports as an error. This prevents me from using parts of Chrono, that I believe don't depend on anything from <time.h>. I am able to work around this by simply defining CLOCK_REALTIME. But I would like to ask: Could Boost.Chrono allow using duration.hpp and time_point.hpp in my case? Regards, Kris

2 3

Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION
by Brian Wood 27 Jun '12

27 Jun '12

Emil Dotchevski: > On Tue, Jun 26, 2012 at 10:24 AM, Brian Wood <woodbrian77(a)gmail.com> wrote: >> >> Is there a penalty for single threaded applications here? There's >> been discussion of the support for transferring exceptions between >> threads; are there aspects of that support that are unneeded in a >> single threaded context? >> > > There are 3 aspects of boost::throw_exception: > > 1) it enables libraries to support BOOST_NO_EXCEPTIONS configurations, > 2) it enables boost::error_info, and > 3) it enables boost::exception_ptr. > > 1) and 2) have nothing to do with threads; 3) implements > std::exception_ptr, which mostly benefits multi-thread programs (until > compilers catch up with std::exception_ptr support.) > > The cost imposed by libraries that use boost::throw_exception to programs > that don't use boost::exception_ptr or boost::error_info is that sizeof() > the exception object grows a little. I'd appreciate a way at compile time to let Boost Exception know I'm using it in a single threaded application and it wouldn't add stuff to the exception object that isn't needed. Also MSDN says, "Most applications do not have to transport exceptions between threads." Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

3 2

Re: [boost] program options (consider using BOOST_THROW_EXCEPTION)
by Leo Goodstadt 27 Jun '12

27 Jun '12

> On 22 June 2012 17:51, Vladimir Prus <ghost(a)cs.msu.su> wrote: > > > On 22.06.2012 11:33, Emil Dotchevski wrote: > > > >> On Thu, Jun 21, 2012 at 11:44 PM, Vladimir Prus<ghost(a)cs.msu.su> wrote: > >> > >> On 20.06.2012 07:44, Rowan James wrote: > >>> > >>> On a related note; is there interest in a patch set to use > >>>> BOOST_THROW_EXCEPTION to add this (yes, programmer-oriented) information > >>>> to > >>>> the exceptions thrown by Program Options and/or other Boost libraries? > >>>> > >>>> > >>> Sorry, but I kinda miss context here (and I did read your original post). > >>> What are advantages of > >>> using BOOST_THROW_EXCEPTION and what are drawbacks? Could you summarize > >>> those for me? > >>> > >>> > >> Allow me :- > >> > >> BOOST_THROW_EXCEPTION, being a macro, is able to record the file name, the > >> function name, and the line number of the throw, which is useful when > >> diagnosing unexpected exceptions: > >> > >> catch(...) > >> { > >> std::cerr<< "Unexpected exception caught. Diagnostic information > >> follows.\n"; > >> std::cerr<< boost::current_exception_**diagnostic_information(); > >> } > >> > >> The exception object is examined dynamically for any and all useful > >> information: type, what(), throw location, any stored boost::error_info > >> objects, etc. The location of the throw (if available) is formatted in a > >> way Visual Studio understands: double-clicking shows the throw location, > >> similarly to double-clicking compile errors. > >> > >> The downside is that when templates are involved, BOOST_CURRENT_FUNCTION > >> (invoked by BOOST_THROW_EXCEPTION) can bloat the code. There is a Trac > >> ticket for this. > >> > > > > Emil, > > > > thanks for explaining. Given the above, I am not sure I am interested in > > using > > BOOST_THROW_EXCEPTION for program_options, given that exceptions are used > > there to report > > user mistakes mostly, and so function name or file line is of limited > > interest. > > > > Thanks, > > Volodya > > > Thanks Emil. > > If I can make the case in favour of BOOST_THROW_EXCEPTION, it is for the > very reason that they are reporting user mistakes. The throw location for > an exception is typically accompanied by, or at least close to, the logic > that delineates such a user mistake from acceptable input. As such, it is > a useful remedy in itself; but also gives the user specific information for > finding documentation relevant to fixing the error. Without it, we have at > best the entry point into the library that; and often a lot less if the > exceptions are caught at a higher level. > > Documentation for valid inputs or states to a function can only say so much > about all the possible errors or exceptions that may occur. To elaborate on what Volodya said, program_options is unusual (for Boost) library in its use of exceptions: Most of the time, exceptions are there to inform the programmer of an error in the programme. However, the majority of exceptions in program_options are there to indicate a problem in the construction of the command line by the *end-user* (not the programmer). In other words, the program *is* working exactly as designed. The programmer has no interest in the provenance of these exceptions *except* that they can be used to inform the end-user how they should retype the command line and try again. So, for example, ten times a day, I will type something like ls --colour * and ls will tell me ls: unrecognized option '--colour' and I will know to retype the US spelling... ls --color * If "ls" were using program options, an unrecognised option exception message will be thrown which eventually allows this informative message to be displayed before exiting. It is entirely unhelpful for the end-user to have Exception XXX on line xxx of file yyy.... To make it easier to use program options *in English*, the exception messages have been recently rewritten to be maximally informative to the end-user rather than the programmers. Thus we can take e.what() and write it out to std::cerr without further ado. Of course, for localisation, these error messages have to be reconstructed in the appropriate language. Hopefully, there is enough data in each exception to allow this. Curiously, the current design of exceptions in program_options ended up try to mirror what Emil has done in BOOST_THROW_EXCEPTION. When the exception is thrown deep in the bowels of the command line parsing, it does not have the full context which would allow an informative message to be constructed. The exception has to be propagated up, and then "decorated" before being rethrown. The alternative was to pass the full context down the function call hierarchy to each point at which exceptions can be thrown. This made the code horribly convoluted and ugly, and provoked loud cries of anguish from Volodya. Leo

5 4

Interest in static multidimensional array.
by Brian Smith 27 Jun '12

27 Jun '12

Hi All, Some time ago I uploaded the maps folder, to Boost's sandbox, containing various multidimensional and mathematical arrays. The resulting discussion appeared to indicate some interest in the multidimensional arrays and that the overall design required some reworking. Having now had the opportunity to use a compiler supporting variadic templates, I have rewritten the static multidimensional array class using them. The class, documentation, and some tests are available at, https://github.com/BrianJSmith/Array All feedback would be welcome. Regards Brian -- www.maidsafe.net

2 2