- 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