June 2005 - Boost - lists.preview.boost.org

[python] Tru64/CXX function template issues
by Markus Schöpflin 20 Jun '05

20 Jun '05

Hello, unfortunately boost.python is unusable on that platform because most of the tests fail at runtime with a stack overflow. The reason is illustrated in the following code sample: ---%<--- void foo(int); template <class T> void foo(T) { foo(0); } int main() { foo(0); } --->%--- When compiling this with CXX 6.5, the code compiles and links cleanly, despite the fact that the overload for foo() is not defined. Instead the compiler instantiates foo<int>(int) and then uses the instantiation for the call to foo() which of course leads to a stack overflow. I had a look at the standard what should happen in this case, but after reading [temp.over] I'm not really sure if we don't indeed end up with two candidate functions for the overload resolution of foo(), one being the overload itself and the other the specialization of the function template for int. Could anyone please clarify this? As for a possible workaround, replacing the overload with a specialization of the function template would work, AFAICT. Would such a patch be accepted? Markus

5 20

[function types][review] REMINDER
by John Maddock 19 Jun '05

19 Jun '05

This is to remind everyone that we have a review going on at present for Tobias Schwinger's Function Types library. Tentatively the review period has been extended until 20th June, which gives everyone a week more to take a look at Tobias submission, I'd really like to encourage as many folks as possible to take a look before then. Here are the details again: Available from the sandbox at: http://boost-sandbox.sourceforge.net/vault/ or the zip file is: http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadfile&fi… This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. (The following is taken from : http://www.boost.org/more/formal_review_process.htm ) Here are some questions you might want to answer in your review: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. John Maddock (Function Types review manager).

7 43

[function types] Review
by Jonathan Turkanis 19 Jun '05

19 Jun '05

Hi, Here's my review of the function types submission. I'm sorry I waited until the last minute to submit my review. I vote to accept the library, even though I have some problems with the design. > What is your evaluation of the potential usefulness of the library? The library is potentially very useful. For my interfaces library ( http://www.kangaroologic.com/interfaces/) I needed a facility for constructing and manipulating function types. Because nothing was available, I wrote this: http://www.kangaroologic.com/function_traits/libs/function_traits/doc/ However, as Tobias politely pointed out, my implementation was a bit naive. It would be valuable to have a single correct and efficient implementation which could be shared by various current and proposed boost libraries. > What is your evaluation of the design? My main criticism is that the metafunctions taking tags are given too prominent a place in the library. I would rather have the library provide a collection metafunctions to handle the most common combinations of tags and provide the more generic metafunctions for 'advanced' use. For example, I'd like to have metafunctions 'is_[plain_]function_type,' 'is_function_pointer,' 'is_function_reference' and 'is_const_member_function_pointer,' like I provided in the above mentioned library, in addition to 'is_function_type.' Also, I'd like to see specialized metafunctions for constructing (plain) function types, function pointers and function references, in addition to the general purpose metafunction 'function_type.' Next, function_type_signature is too complex; it has too many members, and their specifications are hard to understand. I would like to see separate metafunctions which take a function type and return 1. the sequence of arguments; you might call this function_type::arguments 2. the sequence of arguments, including ant implicit 'this' pointer; you might call this function_type::effective_arguments 3. the sequence (return_type, [class,] arg0, ... argN). You could call this function_type::signature. Alternatively, the result of instantiating the templates might themselves be sequences. Next, it's too hard too keep track of all the different tags, esp. remembering the order of the components of the names. Why not have a few atomic tags, and let user's combine them via inheritance? E.g., struct const_tag { }; struct volatile_tag { }; struct reference_tag { }; struct variadic_tag { }; struct stdcall_tag { }; struct my_tag : reference_tag, stdcall_tag, ... { }; typedef is_function_type<my_tag, T>::type result; You could define a bunch of convenience tags for common cases, but people wouldn't be required to learn them. This is what the iostreams library does. Finally, I don't like the fact that the term 'function type' is used to refer to pointers and references. This is bound to cause confusion. Also, it means that you have to write 'plain' all over the place. In my library, I used the term 'signature type,' which I wasn't too happy with, but at least it was clear that I wasn't referring to any pre-existing category of types. > What is your evaluation of the implementation? I studied an early implementation that didn't define any MPL sequences. It was good. > What is your evaluation of the documentation? The documentation needs major improvement. This has been addressed thoroughly in other reviews. > Did you try to use the library? With what compiler? Did you have any > problems? I used previous versions of the library, but not the current version. > How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I've spent much time considering the problem domain, but only about two hours during this review period. > Are you knowledgeable about the problem domain? Yes. Jonathan

3 9

tools/regression/compiler_status.cpp: possible status bug for compile-only tests
by Phil Richards 19 Jun '05

19 Jun '05

Thought I would try and track down the reason for the "Fail" being shown in the HTML regression report generated by compiler_status. (Is there a better mailing list/forum for reporting problems with these tools?) The following logic is used to determine whether a test passed or failed: xml::element_ptr dbp = xml::parse( file, pth.string() ); const xml::element & db( *dbp ); const xml::element & run_element( find_element( db, "run" ) ); pass = !run_element.name.empty() && attribute_value( run_element, "result" ) != "fail"; So, for a test to be shown as "Pass", !run_element.name.empty() must be true - which requires that the XML test result blob contains a "run" element. Tests which are aimed purely at testing expected compile-time fails (e.g., function/function_30) get the following XML generated by process_jam_log: <test-log library="function" test-name="function_30" test-type="compile" test-program="libs/function/test/function_30.cpp" target-directory="bin/boost/libs/function/test/function_30.test/gcc/debug" toolset="gcc" show-run-output="false"> <compile result="succeed" timestamp="2005-06-17 10:25:10 UTC"> </compile> </test-log> So, the test passed, but compiler_status will show a fail due to the lack of a "run" element. The "pass" assignment should take account of the "test-type". (I can put a patch together, but I might not cover all the cases since I don't know the system too well yet.) phil -- change name before "@" to "phil" for email

3 8

Boost.Iostreams breaks due to ::codecvt usage
by Julio M. Merino Vidal 19 Jun '05

19 Jun '05

Hi all, while developing some code for Boost, I've had to add some more tests to the configuration headers so that BOOST_NO_STDC_NAMESPACE gets defined when some functions cannot be found (e.g., std::strdup, which is missing under NetBSD). This is irrelevant, because this symbol could get defined in a future by other changes in Boost. The problem is that when BOOST_NO_STDC_NAMESPACE is defined under NetBSD, Boost.Iostreams does not work any more and breaks the build of programs using it. Consider the following code example: ----- #define BOOST_NO_STDC_NAMESPACE #include <boost/iostreams/device/file_descriptor.hpp> int main(void) { return 0; } ----- When building it, I get: ----- $ g++ -I/home/jmmv/opt/include test.cc In file included from /home/jmmv/opt/include/boost/iostreams/positioning.hpp:19, from /home/jmmv/opt/include/boost/iostreams/device/file_descriptor.hpp:24, from test.cc:2: /home/jmmv/opt/include/boost/iostreams/detail/config/codecvt.hpp:70: error: ` codecvt' not declared ----- The problem arises because codecvt does not exist in the global namespace under NetBSD, although it does inside std::. Therefore, the 'using ::codecvt' line (the one that triggers the error) breaks the build. I don't know how this should be fixed, so I'm just sending a bug report. Maybe the BOOST_NO_STDC_NAMESPACE definition should be made more fine grained, so that defining it due to the lack of a function does not affect others that may exist? Should I file a bug report or is this message enough? Thanks, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

2 3

Boost.Test, lexical_cast and gcc-2.95.3
by John Maddock 19 Jun '05

19 Jun '05

Anything that uses Boost.Test is currently failing with gcc-2.95.3, see for example: http://tinyurl.com/dkreq I'm not sure if this is a lexical_cast or test lib change that's broken things? John.

3 2

Re: [boost] lexical_cast update + Boost.Test question
by Joaquín Mª López Muñoz 19 Jun '05

19 Jun '05

The latest update of lexical_cat introduced a trivial bug, shown for instance at http://tinyurl.com/c9b8s. I'll be commiting the attached patch later today, if no one objects (or commits it first.) Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 16a17 > #include <cstddef> 196c197 < template<class T, size_t N> --- > template<class T, std::size_t N>

2 1

[Boost-bugs] [ boost-Bugs-1223654 ] Pickle support for BGL Python bindings
by SourceForge.net 19 Jun '05

19 Jun '05

Bugs item #1223654, was opened at 2005-06-19 11:48 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=1223654&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Pickle support for BGL Python bindings Initial Comment: Doesn't look too hard... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1223654&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [Ann]: Dox - a C++ documentation tool
by Brian Braatz 19 Jun '05

19 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Eric Goebelbecker > Sent: Saturday, June 18, 2005 10:03 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Ann]: Dox - a C++ documentation tool > > The docs are up at http://www.ominor.net/boost/dox . > > I'm hoping to set up a method for automatically updating them in the > next few weeks. > [Brian Braatz Writes:] I like it, looks like it would come in handy when one is trying to figure out how something is implemented :)

1 0

Re: [boost] MPL: set<> not fully supporting compile time iteration?
by Brian Braatz 19 Jun '05

19 Jun '05

> -----Original Message----- > > Brian Braatz <brianb <at> rmtg.com> writes: > > > > > CLOSER (see below) > > > > > On Behalf Of Ryan > > > [snip] > > > Try: > > > > > > typedef mpl::copy > > > < > > > mpl::begin<myset> > > > , mpl::back_inserter<vec> > > > >::type result_vec; > > > > > > HTH > > > > > > -Ryan > > > > > > > [Brian Braatz Writes:] > > THANK YOU RYAN- I am compiling now (one step closer) > > But I am still not getting the expected (??) behavior > > here is the current code > > ... > [Ryan Writes:] > Sorry about the leading you down the wrong path Brian. I was really > thinking > about: > > typedef mpl::copy > < > mpl::iterator_range<mpl::begin<myset>::type, mpl::end<myset>::type > > , mpl::back_inserter< vec > > >::type result_vec; > > which would only be a work around but IMO is more similar to the runtime > equivalent. I am a little suprised the mpl::begin<> compiled, but I need > to > review Dave's and Alesky's MPL book again and will hopefully come to > understand. > > I was actually on the newsgroup yesterday to see the answer to your great > remove_duplicate_types question. I had just written the equivalent > runtime function using std::vector, std::sort, and std::unique and was > wondering > about how to handle std::sort in the compile_time world. I stopped on > this > thread because I saw that it could likely lead to the answer. > > Thanks for the great question; I'll try to test a little better before > answering > any in the future. Cheers, [Brian Braatz Writes:] Hey, when one is sitting there staring at code going "why doesn't this work?!?!?!?!?!"", ANY Thoughts are appreciated. (the more thoughts that are thrown out there the better:) :) Brian

1 0