January 2008 - Boost-users - lists.preview.boost.org

FW: Export control classification number (ECC) for boost
by matthias.jaeschke＠nsn.com 13 Jan '08

13 Jan '08

> Hi, > > We are using boost in one of our products, and are now in the process of collecting the information needed to export it to other countries. > > Can you tell me what the U.S. Export Control Classification Number (ECCN) for boost is, and whether a license exception may be used for it? > > If you don't know the US ECCN, can you tell me whether any US citizens or people living in the U.S.A. have contributed code to boost? > > In addition to the U.S. ECCN, there is also a German "ECCN", which is called the AL Number. Can you tell me what the AL Number is for boost? > > To better understand the meaning of the U.S. ECCN, please check the following webpage: > http://www.bis.doc.gov/Licensing/Do_I_NeedAnECCN.html > > Many thanks, > Matthias Jäschke / Peter Niggemeier > Nokia Siemens Networks > > > Matthias Jäschke > Senior Quality Engineer > > Nokia Siemens Networks Deutschland GmbH > Heltorfer Str. 1 > D-40472 Düsseldorf > Phone: +49-151-55153859 > Fax +49-211-9412-3383 > E-mail: matthias.jaeschke(a)nsn.com > > Sitz der Gesellschaft: Bochum / Registered office: Bochum > Registergericht: Bochum / Commercial registry: Bochum, HRB 11180 > Geschäftsführung / Managing Directors: Dr. Ulrich Halka, Lydia Sommer > _________________________________________________ > Important Note: This e-mail and any attachment are confidential and may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachment or disclose the contents to any other person. Thank you for your cooperation. > > Wichtiger Hinweis: Dieses E-Mail und etwaige Anlagen können Betriebs- oder Geschäftsgeheimnisse, dem Anwaltsgeheimnis unterliegende oder sonstige vertrauliche Informationen enthalten. Sollten Sie dieses E-Mail irrtümlich erhalten haben, ist Ihnen der Status dieses E-Mails bekannt. Bitte benachrichtigen Sie uns in diesem Fall sofort durch Antwort-Mail und löschen Sie dieses E-Mail nebst etwaigen Anlagen von Ihrem System. Ebenso dürfen Sie dieses E-Mail oder seine Anlagen nicht kopieren oder an Dritte weitergeben. Vielen Dank. > >

2 1

ptime constructor
by Miguel Lopes 13 Jan '08

13 Jan '08

Hi all, I have a small question about ptime class usage. I am currently working on an old project that uses Boost library; unfortunately, when I build and run the project executable some exceptions are thrown. I found out that some parts of the project are trying to create ptime objects like this: *ptime(time_from_string(string(sz)))* That line throws an exception, when sz is empty. So my question is: Is there any version (Boost version) of ptime class that accepts an empty string as argument? The problem is that I need to investigate which version of Boost, is being really used in the project makefile and with all versions of Boost that line throws the exception. On the other hand I have a precompiled binary of the project, and under the same data input conditions, it works perfectly, that is, even with empty dates no exceptions are thrown. Kind Regards, Miguel Lopes

2 1

Re: [Boost-users] Review: Switch library
by legalize+jeeves＠mail.xmission.com 13 Jan '08

13 Jan '08

[Please do not mail me a copy of your followup] boost(a)lists.boost.org spake the secret code <fmblls$ees$1(a)ger.gmane.org> thusly: >I also urge Steven to pursue the dynamic_switch idea I posted >which employs perfect hashing at compile time whereby allowing >equivalent or faster than a switch dispatch at runtime where >the cases are dynamic (instead of compile time constants). I just want to say that I think this approach is so amazingly cool, my socks are not only blown off, but orbiting the planet :-). -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

4 4

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