- Boost - lists.boost.org

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

RE: [boost] Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 16 May '05

16 May '05

> -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: 13 May 2005 15:51 > To: boost(a)lists.boost.org > Subject: [boost] Re: Non-intrusive serialization with VC2003 (7.1) > > Try putting your function inside the namespace D2 I did. I also tried putting it in the global namespace. Same error. > Robert Ramey > > Marcin Tustin wrote: > > I'm trying to use the serialization and archive libraries, and I'm > > having a bit of trouble getting non-intrusive serializaton > to work; I > > keep getting the error > > "c:\boost_1_32_0\boost\serialization\access.hpp(106): error C2039: > > 'serialize' : is not a member of 'D2::Message'". My guess > is that for > > some reason the "long int" hack isn't working properly. I have > > serialize methods in the boost::seralization namespace like this: > > > > namespace boost { > > namespace serialization { > > template<class Archive > > > static void serialize(Archive & ar, const > D2::Message& g, const > > unsigned int version) > > { > > //... > > } > > > > } }; > > > > Which are textually before any use of the library, as far as I can > > tell. > > > > Any help would be much appreciated. > > > > Marcin Tustin > > IT Innovation Centre > > 2 Venture Road > > Chilworth Science Park > > Southampton, SO16 7NP, UK > > > > tel: +44 23 8076 0834 > > fax: +44 23 8076 0833 > > > > mailto:mt@it-innovation.soton.ac.uk > > http://www.it-innovation.soton.ac.uk > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > >

2 1

[Test Documentation] small error in HTML...
by Kevin Wheatley 16 May '05

16 May '05

libs/test/doc/usage/msvc_net.html contains a link to: post_build_event.JPG but the real file is with a lowercase extension at least it is on the main boost site, plus the www.boost-consulting.com/boost/ CVS 'reflector'. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |

2 1

Re: [boost] Visual Studio 2005 Beta 2 + Multi Index
by JOAQUIN LOPEZ MU?Z 16 May '05

16 May '05

----- Mensaje original ----- De: JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> Fecha: Domingo, Abril 24, 2005 2:07 pm Asunto: Re: [boost] Visual Studio 2005 Beta 2 + Multi Index > > > ----- Mensaje original ----- > De: Gordon Smith <schmoo2k(a)hotmail.com> > Fecha: Viernes, Abril 22, 2005 5:43 pm > Asunto: [boost] Visual Studio 2005 Beta 2 + Multi Index > > > The following stdafx.h for a vanilla console app kills the beta > 2 > > compiler > > (I think it creates a corrupt PCH file): > > > > #pragma once > > > > #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from > > Windows > > headers > > #include <windows.h> > > #include <tchar.h> > > > > // BOOST --- > > #include <boost/multi_index/sequenced_index.hpp> > > #include <boost/multi_index/ordered_index.hpp> > > > > Hi Gordon, excuse my late answering, somehow I just didn't see > your post amidst the current flow of messages. > > Did this work for MSVC 8.0 beta 1? I'm afraid I cannot help > much here except suggest that you try to report this to > the MSVC dev team: > > http://lab.msdn.microsoft.com/productfeedback/ > > Also, please try deleting all intermediate files before > doing a fresh compile --this is sometimes helpful specially > in regard to PCHs. If you make any progress or need some > help please keep me informed. > > Also, I forgot to mention: did you play with the /Zm option? http://msdn2.microsoft.com/library/bdscwf1c(en-us,vs.80).aspx Please keep me informed. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3