- Boost - lists.boost.org

[1.33] Program_options and Borland
by John Maddock 17 May '05

17 May '05

The following patches get Boost.Program Options compiling with Borland C++ 5.6.4 (it's enough to fix the regex grep test program which was what I wanted). Is it OK to apply these? I can't see how they would cause problems with other compilers: in fact I'm not at all clear how "cmdline" was ever found without the qualifier on other compilers. I haven't looked at the runtime test failures with this compiler yet (has anyone?), Regards, John. RCS file: /cvsroot/boost/boost/boost/program_options/detail/parsers.hpp,v retrieving revision 1.7 diff -r1.7 parsers.hpp 31c31 < : cmdline(to_internal(args)) --- > : detail::cmdline(to_internal(args)) 38c38 < : cmdline( --- > : detail::cmdline( 49c49 < cmdline::set_options_description(desc); --- > detail::cmdline::set_options_description(desc); 59c59 < cmdline::set_positional_options(desc); --- > detail::cmdline::set_positional_options(desc); 67c67 < cmdline::style(style); --- > detail::cmdline::style(style); 75c75 < cmdline::set_additional_parser(ext); --- > detail::cmdline::set_additional_parser(ext); 84c84 < result.options = cmdline::run(); --- > result.options = detail::cmdline::run();

2 2

boost::program_options INI file parsing
by Preston A. Elder 17 May '05

17 May '05

The INI file parser module of program_options needs to be changed. For some reason, the comment delimiter has been changed from ';' to '#'. The bigger problem is this has been taken beyond the first character of the line and there is no escaping ability! The more common INI file comment behavior is: '#' is a comment ONLY if it is the first character of the line ';' is a comment from that point of the line on, unless preceeded by a '\' (or more accurately, an odd number of '\' characters, since you could theoretically do \\\;, to translate to \; when made a string). I have written my own INI parser for my own purposes, but it is not associated with program_options, which makes its usefulness in that context limited (without a lot of extra coding, etc). You can view the source here: http://www.neuromancy.net/viewcvs/Mantra-I/src/file/inifile.cpp?root=mantra… My own implementation does differ from the standard INI file parsing convention in allowing line continuation, ie. Allowing: my_option = some text \ some more text And it is interpreted as 'some text some more text'. One big selling point of my implementation is that it uses boost::spirit (the lexical parser) to do the parsing - so the logic for parsing is encoded in the lexical parsing language, not in code. Theoretically, this means you should be able to use my implementation directly, and adapt the code from IniFile::Load() that uses it for program_options relatively easily, and not have to worry about the parsing logic itself. Otherwise (if you don't want to use a lexical-parser based implementation, or my version specifically), could we please stick to the standards, and allow '#' as a comment ONLY from the beginning of the line, and then ';' from any point in the line (as '#' is treated in the current version) (with the 'escaping' rules). Thanks, -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

6 7

[ptr_container] and bcc32
by Russell Hind 17 May '05

17 May '05

I'm trying the regression tests on bcc32 5.6.4. The first error (and often occuring one with bcc32) is in detail/static_move_ptr.hpp line 70 should be changed from static_move_ptr( const move_ptrs::move_source<static_move_ptr>& src ) to static_move_ptr( const move_ptrs::move_source<static_move_ptr<T, Deleter> >& src ) The next is in detail/reversible_ptr_container.hpp line 117 where typedef null_clone_allocator<allow_null> null_cloner_type; needs to be typedef null_clone_allocator<reversible_ptr_container::allow_null> null_cloner_type; The next is in ptr_vector.hpp line 43: BOOST_PTR_CONTAINER_DEFINE_NON_INHERITED_MEMBERS( ptr_vector, needs to be BOOST_PTR_CONTAINER_DEFINE_NON_INHERITED_MEMBERS( ptr_vector<T,CloneAllocator,Allocator>, And the same in ptr_deque. I guess this is the same for the other ptr_XXXX.hpp files (list,set,map etc). The next error I'm not so sure on is in tutl.cpp line 233: tut1.cpp: Error E2227 tut1.cpp 233: Extra parameter in call to boost::ptr_deque<animal,boost::heap_clone_allocator,_STL::allocator<void *> >::release() in function farm::sell_animal(boost::void_ptr_iterator<_STL::_Deque_iterator<void *,_STL::_Nonconst_traits<void *> >,animal>) Error E2034 tut1.cpp 233: Cannot convert '_STL::auto_ptr<boost::ptr_deque<animal,boost::heap_clone_allocator,_STL::allocator<void *> > >' to 'boost::ptr_container_detail::static_move_ptr<animal,boost::ptr_container_detail::clone_deleter<boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<animal,_STL::deque<void *,_STL::allocator<void *> > >,boost::heap_clone_allocator>::null_clone_allocator<0> > >' in function farm::sell_animal(boost::void_ptr_iterator<_STL::_Deque_iterator<void *,_STL::_Nonconst_traits<void *> >,animal>) Cheers Russell

2 13

RE: [boost] Re: Math constants - updated.
by Simon Li 17 May '05

17 May '05

> > On the other hand, the boost libraries have never, as far as I can > > tell, compromised on interfaces to accommodate programmers > who don't > > like templates or modern C++ idioms. [...] > > Why should the constants library be any different? Why should boost > > give physicists special consideration that most C++ > programmers do not > > get? > > There is nothing extraordinary about it. A library is > designed for clients, and it's sound to listen to what they > desire. If they don't like the product, they'll use > something else. That may or may not matter to you. > True, but a library should also be consistent within itself. The impression I get from Boost is that, as pointed out above, it tries to apply strong principals in the design of its interfaces. It also seems to have no qualms (and arguably makes a point) about using relatively recent c++ features (eg. template specialisations) rather than getting bogged down with established practice. IMHO if a user wanted a library using long established programming practice, they definitely wouldn't be using Boost. However, if for some reason someone really did want the constants library, they'd be free to rewrite it (and even release it) in a format they required... it's not as if the values of constants are likely to change :-) Simon This e-mail message (including its attachments) is private, is intended for the recipient named in it and may contain material which is confidential and privileged. No-one other than the named recipient may read, copy, rely on, redirect, save or alter the message or any part of it or any attachment to it in any way. VMS does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not represent those of VMS unless otherwise specifically stated. While reasonable effort has been made to ensure this message is free of viruses, opening and using this message is at the risk of the recipient.

1 0

[program_options] options_description errors..
by Rene Rivera 17 May '05

17 May '05

For CW-8.3 the program_options DLL doesn't build. The stated reason is because of the missing locale support in the DLL configuration. But the error shown doesn't match that: http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/ou… http://tinyurl.com/dc7mz Which looks like a real problem. It's caused by this line in: const unsigned m_line_length; In the boost::program_options::option_description class. I don't what the intent is for having a const non-static member so I'm not sure how to fix this. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 1

[static_assert] Problems with CodeWarrior 8.3
by Rene Rivera 17 May '05

17 May '05

While investigating this test failure.. http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/ou… http://tinyurl.com/93yz9 Which is a compile-fail test, but compiles successfully with CW-8.3. I narrowed the problem down to this minimal test.. #include <boost/static_assert.hpp> template <std::size_t N> void foo_p() { BOOST_STATIC_ASSERT(N < 3); } int main() { foo_p<5>(); } ..Which compiles without problems. The static_assert code is simple enough so I'm somewhat at a loss here. Don't know how many other tests this affects but it seems kind of important to fix this. So any ideas on what sort of feature/bug this is hitting would be appreciated ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

4 16

Singleton: review
by Gennadiy Rozental 16 May '05

16 May '05

Hi, I know I am slightly late but I am quite busy lately. Problem domain ============ Singleton is just a glorified global variable ( (c) Peter Dimov). Singleton is an old pattern. Used quite frequently. But... from my experience it's really bad idea to try to manage an order of destruction of global variables. Any responsible library designers should prefer explicit teardown procedure. There are many reasons for that from general to specific technical issues, i.e: * class destructors preferably shouldn't be doing anything smart * if teardown procedure is not trivial it's part of normal program flow and should reside within main() bounds * it doesn't seem to be ever portable to rely on order of global variables destruction in different libraries (dynamic or static) * it's unreasonable to expect all global variables to employ single manager facility within bound any reasonably big application * if any teardown procedure fails it's really non-trivial to insure proper destruction for the rest of globals (if possible at all), while reporting an error may be impossible/difficult And so on. Taking attempts to manage destruction order out of the picture we have three known techniques to implement singleton: * don't use any objects at all. use free functions in some namespace with static object in implementation namespace log { void print(...) }; * inline static T& log() { static T inst; return inst; } * inline static T& log() { static T* inst = 0; if(!inst) inst = new inst; return *inst; } should cover majority of users needs. They do not need to be formalized in a form of the library but just could exist in a form of reusable idioms. Specific need could easily be achieved by little variations. Design ===== PBD is not about supplying implementation as template parameter and any kind of "super policies" are never a good idea IMO. They trying to bring simplicity of single template parameter, but does not really bring anything. In trivial cases (use all defaults) design with orthogonal polices is as simple. While any customization attempt immediately shows an advantage of later is more convenient and straightforward. For example if I want to use custom locking policy with submitted singleton I would write: class A : singleton_ex<static_lifetime_ex<instant_creation,my_lock> > {...}; Here I not only need to mention default creation policy, but also strange beast static_lifetime_ex. And I only needed custom lock: class A : singleton<lock<my_lock> > {} ----------------- Inability of the author to clearly recognize orthogonal policies lead to 2 subpolicies with "create" in their name: CreationPolicy and Creator. In addition some instances of a Creator take responsibilities of CreationPolicy. For example assert_creator clearly used to manage *when* to create not *how*. The same with throw_.. and null_... The rest of a "Creator"s are also a misplaced efforts. I do not see why would anyone would need to employ malloc or std::allocator to allocate memory for global variable. In most case it's done once per program lifetime. some contrived phoenix singletons with performance requirements seems to have contradicting design goals and I do not see a need for generic support. Most interesting is that among all of these "creators"/creation_policies I don't see a solution for singleton with non-default constructor. ----------------- Singletons very frequently are the bottleneck of program performance. Any singleton solution couldn't afford significant performance overhead. Submitted design clearly leads to some rotationally inlined functions to be offlined (in addition to extra overhead). For the following trivial class class A { public: void foo() {++i; } private: int i; }; I noticed that A* a = new A; int n = ..; while( n-- > 0) a->foo(); is about 300 times faster then (modify definition above to employ default singleton: class A : public basic_singleton<A>) A::pointer a; int n = ..; while( n-- > 0) a->foo(); (used g++ 3.3.3 on windows) ----------------- Author does admit that multithreading issues were not considered. IMO any singleton design that doesn't cover MT couldn't be accepted as generic. It's quite possible that it may need to be reworked completely to adopt MT issues. And piles of static variable used in implementation only confirm my suspicion. Interface ====== * I do not see a need for these basic_singleton and singleton_ex. Single template singleton with default template parameters would suffice * As I mention in design section interface with single "super policy" is unacceptable IMO * A::pointer interface is not convenient. I do not want to know about any "pointer". It should be either A::instance() or even better simply A; Most frequently I use this idiom (don't remember the name) class A_t { public: A_t& instance() {...} }; namespace { A_t& A = A_t::instance(); } Implementation ========== The submitted solution dropped on unaware user dependency on a <list>, <map>. <new>, <memory>, <cstring>, <cstdlib>, shared_ptr, aligned_storage and many other things. In my experiment simple include <singleton.hpp> leads to 1M of preprocessed code, while preprocessed size of trivial_singleton I am using in Boost.Test is ~6k. This all is a consequence of incorrect design and non-optimal implementation (too many interdependencies). I did not delve deep enough to comment in more details. Also I noticed that even default lifetime policy require partial specialization. Isn't clear why it should be this way. Tests ==== Tests are virtually absent. So there is nothing to comment here. Documentation =========== I guess it's not bad. But it's not my primary area of expertise. As you may figured by now my vote is NO. A would actually vote no even to include this into review queue, but did not paid enough attention at the time. Regards, Gennadiy. P.S. We really need go ahead with "mentor" idea. Also I would propose to enforce some "cool off" time (as 4 month since initial "query of interests point" is clearly not enough). May be it could enhance quality of submissions we invest time reviewing

4 5

Re: [boost] Re: char[] support in Boost.Range
by dan marsden 16 May '05

16 May '05

IMO the char[] as string default looks cool in the examples from boost for each and the string algorithms, but I cannot think of many practical examples of where I would have used it in my code. If I'm handing strings that I want to do something interesting with, I'll probably have read them into std::string as I usually cannot predict their lengths. Of course my experience may be atypical. Maintaining the uniformity of treatment of arrays would seem to me to be of more benefit in generic code. --- Eric Niebler <eric(a)boost-consulting.com> wrote: > > Pavol Droba wrote: > > On Sun, May 15, 2005 at 08:17:15PM -0400, David > Abrahams wrote: > > > >>"Thorsten Ottosen" <nesotto(a)cs.auc.dk> writes: > >> > >> > >>>| I'd like to leave it for the discussion. Right > now it seems, that > >>>| most of the people that entered discussion > prefer c-array view. > >>>| I would prefer c-string view, but I'm probably > biased by the fact > >>>| that I'm the author of StringAlgo library. > >>> > >>> I prefer the string view too. > >> > >>I just have one thing to say: vector<bool>. > >> > > > > > > Pardon me, but somehow I cannot figure out the > point here. Can you please > > explain the me the connection to vector<bool> > > > > > vector<bool> creates all kinds of problems because > generic code can't > make assumptions about the behavior of vector<T>. > vector<bool> is widely > regarded as a Bad Move. Dave is saying that treating > char[] different > than, say, int[] is inviting the same sorts of > problems. It will make it > difficult to deal with T[] in generic code. > > I agree with Dave. > > -- > Eric Niebler > Boost Consulting > www.boost-consulting.com > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

[string_algo] vc7 help needed
by Pavol Droba 16 May '05

16 May '05

Hi, Is there anybody with an access to vc7, who can help me with solving out remainig compatibility issues in string_algo library? There is just one last outstanding issue: http://tinyurl.com/cvl8x I can probalby get to fixing it, but because I'm not 100% sure what is the problem, I can only try and see the result. Unfortunaletely, it take very long to discover an error. Thanks. Best regards, Pavol.

1 0

[graph] libbgl-viz.lib #line problems work around...
by Rene Rivera 16 May '05

16 May '05

The problems that come up with some compilers not handling the #line directive: http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/ou… http://tinyurl.com/9jwue Can be worked around by not having the #line directives generated. All that's needed is adding the "-L" switch to have flex omit them. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 0