- Boost - lists.boost.org

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

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

15 Mar '05

Hi Dave, I've taken the liberty of correcting my poor spelling in the quoted parts of my message of last night. My only excuse is that it was late :-(. ( And I am a native English speaker :-( ). On Mon, 2005-03-14 at 22:34 -0600, David B. Held wrote: > Iain K. Hanson wrote: > > [...] > > There is no doubt ( in my mind ) that Andreas has done some very > > good work. The issue is whether this library is suitable for > > acceptance into boost. IIUC boost is predominately about best of > > breed libs. > > Yes. And sometimes there is more than one best in the breed. Agreed. We have a collection of containers to deal with genuine trade- offs. > > > The primary philosophy in C++ is you don't pay for what you don't use. > > ...And yet, we have iostreams. I don't know the history of iostreams or std::string but I'd be surprised and a little disappointed if there flaws were known and yet they were still admitted to the std. I know iostreams pre-dates the std so perhaps its historical. > > Andreas has deliberately taken a different approach. He has chosen > > to go for the all singing, all dancing heavy weight approach. > > ...Much like shared_ptr<>, which got into TR1. And I dare say that > shared_ptr<> is used in far more performance sensitive contexts than > the FSM. If we declared that shared_ptr<> is the end-all, be-all > smart pointer for C++, I would be as unhappy as you are. For very different reasons. shared_ptr deals with safety. The current FSM proposal takes a feature like state specific storage and every user has to pay for it whether they need it or not even if there is another cheaper way to provide it. ( there always is ). > > > He has explained his approach on this list. You pay for State > > Specific Storage whether you want it or not. You currently get > > non-linear event dispatch ( without orthaganal regions ) if you > > use outer states. And you get horrible performance on transitions > > ( with loss of state specific storage when you transition out of > > a state ). > > And if that were a deal-breaker, people wouldn't be using the > library, would they? Apparently, there are applications where > these are not the critical metrics, and people have already found > use for it. I'm sure its useful. Just as iostreams and std::string are useful. But I don't think that std::string would get through a boost review if presented for the first time today. And nor would it deserve to. Associative containers have O ( log N ) performance for a number of operations because of the underlying algorithm. The current FSM ( State Chart ) proposal has its performance characteristics because of the choices made by the author not for any fundamental underlying reason. All state charts can be collapsed to a STT. > > > I know that if I hand write a GOF state pattern I can get close > > to the scalability of the FSM lib but with constant time event > > dispatch through a single indirection and can change state through > > a single assignment. > > But can you provide all the other features of the FSM proposal? If > not, then you're comparing apples to oranges, right? Of course. At the end of the day, the most an FSM lib can give us is the elimination of some boiler plate code. The doing away with cut and paste. I think few will be willing to pay the performance price to do away with boiler plate and cut & paste. > > FSM is the domain but whether it is spelt STT or StateChart is > > irrelevant one can be mechanically collapsed to the other. But > > the fsm proposal does not do this. > > > > If we have a StateChart lib in boost it should scale as well as any > > other library in boost > > I'm not quite sure what you're saying here, but clearly there is > precedent for solutions at different granularities/complexities > /performance tradeoffs in Boost. Consider tokenizer/regex/spirit. > Consider compose/bind/lambda. If you think that Boost needs a > low-level FSM that concentrates on performance over abstraction, > you may be right. But if you think that it does not need an FSM > library that focuses on abstraction and ease of use, it would > appear that some users might disagree with you. > I think that you are mistaking me. I strongly believe in solutions at different granularities and the trade-offs that they require. If this proposal was an just an std::map and presented as the containers library then it would just need docs to be corrected to say that it is part of a containers lib. ( Just as Andreas has agreed his proposal should be spelt StateChart ). My issue is that this is a std::vector with the performance and weight of std::map. When we know this up front then *I believe* it is a good reason to vote for rejection. /ikh

1 0

[addressof] patch for Borland
by Eric Niebler 15 Mar '05

15 Mar '05

Borland doesn't like boost::addressof when used with arrays. It won't let you reinterpret_cast from an array reference to a char &. Russell Hind was good enough to test the following patch for me and confirmed that it works around the problem. (This is needed to get BOOST_FOREACH to work with Borland.) If no one objects, I'll apply the patch myself. -- Eric Niebler Boost Consulting www.boost-consulting.com Index: addressof.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/utility/addressof.hpp,v retrieving revision 1.7 diff -b -d -u -r1.7 addressof.hpp --- addressof.hpp 27 Jul 2004 03:43:33 -0000 1.7 +++ addressof.hpp 14 Mar 2005 18:15:31 -0000 @@ -33,6 +33,22 @@ &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); } +// Borland doesn't like casting an array reference to a char reference +// but thes overloads work around the problem. +# if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) +template<typename T,std::size_t N> +T (*addressof(T (&t)[N]))[N] +{ + return reinterpret_cast<T(*)[N]>(&t); +} + +template<typename T,std::size_t N> +const T (*addressof(const T (&t)[N]))[N] +{ + return reinterpret_cast<const T(*)[N]>(&t); +} +# endif + } #endif // BOOST_UTILITY_ADDRESSOF_HPP

4 8