- Boost - lists.boost.org

Logo: version for candidate libs
by rasmus ekman 15 Mar '05

15 Mar '05

When the winning logo is selected, ask the designer to please create a version with the word "Candidate" stamped over or just below. It could also be somewhat greyed-out or whatever. This logo may be used in docs for libraries at all steps until acceptance; the Boost logo should be reserved for acccepted libs. (sorry if already suggested - haven't read all posts) re

2 2

Re: FSM Review
by Johannes Brunen 15 Mar '05

15 Mar '05

David B. Held and Paul A Bristow wrote: >> It will be a sad day when Boost rejects a good library because >> another library in a different part of the design space is >> theoretically faster. > IMO this hits the nail on the head. > As with too many reviews, there have been very interesting, > but essentially speculative, alternative ideas, > produced not during the 'proposed library' development phase, > but somewhat destructively and at the 'last minute'. > > These should not be a reason for rejection, > but should spur development of different > (and hopefully in some ways better) ideas to submit in future. I would like to second that. With best regards Johannes Johannes Brunen DataSolid GmbH Nobelstr. 3-5 41189 Mönchengladbach Tel.: 02166 / 955 789 Email: JBrunen(a)DataSolid.com Internet: www.DataSolid.com ____________ Virus checked by G DATA AntiVirusKit Version: AVK 15.0.3667 from 15.03.2005 Virus news: www.antiviruslab.com

1 0

Re: [boost] Re: Sockets: proposal for a library design
by Willam Lee 15 Mar '05

15 Mar '05

A C++ framework for network is very useful and long for. I have seen the ACE, but felt it too weight. The proposed library seems a lightweight one and the socket wrapper is appropriate. I think if user manage the sockets one by one, the proposed library will work perfectly. But in common network applications, a server usually serves on several sockets or ports with a select() style function. In this condition, how to process multiple socket class for different connection the proposal ? In the pseudo code, select() function is a member function of socket, maybe it can only process the 'this' socket. Finally I don't like build socket lib based on iostream, but the net lib can provide some operator like "<<" , ">>" to simulate the iosteam-style calling. Thanks Boris's work. best regards William Lee _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

3 2

boost::begin/end disappeared?
by Caleb Epstein 15 Mar '05

15 Mar '05

A number of regression tests failed today on gcc-3.4.3+ (both mine and Martin Wille's runs) for failure to find boost::begin and boost::end. I'd suspect something changing in the Range library, but nothing looks obivous. Anyone? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

[test] numerous tests broken
by Caleb Epstein 15 Mar '05

15 Mar '05

This has been happening for several days. A number of the Boost.Test regression tests are failing across most/all platforms: http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/te… errors_handling_test ifstream_line_iterator_test test_fp_comparisons test_tools_test Gennadiy? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 15 Mar '05

15 Mar '05

In-Reply-To: <018201c52567$1b710ca0$6601a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > But as I said, benchmarking hash functions is pointless. Real programs > do not compute the hash value of a random 256 byte buffer five million > times. They usually need to do something with the hash value. This > something typically involves a division on a prime to obtain a modulus, > several pointer chasings, and at least one equality comparison (which > on a 256 byte buffer will have considerable impact). I'd add that my own application caches the results of the hash at highish level, so it doesn't actually matter that much if it is slow. The equality comparison is only needed if the hashes are equal. If you are doing something like adding values to a set, and all the values are in fact different, then hopefully the hashes will be different and the equality tests never needed. In my own code I use a mixture of hashing and interning. This means that if objects are equal they probably have the same address. If they are different they probably have different (cached) hashes. Full byte-by-byte compares of all the data are rarely needed. -- Dave Harris, Nottingham, UK

1 0

template_assert
by Johan Paulsson 15 Mar '05

15 Mar '05

(If this is off topic, has already been discussed, or is stupid, I'm sorry) I wanted a static assert without #define, I ended up with this: template<bool MustBeTrue, int TemplateAssertError = 1 / static_cast<int>(MustBeTrue)> class template_assert {}; so template_assert<true> means TemplateAssertError = 1 / 1, no error template_assert<false> means TemplateAssertError = 1 / 0, error The only compiler I have is MSVC++ 2003. I have no idea how other compilers like it, but to me this seems like a better alternative to BOOST_STATIC_ASSERT. Is it? An example, with the code that will trigger template_assert commented out: // template<class Type> struct test { typedef template_assert<sizeof(Type) == sizeof(int)> assert_type; void do_nothing() {} }; template<bool Boo> void function() { template_assert<Boo>(); test<int> works; works.do_nothing(); //test<char> fails; //fails.do_nothing(); } void start() { function<true>(); //works //function<false>(); //fails } // In MSVC++ 2003 i can also use: template<bool Boo> void function() { template_assert<Boo>; //<-- no parenthesis ... but i suppose this is not portable (I don't have a copy of the C++ standard). Thank you all for making boost! /Johan Paulsson

2 1

RE: [boost] Re: FSM Review
by Iain Hanson 15 Mar '05

15 Mar '05

On Tue, 2005-03-15 at 12:06 +0000, Paul A Bristow wrote: > > | -----Original Message----- > | From: boost-bounces(a)lists.boost.org > | [mailto:boost-bounces@lists.boost.org] On Behalf Of David B. Held > | Sent: 15 March 2005 00:13 > | To: boost(a)lists.boost.org > | Subject: [boost] Re: FSM Review > > | It will be a sad day when Boost rejects a good library because > | another library in a different part of the design space is > | theoretically faster. > > IMO this hits the nail on the head. > > As with too many reviews, there have been very interesting, > but essentially speculative, alternative ideas, > produced not during the 'proposed library' development phase, > but somewhat destructively and at the 'last minute'. > Sorry, but check the archives before "speculating" on when comments have been made. I argued for state charts to be implemented in terms of STT at the pre-review in May 2004. > These should not be a reason for rejection, > but should spur development of different > (and hopefully in some ways better) ideas to submit in future. > Rejection is not permanent. If a library has flaws and they are substantial enough then it should be rejected so that when changed, it can be reviewed again. I would like to see a state chart lib in boost but not as it currently stands. I would not mind if it was accepted as *beta* which would tell users that it has caveats. /ikh

1 0

Boost.Thread docs and more (1.32)
by Johan Nilsson 15 Mar '05

15 Mar '05

Hi, I was browsing the website for Boost.Thread 1.32 updates and became somewhat confused. This is just the few items I noticed during a quick browse. 1. The library isn't mentioned along with other updated libraries on the start page. 2. Quote from 'Design/The Next Phase': "The next phase will address more advanced synchronization concepts, such as read/write mutexes and barriers.". I guess this is just one of the mentioned "remaining inconsistencies" from the release notes. 3. In the release notes it is also stated that recursive_mutex is now implemented using a critical section under Win32. AFAIK this was already the case with 1.31 (or perhaps even earlier?). I also glanced a bit at the recursive_mutex implementation under Win32 and it looks a bit weird to me (this is just an extract): --- recursive_mutex.cpp --- ... recursive_mutex::recursive_mutex() : m_mutex(0) , m_critical_section(false) , m_count(0) { m_critical_section = true; if (m_critical_section) m_mutex = new_critical_section(); else m_mutex = new_mutex(0); } recursive_mutex::~recursive_mutex() { if (m_critical_section) delete_critical_section(m_mutex); else delete_mutex(m_mutex); } ... The if/else clause exists in virtually all methods even though there is no way to affect it from client code. Is this some kind of preparation for future improvements, just some cut and paste from recursive_try_mutex, or ...? 5. Last (but not least): Why aren't the more recent contributors mentioned a bit more up-front in the documentation - I think they deserve a lot more credit than this? // Johan

1 0

Re: [boost] No tests on como?
by Bronek Kozicki 15 Mar '05

15 Mar '05

Bronek Kozicki <brok(a)rubikon.pl> wrote: > 2 como does not support dynamic libraries at all; this is going to be > improved with next version (hopefully to be released soon) my poor memory does not serve me well. Apparently there is some support for consuming DLLs (like system libraries), however support for building them is still lacking. B.

1 0