- Boost - lists.boost.org

problem with BOOST_PP_IS_EMPTY macro
by Serguei KOLOS 22 Feb '06

22 Feb '06

Hello Using the BOOST_PP_IS_EMPTY macro with string literal as parameter causes compiler warning: warning: pasting "BOOST_PP_IS_EMPTY_DEF_" and ""AA"" does not give a valid preprocessing token In order to avoid this warning I have reimplemented this macro as it is shown below. Could something similar be implemented by the preprocessor library. Cheers, Sergei #include <boost/preprocessor/if.hpp> #include <boost/preprocessor/tuple.hpp> #include <boost/preprocessor/facilities/is_empty.hpp> #define MY_BOOST_PP_IS_EMPTY(x) MY_BOOST_PP_IS_EMPTY_I(MY_BOOST_PP_IS_EMPTY_HELPER x) #define MY_BOOST_PP_IS_EMPTY_I(contents) MY_BOOST_PP_IS_EMPTY_II( contents() ) #define MY_BOOST_PP_IS_EMPTY_II(contents) MY_BOOST_PP_IS_EMPTY_III( contents ) #define MY_BOOST_PP_IS_EMPTY_III(contents) BOOST_PP_TUPLE_ELEM( 2, 0, ( MY_BOOST_PP_IS_EMPTY_DEF_ ## contents ) ) #define MY_BOOST_PP_IS_EMPTY_HELPER() MY_BOOST_PP_IS_EMPTY_TRUE #define MY_BOOST_PP_IS_EMPTY_DEF_MY_BOOST_PP_IS_EMPTY_TRUE 1 , #define MY_BOOST_PP_IS_EMPTY_DEF_MY_BOOST_PP_IS_EMPTY_HELPER 0 , #define TEST_CASE_1( x ) BOOST_PP_IF( BOOST_PP_IS_EMPTY( x ), is empty, x ) #define TEST_CASE_2( x ) BOOST_PP_IF( MY_BOOST_PP_IS_EMPTY( x ), is empty, x ) TEST_CASE_1( "" ) TEST_CASE_1( "AA" ) TEST_CASE_1( AA ) TEST_CASE_1( ) TEST_CASE_2( "" ) TEST_CASE_2( "AA" ) TEST_CASE_2( AA ) TEST_CASE_2( )

3 5

on reflection
by Neal Becker 22 Feb '06

22 Feb '06

http://freshmeat.net/releases/220506/

1 0

[multi_index][cw-8_3] help request for regressions in CW 8.3 Windows
by Joaquín Mª López Muñoz 22 Feb '06

22 Feb '06

Hello, Most current tests for Boost.MultiIndex under CW 8.3 in Windows fail at run time with the following: Running 1 test case... unknown location(0): fatal error in "test_main_caller( argc, argv )": unknown type *** 1 failure detected in test suite "Test Program" EXIT STATUS: 201 (see for instance http://tinyurl.com/fqarz) compilation and building having gone fine. As this is giving very little info, I'd be grateful if someone with local access to CW 8.3 Windows (it is likely that Mac will also do) volunteer to do some exploration of the problem. If you are such volunteer, please contact me privately. Thank you very much, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[docs] icons for common questions
by Thorsten Ottosen 22 Feb '06

22 Feb '06

Hi, Maybe it was an idea to have icons to show - on the list of libraries - in the opening page of each library that quickly reminds the user that - the library supports serialization - the library supports no exceptions Too pop-smart? -Thorsten

4 3

Fonts in in_place_factories.html
by David Abrahams 21 Feb '06

21 Feb '06

For some reason the code in this file displays in a bitmapped font on my screen, and doesn't scale well. My preferred fixed-width font looks great; why is this file choosing an ugly one for me? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

[preprocessor] Patch for stringize.hpp
by Steve Cornett 21 Feb '06

21 Feb '06

The file boost/preprocessor/stringize.hpp contains a trivial bug, for which I have attached a proposed patch. The problem is that there are three incorrect usages of the ## operator. The proposed fix is to simply remove the ## operators, as they are unnecessary. The ## operator joins two tokens and makes a new single token. But all three usages of ## in this file attempt to join an identifier with '(', which does not result in a single token. The action taken by most C/C++ translators in this situation is to rescan the invalid text back into two tokens, which makes the incorrect ## usage innocuous in most situations. However, the behavior is undefined by the C++ and C standards. With our code coverage tool, this improper ## usage results in a warning. *** stringize.hpp.orig Fri Feb 17 10:16:41 2006 --- stringize.hpp Fri Feb 17 10:18:36 2006 *************** *** 20,30 **** # # if BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC() # define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_A((text)) ! # define BOOST_PP_STRINGIZE_A(arg) BOOST_PP_STRINGIZE_B ## (arg) ! # define BOOST_PP_STRINGIZE_B(arg) BOOST_PP_STRINGIZE_I ## arg # elif BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MWCC() # define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_OO((text)) ! # define BOOST_PP_STRINGIZE_OO(par) BOOST_PP_STRINGIZE_I ## par # else # define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_I(text) # endif --- 20,30 ---- # # if BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC() # define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_A((text)) ! # define BOOST_PP_STRINGIZE_A(arg) BOOST_PP_STRINGIZE_B(arg) ! # define BOOST_PP_STRINGIZE_B(arg) BOOST_PP_STRINGIZE_I arg # elif BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MWCC() # define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_OO((text)) ! # define BOOST_PP_STRINGIZE_OO(par) BOOST_PP_STRINGIZE_I par # else # define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_I(text) # endif

3 11

[ptr_container] help needed with wierd codewarrior problem
by Thorsten Ottosen 21 Feb '06

21 Feb '06

In all it's glory, http://tinyurl.com/7ht55 Or in verbatim here: Error : illegal non-type template argument (point of instantiation: 'test_ptr_vector()') (instantiating: 'boost::ptr_vector<int, boost::heap_clone_allocator, std::allocator<void *>>') (instantiating: 'boost::ptr_sequence_adapter<int, std::vector<void *, std::allocator<void *>>, boost::heap_clone_allocator>') (instantiating: 'boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<int, std::vector<void *, std::allocator<void *>>>, boost::heap_clone_allocator>') ../boost/ptr_container/ptr_sequence_adapter.hpp line 141? CloneAllocator > Could there some wierd source character that I can't see or something? Thanks -Thorsten

2 1

Operating System API Error Reporting Guidelines
by Beman Dawes 21 Feb '06

21 Feb '06

Each Boost library that calls operating system API's seems to deal with API error reporting in its own way. That's hard on users, and doubly so if a particular library's approach doesn't easily support a needed use case. Boost.Filesystem certainly had that problem, and users reported having to litter their code with try/catch blocks to cope with it only supporting error-reporting-by-exception. I think the two-pronged approach Boost.Filesystem finally settled on might work well for other library's too. I've written it up as a general guideline. See attached. Do other Boosters like the idea of an overall guideline for dealing with operating system API error reporting? Do the specific guidelines make sense? How can they be improved? Comments welcome, --Beman Operating System API Error Reporting Guidelines Introduction Operating system application program interface (API) functions may encounter errors. How should these errors be reported by Boost Library functions that use the operating system API? Guidelines Unless otherwise specified, the default versions of all Boost library functions, except destructors, that call operating system API functions should check for API errors and report the occurrence of such errors by throwing an exception of type boost::system_error. Such functions should also have an overload that takes an additional argument of type boost::system_error_code& ec. The behavior of this overload is the same as the non-overloaded version, except that it does not throw an exception on an API error, and it sets ec to the error code reported by the operating system, or to 0 if no error is reported. For functions where the non-overloaded version returns void, the overloaded version returns an object of type boost::system_error_code with the same value that ec was set to. The problem The traditional C approach to error reporting followed by many operating systems is for the API function to indicate failure by returning an out-of-range value, and to set a global variable with an error code indicating the particular error condition. API functions that do no return an out-of-range value just set the error code global. These C error reporting idioms are viewed with distaste by C++ programmers: * It is far too easy and common for programmers to ignore error returns. * Global variables are dangerous. * It is difficult in reading code that ignores errors to know if lack of checking was done for a well-founded reason or simply by mistake. * Checking for errors obscures otherwise clean code. * Requires error checking be done immediately even though the most logical place to deal with errors may be higher up in the call chain. * Because the mechanism for reporting errors isn't uniform, coding errors are a concern as is the need to refer excessively to documentation. One possible C++ approach is to throw an exception whenever an operating system API error occurs. The exception can capture the particular error code from the operating system, or a fine-grained exception hierarchy can provide a type for each possible error code. This approach solves all of the problems of the tradition C approach, but suffers from the usual problems associated with exceptions: * Very time inefficient (factor of 1000 not uncommon) compared to error returning codes via return statement. * Clutters code with try/catch blocks when errors must be dealt with immediately. * May be totally inappropriate in some contexts (particularly destructors). * Is the wrong idiom when errors are commonplace and unexceptional. Traditionally, when C++ developers don't feel exceptions are appropriate for API error reporting, they take several approaches: * Unconditionally ignore the error. * Provided a nothrow overload that ignores the error. * Fallback to the errno approach. None of these is entirely satisfactory, and the lack of uniformity between libraries is a user irritation. Rationale The default version of library functions, without the additional argument, throws on errors, ensuring that error checking cannot be ignored and covering the important use case where error reporting via exception is the preferred mechanism. The overloaded version of library functions, with the additional boost::system_error_code& argument, covers both the use case where errors are best ignored, and the use case where errors are best reported directly rather than by exception. Making error-reporting-by-exception uniformly the default, without any attempt to prejudge the most commonly usage case, aids learning and avoids endless arguments over which approach is "best". Providing both error-reporting-by-exception and error-reporting-by-error-code ensures common use cases are accommodated, and moves the decision as to which to use from the library designer to the library user. Returning a copy of the error code, in the case of functions that otherwise would otherwise return void, results in cleaner user code. No doing so in the case of functions already returning a value keeps the interface simple. History Experience with the Boost.Filesystem library led to the conclusion that both error-reporting-by-exception and error-reporting-by-error-code are important, and which is best is highly context dependent. _________________________________________________________________ Revised 17 Feb 2006 Â© Copyright Beman Dawes 2006 Distributed under the Boost Software License, Version 1.0. (See accompanying file [1]LICENSE_1_0.txt or copy at [2]www.boost.org/LICENSE_1_0.txt) References 1. file://localhost/C|/boost/site/LICENSE_1_0.txt 2. http://www.boost.org/LICENSE_1_0.txt

9 26

Formal Review Request - PQS physical quantities system
by Andy Little 21 Feb '06

21 Feb '06

PQS Physical Quantities System, is now in a reasonably complete state, so I hereby request a Formal Review. pqs is designed to simplify modelling physical-quantities in C++ programs. The library will eventually include 3 related types: t1_quantity where the dimension and units are fixed. t2_quantity where the dimension is fixed but the units can be modified at runtime. t3_quantity where the dimension and units can be modified at runtime. Thie subject of the Formal Review will be the t1_quantity - the first to be implemented. *t1_quantity features* The t1_quantity is a C++ representation of a physical_quantity with the dimension and units fixed at compile-time. The t1_quantity has many similar features to an inbuilt-type... * Concrete type with simple, consistent semantics close to those of built-in types. * Can match speed and code size performance of built-in types, while being much more user-friendly to work with. * Requires no special framework to use ... but with added functionality: * Strong type checking enforces dimensional integrity, catching calculation errors at compile time. * Automated unit conversion reduces drudgery. * Being self documenting using pqs helps code clarity. * Increases programmer satisfaction and enhances productivity. The latest version is pqs_3_0_6, which is available as a .zip from the 'Physical Quantities Units' subdirectory in the Vault. Try this tinyurl as a shortcut to downloading pqs: http://tinyurl.com/7m5l8 The library has been tested (successfully) on the following compilers: VC7.1, VC8.0, GCC3.2, GCC4.0. Assuming this review request is successful I am looking for a review manager to supervise the review process. Heres a quick reminder of the Noble and Outstanding qualities required of this fine position: http://www.boost.org/more/formal_review_process.htm#Review_Manager I have spent a fair amount of time on the documentation, with styling courtesy of the Quickbook guys and very nice it is too (the styling that is). I would appreciate feedback on the content and presentation of the documentation especially, as a part of the rationale behind pqs is to provide a common specification ,and to make code self documenting thus reducing the need for extensive in-house documentation of source code. Is the documentation easy to understand? Is it adequately laid out? Is the layout comprehensible? Can you find the information you want easily? Is there any information lacking? Are there enough examples? Is the technical section acceptable? I would sure appreciate any comments or guidance on improving the documentation, especially from authoritative sources. Comments on the design and use of the library will also be generously accepted, together with suggestions for improvements and enhancements. The library comes complete with a selection of useage examples in the usual <libs/pqs/examples/> directory as well as tests in <libs/pqs/tests/> regards Andy Little

2 2

[wave] [v2] V2/1.34: Problems with testwave_dll
by Reece Dunn 21 Feb '06

21 Feb '06

Hi Hartmut/Volodya, I have been running v2 regression tests which build in debug mode by default. When the testwave_dll test runs, msvc-7.1 generates a debug assert somewhere in the dbgheap CRT memory allocation routines. However, if I copy the wave, program options and filesystem DLLs (rtti-off, runtime-link-static versions) into the testwave_dll directory, the problem went away. It is generally recomended to use the runtime-link-shared version of the CRT libraries if they are being used across an application and several DLLs. - Reece

1 0