February 2009 - Boost - lists.boost.org

[thread]link problem with ibboost_thread-vc71-mt-gd-1_38.lib
by WANG Xuewen 16 Feb '09

16 Feb '09

Hello, I had a dll using MFC as shared library which works fine with boost 1.35. Recently, I've started to look at 1.38 and got the following link problem: libboost_thread-vc71-mt-gd-1_38.lib(tss_pe.obj) : error LNK2005: __pRawDllMain already defined in mfcs71d.lib(dllmodul.obj) libboost_thread-vc71-mt-gd-1_38.lib(tss_pe.obj) : warning LNK4006: __pRawDllMain already defined in mfcs71d.lib(dllmodul.obj); second definition ignored I've searched on internet and mailing list archive and didn't find a solution to the problem. Does anyone have an idea? Thanks, Xuewen

2 1

Seeking writers to develop quarterly digests of Boost newsgroups
by Brian Wood 16 Feb '09

16 Feb '09

I'm planning to start an on line magazine called C++ Quarterly. *http://tinyurl.com/df6hn2 or **http://preview.tinyurl.com/df6hn2 * If you are interested in writing a quarterly digest of Boost Users and/or Boost Developers, please let me know. Alternatively, if you're interested in writing a non-digest article, I'd be happy to hear from you. Just to clarify something from the above link. I want to set things up so that advertisers send money directly to authors. Advertisers would send ads to us but money to authors. Brian Wood Ebenezer Enterprises www.webEbenezer.net <http://www.webebenezer.net/>

1 0

Releases and EOLS
by Rene Rivera 16 Feb '09

16 Feb '09

In the past there's been confusion as to what the release packages contain with regards to EOLs <https://svn.boost.org/trac/boost/ticket/2641>. My idea for dealing with the confusion is to tag the packages with an EOL indicator (as explained in the bug). Any other ideas? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 6

boost::ptr_container: seems bug in erase_if
by Anton Ivanov 15 Feb '09

15 Feb '09

Hi! In ptr_sequence_adapter.hpp we have function: template< class Pred > void erase_if( iterator first, iterator last, Pred pred ) { range_check(first,last); this->base().erase( std::remove_if( first.base(), last.base(), void_ptr_delete_if<Pred,value_type>(pred) ), this->base().end() ); } If we call this function with second parameter not equal to this->base().end() then function remove not only elemets for wich pred return true, but also all alement from last.base() to the end of container (this->base().end()). This is seems bug due to function documentation: template< class Pred > void erase_if( Pred pred ); template< class Pred > void erase_if( iterator begin, iterator end, Pred pred ); * Requirements: Pred must take an const T& argument * Effects: removes all elements t for which pred(t) returns true from the entire container or the specified range -- Yours sincerely, Anton Ivanov (ai(a)drweb.com)

3 4

Fusion + New Iterator Concepts?
by Brandon Kohn 15 Feb '09

15 Feb '09

Greetings Ladies and Gents, I've been kicking around a problem in which I'm trying to create an access policy interface which specializes compile-time and run-time access to values mapped on an integral index. I.e. something like: value_type access<T>::get<Index>( T t ) value_type access<T>::get( T t, size_t index ) Where access<T> describes a specialized access policy for T. In this context T is a sequence of anything (polymorphic even) that provides a value_type instance. The elements of T may be simple values, a generator() instance, A member function of some type etc. I began implementing an access type to specialize compile-time indexed access which assumes T is a model of the Boost.Fusion RandomAccessSequence which works wonderfully. I then began to write an extension that allows me to define fusion sequences of member functions (which provide the required values.) This is where I seem to have hit a snag. Among the use-cases I would like to support is a case where the value is returned from the provider using pass-by-value semantics. Fusion seems to be built using iterator concepts which essentially expect the underlying types to be able to provide a reference type. Looking further I found a document in the Boost.Iterator library defining "New Iterator Concepts" ( see: http://www.boost.org/doc/libs/1_38_0/libs/iterator/doc/new-iter-concepts.ht… ) . This document seems to define exactly what I need which is the separation of traversal behavior from access behavior. My question (finally!) is whether or not anyone has thought about applying these ideas to Boost.Fusion (or if they are perhaps already supported in some undocumented form?) Cheers, Brandon

2 1

Re: [boost] boost interprocess / shared memory question
by Ion Gaztañaga 15 Feb '09

15 Feb '09

Naveen Santhanam wrote: > Hello, > > We have a windows application (a process) that requires a large data > file (approx. 100 MB) to perform a task. We have a master that launches > several instances of this application. We would like to share the large > data file across the processes such that, there is just one instance of > the data file in physical memory without any disc access. Hence each > application will have a small footprint in memory during execution. We > have tried using a managed shared memory object from the > boost::interprocess library to achieve this. However, this doesn’t help > us as the memory footprint of the application goes up upon access of the > data file. Is there a way to achieve the desired single footprint > memory sharing? Does this work as expected with other OSes? When managed_shared_memory is used (in Windows this is emulated with a temporary memory mapped file). The OS will allocate memory on demand as you access the file, and that memory will be shared across processes: although you see that each process has 100 MB extra memory, the global used memory will grow only 100MB, because those 100MB are shared across processes. If you don't need managed features and just read raw data from a file, you can use file_mapping and mapped_region to map /unmap a concrete memory region and avoid mapping the whole file. But of course, this will require much more manual work. Regards, Ion

1 0

[serialization] export.hpp changes from 1.37 to 1.38
by Chard 15 Feb '09

15 Feb '09

The BOOST_CLASS_EXPORT.. macros have been moved into a detail namespace (1.38) from a (public) anonymous namespace (1.37). I'm guessing that the reasoning for this was in order to avoid many definitions of the class singletons. However, this appears to have enforced that all of the guids (for all archive types) now have to reside in a single compilation unit. The attached code illustrates the limitation; this compiles under 1.37 but results in duplicate symbol definitions in 1.38 (with MSVC7.1). It worked with 1.37 because the anonymous namespace ensured no symbol clashes, but now the symbols are all in the same namespace. The example shows a case where two archive types (xml and binary) might be in use. The obvious solution to this (simple) case would be to just use a single compilation unit, which brings in the guids for both binary and xml. However, turning a blind eye to the 'untidiness', this fix does not help with the project we're working on. In our project, there is not just a simple type being serialized; there are a lot more classes and a bit of mpl thrown in. This actually resulted in breaching the COFF symbol limit (approx. 65k) with MSVC7.1, so we were forced to split the serialization. In fact, we had to split both the save and load parts of the binary serialization. Our current workaround is to use the archive.register_type<...> method, and ignore the export macros, but this does mean ensuring all types are covered (as described in the documentation).

2 3

Re: [boost] RFC: interest in Unicode codecs?
by Graham 15 Feb '09

15 Feb '09

Esben, >I think you have gotten something mixed up. UTF-8 and UTF-32 (aka UCS4) are >just two encodings of the same character set, including the combining you >mentioned (which are really not that uncommon, e.g. m?l?e contains 2 >characters which could be written by combining glyphs. In practical terms, >UTF-32 is somewhat useless. (A case might be made for UTF-16, though) >Kind regards, Esben Having written both basic text editors and Unicode text editors, I can say that if you are going Western Hemisphere then may be more efficient to go UTF-8. If you stick to Unicode Code Page 0 then UTF-16 might be appropriate if you have no formatting bits, but by the time you want to do a full Unicode text editor you end up with [from memory] 21 or 22 bits of the UTF-32 encoding, and the remaining bits for your own formatting info if you need it [font/ colour etc]. With surrogates, you are still [very] slightly encoded in a 32 bit width, but this is a very acceptable trade off for simplicity. In that sense UTF-32 is a misnomer as it does not occupy a full 32 bits, but it is still an encoding ! Yours, Graham

1 0

Re: [boost] Review Request: Introduction of boost::string, namespace and string-conversion functions
by Anders Dalvander 14 Feb '09

14 Feb '09

On Sat, 14 Feb 2009 22:41 +1100 Vladimir Batov wrote: > Yes, 'convert' is well worth considering. It might work both ways as > well. > Like > > string s = boost::string::convert(-1); // to string > int i = boost::string::convert(str); // from string That would be: string s = boost::string::convert(-1); // to string int i = boost::string::convert<int>(str); // from string And with that we're almost back at the interface of boost::lexical_cast once again. Also the user might want to convert between std::wstring and std::string, and in C++0x, std::u8string, std::u16string, and std::u32string. Regards, Anders Dalvander

1 0

Re: [boost] Review Request: Introduction of boost::string namespace, and string-conversion functions
by Anders Dalvander 14 Feb '09

14 Feb '09

On Fri, Feb 13, 2009 at 07:15 +1000, Vladimir Batov <batov(a)people.net.au> wrote: >> 2. The name of the namespace. >> >> People largely seem content with "boost::string". I think that is a pretty bold statement as your proposal for boost::string was initially posted merely 26 hours earlier. Perhaps this library should be bundled with the Boost String Algorithms Library, and reside in the boost::algorithm namespace. >> 3. Naming of the conversion functions. >> >> The "to/from/is" set seems to sit well with the majority of people. I really like the compactness of to/from/is, but something about it feels strange. It feels a bit backward as boost::string::to converts from a string, and boost::string::from converts to a string. Perhaps parse and to_string (or construct). namespace bsa = boost::algorithm; // or boost::string, or boost::convert, or boost::text, or boost. int i_from_s = bsa::parse<int>(s); std::string s_from_i = bsa::to_string<std::string>(i); >> 8. Throw/No-Throw Behavior. >> >> You might have noticed that the interface above *never* throws anything on failure. >> >> template<class T, class String> >> >> boost::string::value<T> >> >> boost::string::to(String const&, T const& =T()) throw(); >> >> template<class T> >> >> boost::string::value<std::string> >> >> boost::string::from(T const&) throw(); I don't think it is a good idea to have the nothrow exception specification on either boost::string::from nor boost::string::to as the underlying mechanism (iostreams I would believe) or copy-construction of T or construction of String could throw exceptions. Nothrow simply cannot be guaranteed. Regards, Anders Dalvander

2 1