June 2010 - Boost - lists.preview.boost.org

[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

[website] links to boost docs
by Eric Niebler 16 Jun '10

16 Jun '10

I'd like a URL that automatically redirects to the docs for the latest version of my library. Is there such a redirect on boost.org already? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 6

nvcc cuda patch
by Andrey Asadchev 16 Jun '10

16 Jun '10

hello here is a small patch to make boost mpl libraries usable with cuda nvcc compiler. http://code.google.com/p/asadchev/source/browse/trunk/work/cuda/boost-cuda.…

2 1

Re: [boost] [Boost-commit] svn:boost r62919 - in trunk: boost/filesystem/v2 boost/filesystem/v3 libs/filesystem/v2/test libs/filesystem/v3/test
by Scott McMurray 16 Jun '10

16 Jun '10

On 13 June 2010 10:33, <bdawes(a)acm.org> wrote: > Author: bemandawes > Date: 2010-06-13 13:33:39 EDT (Sun, 13 Jun 2010) > New Revision: 62919 > URL: http://svn.boost.org/trac/boost/changeset/62919 > > [...] > > @@ -620,7 +620,7 @@ > basic_path< String, Traits > & ph ) > { > String str; > - is >> str; > + std::getline(is, str); // See ticket 3863 > ph = str; > return is; > } > I'm not convinced this is the right approach here, since cout << mypath << ' ' << myint; doesn't roundtrip with cin >> mypath >> myint; the way I expect operator<< and operator>> to work. Perhaps the portable pathname grammar could be extended to allow backslash-escaping of spaces and backslashes? That or remove the stream operators entirely and force people to choose which way they want to print the path and deal with the result as a fully-general string.

6 14

[log] auto_flush not flushing?
by Michael Caisse 15 Jun '10

15 Jun '10

I'm running on Vista and compiled with VC8. I have initialized the backend like this: ----------------------- typedef sinks::synchronous_sink< sinks::text_file_backend > sink_type; boost::shared_ptr< sink_type > sink = boost::make_shared< sink_type >( keywords::file_name = "%Y%m%d_%H%M%S_%5N.log", keywords::open_mode = (std::ios::out | std::ios::app), keywords::auto_flush = true, keywords::rotation_size = rotate_size // rotation size, in characters ); if( target_directory.empty() ) { target_directory = suggest_target_directory(); } // Set up where the rotated files will be stored sink->locked_backend()->set_file_collector( sinks::file::make_collector( keywords::target = target_directory, // where to store rotated files keywords::max_size = max_stored_size, // maximum total size of the stored files, in bytes keywords::min_free_space = min_free_space // minimum free space on the drive, in bytes )); sink->locked_backend()->auto_flush(true); // Upon restart, scan the target directory for files matching the file_name pattern sink->locked_backend()->scan_for_files(); typedef aux::add_common_attributes_constants< char > traits_t; sink->locked_backend()->set_formatter( formatters::stream << formatters::attr< unsigned int >(traits_t::line_id_attr_name()) << " [" << formatters::date_time< boost::posix_time::ptime >(traits_t::time_stamp_attr_name()) << "] [" << formatters::attr< attributes::current_thread_id::held_type >(traits_t::thread_id_attr_name()) << "] [" << formatters::attr< severity_level >(sources::aux::severity_attribute_name< char >::get()) << "] " << formatters::message< char >() ); core::get()->add_sink(sink); --------- Notice I have also added a call to auto_flush (for good measure with the keyword didn't work (o; ) What happens is that the log file shows up after the program exits. Since I was hoping to tail the file for some debug ... that isn't very convenient. Ideas of what I have done wrong? TIA michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 9

[log] Can Boost.Log be used in clean-up functions?
by Andrzej Krzemienski 15 Jun '10

15 Jun '10

Hi, By 'clean-up functions' I mean destructors or automatic objects, destructors of static objects, functions registered with std::atexit and std::terminate. So, what I want to ask is: Can I use Boost.Log for logging inside destructors of automatic objects? Destructors are exected not to throw by STL containers and algorithms, also it is often taught that a destructor throwing during stack unwinding ... Can the logging throw an exception? I guess it cn, and I guess, it my be unsafe to log in the destructor. Am I right? Can I use Boost.Log in functions that are run after function main finishes? I.e. can I safely log in destructors of static objects, or functions registered with std::atexit? Similarly, can I log in the std::terminate (if I have installed my custom handler)? When are log sources or sinks destroyed? Regards, &rzej

2 1

[xint] Fifth release -- one more round of reviews, please
by Chad Nelson 15 Jun '10

15 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One more time... the next iteration of the Extended Integer library (a arbitrary-length integer math library) is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z…>). It incorporates almost all of the suggestions offered on this list. The changes between this release and the last one are: * All three types (integer, nothrow_integer, and fixed_integer) have now been consolidated into a single template, using Boost.Parameter for the options. This release, like the last one, includes a slightly older version of Ion Gaztañaga's preliminary Move library too. I haven't tested it with the current version, but it should work with that as well. The Move library is not used by default, and makes only a slight difference to the speed when thread-safety is enabled. Still on my immediate to-do list: * Add an "unsigned" option, so that the mod operation will work as expected. * Add support for GCC's -fno-exceptions option. * Add more examples. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwTu5sACgkQp9x9jeZ9/wS2AQCfekF0zJW4TjDUhFNP/Cts6ZLC xXkAoNOchGNvIbJcimXnYo3PrSIF68or =4Knn -----END PGP SIGNATURE-----

2 7