December 2010 - Boost - lists.boost.org

Re: [boost] [filesystem] temp_dir_path()
by Domagoj Saric 21 Feb '11

21 Feb '11

"Beman Dawes" <bdawes(a)acm.org> wrote in message news:AANLkTinFigAxpqkbgwQCnOXrr-Jg44=_dep1QWn+hy-Z@mail.gmail.com... > On Tue, Oct 19, 2010 at 3:35 AM, Domagoj Saric <dsaritz(a)gmail.com> wrote: >> Would it be perhaps possible to provide a lower-level function (even in >> the detail namespace) that uses a plain char buffer and an error code, >> that is free of std::vectors, std::strings, boost::paths, >> system::error_codes and >> other things one might not want to pay for (especially if one does not >> use them otherwise) just to make a system API call..? The 'proper' >> version can then wrap the thinner one... > > It would be technically possible, of course, but ... > > What you are really asking for, I think, is a C language interface or > something pretty close to that. The attitude/assumption that anything C++ must implicitly become intimate with the keywords new, virtual and throw otherwise it is actually 'only C' is just plain wrong in the fullest sense of the word: - it is wrong 'factually' not only because (most of) C is a subset of C++ but because it is quite possible to do heavy C++ programming (e.g. so heavy that it causes GCC 4.2.1 to allocate tens of gigabytes of RAM before it eventually kills the entire OS) practically without using any of the before mentioned STL 'goodies'... - it is wrong 'morally' because it is guilty of the typical 'premature pessimization' that feeds the typical anti C++ and anti Boost arguments...IOW Linus will no longer have to ask 'How many memory allocations does it take a C++ programmer to concatenate two strings?' but 'Guess how many tens of kilobytes will calling boost::temp_dir_path() add to your binary?' The 'plain char buffer' can also be understood in a more 'relaxed'/'broader' way to for example also encompass a, more C++ like, iterator_range that specifies a preallocated chunk of storage... > I could have designed the library that way, but didn't want to add a > third way for users to do things, and didn't want to take on the > increased documentation, test, etc, workload. Calling it a 'third way' is bit too hard IMO, why not think of it just as an overload (albeit of a more extreme kind)? -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

3 2

[C++0x] Emulation of scoped enums
by Beman Dawes 16 Feb '11

16 Feb '11

The improved type safety of the C++0x scoped enum feature is attractive, so I'd like to start using it as it becomes available in compilers. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a description. Note that the committee changed the name from strongly typed enums to scoped enums. See the attached for a boost/detail header that provides macro wrappers that use scoped enums if available, otherwise fall back on C++03 namespaces and unscoped enums. It lets a library write: BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END ... BOOST_SCOPED_ENUM(algae) sample( algae::red ); void func(BOOST_SCOPED_ENUM(algae)); and then a user can write: sample = algae::green; func( algae::cyan ); Comments or suggestions appreciated, --Beman // scoped_enum_emulation.hpp ---------------------------------------------------------// // Copyright Beman Dawes, 2009 // Distributed under the Boost Software License, Version 1.0. // See http://www.boost.org/LICENSE_1_0.txt // Generates C++0x scoped enums if the feature is present, otherwise emulates C++0x // scoped enums with C++03 namespaces and enums. The Boost.Config BOOST_NO_SCOPED_ENUMS // macro is used to detect feature support. // // Caution: only the syntax is emulated; the semantics are not emulated and // the syntax emulation doesn't include being able to specify the underlying type. // // See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a // description of the feature. Note that the committee changed the name from // strongly typed enums to scoped enums. // // Sample usage: // // BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END // ... // BOOST_SCOPED_ENUM(algae) sample( algae::red ); // void foo( BOOST_SCOPED_ENUM(algae) color ); // ... // sample = algae::green; // foo( algae::cyan ); #ifndef BOOST_SCOPED_ENUM_EMULATION_HPP #define BOOST_SCOPED_ENUM_EMULATION_HPP #include <boost/config.hpp> #ifndef BOOST_NO_SCOPED_ENUMS # define BOOST_SCOPED_ENUM_START(name) enum class name # define BOOST_SCOPED_ENUM_END # define BOOST_SCOPED_ENUM(name) name #else # define BOOST_SCOPED_ENUM_START(name) namespace name { enum enum_t # define BOOST_SCOPED_ENUM_END } # define BOOST_SCOPED_ENUM(name) name::enum_t #endif #endif // BOOST_SCOPED_ENUM_EMULATION_HPP

14 27

Stack-based vector container
by Gregory Crosswhite 30 Jan '11

30 Jan '11

Hey everyone, In the course of my work as a computational scientist I have written a container that emulates std::vector, but which is backed by an array whose size is fixed at compile time. Concretely, the class looks something like the following: template<typename T,unsigned int buffer_size> class static_vector { ... protected: T data[buffer_size]; T* end_ptr; size_t current_size; } where in the [...] there are methods that emulate (at this time, partially) the interface of std::vector, save that the size of the static_vector is not allowed to grow beyond the buffer_size. The advantage of using a static_vector over vector is performance. In my code I have performed benchmarks that show up to a 30% performance boost of static_vector over vector; the benefit occurs most stongly when working with lots of arrays of small objects, so that the use of dynamic memory rather than stack memory appears to add significant overhead to the computation. (Note that I when running these benchmarks I would use std::vector::reserve() to pre-allocate the array so that std::vector would not perform multiple allocations as the container grew, so that should not have been a source of overhead.) It seems to me that it would be useful to have this functionality generally available as a library, and in particular it might be a good fit for the boost family of libraries. Is there any interest out there for having such a library in boost? If so, I would be happy to do the work of taking what I have and fleshing it out so that it can function as a drop-in replacement for vector, which means modeling the Random Access Container and Back Insertion Sequence concepts as well as adding capacity() and reserve(size_t) (no-op) methods. Thoughts? Cheers, Gregory Crosswhite

17 53

GIL io_new review
by Phil Endecott 30 Jan '11

30 Jan '11

Back in 2006 I had some code that used ImageMagick's Magick++ library to read and write images in various formats and do some basic processing. That library works well and is very feature-full, but is not what you would call "Boost like", so I was excited when GIL came along. I looked at it at the time of its review, and I thought at first that I must have missed a big chunk of the documentation where all the algorithms were described! Of course, it has no image processing algorithms; it's just a layer; if you want to scale or rotate or merge images, you have to do that yourself. I don't think I wrote a review in the end; my feeling was - in comparison with ImageMagick - "come back when you've finished" - but I didn't want to say that in public. So it's great that now, 4 years later!, we are finally getting some GIL extensions. Thank you Christian for - I hope! - getting the ball rolling. I hope we'll see more. Having said that, I suspect that even with lots of extensions GIL might not really be what I need. Here's a typical problem that I will have to address in the next few weeks: I have a 1e12 pixel image - a map - which is supplied as a few thousand 5000x5000 TIFF tiles; I have to join them together, tweak the colours, draw some lines on top, and re-chop it into a few million 256x256 PNG tiles. The issue of course is that that image can't be held in RAM. I will do this with my own wrappers around libtiff and libpng, in rows or chunks. So, do the image concepts (and concrete classes) that GIL defines accommodate that sort of problem? Even if they do, is a "virtual image" of some sort a good way of doing it? I suspect not. But even if the image concept is not useful, presumably other GIL concepts like pixel formats and algorithms in future extensions (pixel format conversion, blending) could still be useful. So, along comes Christian's IO extension. Wrapping the "legacy" image libraries is something that I have done a few times now and it can be painful, not least because of the need to read a lot of documentation; the libraries all differ and it would be great to get a unified set of wrappers that provide a sane C++ interface. But as you can see, I don't really want something that reads and writes complete GIL images, and that is what Christian's extension does. Ideally, this extension would have separated out the wrapping of the libraries from the actual GIL image integration, with the GIL image integration just being a layer on top of the image library wrappers. Since it doesn't do that, it's not much use to me. It is, however, better than what GIL currently has. So for that reason I suggest that it should be accepted. > - What is your evaluation of the design? In addition to my comments above, I note that it's necessary to jump through hoops (using Boost.IOStreams) just to read an image from memory. Surely this should be a fundamental operation; it would be much better to have a ctor that takes begin and end pointers for the encoded image data. > - What is your evaluation of the implementation? When I first looked at the library I noticed that the error handling was clearly broken. Although that seems to have been resolved, it has given me a poor impression of the quality (i.e. likely correctness) of the implementation. It seems that this error handling has received almost no testing. Thorough testing will be difficult for this library because as well as all the usual permutations of platform features, compilers etc. the variations in the image libraries must also be considered. The library version and compiler settings could both affect the correct operation of this code. I have some concerns about the likely performance of the code due to excessive copying of the data both in and out of the image library. Although I've not measured the performance impact, I feel it would be very desirable (and is certainly possible) for this library to have zero copying. > - What is your evaluation of the documentation? Satisfactory. (As a meta-comment - I think libraries being reviewed really should have their docs available online somewhere, and preferably also their source code in a source browser of some sort. In fact, I thought this was already a requirement. Can it be added to the review managers' checklist for future reviews?) > - What is your evaluation of the potential usefulness of the extensions? It's better than what was there before. > - Did you try to use the extensions? With what compiler? Did you have > any problems? No, I've not compiled anything. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? Probably half a day during the review, and a similar amount of time a few months ago. > - Are you knowledgeable about the problem domain? I've written a few wrappers for libjpeg, libpng and libtiff. I've never used GIL though I've read extensively about it. > And finally, every review should answer this question: > - Do you think the extensions should be accepted as a part of Boost.GIL > library? On the grounds that this is better than what is currently there, and on the assumption that Domagoj Saric is not imminently going to post something else that would supersede this, I believe that it should be accepted. (I have not looked at the "toolbox" at all, and I've not seen it mentioned in any other reviews yet. My "yes" is just for the io_new functionality.) Regards, Phil.

7 39

[gil][io_ew] performance test
by Christian Henning 30 Jan '11

30 Jan '11

Hi there, I did a little performance test of io_new vs io2. The code is here. http://pastebin.com/eCeFZuMS On my machine io_new runs in 1.15sec for 2658 jpegs. IO2 run in 1.005sec. All jpegs are the same image but they are a different file. This way I'm sure I don't have to convert the image into a different color space. I did that since io2 doesn't support any_image, I believe. Thanks, Christian

3 5

[SQL-Connectivity] Is Boost interested in CppDB?
by Artyom 25 Jan '11

25 Jan '11

Hello, I have recently released a new SQL Connectivity library: General ------- Documentation : http://art-blog.no-ip.info/sql/cppdb/ Mirror Docs. : http://cppcms.sourceforge.net/sql/cppdb/ Download : https://sourceforge.net/projects/cppcms/files/cppdb/ Features -------- - Performance is the primary goal - make fastest possible SQL connectivity as possible - Transparent connection pooling support - Transparent prepared statements caching - Dynamic DB modules loading and optional static linking - Full and high priority support of FOSS RDBMS: MySQL, PostgreSQL, Sqlite3 - Support as many RDBMSs as possible via cppdb-odbc bridge - Simplicity in use - Locale safety - Support of both explicit verbose API and brief and nice syntactic sugar What it is not: --------------- This is not ORM library and not supposed to be so. This is something similar to what JDBC gives to JDK and QtSql gives to Qt and more. Boost Interest -------------- Currently I'm think whether should I boostify it, release it under BSL (currently it is LGPLv3) and submit it for formal review in boost or shouldn't I? Why do I ask, not because I'm thinking it is not good enough but rather because I feel that the "boostification" effort would be wasted at this point. For about half a year ago I had submitted a Boost.Locale for formal review, I use it under other namespace as part of CppCMS project all the time and in fact I receive most request and bug reports for Boost.Locale via CppCMS project and not via CppCMS.Locale so basically I have to handle two projects and synchronize between them all the time, and Boost.Locale is still stuck in review queue. So does it worth the effort? So before I do any steps forward may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily). Regards, Artyom

22 53

[process] How to run test cases
by Boris 23 Jan '11

23 Jan '11

As Boost.Process 0.3 has been released it would be great if the test cases are run on various platforms. So far I've tested Boost.Process on WinXP with MSVC 9.0, Cygwin with g++ 3.4.4 and Solaris with g++ 3.4.6 and Sun C++ 5.9. To make it as easy as possible for others to run the test cases here's a short description of how to proceed. Nearly all test cases depend on a program called "helpers". This program is built first and is started by many test cases as a child process. In order to find the program "helpers" the test cases must know its location. As there is no way to get the location at runtime it is hardcoded in the file libs/process/test/misc.hpp. As the location differs depending on what compiler is used YOU MUST CHECK FIRST THE PATH IN libs/process/test/misc.hpp! Otherwise most of the test cases will fail as they look for a program "helpers" in the wrong directory. As of today only those paths are correct and have been tested which are set for Windows, Cygwin and Solaris. Only after you have checked and maybe updated the path in libs/process/test/misc.hpp you should try to build and run the test cases: WinXP/MSVC 9.0 ************** With MSVC 9.0 you only need to open the Visual Studio 2008 Command Prompt, change to the directory with the test cases and run bjam: C:\boost_1_36_0\libs\process\test> ..\..\..\bjam.exe -q Cygwin/GCC 3.4.4 **************** On Cygwin it's important to know if the Boost libraries have been built for the POSIX or Windows API. By default Boost libraries on Cygwin use the Windows API. With the Windows API the Boost.Process test cases are not passed successfully though (there are compiler errors where I'm not sure currently if they are a Boost.Process problem and how they could be fixed). If you want to run the test cases on Cygwin you must (re-)build the Boost libraries to use the POSIX API: $ cd ~/boost_1_36_0 $ ./bjam cxxflags=-DBOOST_POSIX_API Afterwards you can run the test cases: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam cxxflags=-DBOOST_POSIX_API -q Solaris/GCC 3.4.6 ***************** At first you have to put the following line in ~/user-config.jam: using gcc : : : <linker-type>sun ; Then start building the Boost libraries: $ cd ~/boost_1_36_0 $ ./bjam --toolset=gcc cxxflags=-mcpu=ultrasparc For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. Afterwards the test cases can be run: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=gcc cxxflags=-mcpu=ultrasparc -q Solaris/Sun C++ 5.9 ******************* Build the Boost libraries with the sun toolset: $ cd ~/boost_1_36_0 $ ./bjam --toolset=sun stdlib=sun-stlport For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. If you run the test cases now you'll get this compiler error for one test case: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. The bug has been reported to the Boost.Asio mailing list. If you want to build that one test case, too, you need to fix the two files in Boost.Asio 1.36.0 yourself. All the test cases can be built and run with: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=sun stdlib=sun-stlport -q

4 9

geometry moved to trunk
by Barend Gehrels 21 Jan '11

21 Jan '11

hi, Boost.Geometry is moved from sandbox to trunk yesterday. Questions: 1) Will I update the two files libraries.htm and maintainers.txt within $/trunk/libs to add geometry there? 2) How will geometry appear in the trunk regression overviews? There are already many unit tests using Boost.Test and jamfiles handling them. Thanks, Barend

4 6

[context] new version - support for Win64
by Oliver Kowalke 20 Jan '11

20 Jan '11

I've uploaded boost.context-0.3.0.zip to boost vault. The new version supports the context-/stack- swapping provided by the OS (ucontext ABI on UNIX, Fiber ABI on Windows) as well a fast context swapping (using assembler). supported platforms: i386, x86_64, arm, mips, ppc OS: UNIX, Windows (32 bit/64 bit) More details can be found in the documentation (included in the archive).

7 28

review request: addition to type_traits library of has_operator_xxx
by Frédéric Bron 19 Jan '11

19 Jan '11

I would like to propose to your review the following addition to the type_traits library, available at the following addresses: https://svn.boost.org/trac/boost/browser/sandbox/type_traits http://dl.free.fr/lRm4VL6WP/type_traits.tar.bz2 The purpose of the addition is to add type traits to detect if unary and binary operators can be applied to given types. For example, is "x<y" or "!x" or "x+y" meaningful? If required, the return type of such an expression is checked to know if it is convertible to a given type. Default behaviour is to not check the return type. The following traits are added: // binary operators: template < typename LHS, typename RHS=LHS, typename RET=void > == has_operator_equal_to != has_operator_not_equal_to > has_operator_greater >= has_operator_greater_equal < has_operator_less <= has_operator_less_equal + has_operator_plus - has_operator_minus * has_operator_multiplies / has_operator_divides % has_operator_modulus && has_operator_logical_and || has_operator_logical_or & has_operator_bit_and | has_operator_bit_or ^ has_operator_bit_xor // unary operators: template < typename RHS, typename RET=void > + has_operator_unary_plus - has_operator_unary_minus ! has_operator_logical_not This new version reflects the discussions we had on the list: http://thread.gmane.org/gmane.comp.lib.boost.devel/194625 In particular about the check or not of the return type. All operators are now included and not only comparison binary operators. Example: has_operator_less<LHS, RHS, RET>::value_type is the type bool. has_operator_less<int> inherits from true_type. has_operator_less<int, int, std::string> inherits from false_type. has_operator_unary_minus<int, long> inherits from true_type. has_operator_unary_minus<double, int> inherits from true_type. has_operator_unary_minus<int, std::string> inherits from false_type. Documentation is accessible at libs/type_traits/doc/html/index.html in the archive. Regards, Frédéric PS: tested with g++ 4.4.5 on i686-linux.

14 53