- Boost - lists.boost.org

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

Re: [boost] [mini-review] Update of Boost.Assign (13th-19th of June)
by Thorsten Ottosen 17 Jun '10

17 Jun '10

er skrev: > >> With a view to promote separation of responsibility between different >> functions, perhaps we may (also) consider a new function : >> >> push_back_range(const V&,const R&); >> > > This would tie in with the proposed extension like this: > > > > push_back_range(v,cref_csv(1,2,3,4)); > > > > > > On second thought boost::copy is sufficient: > > boost::copy(cref_csv(1,2,3,4),std::back_inserter(v)); > > Also, > > BOOST_AUTO( tmp, ref_csv(a,b,c,d)); > boost::copy( v, boost::begin(tmp)); > > may come in handy. I would turn my attention to the new Range library: boost::push_back( cont, cref_csv(1,2,3,4) ); http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/reference/al… -Thorsten

1 0

[interprocess] (Win32) shared memory totally doesn't work :(
by David M. Cotter 16 Jun '10

16 Jun '10

so in process A i do this: shared_memory_object obj(create_only, "guid of some kind", read_write); during the construction of that object, it makes a call to "get_boot_time_str()" to construct a folder name based on the boot time. this makes sense, so process B can locate the SAME folder, cuz the boot time is the same, right? well, wrong. you see, the function *says* get_BOOT_time, but it is actually getting boot PLUS SYSTEM (current) time. which is going to be different for the two processes, unless they made the call at the *exact* same time. so it would seem, unless i'm totally misunderstanding this, that it is impossible to use the shared memory thing as it is implemented. if i *remove* the part where it relies on SYSTEM time and only let it use BOOT time, everything works as documented and as expected. what is this about? i'm so curious how other people could be using this? -dave

4 15

[serialization] example/portable_binary_[i|o]archive.cpp do not compile anymore
by Hartmut Kaiser 16 Jun '10

16 Jun '10

I'm seeing: boost::archive::version_type::version_type' : cannot access private member declared in class 'boost::archive::version_type' Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

1 0