- Boost - lists.boost.org

Bind question, is there any way to implicitly go through a reference_wrapper?
by Michael Goldshteyn 15 Jul '08

15 Jul '08

Here is a contrived example that illustrates the issue: #include <boost/bind.hpp> #include <boost/ref.hpp> #include <string> // Define a simple class for our example class Crayon { public: explicit Crayon(const std::string &color=std::string()):m_color(color) {} const std::string &GetColor() const {return m_color;} private: std::string m_color; }; int main(int argc, char *argv[]) { using namespace std; using namespace boost; Crayon cr("blue"); boost::reference_wrapper<const Crayon> crefCr(cr); // This compiles std::string color(boost::bind(&Crayon::GetColor,_1)(cr)); // This also compiles, using an explicit get on crefCr std::string colorFromConstRef(boost::bind(&Crayon::GetColor,boost::bind(&boost::referenc e_wrapper<const Crayon>::get,_1))(crefCr)); // This doesn't compile, however, even though the reference_wrapper class template has // an overloaded operator T& () const function std::string colorFromConstRef2(boost::bind(&Crayon::GetColor,_1)(crefCr)); }

2 1

Re: [boost] [thread_pool]: formal review request
by Oliver Kowalke 15 Jul '08

15 Jul '08

> Do you have formal documentation? > Emil Dotchevski > Reverge Studios, Inc. > http://www.revergestudios.com/reblog/index.php?n=ReCode documentation should be included in the archive Oliver -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

1 0

version 0.2.1 of Mirror available
by Matus Chochlik 15 Jul '08

15 Jul '08

Hi there, a new version of the Mirror reflection library is available in both the vault and the sandbox. This version includes multiple important changes and many things were rewritten from scratch. Just to mention some of them: - nearly all of the registering and reflection macros have (hopefully ;) ) become more user friendly and some more universal. - more complex types like multi-dimensional arrays and functions/ pointers-to-function/references-to-functions are now supported by the typename returning functions base_name() and full_name(), which were also completely rewritten. And are now returning C++ strings. - registering of typedefined types - support for registering attributes with types derived from typedef-ined types some of the examples have been cleaned up (the rest are to follow). the examples were successfully compiled with msvc-9.0 EE on Vista g++ 4.2.1/4.3.0 on OpenSuSE 10.3 Linux g++ 4.2.1. on FreeBSD 7.0 Any comments are welcome Best regards, -- ________________ ::matus_chochlik

2 3

SOCI 3.0.0 - The Database Access Library
by Maciej Sobczak 15 Jul '08

15 Jul '08

Hi, After more than one year and a half from the last release I'm pleased to announce the availability of the next major SOCI release (3.0.0). The SOCI library is a C++ database access library that during the last years was recognized for its innovative interface, ease of use and high quality. The main project website is: http://soci.sourceforge.net/ The 3.0.0 release brings many improvements and new features. Some of them were suggested here during previous discussions on database interfaces. Some of them will be explained in more detail below. The most important of the new library features include: * Naming and coding convention compliant with Boost. * Integration with Boost types: optional, tuple, fusion and gregorian::date. Please see <http://soci.sourceforge.net/doc/boost.html> for details. * Dynamic backend loading. The advantages and potential uses of this feature have been discussed here previously. An example code establishing the new connection to the database might look like: soci::session sql("postgresql://dbname=my_database"); As a result, the SOCI library will try to locate the dynamically loadable plugin (called backend) for PostgreSQL and handle all further database-related activity. This feature exists not instead, but in addition to the statically-bound interface that was available in previous releases. * Multithreaded connection pool. * Improved integration and conversion system for user-defined datatypes. Actually, integration with Boost types has been implemented with the help of this conversion system. It is non-intrusive and based on traits, which means that neither SOCI nor user-defined types need to be modified to integrate them. This system is also composable, which means that user-defined datatypes can wrap one another without special arrangements. For example, boost::tuple can contain boost::optional<Employee> even though all three conversion traits can be defined separately. * Extended the set of basic datatypes with long long. * Additional simplified interface (of the extern "C" type) for integration with other programming languages. It is expected that bindings for other languages will be created as external projects with the potential advantage of reducing the total number of libraries used in multi-language projects and increasing conceptual coherency of database-related operations. Boost.Python and similar solutions can be helpful here. The 3.0.0 release includes the following backends: * Oracle * PostgreSQL * MySQL They were tested on a variety of platforms, please see the documentation pages devoted to each backend for details. Other backends (ODBC, SQLite, Firebird) exist in the CVS repository and are provided "as is" for those who are willing to experiment with them and accept the cost of using less-tested and unsupported code. It is very likely that future releases of the library will officially include some of these additional backends. It is also possible that other database servers will be targeted with dedicated backends. An extensive HTML documentation is available both on the project website and as part of the distribution. In particular, the doc/structure.html page explains the structure of the library and provides instructions how to build it. ------ This release is also a good motivation for reviving the discussion on the future Boost database library. As you have seen during the last couple of years, SOCI is one of the very few (should I say "the only one"?) projects that actually move forward and that are now culturally consistent with Boost. The extensive out-of-the-box integration with the Boost datatypes, Boost license and compliant naming conventions, already make SOCI the natural choice in those projects that use Boost libraries. As a natural consequence of this, the following question has to be asked: What is the future of database interfacing from the Boost community point of view? Proposing SOCI as a candidate library for Boost might be a possible answer to this question, but it is not obvious in a wider perspective. Some of the SOCI users do not use Boost for various reasons and this justifies retaining SOCI as a separate entity (note: even though SOCI offers extensive integration with Boost, it does not mandate it and SOCI can be compiled without any reference to Boost). Most likely solution is to keep SOCI orbiting around Boost in terms of coding conventions and seamless interfacing, as it does today, so that benefits for all interested parties can be retained. Your comments and suggestions considering the above are very welcome. Final note: SOCI does not use bjam. If this is considered as missing from the Boost point of view, contributions from experienced bjam users would be needed. Cheers, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com

9 20

[filesystem] Following symlinks
by Scott McMurray 15 Jul '08

15 Jul '08

Suppose I want to add to simple_ls so it tells me the target of a symlink like ls -l does. else if ( fs::is_symlink( dir_itr->status() ) ) { ++other_count; std::cout << dir_itr->leaf() << " -> " << symlink_path(*dir_itr) << "\n"; } I haven't found any function to put in place of symlink_path. Is there one? It can't be a path decomposition, and the only other functions that return paths are current_path, initial_path, and the complete functions, so I don't think there is. ~ Scott

1 0

[filesystem] Resolving a path ?
by Loïc Joly 15 Jul '08

15 Jul '08

Hello, I'd like to know if there is in boost::filesystem a way to "resolve" a path. For instance, I have a path that is built from : "c:\foo1\foo2\..\bar1\bar2" And I'd like to obtain: "c:\foo1\bar1\bar2" Best regards, -- Loïc

4 5

[extension] Suggestion: Loading shared libraries from memory
by Robert Dailey 15 Jul '08

15 Jul '08

Hi, I'm not a huge expert on shared libraries, however I was wondering if there's a portable way to support loading libraries from a memory buffer instead of from the file system. If this is possible, could it be added as a feature to Boost.Extension? Thanks for reading!

3 3

[rfc] dual-mode regression testing
by joaquin＠tid.es 15 Jul '08

15 Jul '08

Hello, As it stands now, most testing force goes to the trunk of SVN, which is good. The problem is that there are few regression runners running against the release branch, and I think we have a trade off: a regression runner volunteer will choose to work on either the trunk or the release branch, but taking care of both is possibly too much of a hassle. It is assumed that the release branch is much cleaner and thus needs less attention, but it's better to be safe than sorry wrt this. My proposal is then: why not modify the regression tool code so that it operates by default in *dual mode*, i.e. it automatically downloads two tarballs (trunk & release) to different folders, test them separately and upload the results to the appropriate destinations? From the point of view of a volunteer, setting this to work is as simple as having it running only against one branch, and the only drawback is that resource consumption doubles, but this might be acceptable to a fair number of people. Comments? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[parameter][accumulators] test failures on release branch
by Richard Webb 15 Jul '08

15 Jul '08

(reposting this in it's own thread, to make sure it doesnt get lost). The release branch parameter/accumulator tests are showing a large number of failures due to a missing #include <boost/type_traits/is_convertible.hpp> in boost/parameter/aux_/tagged_argument.hpp e.g. http://tinyurl.com/642sgq Thanks, Richard Webb

2 1

Re: [boost] [pool] segfault (fun with static initialization ordering)
by joaquin＠tid.es 15 Jul '08

15 Jul '08

Chris Newbold escribió: >> From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] >> On Behalf Of JOAQUIN M. LOPEZ MUÑOZ >> Sent: Friday, July 11, 2008 11:35 AM >> >> BTW, have you tried the fix I was proposing? >> > > Not yet. I'm on vacation this week, but I will try it as soon as possible. My only concern is whether referencing singleton_default from the constructor for fast_pool_singleton will guarantee proper initialization ordering. > > 3.6.2 doesn't really shed any light on how ordered and unordered initialization may be coupled. There isn't, for example, any expressed guarantee that non-locals will be initialized prior to first reference. > There is no such guarantee indeed, but the fix does NOT rely on initialization rules for non-local objects, but on the initialization rules for *local* objects with static storage duration (6.7/4): the singleton is a local static object inside the function singleton_default<T>::instance(), which is explicitly invoked inside fast_pool_allocator ctors via singleton_pool<...>is_from() (if you apply the fix, that is). The non-local object involved in singleton_default<T>, namely singleton_default<T>::create_object is there to guarantee that singleton_default<T>::instance() is invoked, and thus the singleton created in dynamic initialization time *if no one has done it before*. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0