- Boost - lists.boost.org

sonames under BSD systems (possible fix)
by Julio M. Merino Vidal 20 Jun '05

20 Jun '05

Hi all, As seen in http://lists.boost.org/boost/2005/06/28717.php it seems that the Boost libraries are not properly linked under, at least, NetBSD. The problem arises when using --layout=system (although it will probably happen w/o it, too), as the build process only creates .a and .so files for each of the libraries being built, but it fails to create .so.1.32.0 files (as one could expect). Trying the same thing under Linux results in the correct files being created (i.e., three for each library). One of the replies said that it may be because sonames are not being used under NetBSD, and that was correct. The attached patch fixes it; I'm not sure it's correct, though I hope it is. Note that it solves this issue under Dragonfly, FreeBSD and NetBSD, all of which support sonames. Thanks, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

2 2

[function types] Formal Review begins today.
by John Maddock 20 Jun '05

20 Jun '05

The Formal Review of the Function Types Library begins today, and runs until 16th June 2005. Author: Tobias Schwinger tschwinger(a)neoscientists.org 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).

9 68

[mpl][tru64cxx] set failing
by JOAQUIN LOPEZ MU?Z 20 Jun '05

20 Jun '05

mpl::set is currently failing http://tinyurl.com/9qzuh yet it used to work as of the penultimate tru64cxx regression cycle. I've examined the CVS looking for recent changes that could have some impact on this, but I don't really see anything. Any idea about this problem? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[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