- Boost - lists.boost.org

thread_specific_ptr suggestion
by Howard Hinnant 16 May '04

16 May '04

thread_specific_ptr<T> is the thread local data storage mechanism of the excellent (thanks William!) boost threads library. thread_specific_ptr<T> isn't capable of supporting custom deleters for good reason. The deleter function must be a real function (not a functor) so as to work well with various OS level threading api's (like Posix threads). So the pointer passed into a thread_specific_ptr<T> (via reset) must be free-able with delete. thread_specific_ptr<T> could offer a custom deleter constrained to be a function pointer instead of a more general deleter policy (functor), but that seems like it would be of limited functionality and frankly just not much fun in a C++ environment. However, there is one case where another deleter policy is common enough to warrant special attention: delete []. So I suggest a partial specialization for thread_specific_ptr: template <class T> class thread_specific_ptr<T[]> { public: thread_specific_ptr(); ~thread_specific_ptr(); T* get() const; T& operator[](std::size_t i) const; T* release(); void reset(T* p = 0); private: thread_specific_ptr(const thread_specific_ptr&); thread_specific_ptr& operator=(const thread_specific_ptr&); }; In this case, any pointers owned by thread_specific_ptr<T[]> must be free-able with delete []. thread_specific_ptr<int> value; thread_specific_ptr<int[]> array_value; void foo() { value.reset(new int); array_value.reset(new int [3]); ... } -Howard

2 1

[Spirit] Grammar as parser problem
by David B. Held 15 May '04

15 May '04

In the program below, I am having trouble using a grammar as a parser for a rule. In particular, I get an error with gcc 3.3 on the line: Module_ = *Statement; The code below is fully self-contained. Dave //-------------------------------------------------------------------------- - #include <stdexcept> #include <string> #include <iostream> #include <boost/spirit/core.hpp> #include <boost/spirit/iterator/file_iterator.hpp> #include <boost/spirit/attribute.hpp> #include <boost/spirit/tree/ast.hpp> //-------------------------------------------------------------------------- - using namespace boost::spirit; using namespace phoenix; //-------------------------------------------------------------------------- - typedef file_iterator<char> TFileIterator; typedef node_val_data<TFileIterator>::const_iterator_t TNodeIterator; typedef tree_match<TFileIterator>::node_t node_t; typedef tree_match<TFileIterator>::parse_node_t parse_node_t; typedef tree_match<TFileIterator>::container_t trees_t; //-------------------------------------------------------------------------- - enum TRuleID { idModuleTag, idDeclarationTag, idIdentifierTag }; //-------------------------------------------------------------------------- - struct Statement : public grammar<Statement> { template <typename ScannerT> struct definition { public: // Types template <TRuleID ID> struct TRule { typedef rule<ScannerT, parser_context, parser_tag<ID> > type; }; public: // Definition definition(Statement const&) { Declaration_ = root_node_d[Identifier_] >> Identifier_ >> discard_node_d[ch_p(';')]; Identifier_ = lexeme_d[(alpha_p | '_') >> *(alnum_p | '_')]; } typename TRule<idDeclarationTag>::type const& start(void) const { return Declaration_; } public: // Rules typename TRule<idDeclarationTag>::type Declaration_; typename TRule<idIdentifierTag>::type Identifier_; }; }; //-------------------------------------------------------------------------- - struct Module : public grammar<Module> { template <typename ScannerT> struct definition { public: // Types template <TRuleID ID> struct TRule { typedef rule<ScannerT, parser_context, parser_tag<ID> > type; }; public: // Definition definition(Module const&) { Module_ = *Statement; } public: // Rules typename TRule<idModuleTag>::type Module_; } }; //-------------------------------------------------------------------------- - void Generate(std::string const& File); //-------------------------------------------------------------------------- - int main(int argc, char* argv[]) { if (argc > 1) { Generate(argv[1]); } else { std::cout << "No source file specified." << std::endl; } return 0; } //-------------------------------------------------------------------------- - tree_parse_info<TFileIterator> Parse(std::string const& File) { TFileIterator Begin(File.c_str()); TFileIterator End = Begin.make_end(); static Statement Parser; return ast_parse(Begin, End, Parser, space_p); } //-------------------------------------------------------------------------- - void Generate(std::string const& File) { tree_parse_info<TFileIterator> Info = Parse(File); if (!Info.full) { std::cerr << "Parsing failed\n"; std::cerr << "stopped at: \"" << *Info.stop << "\"\n"; return; } node_t const& node = Info.trees[0]; try { std::cout << std::string(node.value.begin(), node.value.end()) << std::endl; } catch (std::runtime_error const& e) { std::cerr << e.what() << std::endl; } } //-------------------------------------------------------------------------- - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.683 / Virus Database: 445 - Release Date: 5/12/2004

1 2

big_integer numeric error
by Joel Young 15 May '04

15 May '04

I believe there is a numeric error in big_integer. I am working to isolate it to a single operation. I can find the error now because the library is fast enough to run one of my sims. I get a different value when running with rational<big_integer> then with any of these choices (which give identical results) rational<long long> rational<big_integer (cln)> rational<big_integer (gmp)> cln::cl_RA Not that it is much use but the wrong answers are: Inonsistent Value: 38485535445/562949953421312 6375930541/562949953421312 Consistent Value: 42780502741/562949953421312 10670897837/562949953421312 Again, I'll try to narrow down the exact point where things go wrong but it might take a while. Joel

3 4

Re:[boost] [serialization] function pointers
by Robert Ramey 15 May '04

15 May '04

Christoph Ludwig wrote: > Is it possible with the serialization library to serialize function > pointers and pointers to member functions? If it is not directly > supported, is there a "best practice" workaround? I didn't find this > info in the documentation. There's no information in the documentation about this. I'm not sure what it would mean to serialize a function pointer. Its possible it might be done by just defining non-intrusive serialize(ar, fp) as and empty function. I would have to think about this. However, I do believe that serialization of a function object would present no new issues. Then there is the possibility of creating a wrapper which makes a function object out a function pointer and serializing that. I'm sure already contains some objects of this nature. Please investigate this and report back. > BTW: Is the version of the serialization library available at > http://www.rrsd.com/boost/ still the most recent or is there a post > review version? Yes, a post review version hasn't been submitted yet. Robert Ramey

3 2

RE: [boost] Re: [iterator facade] Why is dereference const?
by Max Khesin 15 May '04

15 May '04

> -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > > > > Actually, I like the one based on Vladimir Prus much better > than the one I > > wrote, so here is the current: > > I don't love it. Count is overkill; you only need a bool. Also it > only works when value_type is default-constructible. There's a > reason I suggested optional<value_type>, you know ;-) But Neal wants the function to be called count times; how would you do this without a count? thanks\max This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

RE: [boost] Re: Latest ScopeGuard
by Max Khesin 15 May '04

15 May '04

This is funny in the light of Robert R.'s remark that you boostified his version. Anyway it seems like a high priority that the more experienced boost guys should get a basic version of this pushed through before we get 20 slightly different versions sneaking in via the libraries being incorporated into boost. Consensus may be more important than perfection at this stage. max. -----Original Message----- From: Pavel Vozenilek [mailto:pavel_vozenilek@hotmail.com] Sent: Friday, May 14, 2004 2:02 PM To: boost(a)lists.boost.org Subject: [boost] Re: Latest ScopeGuard "Max Khesin" <MKhesin(a)liquidnet.com> wrote: > I recall there have been sevral attempts at a boostified version of Andrei > A. ScopeGuard. I want to start using this functionality and was wondering > a) if there is any consensus about best/most boost-consistent implementation > b) if there is there is a version in the library approval pipeline (or some > definite plans for including this functionality in boost) > thanks, > Multi index container library includes ScopeGuard (almost verbatim from Andrei) until some boost-wide solution appears. /Pavel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

4 4

Questions about the timestamp webbot
by JOAQUIN LOPEZ MU?Z 15 May '04

15 May '04

Reading the documentation guidelines by Bill Kempf I stumbled upon the suggestion of using the so called timestamp "webbot": <p>Revised  01 January, 2001  </p> I've got some questions about this: 1. Is this feature still supported by the Boost web site? 2. What is the checksum stuff? Googling for this yield no info. 3. Where can I find info on the date formats supported 4. Suppose I've got an HTML doc written on May 10 like this:  10 May, 2004  and later on, say May 15th, I update some of its contents and commit the changes to the CVS *without manually replacing the revision date*. Which of these two possibilities happens (if any)? 3a. When I retrieve the HTML doc from CVS again, it has automatically been changed to  15 May, 2004  3b. The "10 May, 2004" stays untouched though it is correctly displayed as "15 May, 2004" when the doc is served by Boost web site. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Re: static sized strings
by Reece Dunn 15 May '04

15 May '04

John Nagle wrote: > Is the code in the Boost sandbox yet? Given the various possible implementation strategies and the fact that the code is currently likely to change rapidly, I have uploaded it to the Boost files section (in the CCompat folder) with the associated files. I will move it to the sandbox when the major issues have been settled and the class is more complete. I have added an mpl implementation of a zero-buffer check, so it will be picked up at compile-time, rather than at run-time with a message similar to: error: 'value' is not a member of zero_buffer_error. Beside that change, I haven't had chance to process the other comments/ideas that have come up. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

RE: [boost] Re: Latest ScopeGuard
by Max Khesin 14 May '04

14 May '04

I understand, and I wish I could do this myself, but I do not feel qualified at this point. I am just pointing out that this is going to become a problem due to inconsistent versions of the same idiom making it into the boost via sub-libraries. So if someone qualified wants to propose (X || Y || ScopeGuard) they should consider this as a factor. This is what I meant. regards, max > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Friday, May 14, 2004 4:23 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Latest ScopeGuard > > > Max Khesin <MKhesin(a)liquidnet.com> writes: > > > This is funny in the light of Robert R.'s remark that you boostified > > his version. Anyway it seems like a high priority that the more > > experienced boost guys should get a basic version of this pushed > > through before we get 20 slightly different versions sneaking in via > > the libraries being incorporated into boost. Consensus may be more > > important than perfection at this stage. max. > > We don't "get ____ pushed through", though. Someone has to make a > library proposal. > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

RE: [boost] Re: Finding operator==(directory_iterator&, directory_iterator&)
by DY, JERRY U (SBCSI) 14 May '04

14 May '04

I'm learning so much reading at the boost code, which is one of the reasons why I'm getting so excited. Please bear with my questions. The compiler appears to be having a problem with matching this operator== due to the return type, it can't find enable_if_interoperable<...>::type. Here's how aC++ expanded the macro BOOST_ITERATOR_FACADE_RELATION from your previous e-mail. template < class Derived1, class V1, class TC1, class R1, class D1 , class Derived2, class V2, class TC2, class R2, class D2 > inline typename detail::enable_if_interoperable< Derived1, Derived2 , typename mpl::apply2<detail::always_bool2,Derived1,Derived2>::type >::type operator ==( iterator_facade<Derived1, V1, TC1, R1, D1> const& lhs , iterator_facade<Derived2, V2, TC2, R2, D2> const& rhs) { typedef ::boost::static_assert_test< sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( ( is_interoperable< Derived1, Derived2 >::value ) ) >)> boost_static_assert_typedef_622; return iterator_core_access::equal( static_cast<Derived1 const&>(lhs) , static_cast<Derived2 const&>(rhs) , is_convertible<Derived2,Derived1>() ); } enable_if_interoperable is declared as follows. It's empty, and since it inherits privately from enable_if, none of enable_if's members would be visible. Now where is the struct member "type"??? template <class Facade1, class Facade2, class Return > struct enable_if_interoperable: ::boost::iterators::enable_if< mpl::or_< is_convertible<Facade1, Facade2> , is_convertible<Facade2, Facade1> >, Return > { }; Thanks! -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Wednesday, May 12, 2004 2:54 PM To: boost(a)lists.boost.org Subject: [boost] Re: Finding operator==(directory_iterator&,directory_iterator&) "DY, JERRY U (SBCSI)" <jd2419(a)sbc.com> writes: > In trying to compile the filesystem library, I'm getting an error that > the compiler cannot find the operator== for the following function: > > bool is_empty_directory( const fs::path & dir_path ) > { > return fs::directory_iterator(dir_path) == end_itr; > } > > aCC-C++-action > ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/acc/debug > /operations_posix_windows.o > Error 226: > "../../../libs/filesystem/build/../src/operations_posix_windows.cpp", > line 176 # No appropriate function found for call of 'operator =='. > > class directory_iterator doesn't declare it, neither do ancestors > iterator_facade and iterator_facade_types. Can't find free function for > operator==(directory_iterator&, directory_iterator&), > operator==(iterator_facade&, iterator_facade&), > operator==(iterator_facade_types&, iterator_facade_types&) or any of its > variants. Is it using the default compiler-generated operator== in > directory_iterator? The compiler is wrong. There is an operator== that takes two iterator_facade specializations in iterator_facade.hpp, generated by this line: BOOST_ITERATOR_FACADE_RELATION(==, return, equal) Try preprocessing the source if you need to see it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1