- Boost - lists.boost.org

[quickbook] All tests failing in Trunk?
by John Maddock 20 Jun '10

20 Jun '10

All the quickbook tests seem to currently be failing in Trunk, this appears to be related to some change in Boost.Build as the Jamfile logic used to work I believe? John.

3 5

[iostreams] Thank you to Steven Watanabe
by eg 20 Jun '10

20 Jun '10

I just wanted to pass along a big thank you to Steven Watanabe for fixing a ton of bugs in the iostreams library this past week! According to Trac it appears there are only 13 Tickets left open (and this number was around 34 at the end of the recent bug sprint). From those of us who use the library, but haven't had the time or wherewithal to tackle these ourselves, this will be very helpful indeed. Thanks again! Regards, Ed

3 2

Requests for comments on a (partly) hypothetical non-relational serialization library
by nathaniel＠photino.org 20 Jun '10

20 Jun '10

Hi all: I've been working for a while on a variety of tools to facilitate application development in normal (cross-platform) C++, and avoid the byzantine dependency chains (including needing multiple boost versions) which so often creep in because real applications always seem to piece together disparate parts with different build systems, requirements, even how to download the source code...pretty soon you're not programming C++ anymore, you're tinkering with Python make scripts, or Perl code generators, or learning Git or Subversion ... know what I'm saying? Anyhow, I'm a fan of the Mongo database, but it's notoriously hard to build even the drivers, and not really suited for simple SQLite-like object serialization for persistence between runs of an application (even though this is theoretically possible, it is poorly documented and still requires linking against the entire Mongo system). So I've decided to develop a serialization framework (not a database) with some "NoSQL" features based on Mongo, but alot easier to use. I believe this framework could provide a foundation upon which useful, moderately complex C++ applications could be designed, by providing extensions to the library which are optional to use but which incorporate my work (I hope that doesn't sound pedantic) on general application development, without extra external dependencies. Specifically, these extensions would include: 1) A tool for generating GUI code -- for wxWidgets, in particular -- from archives that could be edited with a simple textual front-end, vaguely like XAML; 2) A custom language based on Clojure -- a Lisp dialect originally implemented by Rich Hickey on the JVM -- for expressing queries and importing/exporting data from/to an archive; 3) Perl6-like regular expressions for matching against textual fields in an archive; 4) AI-inspired algorithms for sorting, filtering, and in other ways operating on archives. My academic background is in AI -- actually, to be precise, I wrote a doctoral dissertation in the philosophy of science, but I researched AI in this context -- but I'm especially interested in nonrelational database theory because it better captures the process of modeling complex systems, and, in general, nonrelational databases are more interesting from an AI perspective because the lack of a fixed schema means that operations like sorting and filtering can require some "reasoning". I'm particularly interested in application development because I think one concrete application of AI research is to make tools like IDEs smarter. A non-relational serialization library could potentially serve the application development process not only by providing an easy way to persist data, but through IDE extensions or project generators -- store lists of debug breakpoints in an archive, or parse source code for namespaces, types, etc., and store the results in an archive, or an archive to represent all the controls in a GUI... The library I have in mind would differ from boost.serialization by providing explicit support for non-relational functionality, and also by using a restricted type system along the lines of MongoDB and JSON: any persistable data field would have to be marshalled into one of a few predefined types, although users could explicitly extend the type system if desired. Aside from writing persistence code directly in the C++ source (along the lines of, e.g., instantiating a serialize() template in namespace boost::serialization), the test or demo applications I've been writing use external files, written in the (currently very minimal) Clojure-like language I mentioned above, and an interpreter does the actual serialization -- so the persistence strategy could be altered without recompiling the application, even while it is running. I think this offers new potential for using AI-style algorithms for things like tracking usage patterns, because all of that could be implemented fully orthogonal to the application itself. So, that's the project I've sort of assigned myself, and I would appreciate any comments and ideas and what I could do to make this the kind of library C++ programmers would consider trying out. Thanks in advance.

2 1

Re: [boost] [msm] Message queue and copy constructed events
by Christophe Henry 19 Jun '10

19 Jun '10

Hi Richard, >I have that request as well to use the MSM without heap actually I >have managed to compile MSM in an embedded target without stdlib, >rtti, exception and no heap but only if queues are disabled. Yes, message queue and deferred event queue. >In our system we never copy events and for us the best would be if you >could just able to provide us a backend to use our own event queue >implementation where we make sure that we use a queue form the RT >scheduler where no copy operation is required. I think it's two different issues. Having your own queue will save you the heap cost of the std::queue but not the copy, which is done by using boost::bind. Of course I could use ref/cref but there is no way for msm to know how long the event will still be around, unless we add the possibility for a user to tell msm that the event will be around long enough (using some typedef for example). This will, however, not remove completely the heap costs as the bind is then passed to a boost::function (to anonymize the event) => heap. Thus, just providing another container will not do the trick easily. What kind of container are you thinking about? Regards, Christophe

2 1

[filesystem] wfstream file open does not create file in std::ios_base::out mode
by Ramakrishna, Kirankumar IN BLR SISL 19 Jun '10

19 Jun '10

Hello, I am using boost version 1.42 and the below code is tested on Windows Xp SP3 and Suse 11.2 The below code creates new file when opened using fstream object, but fails to create when opened using wftream object. This behavior is consistent across platforms (Windows and Linux). Also the error code which I get after fileHandleW.open call is, 1. ERROR_FILE_NOT_FOUND for std::ios_base::out 2. ERROR_NEGATIVE_SEEK for std::ios_base::app In case of append mode, the file gets created. But still I get the above mentioned error code. #include "boost/filesystem/fstream.hpp" int main() { boost::filesystem::path pA("C:\\testA.txt"); boost::filesystem::wpath pW(L"C:\\testW.txt"); boost::filesystem::fstream fileHandleA; boost::filesystem::wfstream fileHandleW; fileHandleA.open(pA, std::ios_base::out); fileHandleW.open(pW, std::ios_base::out); return 0; } Kindly help me in this regard. Regards, Kiran ________________________________ Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank You.

2 1

[serialization] Segfault after recent changes to trunk
by Hartmut Kaiser 18 Jun '10

18 Jun '10

Hey, The recent changes to the serialization library on trunk broke our application. Everything works fine up to V1.43, but on trunk we see a "vector subscript out of range" error at basic_iarchive.cpp, line 437. Here is the relevant code snippet: class_id_type new_cid = register_type(bpis_ptr->get_basic_serializer()); int i = cid; cobject_id_vector[i].bpis_ptr = bpis_ptr; // <-- here where in our case i == 0x0601 cid == 0x0601 newcid == 6 cobject_id_vector.size() == 7 Is this a known problem? Anything we could do about this? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

1 0

[units] gcc warnings
by Jürgen Hunold 18 Jun '10

18 Jun '10

Hi ! I start using Boost.Units for a new project and found some annyoing warnings when compiling with "-Wall -Wextra" and "-Wconversion" The message is: /home/hunold/src/devel/boost/boost/units/io.hpp: In function ‘int boost::units::get_flags(std::ios_base&, int)’: /home/hunold/src/devel/boost/boost/units/io.hpp:163: warning: conversion to ‘int’ from ‘long int’ may alter its value [-Wconversion] Patch using an explicit static_cast<int> for the return value attached. Ok to commit ? Other suggestions ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

5 16

[Important] Server downtime tomorrow (Friday) morning
by Doug Gregor 17 Jun '10

17 Jun '10

The Boost server will be down tomorrow for about an hour for maintenance. We'll be upgrading Trac to version 0.12 and also taking this opportunity for a kernel update. Date: Friday, June 18, 2010 Time: 8:00AM to 9:00AM (Eastern Time) We expect that the following services would be NOT available during the upgrade. - Apache server * trac * svn * mail archives * boost web sites. - Doug

1 0

[inspect] Apple macro check
by Daniel James 17 Jun '10

17 Jun '10

Hi, The apple macro errors in the inspect report are only really a problem when certain apple headers are included. This never happens when we can control which headers are included so I think it's only a problem under the boost directory. So is it okay if I change inspect so that it only checks for apple macros under 'boost'? Daniel

5 5

[nowide] Request for interest (nowide unicode support for windows)
by Artyom 17 Jun '10

17 Jun '10

Hello All, I've recently written a small library that allows writing platform independent Unicode aware applications transparently. Problem, basic stuff like opening a file, deleting it, is generally accepted for granted and indeed, STL provides std::fstream and C library provides FILE* API like std::fopen, std::remove, std::rename. However, this API is broken under Windows any time we talk about some basic localization like using Unicode file names. Unlike all other Windows development moved to redesigning API to wide characters instead of adapting backward compatible UTF-8 locales into the core system. Result: it is total nightmare to write any kind of Unicode aware cross platform programs. Even when trying to use wide strings and calling _wfopen or _wremove where needed is not enough, as there is no simple replacement for std::fstream. MSVC provided non-standard extension where std::fstream::open() receives wide string, but this is not accepted by many other compilers including MinGW gcc that has shared libstdc++ over multiple platforms. Not talking about that standard does not define std::fstream::open(wchar_t const *,...) (and not in Tr1 as well). So... proposed solution (in short): namespace boost { namespace nowide { #if !defined(BOOST_WIN32) using namespace std; #else // Windows Wide API std::wstring convert(std::string const &); std::string convert(std::wstring const &); FILE *fopen(char const *,char const *); FILE *freopen(char const *,char const *,FILE *); int remove(char const *); int rename(char const *,char const *); template<typename Char,typename Traits ...> basic_filebuf { ... open(char const *,...); ... }; template<typename Char...> basic_istream {...}; template<typename Char...> basic_ostream {...}; template<typename Char...> basic_fstream {...}; } } When working on non-win32 platform it would use native API (and most POSIX OSes use UTF-8 nativly) On whindows each of these classes and functions assumes UTF-8 strings as input and map underlying functions to _w* alternatives or in case of basic_filebuf implements basic_filebuf over FILE *api and _wfopen. This would allow much easier writing cross platform application using unified and standard API instead of non-standard wide API. Note, functions boost::nowide::convert would allow adapt any library transparently use of widely used UTF-8 API instead of WIN32 one. I had implemented this for my own projects, I'm asking if boost is interested in something like that at all. Artyom

6 26