March 2005 - Boost - lists.boost.org

Re: [boost] Re: [ boost-Bugs-1164057 ]boost::filesystem::existshas bugs with UNC paths
by Iain Hanson 18 Mar '05

18 Mar '05

On Thu, 2005-03-17 at 13:51 -0500, Robert Mathews wrote: > "Martin Bonner" <martin.bonner(a)pitechnology.com> wrote in message > news:E562FCEE3A42D61192880002A5FB433302D7A985@kite.pigroup.co.uk... > So, either, we've got to consider "//server" a valid path, or change the > iterator so that it only returns valid paths. I tend to think that fixing > the iterator would be a better choice. > To me, logically, //server is a valid and well formed path. It just so happens that I can't access it ( permission denied ). /ikh

1 0

[Boost-bugs] [ boost-Bugs-1165844 ] С ompilation test/minmax_element_test.cpp failed on Sunpro
by SourceForge.net 18 Mar '05

18 Mar '05

Bugs item #1165844, was opened at 2005-03-18 13:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1165844&group_… Category: test Group: None Status: Open Resolution: None Priority: 5 Submitted By: simon (atanasyan) Assigned to: Beman Dawes (beman_dawes) Summary: Сompilation test/minmax_element_test.cpp failed on Sunpro Initial Comment: = Bug description: Boost version: 1.32.0 Compiler: Sun Studio 10 release (C++ 5.7) with patch 117830-01 % cd ~/boost/libs/algorithm/minmax/test % CC -library=stlport4 -c -library=stlport4 -I/home/sa154628/boost minmax_element_test.cpp minmax_element_test.cpp, line 230: Error: The function "atoi" must have a prototype. 1 Error(s) detected. == Proposed fix Only std c++ headers are included in the minmax_element_test.cpp. Therefore atoi is in the std namespace and isn't exported to global one. So we should change call atoi to std::atoi. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1165844&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[ptr_container] ptr_map throws in []
by Felipe Magno de Almeida 18 Mar '05

18 Mar '05

Hi. I dont see why ptr_map throws in operator[], I think it should have the same behavior of std::map and return a default constructed object in case it doesnt find the key. Anyway, it is just a opinion. Im using ptr_map in production code and Im obligated to use find to see if the key is already in the map, if it isnt. create one. -- Felipe Magno de Almeida UIN: 2113442 email: felipe.almeida at ic unicamp br, felipe.m.almeida at gmail com, felipe at synergy com I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer from synergy, and Computer Science student from State University of Campinas(UNICAMP). To know more about: Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br current work: http://www.mintercept.com

2 4

possible optimization to adjacency_list?
by Vikram Shrowty 18 Mar '05

18 Mar '05

Hullo boost gurus, The code at detail/adjacency_list.hpp:1815 is currently like this... remove_vertex_dispatch(Graph& g, vertex_descriptor u, boost::bidirectional_tag) { //.... g.m_vertices.erase(g.m_vertices.begin() + u); //... for (v = 0; v < V; ++v) reindex_edge_list(g.out_edge_list(v), u, edge_parallel_category()); //... If I am understanding this correctly, after erasing a vertex we go through all vertices in the graph and reindex their edges/ This is because there may be edges to/from vertices after u. But this can be avoided if u was the last vertex in the graph, right? So this... //.... g.m_vertices.erase(g.m_vertices.begin() + u); //.... if (u != num_vertices(g)) { //all the re-indexing code } is a valid optimization isn't it? My graph grows and shrinks a lot (but always at highest vertex number) and this code change had a dramatic effect on runtime. -- Vikram Shrowty <vikram(a)lsil.com>

2 1

RE: [boost] [ boost-Bugs-1164057 ]boost::filesystem::exists has b ugs with UNC paths
by Beman Dawes 18 Mar '05

18 Mar '05

At 11:59 AM 3/17/2005, Martin Bonner wrote: >----Original Message---- >From: Robert Mathews [mailto:rmathews@envoyww.com] >Sent: 17 March 2005 14:56 >To: boost(a)lists.boost.org >Subject: [boost] Re: [Boost-bugs] [ boost-Bugs-1164057 >]boost::filesystem::exists has bugs with UNC paths > >>> Initial Comment: >>> boost::filesystem::exists(path("//computer")) always >>> fails, even if the computer exists. > >I shall call this, Issue A. > >>> boost::filesystem::exists(path("//computer/share")) >>> always succeeds, even if the share doesn't exist. > >... and this Issue B. > >> Can anyone actually comment on when or if this bug might actually get >> fixed? It's an obvious bug, the fix is a trivial amount of work - it >> comes with a patch that I've tested on Win32 .... > >Well, as I have indicated above, there are two separate and distinct >issues. Yes. >Issue B does seem like a bug to me. On the other hand, does your fix >change >it so that //computer/printer is reported as a filesystem? That would be a >step backwards. A true return from exists() doesn't make any claim that the path is to a filesystem. Consider this program: #include <iostream> #include <fstream> int main( int argc, char * argv[] ) { std::ofstream os( argv[1] ); if ( !os ) { std::cout << "Could not open " << argv[1] << std::endl; return 1; } os << "Hello, printer!\n"; return 0; } The network name of my machine is "bgd". It has a shared printer named "NECSuper". If I invoke the above program (named "test") like this: >test \\bgd\NECSuper A page gets printed with text: "Hello, printer!" And: >test con: Hello, printer! But: >test \\bgd Could not open \\bgd >test \\bgd\no_such Could not open \\bgd\no_such So I would likewise expect calls to exists("//bgd/NECSuper" ) and exists("con:") to return true, and a call to exists("//bgd/no_such") to return false. My initial feeling about exists("//bgd") is that it should return false, but I'm not very sure about that one and would like to hear more opinions. Thanks for the comments, --Beman

1 0

[logo] what I prefer
by Gennadiy Rozental 17 Mar '05

17 Mar '05

Hi, I wanted to share my thoughts on the logos currently submitted. But first I want to state couple things that IMO worth considering (this is driven my experience, for last release I was tried for month to invent some kind of logo for Boost.Test and obviously failed): 1. IMO logo should be transparent - essentially it should work with most pastel and white colors 2. The shouldn't be border - logo should be natural part of the page 3. No funny fonts - in long run it doesn't work 4. No funny/complex objects - it maybe fun to draw. fun to look first N times, but then it became annoying. This criteria would eliminate a lot of current submissions 6. Logo should be scalable - in a sense that it should work ok in different resolutions 7. There preferable should be something beyond the text - plain text with minimal variations doesn't initiate any recognizability Here couple logos I believe worth considering (This is not an order of my preference): 1. #99 - very solid submission. Look professional, simple. ++ could be used for icon. IMO It bring slogan: boost - blur(beyond,extend, e.t.c) the bounds of C++. May be some extra graphic symbol could be added 2. #10 - simple recognizable, easily scalable (including icon), brings a connotation of ++. Though I would definitely change a colors. May be some extra text are in order 3. #67 Even we kinda agreed that it bring unwanted associations the connotation of building blocks seems good. May be we could reorder'em differently: o o o o o o o ooo or o Also I believe it should be transparent That's about it. Genandiy

8 17

RE: [boost] [ boost-Bugs-1164057 ]boost::filesystem::exists has b ugs with UNC paths
by Martin Bonner 17 Mar '05

17 Mar '05

----Original Message---- From: Robert Mathews [mailto:rmathews@envoyww.com] Sent: 17 March 2005 14:56 To: boost(a)lists.boost.org Subject: [boost] Re: [Boost-bugs] [ boost-Bugs-1164057 ]boost::filesystem::exists has bugs with UNC paths >> Initial Comment: >> boost::filesystem::exists(path("//computer")) always >> fails, even if the computer exists. I shall call this, Issue A. >> boost::filesystem::exists(path("//computer/share")) >> always succeeds, even if the share doesn't exist. ... and this Issue B. > Can anyone actually comment on when or if this bug might actually get > fixed? It's an obvious bug, the fix is a trivial amount of work - it > comes with a patch that I've tested on Win32 .... Well, as I have indicated above, there are two separate and distinct issues. Issue B does seem like a bug to me. On the other hand, does your fix change it so that //computer/printer is reported as a filesystem? That would be a step backwards. Issue A seems correct behaviour to me. A server is *not* a filesystem - it is a place that filesystems can be found. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

function<>::contains
by Peter Dimov 17 Mar '05

17 Mar '05

I added a test case to bind that tests bind objects with function<> and function<>::contains; function<> doesn't have such test cases. In the process I patched the implementation of function<>::contains to work on MSVC 6. However contains_test.cpp will still fail on MSVC 6, because it's misnamed: it mainly tests target() and operator== and I didn't attempt to fix these. I added contains2_test.cpp to the function<> test suite that only tests contains(). It should now pass on MSVC 6. -- Peter "bind (mostly) works on VC 6" Dimov http://www.pdimov.com

2 1

[mpl] rational_c
by Andy Little 17 Mar '05

17 Mar '05

Hi again, The problem: For some Integral Constants values mpl::divides<A.,B> truncates. The solution: A new operator... mpl::rational_divides<A,B> When it is desired not to truncate, this form will preserve the fractional part by if necessary converting to a rational number. With this operator in place it is also possible to 'reduce' rationals to integers where possible and further to keep integral constants as integral types by default, knowing that conversion will be automatic if a fraction is required to prevent loss of precision. No mpl::divides<A.,B> is available if A or B is a rational types, because it is assumed that if you are using rationals you require the fraction preserving behaviour. A numeric_cast to an integral type can be used to solve this where necessary. Errors of using divides<A,B> on rationals will show at compile time. Thanks to Alexey Gurtovoy for the conversion mechanism As an example: int main() { // current division operator typedef boost::mpl::divides< boost::mpl::int_<2>, boost::mpl::int_<3> >::type int_div; // error no mpl::divides allowed for rationals /* typedef boost::mpl::divides< boost::mpl::rational_c<int,2>, boost::mpl::rational_c<int,3> >::type XXX;*/ // when some type might be a rational and rational behaviour rather than truncation is required: typedef boost::mpl::rational_divides< boost::mpl::rational_c<long,2>, boost::mpl::int_<3> >::type rat_div1; //also works on int_'s etc... typedef boost::mpl::rational_divides< boost::mpl::int_<2>, boost::mpl::int_<3> >::type rat_div2; typedef boost::mpl::rational_divides< boost::mpl::rational_int<2>, boost::mpl::rational_int<3> >::type rat_div3; // also 'promotes' to int_ where possible typedef boost::mpl::rational_divides< boost::mpl::rational_int<210>, boost::mpl::rational_int<3> >::type rat_div4; // also 'promotes' to int_ where possible typedef boost::mpl::rational_divides< boost::mpl::int_<210>, boost::mpl::integral_c<long,3> >::type rat_div5; std::ofstream os("output.txt"); os << typeid(int_div).name() <<'\n'; os << typeid(rat_div1).name() <<'\n'; os << typeid(rat_div2).name() <<'\n'; os << typeid(rat_div3).name() <<'\n'; os << typeid(rat_div4).name() <<'\n'; os << typeid(rat_div5).name() <<'\n'; } output: (VC7.1) struct boost::mpl::integral_c<int,0> struct boost::mpl::rational_c<long,2,3> struct boost::mpl::rational_c<int,2,3> struct boost::mpl::rational_c<int,2,3> struct boost::mpl::int_<70> struct boost::mpl::long_<70> regards Andy Little

2 3

[string_algo] A tiny bug in the first trimming example.
by Jurko Gospodneti� 17 Mar '05

17 Mar '05

Hi. There seems to be a bug in the first trimming example for the string_algo library. (link: http://www.boost.org/doc/html/string_algo/usage.html#id576378) My guess is the line: string str3=trim_right_copy(str2) was meant to be: string str3=trim_right_copy(str1) or otherwise the comment beside it is incorrect. Hope this helps, Jurko Gospodnetiæ

1 0

Patch - boost::shared_ptr used in redefinition of global operators new/delete
by Korcan Hussein 17 Mar '05

17 Mar '05

shared_ptr causes an infinite recursion when used in the redefinition of global operators new/delete. This is caused by sp_counted_base_impl being allocated on the heap via global operators new/delete. There currently are alternative allocation schemes which clients can select via macros but all current schemes (eventually) explicitly invoke global operators new/delete to de/allocate memory. The proposed patch Ive included just adds another choice of allocation scheme to sp_counted_base_impl with the existing ones by doing exactly the same method. It forwards de/allocation requests to C memory functions std::malloc and std::free. Clients of shared_ptr may select the alternative allocation scheme by defining the macro BOOST_SP_USE_MALLOC_ALLOCATOR before inclusion of shared_ptr/smart_ptr.hpp. >From Korcan Hussein.

1 0

Re: [Boost-testing] Re: [test] [thread] including unit_test_suite_ex.hppfails to compile
by Caleb Epstein 17 Mar '05

17 Mar '05

On Fri, 11 Mar 2005 10:25:53 -0500, Gennadiy Rozental <gennadiy.rozental(a)thomson.com> wrote: > > "Caleb Epstein" <caleb.epstein(a)gmail.com> wrote in message > news:989aceac050311071548498e@mail.gmail.com... > > One of the Boost.Thread library test programs (test_mutex.cpp) fails > > to compile due to the inclusion of the header file > > <boost/test/unit_test_suite_ex.hpp>. This file includes another file > > which does not exist: > > > > http://tinyurl.com/3t83x > > > > This test seems to be failing across several platforms. > > boost/test/unit_test_suite_ex.hpp is not needed anymore. Use > boost/test/unit_test.hpp instead. Here's a patch. Can someone please apply? I don't have write access to the repository: Index: libs/thread/test/test_mutex.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/test/test_mutex.cpp,v retrieving revision 1.11 diff -u -b -r1.11 test_mutex.cpp --- libs/thread/test/test_mutex.cpp 19 Aug 2004 19:38:39 -0000 1.11 +++ libs/thread/test/test_mutex.cpp 14 Mar 2005 14:10:03 -0000 @@ -17,7 +17,6 @@ #include <boost/thread/condition.hpp> #include <boost/test/unit_test.hpp> -#include <boost/test/unit_test_suite_ex.hpp> #define DEFAULT_EXECUTION_MONITOR_TYPE execution_monitor::use_sleep_only #include <libs/thread/test/util.inl> -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

Re: Boost.Threads Bug (recursive_try_mutex)
by Jonathan Biggar 17 Mar '05

17 Mar '05

Mark Rodgers wrote: > Bill, > > recursive_try_mutex::do_trylock() (BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE > implementation) contains the following: > > assert(res == 0); > > Surely that should be > > assert(res == 0 || res == EBUSY); This bug still exists in 1.32! -- Jon Biggar Levanta jon(a)levanta.com

2 1

[Proposal] Library which adds n-arity operators support to C++ plus reducing temporaries.
by Pavel Chikulaev 16 Mar '05

16 Mar '05

I'm currently working on library "Lazy". Library description: Library eases creation of classes which needs lazy evalution and n-arity operators and I guess will be as efficient as Gnu MP class but with pretty syntax. (Not yet tested but I do believe it is so). Library features are: * n-arity operators support; * operator aliasing, such as a + -b will be computed as a - b; * custom operators; * no unnecessary temporaries during evalution and assigning; * easy usage. Library's sample usage: //Matrix.h #include "lazy.hpp" class transpose_tag {}; //Tag class class Matrix { LAZY_CLASS(Matrix) static lazy::type<Matrix> Matrix_; //Similar to Andrei Alexandrescu's Type2Type template public: Matrix(); Matrix(const Matrix &); void swap(void Matrix &); //Libray won't work without swap function. //If name of your swap function isn't swap then use LAZY_CLASS_EX(Matrix, YourSwapFunctionName) Matrix & operator = (const Matrix &); //lazy constuctors which enables lazy operators Matrix(LAZY_OP(Matix_ + Matrix_)); //Matrix operator +(Matrix, Matrix) Matrix(LAZY_OP(Matrix_ * Matrix_)); //... Matrix(LAZY_OP(-Matrix_); Matrix(LAZY_OP(Matrix_ + Matrix_ * Matrix_)); //ternary operator //Now enable operators LAZY_ENABLE_OP(Matrix_ = Matrix_ + Matrix_); LAZY_ENABLE_OP(Matrix_ = Matrix_ * Matrix_); LAZY_ENABLE_OP(Matrix_ = -Matrix_); LAZY_ENABLE_OP(Matrix_ = Matrix_ + Matrix_ * Matrix_); //Actually we can make declaration of lazy operators and enabling them using only one macro e.g. LAZY_CONSTUCTOR(Matrix_ = Matrix_ * Matrix_ * Matrix_); //Aliasing LAZY_ALIAS(Matrix + -Matrix_ = Matrix_ - Matrix_); //Custom operation Matrix(LAZY_CUSTOM_OP(transpose_tag, (Matrix_))); LAZY_ENABLE_CUSTOM_OP(transpose, Matrix_ = lazy::custom_op<transpose_tag>(Matrix_)); //same as Matrix transpose (const Matrix &) but there won't be any temporary objects }; //Matrix.cpp Matrix::Matrix(LAZY_OP(Matix_ + Matrix_) op) { //Construct matrix object //lhs matrix = op._1 //rhs matrix = op._2 } Matrix::Matrix(LAZY_CUSTOM_OP(transpose_tag, (Matrix_) op) { //Construct matrix object tranposed to op._1 } //etc //Now the use of Matrix class Matrix a, b, c, d; //... a = b + c; //No tempories at all //Using normal practice it will take two temporary objects (no NRVO or RVO ) a = b + -c; //Will be evaluates as a = b - c; No temporaries again //Using normal practice it will take three temporary objects (no NRVO or RVO) a = b + c * d; //Will use ternary operator. No temporaries again a = transpose(b); //Custom lazy operation. No tempories again Maybe the library is very similar to uBLAS's matrix_expression and vector_expression. But with my approach there is no need to code matrix_expression and vector_expression at all and it is easy to create new classes which needs lazy evaluation and n-arity operators. So what do you think? Is there any similar approaches available? Is there any need of such library?

2 7

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

16 Mar '05

In-Reply-To: <012301c5299e$0e2b2f90$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > This is because you ignored the "use_a" member when computing the hash > value. I didn't ignore it; hash_value uses it, albeit not in the best way. > We can't prevent these mistakes in general; if you omit a member > (that affects the equivalence relation) when computing the hash value, > the computation is just wrong. In this case the computation was correct, and indeed carefully chosen, but produced needlessly many collisions. > A hash_value that encodes the type will just hide the error from you if > a and b have different types The point is that even the corrected version is needlessly throwing away some valuable entropy. It's not about hiding the error, it's about having the best possible hash function. -- Dave Harris, Nottingham, UK

3 3

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

16 Mar '05

In-Reply-To: <01b201c52987$e0bbb950$6801a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > If you _know_ how the default hash function will perform on your key > set, you can make the decision of whether to use it or not, and if the > hash function is standard, you do not have to re-evaluate your decision > each time you change platforms. I do appreciate the benefits of stability. What isn't clear is whether it trumps hash quality. This is a judgement call, in that it partly depends on which issue is more important to you. Ultimately if you want stability you can get it by using your own hasher. If you want the best quality the platform can deliver, then that's intrinsically non-portable; it should be provided by the vendor but in a standard way. We could both be made happy if boost provided 2 hashers as standard, one for stability and one for quality. However, I don't think we want to go that route at this stage, and anyway there can only be one default. This is /not/ a deal-breaker for me. I won't reject the proposal because it favours stability over hash quality. -- Dave Harris, Nottingham, UK

2 1

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

16 Mar '05

In-Reply-To: <01c301c52989$d50a2f40$6801a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > I think that it is better to fix the zero trap in hash_combine, because > this does not depend on users remembering to initialize the seed to > default_seed, instead of zero. Did you see my suggestion of changing the primitive hash_value functions instead? That also does not depend on users remembering to initialise the seed. size_t hash_value( int v ) { return size_t(v) + default_seed; } And similarly for long, etc. Is there a reason to reject this? > 2. Add a hash_range overload that takes a seed. > > 2a. void hash_range( size_t & seed, It first, It last ); > 2b. size_t hash_range( size_t seed, It first, It last ); > 2c. size_t hash_range( It first, It last, size_t seed ); > > which are listed in order of my preference. So we're talking about a family of 3 functions: 2a: void hash_combine( size_t &seed, T value ); void hash_range( size_t &seed, It first, It last ); size_t hash_range( It first, It last ); 2b: void hash_combine( size_t &seed, T value ); size_t hash_range( size_t seed, It first, It last ); size_t hash_range( It first, It last ); 2c: void hash_combine( size_t &seed, T value ); size_t hash_range( It first, It last, size_t seed=0 ); I think 2b is very error-prone, because of the lack of consistency between how hash_combine and the seeded version of hash_range return their results. 2a is less error-prone, but it seems needlessly confusing to have the two versions of hash_range return their results in different ways. In general there's a lot of similarity between hash_combine and hash_range which those versions fail to bring out. I'd rather be more consistent, eg: (a) size_t hash_combine( size_t seed, T value ); size_t hash_range( size_t seed, It first, It last ); or: (b) void hash_combine( size_t &seed, T value ); void hash_range( size_t &seed, It first, It last ); (Perhaps with overloads to catch passing a non-size_t first argument.) I don't see much value in adding a hash_range which doesn't take a seed. Especially with (a), because we can easily pass 0 explicitly. -- Dave Harris, Nottingham, UK

2 1

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

16 Mar '05

In-Reply-To: <019d01c52985$a04f54f0$6801a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > You also need equal_ptr<MyType>. Indeed. > Also, it is easy to break the above unordered_set my modifying some > of the MyTypes. Yes, that's something to be aware of. I use the approach on types which are immutable, so it doesn't arise. > size_t Derived::hash_value() const > { > size_t seed = my_unique_value; > > hash_combine( seed, Base::hash_value() ); > hash_combine( seed, m_value ); > > return seed; > } That leaves the problem of assigning a different my_unique_value to each subclass, bearing in mind that different subclasses may be written by different people, teams or organisations. Without some kind of system people may just copy and paste code from one class to another and not change the value. -- Dave Harris, Nottingham, UK

2 1

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

16 Mar '05

In-Reply-To: <d17nlh$8o3$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > I'm glad that I'm not the only person who's worried about alignment. > But this is a problems for a cross-platform library. Either I'll have > to introduce a load of macros to tweak it on various platforms (I'll > need help there) or just accept it. We can probably find something which gives reasonable results across a wide range of platforms. Shuffling the bits in a hash_combine-like manner would help. Eg something like: template <typename T> size_t hash_value( const T *p ) { size_t value = reinterpret_cast<size_t>(p); return value + value / sizeof(T); } If there's an easy way to turn sizeof(T) into a power of 2, use it. In many cases it will already be a power of 2, and I suspect the performance difference isn't crucial anyway. Alternatively we could just use: return value + (value >> 3); which ought to be reasonable for most small objects. It may also be reasonable for large objects that are heap-allocated, depending on how the heap is implemented. Anyway, I think it is better to do something like this than to just return value. -- Dave Harris, Nottingham, UK

1 0

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

16 Mar '05

In-Reply-To: <989aceac05031508512fb3bd43(a)mail.gmail.com> (reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfe r-encoding:references; b=R/dgT5RcmFTM4l6wo1FsmJV0WmZRxxS4UwfDvrZfxiBXu3i07NjqdqXmY0k93EfeA2rzuv0U dyun6iZo4Mn86mrySznULAY97Xn/zgqN3tU49cmIB/EtvwNWQzyHhnrH/iKu8pfDQoo6swyqX4 AJ8ih0MJXLu4umRrhBw7YSD2E=) wrote (abridged): > > However, it yields hash values for int * different to the values for > > char *, so with the current design aims we can't use it. > > It also has the undesirable side-effect of making the hash value > depend on the machine endianness. The same set of integers would hash > to different values on (say) Sparc and Intel machines. True - another variant of the stability issue. -- Dave Harris, Nottingham, UK

1 0

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

16 Mar '05

In-Reply-To: <d174ak$vp3$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > are you saying we don't want to hash a Base* as a void*, but use > object properties instead? Sometimes. It's a reasonable thing to do. It's what my own app actually does. It shouldn't be the default, of course. Mainly I'm saying that equality tests sometimes need to be polymorphic, and when they are the corresponding hash_value needs to be as well. So sometimes we will be comparing hash values from different types. (Other people here have claimed that never happens.) -- Dave Harris, Nottingham, UK

1 0

No tests on como?
by Peter Dimov 16 Mar '05

16 Mar '05

We don't seem to be running any tests on Comeau C++, why? Not using the "reference compiler" for our testing doesn't make much sense. Has the "reference compiler" changed without me noticing? -- Peter Dimov http://www.pdimov.com

8 23

How to add examples ot the regression testing?
by Gennadiy Rozental 16 Mar '05

16 Mar '05

I want to make sure that all examples are successfully compilable. What is the best way to do this? Gennadiy

3 3

Re: Sockets: proposal for a library design
by Don G 16 Mar '05

16 Mar '05

Hi Scott, > Networking is inherently asynchronous. Initiation and acceptance > of connections and I/O may be disguised as synchronous but other > activity (e.g. "network down") cannot. Network APIs will often > defer such errors until the next reporting opportunity (e.g. next > I/O request) but this is a band-aid that is sometimes enough and > at other times downright misleading. I assume that something > going by the name of Boost.Net would be targeting a higher > sophistication. Amen. It took me some time to get used to the work around that one should always try to have a pending read in order to detect problems. In some cases that works, but it depends on the protocol whether or not you can read at the right time. > Proposing that all network communication is asynchronous does > not preclude any synchronous coding. As discussed in other > threads (i.e. RPC) a "low-level", asynchronous library may be > the "core" of a Boost.net while synchronous services may be > built on top. While this will work, in my experience there are efficiencies to be had if the synchronous methods aren't forced to create/store callbacks that simply signal condition variables. Of course, the gains will depend on the cost of the async mechanism in question. > I think an asynchronous, core Boost.Net should expose fundamental > network services. In the case of TCP, that would be the reliable, > async 2-way transfer of data blocks. Achieving a clean and > portable library at this level would be achievement enough. What, no UDP? :) > Dragging I/O streams into the "network discussion" at this > point is almost premature; it moves the focus up the network > stack. Again this doesn't preclude those who need to from > integrating with I/O streams at a later point. I agree. > $0.01 Hey! That was at least $0.03! Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0

Re: Sockets: proposal for a library design
by Don G 16 Mar '05

16 Mar '05

Hi Boris, My responses are below... >> I would suggest that a proposed Boost.Net library should focus >> on networking in a more abstract manner, and not be merely a >> socket encapsulation. IMHO, sockets are a terrible API and >> should be hidden as fast as possible. A socket wrapper class >> is appropriate, but I would not go to any trouble to change >> the socket API. Simply wrap the resources and provide portable >> access to the underlying system. The real end-user part of the >> Net library should not talk about sockets (unless one provides >> a method like get_native to return the socket handle, and that >> method is defined as non-portable). > > This reminds me of the layers requirement from > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl? > BoostSocket/SocketRequirements. > I agree that it would be nice to have some easy-to-use high-level > classes for concepts that are used in network applications again > and again. Yes; sockets are just a means to that end and not the end in themselves. As such, they need not receive much special design consideration because that is not where you want users to interact with the library. A robust socket layer may only encourage undesirable use. The socket layer that has involved in my own code consists of a single Socket class with: a destructor for cleanup, methods that handle the mapping of non-portable EFOOBAR codes to portable exception types or return values, const-correctness, default arguments in a few places, etc.. The network layer simply uses sockets to implement the abstraction, and is the only direct user of sockets. > I agree again. There shouldn't be any of the four I/O models > omitted. We will see as we proceed if supporting various I/O > models is easy to implement and to use at runtime (especially > switching between I/O models). The I/O model that troubles me is the select/poll model. That is the mechanism I have used to implement the other three and it is not readily apparent how to expose it to the user as well. I may be surprised, but I think most folks would not mind seeing that model go away. The async I/O model with callbacks (essentially made from inside the select/poll/whatever loop) would provide a robust replacement for that tedious body of code. >> As others have also suggested, I would agree that the net >> facilities not be tied up into I/O streams. It would be >> better to provide the network facilities and then layer >> on I/O streams for those that want it. > > Several people dislike the idea of a network library built > on I/O streams. What are the reasons for this? I can only speak for myself, but I just don't like I/O streams. They seem to have a lot of clunk and little value, IMHO. They may work for text protocols, but in my use of network communications, they don't feel right. For example, the output would probably need consistent flushing do get data out of the buffer and on to the wire. > Is this a request for a more low-level access to socket > functions like read(), write(), send() and recv()? Again, I don't view socket access as the goal, but essentially yes: access to the "primitives" is what I would want. For example, I would want to be able to differentiate EOF from ECONNRESET(?) from ETIMEOUT, etc.. > The only reason I see why I/O streams should not be used is > the lack of support for an asynchronous I/O model. The > network library would have to add functions for asynchronous > support Yes, the network layer has to define what asynchronous I/O looks like. Again, I think a function<> with an appropriate signature is the answer. If the users needs those calls to be queued/marshalled, that is not the problem of the network layer. > until one day I/O streams support an asynchronous > I/O model by default (btw, anyone working on this?). I don't see how I/O streams could be asynchronous because async file I/O is not portable. For example Windows 95/98/Me don't have it. I suspect that many other systems are similar. Even though Windows NT (and 2000, XP, 2K Server) have async file I/O, it is not something that select() can handle as it can on *nix. >> Usage examples: > > Thanks again! When the socket class hierarchy is more > stable I hope to move upwards to high-level classes > representing concepts from the network world you used > in your examples. Most welcome. If I recall, the actual number of calls to socket API's made in my entire code base was so few (probably around 10-20) that even the little time I had spent on the socket layer was probably overkill. >> One thing I think is essential when using a blocking model >> is cancellation. For example, I have a reset() method on >> Acceptor, Address, Datagram and Stream that can be called >> at any time to cause blocking methods to terminate with a >> cancel exception (obviously this must be from another >> thread). Ironically, these reset() methods meant I could >> not use blocking socket calls to implement my blocking >> methods - recv() cannot be canceled once it blocks (at >> least not portably)! > > I added this to the Wiki but I am not sure if a network > library should support it. If you have two threads in your > application and one thread is halted because of a blocking > call it might have been better to use a > nonblocking/asynchronous I/O model? Perhaps, but some produces are just best designed as synchronous. They can go along merrily producing data and waiting for it to be consumed before producing more. Eventually they will block, and if they cannot be canceled (forced to unblock), you have a problem. IMO, any mechanism that can block indefinitely really needs some way to cancel. This should not be confused with thread cancellation. In this situation, once a stream is canceled/reset, it is almost completely unusable (most methods will throw the cancel exception). Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0