- Boost - lists.boost.org

[1.35.0] Serialization demo.cpp problem
by Scott Woods 16 Jul '08

16 Jul '08

Hi, Just trying to get a comparison going between several different techniques for serialization. After downloading 1.35.0 and using the beautiful auto-installer it was looking pretty good. Trying to compile demo.cpp hasnt gone quite so well; Deleting intermediate files and output files for project 'demo - Win32 Debug'. --------------------Configuration: demo - Win32 Debug-------------------- Compiling... demo.cpp c:\program files\boost\boost_1_35_0\boost\serialization\utility.hpp(50) : error C2989: 'is_bitwise_serializable<struct std::pair<T,`template-parameter258'> >' : template class has already been defined as a non-template class c:\program files\boost\boost_1_35_0\boost\serialization\utility.hpp(50) : error C2988: unrecognizable template declaration/definition c:\program files\boost\boost_1_35_0\boost\aligned_storage.hpp(59) : fatal error C1506: unrecoverable block scoping error Error executing cl.exe. demo.exe - 3 error(s), 0 warning(s) I've searched the mail arachives. There have been a few issues around demo.cpp but they seem unrelated. Anyone know whats going on? Windows XP, Microsoft Visual C++ 2005. Thanks, Scott

1 0

[statechart] test failures on the release branch
by Richard Webb 15 Jul '08

15 Jul '08

Merging the changes in Function to the release branch has caused some failures in the statechart tests (e.g. http://tinyurl.com/6hmxod) So i guess that Statechart needs to be merged as well now? Thanks, Richard Webb

2 2

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

15 Jul '08

"Peter Dimov" <pdimov(a)pdimov.com> wrote in message news:00c501c8e6b1$b3a11f60$6607a80a@pdimov2... > > It doesn't because of the mem_fn behavior that bind inherits. The > argument is not a reference to Crayon and so is assumed to be a smart > pointer to Crayon. mem_fn then tries to invoke get_pointer() on it to obtain a Crayon*. > You should be able to make it compile by adding a get_pointer overload > for > reference_wrapper: > > namespace boost > { > > template<class T> T* get_pointer( reference_wrapper<T> const & r ) { > return r.get_pointer(); > } > > } That would be an awesome addition, since reference_wrapper is an oft-used part of boost and there's really no reason for it not to be automatically traversed, making bind constructs that involve it a little simpler. Thanks, Michael Goldshteyn

1 0

[extension] factory_map::get() suggestion
by Robert Dailey 15 Jul '08

15 Jul '08

Currently, there is no typedef to provide a convenient way to create variables of the return type of boost::extensions::factory_map::get(). For example, right now I have to do this: factory_map fm; std::map<int, factory<word> > & factory_list = fm.get<word, int>(); It would be ideal to do this instead: factory_map fm; factory_map::type& factory_list = fm.get<word, int>(); Could this be done?

5 10

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