- Boost - lists.boost.org

[Boost.Format] 64 bit failure test case
by Angus Leeming 25 Mar '04

25 Mar '04

This test code aborts at run time when compiled against version 1.31 of the boost libraries using g++ 3.3.3 on a Linux/Alpha machine (64bit architecture.). It also aborts at run time when compiled against current cvs. #include <boost/format.hpp> #include <string> #include <iostream> using std::string; string bformat(string const & fmt, string const & arg1) { return (boost::format(fmt) % arg1).str(); } int main() { std::cout << bformat("Creating directory %1$s and running configure...", "/home/foo/.bar") << std::endl; return 0; } I believe that I have tracked down the cause of the failure. Adding this patch to format/feed_args.hpp $ diff -u lyx/devel/boost/boost/format/feed_args_orig.hpp lyx/devel/boost/boost/format/feed_args.hpp --- lyx/devel/boost/boost/format/feed_args_orig.hpp 2004-03-24 15:13:50.000000000 +0000 +++ lyx/devel/boost/boost/format/feed_args.hpp 2004-03-24 15:10:59.000000000 +0000 @@ -162,6 +162,14 @@ static_cast<std::streamsize>(specs.truncate_ - !!prefix_space), oss_.pcount()); + std::cout << "std::numeric_limits<std::streamsize>::max() " << std::numeric_limits<std::streamsize>::max() << '\n' + << "specs.truncate_ " << specs.truncate_ << '\n' + << "!!prefix_space " << !!prefix_space << '\n' + << "static_cast<std::streamsize>(a - b) " + << static_cast<std::streamsize>(specs.truncate_ - !!prefix_space) << '\n' + << "oss_.pcount() " << oss_.pcount() << '\n' + << "res_size " << res_size << std::endl; + mk_str(res, res_beg, res_size, w, oss_.fill(), fl, prefix_space, (specs.pad_scheme_ & format_item_t::centered) !=0 ); } leads to the following output prior to the code aborting: $ ./trial std::numeric_limits<std::streamsize>::max() 9223372036854775807 specs.truncate_ -1 !!prefix_space 0 static_cast<std::streamsize>(a - b) -1 oss_.pcount() 14 res_size -1 Aborted specs.truncate_ is being initialised incorrectly in the format_item constructor because it is an int (sizeof(4)) whilst std::streamsize has sizeof(8) on the Alpha. FWIW, I attach the gdb backtrace also. Note the 'size == -1' in #9 of this backtrace. Hoping this all makes sense, Regards, Angus (gdb) where #0 0x00000200002384a8 in kill () from /lib/libc.so.6.1 #1 0x0000020000238224 in raise () from /lib/libc.so.6.1 #2 0x0000020000239bb0 in abort () from /lib/libc.so.6.1 #3 0x00000200000ff638 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5 #4 0x00000200000ff690 in std::terminate() () from /usr/lib/libstdc++.so.5 #5 0x00000200000ff82c in __cxa_throw () from /usr/lib/libstdc++.so.5 #6 0x0000020000098d30 in std::__throw_length_error(char const*) () from /usr/lib/libstdc++.so.5 #7 0x00000200000ed348 in std::string& std::string::_M_replace_safe<char const*>(__gnu_cxx::__normal_iterator<char*, std::string>, __gnu_cxx::__normal_iterator<char*, std::string>, char const*, char const*) () from /usr/lib/libstdc++.so.5 #8 0x00000200000e9a34 in std::string::append(char const*, unsigned long) () from /usr/lib/libstdc++.so.5 #9 0x0000000120008ec8 in void boost::io::detail::(anonymous namespace)::mk_str<char, std::char_traits<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char const*, long, long, char, std::_Ios_Fmtflags, char, bool) ( res=@0x120025a58, beg=0x1200265e8 "/home/foo/.bar", size=-1, w=0, fill_char=32 ' ', f=4098, prefix_space=0 '\0', center=false) at feed_args.hpp:73 #10 0x0000000120008568 in void boost::io::detail::(anonymous namespace)::put<char, std::char_traits<char>, std::string const&>(std::string const&, boost::io::detail::format_item<char, std::char_traits<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, boost::io::basic_outsstream<char, std::char_traits<char> >&) (x=@0x11ffff950, specs=@0x120025a50, res=@0x120025a58, oss_=@0x11ffff738) at feed_args.hpp:165 #11 0x0000000120007544 in void boost::io::detail::distribute<char, std::char_traits<char>, std::string const&>(boost::basic_format<char, std::char_traits<char> >&, std::string const&) (self=@0x11ffff6e0, x=@0x11ffff950) at feed_args.hpp:241 #12 0x00000001200056c8 in boost::basic_format<char, std::char_traits<char> >& boost::io::detail::feed<char, std::char_traits<char>, std::string const&>(boost::basic_format<char, std::char_traits<char> >&, std::string const&) ( self=@0x11ffff6e0, x=@0x11ffff950) at feed_args.hpp:249 #13 0x0000000120003b0c in operator%<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > (this=0x11ffff6e0, x=@0x11ffff950) at format_class.hpp:61 #14 0x00000001200035f8 in bformat(std::string const&, std::string const&) ( fmt=@0x11ffff930, arg1=@0x11ffff950) at trial.C:11 #15 0x0000000120003748 in main () at trial.C:16

2 3

UnitTest/BOOST_CHECK_EQUALS always fails with Intel + C-strings
by Stefan Slapeta 25 Mar '04

25 Mar '04

BOOST_CHECK_EQUAL c style strings does not work on Intel if strings are passed in a buffer: char val[10]; strcpy(val, "test"); BOOST_CHECK_EQUAL("test", "test"); // ok BOOST_CHECK_EQUAL(val, "test"); // fails always The reason: void f(const char *, const char *) { } template <typename T1, typename T2> void f(const T1&, const T2&) { } int main() { char val[100]; strcpy(val, "test"); // Here is the difference to VC 7.1: // VC calls f(const char *, const char*) // Intel calls the function template f(val, "test"); } I would guess that Intel works correctly here as f(const char*, const char*) is no exact match for the arguments char[10], const char*. Any suggestions? Stefan *********************************** Stefan Slapeta Wien/Vienna, Austria http://www.slapeta.com

1 0

[program_options] good work
by Neal D. Becker 25 Mar '04

25 Mar '04

I am really excited to see program_options progress. From my limited testing so far it looks really good, and I have been looking forward to using it in my code. I hope we can add it to boost soon, because I'm reluctant to rely on unreleased boost code. The doc needs work. It was hard for me to find the doc for the function parse_environment for example. There needs to be links from the top-level html page. Also, how can I build the html docs myself from the distributed xml? It looks like I need the "boost v2" build stuff, but I don't know what that means.

2 5

[Threads] Much faster try_mutex on Windows NT
by Adal Chiriliuc 25 Mar '04

25 Mar '04

Hello. try_mutex uses a Mutex instead of a CRITICAL_SECTION because on Windows 9x and Me it's impossible to try the aquisition of a CRITICAL_SECTION. On Windows NT/2000/XP this is possible, using the function TryEnterCriticalSection. So I suggest this: choose at runtime what syncronization primitive to use based on the running OS. CRITICAL_SECTIONS are much faster and since Windows NT is gradually replacing Windows 9x systems I think it is good to use this feature. A sketch follows. ---------- mutex.cpp ----------- namespace { bool g_Init = false; bool g_UseTryCritical; TryCriticalProcType g_TryCritical; void TryCriticalInit() { g_Init = true; g_UseTryCritical = false; get windows version; if (!windows nt) return; lib = load library (kernel32.dll); g_TryCritical = get proc address (lib, TryEnterCriticalSection); g_UseTryCritical = true; } } try_mutex::try_mutex() { if (!g_Init) TryCriticalInit(); if (g_UseTryCritical) { try { m_mutex = reinterpret_cast<void*>(new CRITICAL_SECTION); } catch (...) { } } else { m_mutex = reinterpret_cast<void*>(CreateMutex(0, 0, 0)); } if (!m_mutex) throw thread_resource_error(); if (g_UseTryCritical) InitializeCriticalSection(reinterpret_cast<LPCRITICAL_SECTION>(m_mutex)); } bool try_mutex::do_trylock() { if (g_UseTryCritical) { return g_TryCritical(reinterpret_cast<LPCRITICAL_SECTION>(m_mutex)) != 0; } else { unsigned int res = 0; res = WaitForSingleObject(reinterpret_cast<HANDLE>(m_mutex), 0); assert(res != WAIT_FAILED && res != WAIT_ABANDONED); return res == WAIT_OBJECT_0; } } ---------- mutex.cpp ----------- There is only one potential problem: if (!g_Init) TryCriticalInit(); might not be thread safe. Something like a thread safe singleton might be needed. Or maybe we could use InterlockedExchange & co. I'm not sure if timed_mutex could also benefit from this. In the docs you should explain what joining means. I worked a lot with threads in the past, but I've never heard of such a concept. I had to look through the source codes to understand what join means. Many Win32 developers will not know of concepts not covered by the Platform SDK. You do explain that conditions are some sort of events, but you use joining in sample code without explaining what it does. Regards, Adal Chiriliuc

7 13

RE: [boost] Re: [Threads] Much faster try_mutex on Windows NT
by Hanson, Iain 25 Mar '04

25 Mar '04

> Dijkstra's 1965 paper "Cooperating Sequential Processes" > explained the > problems associated with events and any other constructs that > depend on > processing speed assumptions to work correctly. That paper > was recently > reprinted in the book "The Origin of Concurrent Programming", > Per Brinch > Hansen, editor, 2002. > "Cooperating Sequential Processes" is also available here. http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD123.PDF /ikh ------------------------ #include <std_disclaimer> Everything following this line has been provided courtsey of my ISP and I have no control over it. ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ==============================================================================

1 0

[BGL] How to fix read_graphviz? with spirit?
by HIRAKI Hideaki 25 Mar '04

25 Mar '04

Hello there, I submitted a bug fix on read_graphviz() to the bug tracker (Bug ID 865882, see P.P.S. below for the summary). When thinking about possible fixes, I got some questions. Q1) May boost depend on build tools other than C++ compiler? There seemed to be a building problem due to the dependency of the parser code on some specific versions of bison. This is not a real problem because the generated C++ codes are bundled. I think the dependency should be removed, if possible. Q2) How easy is it to migrate a flex/bison code to spirit? Boost seems to have its own parser generator, spirit. Its features are uncertain for me. I just expect that it is straightforward for an expert of spirit to write a reentrant parser to be replaced with the current flex/bison parser. Q3) Why boost::subgraph isn't general subgraph but "induced" subgraph? BGL seems to have a fundamental restriction on reading graphviz files. The graph data read in read_graphviz() is stored in the boost::subgraph<> where any edge connecting vertices of a subgraph is assumed to be part of the subgraph. This is against the semantics of the graphviz format. For example, digraph g0 { edge [color=blue] subgraph g1 { edge [color=red] n1 -> n2 } n1 -> n2 } this graph has one edge in the subgraph g1 (red) and the other not in g1 (blue). But the graph read by BGL must have both edges belonging to g1. I guess that the complexity to realize this restriction may be the cause for the wrong codes in boost/graph/subgraph.hpp (see the comments at the lines 603 and 612). Anyway, a handy data structure to treat general subgraph is useful. I hope boost::subgraph will be the one. Q4) How are the graph adapters for graphs of graphviz library? Another option imagined is wrapping the graphviz library. This will introduce library dependency instead of build tool dependency. But no parser need to be developed. A data structure for general subgraph will be provided as a wrapped object. BGL seems to include wrappers for Stanford GraphBase and LEDA, C++ libraries. How are they adapted to graphviz, a C library? Regards, Hideaki Hiraki P. S. To Vladimir Prus: I'm sorry to lay this subject aside so long. I appreciate your every effort. P. P. S. Summary of the bug: The problem was that calling read_graphviz() for the second time was failed. The fix was to clear the garbage left in static variables: --- boost_1_31_0/libs/graph/src/graphviz_parser.yy Fri Aug 29 16:02:59 2003 +++ boost/libs/graph/src/graphviz_parser.yy Mon Jan 26 18:16:16 2004 @@ -259,6 +259,10 @@ graph_header: graph_type graph_name { + graphviz::vlist.clear(); + graphviz::attributes.clear(); + graphviz::subgraphs.clear(); + graphviz::nodes.clear(); std::string* name = static_cast<std::string*>($2); graphviz::previous_graph = static_cast<graphviz::Subgraph*>(g); graphviz::current_graph = static_cast<graphviz::Subgraph*>(g); This workaround was found without understanding the code. As this worked for me, I gave up digging more. A better fix may remove the uses of static variables. The item in the bug tracker has been closed but is accessible: http://sf.net/tracker/index.php?func=detail&aid=865882&group_id=7586&atid=1…

3 4

borland-5.6.4, auo_link and common-names (v1)
by Hugo Duncan 24 Mar '04

24 Mar '04

The boost/build/v1 common-names rule computes a toolset name of "bcb56" when using borland-5.6.4-tools. The boost/config/auto_link.hpp file does not discriminate between bcb5.5 and bcb5.6, using "bcb". Auto link therefore fails. I have made the following local fix to auto_link.hpp, since to me the common-names toolset name computation seems to be self-consist across toolsets. Whould it be possible to fix either auto_link.hpp or the boost build v1 common-names rule - whichever makes more sense. Thanks Hugo Index: auto_link.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/config/auto_link.hpp,v retrieving revision 1.9 diff -u -r1.9 auto_link.hpp --- auto_link.hpp 21 Jan 2004 11:54:55 -0000 1.9 +++ auto_link.hpp 22 Mar 2004 14:09:39 -0000 @@ -120,9 +120,14 @@ // vc71: # define BOOST_LIB_TOOLSET "vc71" -#elif defined(__BORLANDC__) +#elif defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) // CBuilder 6: +# define BOOST_LIB_TOOLSET "bcb56" + +#elif defined(__BORLANDC__) + + // BCB: # define BOOST_LIB_TOOLSET "bcb" #elif defined(__ICL)

4 7

Naming Issues [part of Formal Review: Indexed Set]
by Pavel Vozenilek 24 Mar '04

24 Mar '04

This should be starting point of discussions about proper indexed_set naming. indexed_set name was picked long before the library gained much more functionality. Instead of changing name immediatelly it was decided to wait on opinion of others (any change requires quite a lot of work). Here are my suggestion of names, with rationale: 1. the data structure should be named "multi_container" and should reside (or be lifted) in boost namespace. Rationale: it is superset of std::set/multiset/list and possibly slist and deque). Therefore the "multi". The structure is important and will be probably unique - therefore the boost namespace. 2. library specific names that won't fit into boost namespace should be in "multiindex" namespace. Rationale: it will be used mainly for index related names. The name is aso reasonably short. 3. indexes should be named: set_like, multiset_like, list_like, slist_like, deque_like. Rationale: it gives idea to user what it is about (more than e.g. sequenced). 4. Since indexed_set::unique may clash with std::unique I suggest to use words "distinctive", "non_distinctive". Rationale: I found it in a dictionary as the only one word synonum to unique. English native comment welcomed. /Pavel

5 6

FC++ Review results: Real Soon Now
by Mat Marcus 24 Mar '04

24 Mar '04

Some folks have been wondering whether they missed the FC++ review results. I am still working on it. I must apologize for the delay, but please be assured that completion of the determination is at the top of my list of priorities. - Mat

1 0

[Boost-bugs] [ boost-Bugs-918568 ] signals
by SourceForge.net 24 Mar '04

24 Mar '04

Bugs item #918568, was opened at 2004-03-17 23:57 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=918568&group_i… Category: functional Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Rodgers (mark_rodgers) Summary: signals Initial Comment: //to suppoet intel-win32 under inter8.0, change bellow! file:singals namespace boost { namespace BOOST_SIGNALS_NAMESPACE { class trackable; namespace detail { // Represents an object that has been bound as part of a slot, and how // to notify that object of a disconnect struct bound_object { void* obj; void* data; void (*disconnect)(void*, void*); bool operator==(const bound_object& other) const { return obj == other.obj && data == other.data; } bool operator<(const bound_object& other) const { return obj < other.obj; } //Add by ty, to support intel 80 compiler, 2004/03/18 bool operator!=(const bound_object& other) const { return !(*this==other); } bool operator>(const bound_object& other) const { return !(*this < other); } }; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=918568&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1