- Boost-users - lists.boost.org

Re: [Boost-users] [Boost String Algorithms library] ireplace_all bug with character arrays]
by Pavol Droba 13 Jan '08

13 Jan '08

Hi, Thorsten Ottosen wrote: > shunsuke skrev: >> Richard Turrin wrote: >>> Hi, >>> >>> I've encountered a bug with ireplace_all from the Boost String >>> Algorithms library for version 1.35. If I pass a character array for >>> the Format argument, the function ignores the null terminator and >>> instead uses the entire array minus the last character to replace the >>> occurrences of the Search string in the Input parameter. However, if >>> I provide a pointer to a character array, the string replacement is >>> done as expected. >>> >>> When I stepped into the code, I came across the following lines >>> (excerpt from /trunk/boost/range/as_literal.hpp): >>> >>> template< class Char, std::size_t sz > >>> inline iterator_range<const Char*> as_literal( const Char (&arr)[sz] ) >>> { >>> return boost::make_iterator_range( arr, arr + sz - 1 ); >>> } >>> >>> There is no check for a null terminator. Nor did I find one after >>> this function returned. I think the author here assumed that a >>> caller would always pass in a character array of the right size. >> >> Character array seems to have three views. >> >> 1. array: SIZE("ab\0c") == 5; >> 2. literal: SIZE("ab\0c") == 4; >> 3. null-terminated: SIZE("ab\0c") == 2; >> >> Both 2. and 3. is forced into boost::as_array. >> "One name, two facilities" usually makes trouble. >> IMO, `as_c_str` should have been added for 3. > > I agree we could add a new function. Can we come up with a better name > than as_c_str()? > > Or should we simply make as_literal() scan the array? > I think, that as_literal should behave the same way for character arrays and for c-string. Different behaviour is unexpexted here. The only difference that could be beneficial is that for arrays, the scanning for nulls can be bounded to protect agains the buffer overruns. Regards, Pavol.

1 0

/trunk/boost/range/is_literal.hpp: preprocessor bug
by Richard Turrin 13 Jan '08

13 Jan '08

Hi, Sorry for being a nitpicker here: There is a preprocessor bug in /trunk/boost/range/is_literal.hpp in the SVN repository. Line 18 has the following statement: #if BOOST_NO_FUNCTION_TEMPLATE_ORDERING It should really read: #ifdef BOOST_NO_FUNCTION_TEMPLATE_ORDERING This might manifest itself as compile errors in some of the older compilers (Metrowerks Code Warrior 5.3, SunPro 5.0, and Microsoft Visual C++ 7.0). Rich Turrin

2 1

Re: [Boost-users] [boost] Review: Switch library
by Stjepan Rajko 13 Jan '08

13 Jan '08

On Jan 12, 2008 5:22 PM, Joel de Guzman <joel(a)boost-consulting.com> wrote: > > For the record, I am changing my vote to "yes". I'm quite happy > with the response to my concerns. I am very confident Steven > will produce an amazing library from the very constructive > discussions so far. I'm obviously very adamant in my posts, > the reason being that I really need such a library now but I > have certain use-cases that I need to be handled by the library, > *now*, and not later in another lifetime. I can't wait for > another review or another library to come along that's closer > to my needs. I believe the switch_ library can, with additional > thought and design, handle my needs. > Thank you, Joel. Your contribution to this review is greatly appreciated. I do believe that without addressing your concerns the library would not be a true Boost.Switch. Regards, Stjepan

1 0

libXXX
by Lars Schouw 13 Jan '08

13 Jan '08

I am having a problems with the boost libs I have build the names does not start with lib When I build boost using bjam "-sTOOLS=vc9" install I got a bunch of .lib files in c:\boost\lib e.g. boost_thread-vc90-mt-1_35.lib but when I build my library against tghis if fails to link since it needs a file libboost_thread-vc90-mt-1_35.lib What am I doing wrong? I am using boost from subversion, Windows Vista and Visual Studio 2008 Thanks in advance Lars ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

3 2

boost.time_series
by Kim Kuen Tang 13 Jan '08

13 Jan '08

Hello everybody, i want to start using the time series library. But unfortunately i've got compiler errors while compiling the time_series\libs\time_series\example\main.cpp file with visual studio compiler 2005. ------ Erstellen gestartet: Projekt: example, Konfiguration: Debug Win32 ------ Kompilieren... main.cpp using native typeof c:\Boost\src\time_series\boost/sequence/size.hpp(26) : error C2143: Syntaxfehler: Es fehlt ';' vor '<' c:\Boost\src\time_series\boost/sequence/size.hpp(32): Siehe Verweis auf die Instanziierung der gerade kompilierten Klassen-template "boost::sequence::impl::size<S,T>". c:\Boost\src\time_series\boost/sequence/size.hpp(26) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt. c:\Boost\src\time_series\boost/sequence/size.hpp(26) : error C2039: 'type': Ist kein Element von '`global namespace'' c:\Boost\src\time_series\boost/sequence/size.hpp(26) : error C2238: Unerwartete(s) Token vor ';' c:\Boost\src\time_series\boost/sequence/size.hpp(28) : error C2143: Syntaxfehler: Es fehlt ';' vor '(' c:\Boost\src\time_series\boost/sequence/size.hpp(28) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt. c:\Boost\src\time_series\boost/sequence/size.hpp(29) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt. Das Buildprotokoll wurde unter "file://c:\Boost\src\time_series\libs\time_series\example\Debug\BuildLog.htm" gespeichert. example - 7 Fehler, 0 Warnung(en) ========== Erstellen: 0 erfolgreich, Fehler bei 1, 0 aktuell, 0 übersprungen ========== The errors might come from clr-syntax in the quellcode since the compiler doesnt support the response file that contains the clr-syntax without the \clr option. Perhaps anybody can give me a hint how to solve this problem?

1 0

[iterator_facade] Help with const iterator for binary file
by nicola 12 Jan '08

12 Jan '08

Hi, I have a class modeling a record-based read-only binary file and I have written a random access iterator based on iterator_facade to iterate over the records. The class looks like this: class my_binary_file { public: typedef std::string key_type; typedef unsigned int value_type; typedef std::pair<key_type, value_type> record_type; private: class my_binary_file_iterator : public boost::iterator_facade< my_binary_file_iterator, my_binary_file::record_type const, boost::random_access_traversal_tag, my_binary_file::record_type&, int> { public: my_binary_file_iterator() : rec_num_(0), ff_ptr_(0) { } explicit my_binary_file_iterator(my_binary_file* ff, unsigned int n) : ff_ptr_(ff), rec_num_(n) { } private: friend class boost::iterator_core_access; unsigned int rec_num_; my_binary_file* ff_ptr_; mutable my_binary_file::record_type record; void increment() { ++rec_num_; } void decrement() { --rec_num_; } void advance(int n) { rec_num_ += n; } int distance_to(const my_binary_file_iterator z) const { return z.rec_num_ - this->rec_num_; } bool equal(my_binary_file_iterator const& other) const { return this->ff_ptr_ == other.ff_ptr_ && this->rec_num_ == other.rec_num_; } const my_binary_file::record_type dereference() const { ff_ptr_->seekg(rec_num_); my_binary_file::key_type key; my_binary_file::value_type val; ff_ptr_->get_record(key, val); record = std::make_pair(key, val); return record; } }; public: typedef my_binary_file_iterator iterator; iterator begin() const { return iterator(this, 0); } iterator end() const { return iterator(this, num_records_); } // Opens a binary file for reading explicit my_binary_file(const std::string& path); ~my_binary_file(); operator void*() const; bool operator!() const; // Reads the record at the current position bool get_record(key_type& k, value_type& v); std::ios::pos_type tellg() const { return fs_.tellg(); } void seekg(unsigned int n) { fs_.seekg(start_record_ + std::ios::off_type(n * record_size_), std::ios::beg); } private: boost::filesystem::path pathname_; mutable boost::filesystem::fstream fs_; std::streampos start_record_; key_type::size_type key_size_; unsigned int record_size_, num_records_; }; Unfortunately, when I try to compile my project, I get the following error: error: invalid conversion from 'const frequency_file* const' to 'frequency_file*' I have tried several variants of my code, but without success. I think I'm missing something pretty obvious in my definition of my_binary_file_iterator, but I can't get out of it. Anyone can help? Regards Nicola

2 4

Re: [Boost-users] [boost] Switch library review - summary of discussion so far
by Stjepan Rajko 12 Jan '08

12 Jan '08

On Jan 12, 2008 8:25 AM, Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > Stjepan Rajko wrote: > > > * Default default behavior > > > > Alexander Nasonov has also > > indicated that a throwing default case can cause inefficiency, even > > when it is guaranteed not to be invoked. > > Wouldn't an assert be more suited then? > If default behaviour is unspecified and yet invoked, terminating sounds > like a good thing to do. > An assert was considered as well - e.g., see: http://groups.google.com.by/group/boost-list/msg/0d73059086974920 This behavior is also analogous to the standard switch statement - if the default label is omitted, and none of the cases is matched, no termination occurs. > > > There has been a lengthy discussion on the underlying design of the > > library, what it should offer, and whether the name of the library is > > appropriate. There are two types of designs that have been put > > forward as being appropriate and/or necessary for a Boost.Switch > > library. On one hand, there is the submitted design (labeled "A" in > > recent postings), which takes the switch cases in an MPL sequence and > > a single function object containing implementations of all cases. > > Joel de Guzman has proposed another design (labeled "B"), in which the > > switch cases are specified separately and allow a different function > > to be used for each case. > > It seems to me that B is convertible to A... > There would be no need to duplicate the interface then. > Under the right details, yes: http://thread.gmane.org/gmane.comp.lib.boost.user/32628/focus=169957 Tobias offered formal transforms between the two: http://groups.google.com.by/group/boost-list/msg/1b1fa0084cd7baad > An utility which converts B to A would be quite useful though, even > outside of boost.switch. > Thanks for your comments! Stjepan

1 0

[Boost.Serialization] Questions about the New Release of Boost.Serialization 1.36
by Marc Viala Perso 12 Jan '08

12 Jan '08

Hello, This mail is about Boost.Serialization and more specifically the new release of this library, tagged as 1.36, which can be found via the link: www.rrsd.com <http://www.rrsd.com/> ; I've found this link into a specific thread about Serialization and multi-threading. Last week, I've downloaded this new release and tested it in my environment - Windows XP and Visual C++ 7.1.6030; the compilation was done against Boost.1.34.1 trunk and was running with success but I've noticed that some, "not all", old binary archives generated w/ Boost.Serialization 1.34.1 can't be restored with this new version of Boost.Serialization. When I compare the binary files with a file binary comparison software utility it seems that the binary formats between these two versions are not comparables. I would like to know if this behaviour is "normal": i.e. the binary formats between 1.34.1 and 1.36 are not strictly equivalent and that an old binary archive can be declare "not compatible" w/ the 1.36 release. Is this right? Furthermore, is it possible to have the same behaviour w/ an XML or Text Archive format? Could we guarantee a sort of compatibility in the future? And more generally speaking, what is the policy for insuring compatibility between new releases of Boost.Serialization? Best regards, Marc VIALA

5 15

Solve linear system (tridiagonal matrix)
by nisha kannookadan 12 Jan '08

12 Jan '08

Hi everybody I need to solve a linear system Ax = b, where A is a tridiagonal matrix, is there an easy way to do it? I programmed an algo, which computes the inverse of the tridiagonal matrix with the usmani-algo and uses prod then, but this is quite time intense. I want to use the lapack bindings, but I dont get along with it. Im bit confused, if I need to install something additional to it, the way I tried out gesv, its not working and I get error msgs. I searched through out the www, but its hard to find good info. If somebody has already the code to solve linear equations with lapack, I would thankful, if he could post it here. Thank you Nisha K _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

Switch library review - summary of discussion so far
by Stjepan Rajko 12 Jan '08

12 Jan '08

I will try to summarize the discussions happening so far on the Switch library under review - maybe this will be helpful to those considering joining the discussion and submitting a review. * Documentation All reviewers have noted that the documentation could be improved - e.g., additional examples, performance stats, as well as more explanation of the types involved and how they are used. * Return type Tobias Schwinger suggested that the return type should be specified explicitly in the switch_ call, rather than inferring it from the function object, and this is now a part of the recent designs being discussed. Joel de Guzman also suggested that if a version of switch_ should infer the return type, that return type should be a Boost.Variant of the types returned by each of the cases. * Default default behavior If the default behavior is left unspecified, switch_ should invoke the default constructor of the return type in the default case, rather than throwing an exception. This was suggested by Tobias Schwinger after the issue was raised by Dan Marsden. Alexander Nasonov has also indicated that a throwing default case can cause inefficiency, even when it is guaranteed not to be invoked. * Fall-through Alexander Nasonov pointed out the lack of fall-through capability in the submitted implementation. Fall-through has been incorporated into the recent designs being discussed. * Allowing void-returning function objects for the default case with a non-void returning switch Tobias Schwinger mentioned the possibility of allowing default case function objects of void return type even when the switch return type is non-void, as long as the function object call does not return. This would be useful, for example, if the function object is guaranteed to throw. There is still some discussion on whether determining if the return type is void can be done efficiently. * Design There has been a lengthy discussion on the underlying design of the library, what it should offer, and whether the name of the library is appropriate. There are two types of designs that have been put forward as being appropriate and/or necessary for a Boost.Switch library. On one hand, there is the submitted design (labeled "A" in recent postings), which takes the switch cases in an MPL sequence and a single function object containing implementations of all cases. Joel de Guzman has proposed another design (labeled "B"), in which the switch cases are specified separately and allow a different function to be used for each case. Design "A" is better suited for situations in which the number of cases is determined by a compile time constant, while "B" is more appropriate for many use cases, and provides more flexibility and a more familiar syntax. It seems that a consensus has been reached that this library could offer either both interfaces in different layers, or an interface that can be used in different ways for different uses (based on a common concept capturing case sequences). (Apologies if I have missed or misinterpreted something) More reviews/votes would be extremely welcome! Regards, Stjepan

1 0