- Boost - lists.preview.boost.org

Unittest capability for meta-programs feedback request
by Ben Robinson 16 Oct '11

16 Oct '11

This submission would make it possible to write a complete set of unit tests for meta-programs, to test both the positive, compiling statements, and the negative, non-compiling statements. These tests will all compile, and the negative tests can throw an exception instead of failing to compile. The submission source is available at https://github.com/icaretaker/Metatest. The provided examples are based on the factorial metafunction from Chapter 8 of "C++ Template Metaprogramming" by David Abrahams and Aleksey Gurtovoy - http://www.boostpro.com/mplbook/. Chapter 8 explains the rational behind the BOOST_MPL_ASSERT_* macros. This submission complements these macros by allowing the writing of regression unit tests, to ensure the user will encounter the mpl formatted compiler error, if the library types are incorrectly instantiated. Currently, many meta-programs are written using one of the BOOST_MPL_ASSERT_* macros. Unit tests for these metaprograms must of course compile, therefore unittests for these programs can verify that valid types produce the correct run-time behavior. This submission provides the following four complementary macros: BOOST_METATEST(pred) BOOST_METATEST_NOT(pred) BOOST_METATEST_RELATION(x, rel, y) BOOST_METATEST_MSG(cond, msg, types) Meta-program authors can use these macros to assert predicates/relations/conditions exactly as done with BOOST_MPL_ASSERT_*. In shipped library code, these four macros exactly forward to their BOOST_MPL_ASSERT_* counterparts, since the BOOST_MPL_ASSERT_* macros do an excellent job of providing maximally informative compiler error messages. In unit test code (where BOOST_METATEST_RUNTIME will need to be defined), these macros will instead instantiate an object, which will throw a runtime exception if the predicate/relation/condition fails. Now meta-program authors can write unittests like the following: BOOST_AUTO_TEST_CASE(factorials_should_not_be_negative) { BOOST_CHECK_THROW( factorial<mpl::int_<-1> > instance;, metatest_exception ); } As you can see, this unit test validates that the factorial meta-function will in fact fail to compile. All exceptions are subclassed from boost::metatest_exception. If the user would instead like to supply their own exception types for individual assertions, one of the following four macros can be used alternatively: BOOST_METATEST_EXP(pred, exp) BOOST_METATEST_NOT_EXP(pred, exp) BOOST_METATEST_RELATION_EXP(x, rel, y, exp) BOOST_METATEST_MSG_EXP(cond, msg, types, exp) Another feature of this library, is that it is independent of any unit testing framework, provided the framework can catch exceptions by type. The examples provided show how this is done with Boost Test. The submission files also show how to use try/catch directly should your unit test framework not have such a capability. I look forward to your feedback. Thank you, Ben Robinson, Ph.D.

16 40

[test] Still having issues
by John Maddock 16 Oct '11

16 Oct '11

I'm still having a lot of issues with the latest Boost.Test not building: On Win32 with Intel's 11.1 and 12.1 compilers I see: ..\..\..\boost/test/impl/execution_monitor.ipp(104): error: invalid redeclaration of type name "_invalid_parameter_handler" (declared at line 228 of "C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\stdlib.h") typedef void* _invalid_parameter_handler; And on Ubuntu Linux with gcc I see: gcc.compile.c++ /home/john/bin/boost/bin.v2/libs/test/build/gcc-4.4.3/debug/link-static/unit_test_main.o In file included from ../../../libs/test/src/unit_test_main.cpp:16: ../../../boost/test/impl/unit_test_main.ipp: In function 'int boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**)': ../../../boost/test/impl/unit_test_main.ipp:97: error: 'getchar' is not a member of 'std' "/usr/local/gcc/4.4.3/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -DBOOST_ALL_NO_LIB=1 -I"../../.." -c -o "/home/john/bin/boost/bin.v2/libs/test/build/gcc-4.4.3/debug/link-static/unit_test_main.o" "../../../libs/test/src/unit_test_main.cpp" Probably a missing <cstdio> include? John.

3 13

[1.48] Reminder: merge fixes by Monday!
by Eric Niebler 14 Oct '11

14 Oct '11

Just a reminder that as of Monday, the release branch will be closed except for permission by a release manager. If you have fixes to merge to the release branch, please try to get them in over the weekend. Here's the schedule: October 10: The release branch was closed for major code changes. It is still open for serious problem fixes and docs changes. October 17: branches/release closed for all library changes except when specific permission given by release manager(s). October 24: Beta target date. Further betas and/or release candidates as feedback dictates. November 7: Release target date View Boost calendar: http://tinyurl.com/4xacpyj Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Is Boost interested in the Boost-based Base64 library
by Denis Shevchenko 14 Oct '11

14 Oct '11

Hi all! Not so long ago I was looking for a solution to Base64 encoding/decoding. In this page - http://www.boost.org/doc/libs/1_46_1/libs/serialization/doc/dataflow.html - I found example of such solution, with 'base64_from_binary' and 'transform_width' iteartors. But it is just a "blank", not ready-to-use solution. I created solution. But I definitely know many developers looking for a simple, ready-to-use, header-only and 'real C++' solution for Base64. So I want to offer you such solution. Some examples: int main() { std::string my_text = "My text for encoding!"; std::string encoded_text = boost::base64().encode( my_text ); std::string my_text_again = boost::base64().decode< std::string >( encoded ); } For binary data: int main() { typedef std::vector< unsigned char > binary_string; binary_string my_bin = list_of( 0xFF )( 0xAA )( 0x01 ); std::string encoded_bin = boost::base64().encode( my_bin ); binary_string my_bin_again = boost::base64().decode< binary_string >( encoded ); } For streams: int main() { boost::filesystem::ifstream my_jpeg( "/some/path/to/my/image" ); // fstream checking omitted... std::string encoded_jpeg = boost::base64().encode( my_jpeg ); boost::filesystem::ofstream my_jpeg_again( "/some/path/to/decoded/image" ); // fstream checking omitted... boost::base64().decode( encoded_jpeg, my_jpeg_again ); } This is first variant. IMHO such solution will be useful for Boost users. What you think about it? - Denis

7 27

[date_time] performance tests
by Greg Rubino 13 Oct '11

13 Oct '11

Hi all, Does anyone know of/have an open source suite of performance tests for Boost.Date_Time? If not, I'll post back with whatever I come up with. Thanks, Greg

1 0

Checking interest in to_string functions
by Antony Polukhin 13 Oct '11

13 Oct '11

As was mentioned in `[boost] to_string(v)` 1) Functions to_string and to_wstring are part of the upcoming C++0x standard. However, there are no functions for char16_t and char32_t conversions. 2) Some users can't use C++11 in some projects for quite some time, but can use boost. 3) "to_string(5)" is a lot shorter than "lexical_cast<std::string>(5)". Some users would like to use a shorter form. Is there interest in stoi, stoll, stof, to_string, to_wstring, to_u16string, stod and other functions for char, wchar_t, char16_t and char32_t conversions? Shall I add them to lexical_cast library, or as a separate conversion library? Best regards, Antony Polukhin

8 15

[ASIO] tcp::socket::async_connect() connections count
by Jim Xochellis 13 Oct '11

13 Oct '11

Hi list, I am testing a slightly modified version of the chat_client/chat_server ASIO examples and I have noticed that, immediately after the tcp::socket::async_connect() call from inside the chat_client constructor, the client is creating and establishing not one, but three TCP connections, only one of which is targeting to the server-port. Furthermore, calling repeatedly the async_connect() seems to constantly create three connections per call. I have also noticed that other programs in my system, which also communicate via TCP (ie the hyper-terminal), only open one connection at the client side. Is this async_connect() behavior, which I have mentioned above, the expected/natural behavior, or maybe I am doing something wrong? If this behavior is expected, is there a reason for it? Do I have a choice to change it? Please note that there is a near-4000 outbound concurrent connections default limit in many Windows-XP installations, hence this question has a practical meaning. Configuration informations: OS: Windows XP Pro SP3 Boost version: 1.46.1 IDE: MVS 2005 Thank you in advance, Jim Xochellis ----- Homepage: https://sites.google.com/site/xochellis/ -- View this message in context: http://boost.2283326.n4.nabble.com/ASIO-tcp-socket-async-connect-connection… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[filesystem] scoped_file feature request?
by Beman Dawes 13 Oct '11

13 Oct '11

There is a long outstanding feature request, #1090 from Marcus Lindblom, requesting the following be added to Boost.Filesystem: class scoped_file { public: explicit scoped_file(const boost::filesystem::path& file) : m_path(file) {} ~scoped_file() { boost::filesystem::remove(m_path); } private: boost::filesystem::path m_path; }; My weakly held opinion is that this request should be rejected. Rationale: Easy enough for users to do themselves, so it doesn't justify the additional surface area it would add to of the library. Does anyone have a killer argument for adding it? --Beman

5 12

Dennis Ritchie passed away
by Nevin Liber 13 Oct '11

13 Oct '11

<https://plus.google.com/101960720994009339267/posts/ENuEDDYfvKP> via Rob Pike - 8:02 PM - Public I just heard that, after a long illness, Dennis Ritchie (dmr) died at home this weekend. I have no more information. I trust there are people here who will appreciate the reach of his contributions and mourn his passing appropriately. He was a quiet and mostly private man, but he was also my friend, colleague, and collaborator, and the world has lost a truly great mind. -- Nevin Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

2 1

BGL: labelled edge graph
by Shaun Jackman 12 Oct '11

12 Oct '11

Hi, I have a directed acyclic word graph (DAWG) [1] for which the fundamentally efficient operation takes a vertex descriptor and an edge label and returns an edge descriptor (if that edge exists). An out_edge_iterator can be used to iterate over the edges to find the edge with the specified label, but it's not very efficient. I plan to extend the BGL API to add the needed functionality. I wanted to check first that this function doesn't already exist, and if it doesn't, ask for suggested names. I was thinking of... pair<edge_descriptor, bool> out_edge( vertex_descriptor u, edge_label i, Graph g); The type of edge_label would depend on the graph. For me, it's a char. This sort of labelled edge navigation also applies to a de Bruijn graph [2]. Cheers, Shaun [1] http://en.wikipedia.org/wiki/Directed_acyclic_word_graph [2] http://en.wikipedia.org/wiki/De_Bruijn_graph

2 1

[numeric][interval] clang support patch
by Jürgen Hunold 12 Oct '11

12 Oct '11

Hi, I've been running into the (in-)famous clang bug http://llvm.org/bugs/show_bug.cgi?id=6907 which prevents detail/c99sub_rounding_control.hpp from working. Boost contains workaround code in <boost/detail/fenv.hpp> which is used by the patch attached. Ok to commit? Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

3 3

[thread] How to return a lazy future ?
by Ivan Le Lann 12 Oct '11

12 Oct '11

Hi, Boost.Thread documentation has a section regarding the creation of lazy futures. http://www.boost.org/doc/libs/1_47_0/doc/html/thread/synchronization.html#t… The code on this page runs fine, but I can't find a way to return such future. Naïve code below exits with a boost::broken_promise in unique_future::get(). boost::unique_future <int> create_future() { boost::packaged_task<int> task(calculate_the_answer_to_life_the_universe_and_everything); task.set_wait_callback(invoke_lazy_task); return task.get_future(); } int main() { assert(create_future().get()==42); } Exceptional finish is marked in packaged_task destructor. And regardless of exceptions, since set_wait_callback want something that operates on packaged_task and not on pointed task_base, the code is doomed to do an access violation. So, is there any way to return lazy futures ? Regards, Ivan

1 0

Disable_if_type / is_pair
by Olaf van der Spek 12 Oct '11

12 Oct '11

Hi, I've got a find wrapper (returning a pointer instead of an iterator) that works for map, unordered map, ptr map, etc. I'd like to extent it to set and mult_index. What is the recommended way to disable the second overload? I didn't find a is_pair type_trait or disable_if_type. I call the find() member, which for example vector doesn't have. How should I use the free find() if a member find() isn't available? template <class T, class U> typename T::value_type::second_type* find_ptr(T& c, U v) { typename T::iterator i = c.find(v); return i == c.end() ? NULL : &i->second; } template <class T, class U> typename iterator_traits<typename T::iterator>::pointer find_ptr(T& c, U v) { typename T::iterator i = c.find(v); return i == c.end() ? NULL : &*i; } Greetings, Olaf

2 6

[chrono][system] Make possible to don't provide hybrid error handling.
by Vicente J. Botet Escriba 11 Oct '11

11 Oct '11

Hi, Boost.Chrono provides by default an hybrid error handling for the Clock::now() function, implementing the following prototype Clock::now(system::error_code&= boost::throws()); Now that the standard has accepted the prototype Clock::now() noexcept; and set as NAD-Future the Beman proposal (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3314.html#935) The hybrid prototype can not be noexcept, as the use of boost::throws() force to throw an exception on error. We need to overload the function as follows: Clock::now() noexcept; Clock::now(system::error_code&); This lost the advantages of the announced by the hybrid error handling design (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html) as we are forced to have two implementations. In addition, while most of the uses of now(ec) expect that there is no exception, the prototype can not state it using noexcept, if the boost::throws() semantic is taken in account. Due to this split, we can now make Boost.Chrono a real header-only library if we admit to renounce to use the hybrid interface. The library could add a macro that prevent the inclusion of these prototype, as e.g. BOOST_CHRONO_DONT_PROVIDE_HYBRID_ERROR_HANDLING. The experience while using these hybrid approach and mixing all these semantics has shown me that this doesn't promotes good design and doesn't compose well. Split the prototypes is cleared. system_clock::time_point system_clock::now() noexcept { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) // Note that this call is used only when the platform provides this interface. { BOOST_ASSERT(0 && "Boost::Chrono - Internal Error"); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(system::error_code & ec) { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { if (BOOST_CHRONO_IS_THROWS(ec)) //[1] { boost::throw_exception( system::system_error( errno, BOOST_CHRONO_SYSTEM_CATEGORY, "chrono::system_clock" )); } else { ec.assign( errno, BOOST_CHRONO_SYSTEM_CATEGORY ); return time_point(); } } if (!BOOST_CHRONO_IS_THROWS(ec)) // [2] { ec.clear(); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } Note how the test on whether the ec is thows() in [1] to throw and in [2] see if the ec can be cleared are obscuring what in principle was simple. It will be maybe better to add yet a 3rd prototype that forces the throw_on_error. Clock::now() noexcept; Clock::now(system::error_code&) noexcept; Clock::now(throw_on_error_t&); system_clock::time_point system_clock::now() BOOST_CHRONO_NOEXCEPT { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { BOOST_ASSERT(0 && "Boost::Chrono - Internal Error"); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(system::error_code & ec) { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { ec.assign( errno, BOOST_CHRONO_SYSTEM_CATEGORY ); return time_point(); } ec.clear(); return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(throw_on_error_t & /*tag*/) noexcept { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { boost::throw_exception( system::system_error( errno, BOOST_CHRONO_SYSTEM_CATEGORY, "chrono::system_clock" )); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } While these functions are quite simple and repeating the code is not an issue, when the logic is more complex, this could become a maintenance issue that should be resolved other techniques, as using internal functions, policies, ... I see three alternatives: A- Standard Clock::now() noexcept; B- Standard+Hybrid Clock::now() noexcept; Clock::now(system::error_code&); // takes care of boost::throw() C-Standard+EC+TOE Clock::now() noexcept; Clock::now(system::error_code&) noexcept; Clock::now(throw_on_error_t&); A breaks code using the error_code. C breaks code using the boost::throws() Yet another temporary alternative: D- Clock::now() noexcept; Clock::now(system::error_code&); // takes care of boost::throw() but it is deprecated Clock::now(throw_on_error_t&); We can start by providing D and let the user using boost::throws to move to throw_on_error, and the move to C. In addition the library must provide the user the possibility to don't include the extensions. Which way do you prefer? What do you think? Best, Vicente

4 6

Re: [boost] [filesystem] scoped_file feature request?
by Andrzej Krzemienski 11 Oct '11

11 Oct '11

> There is a long outstanding feature request, #1090 from Marcus > Lindblom, requesting the following be added to Boost.Filesystem: > class scoped_file { > public: > explicit scoped_file(const boost::filesystem::path& file) > : m_path(file) {} > ~scoped_file() { boost::filesystem::remove(m_path); } > private: > boost::filesystem::path m_path; > }; > > My weakly held opinion is that this request should be rejected. > Rationale: Easy enough for users to do themselves, so it doesn't > justify the additional surface area it would add to of the library. > Does anyone have a killer argument for adding it? > --Beman Hi, I would add to the rationale for rejection, that scoped_file's destructor performs an operation that might throw an exception, which is counter to well established practices in C++. You could use the error_code version, but that would hide the error if any occurs. Regards, &rzej

1 0

BOOST_FORCE_INLINE
by Mathias Gaunard 11 Oct '11

11 Oct '11

I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp Who do I need to contact to make this happen?

16 31

Problems with proto and /clr
by Jorge Lodos Vigil 11 Oct '11

11 Oct '11

Hi In boost 1.47 proto stopped compiling with /clr in VS2008 and VS2010. Take the calc3 example, for instance. The root problem is that /clr is instantiating templates that normally are not. The change in proto is the new is_applyable metafunction. In normal compilation, when the received parameter is not callable mpl::and_ ensures that there is no need to fully instantiate the is_transform metafunction parameter. Apparently when using /clr it gets instantiated any way. You may verify this commenting out the 3 BOOST_MPL_ASSERT_RELATION lines in calc3 sample (so it will compile) and adding the following in the main function: // This is an instantiation of is_applyable that causes problems typedef boost::mpl::max<CalculatorGrammar,boost::proto::_state> is_applyable_parameter_t; // This is why it normally compiles BOOST_MPL_ASSERT_NOT((boost::proto::is_callable<is_applyable_parameter_t>)); // The following correctly fails to compile, the is_transform metafunction must never be instantiated //bool is_tranform = boost::proto::is_transform<is_applyable_parameter_t>::value; // This is the line that does not compile with /clr but normally does typedef mpl::and_<mpl::false_, boost::proto::is_transform<is_applyable_parameter_t> > problem_t; This code fails to compile with /clr, because is_applyable_parameter_t is instantiated and CalculatorGrammar is not comparable. Before I continue to dig in proto code, try workarounds and create tickets, I thought I might ask these questions here: 1. In case a workaround can be found (decomposing is_applyable in 2 metafunctions, for instance) is it of interest to support /clr? 2. Is this situation a compiler bug, a proto bug or just bad luck + undefined behavior? I'll appreciate any comment you may have on this. Please note that this causes xpressive and probably spirit to fail compilation with /clr. On a side note note, if there is interest to support /clr, it should not be a problem to modify MSVC test scripts. Only the /clr parameter must be added to the command line, nothing else. Apparently there is no big demand for C++ with /clr, but if there is interest I could try to modify tests scripts and correct any problem that may surface. Thank you in advance for your time. Best regards Jorge

2 1

[serialization] Technique used for registration of derived through base ( Abrahams wizardy )
by Sebastian Karlsson 11 Oct '11

11 Oct '11

A good while ago I got interested in how the registration process works in boost::serialization, I was never able to understand how the technique works, even if the gist of it is contained in 2 fairly small headers ( boost/serialization/export.hpp & boost/archive/detail/register_archive.hpp ). It would seem the creator of the technique is David Abrahams, so I'm hoping he or anyone else which understands how the registration process works could explain the technique used. >From my understanding it solves the problem of having 2 different sequences of types, and then being able to operate on all the combinations. All the techniques I've seen used previously for this requires the maintenance of some sort of compile time vector of one of the sequences. This is very cumbersome, not only does it needs to manually managed, but the file that defines the vector turns into a large dependency bottleneck. From my understanding the technique used in boost::serialization currently one sequence simply adds an overload to a free function, then at the registration point of the other sequence just having the overloads considered at compile time causes the magic to happen when the return type needs to instantiated. Unless I'm missing something obvious I think it would make for a very interesting subject of an article or discussion on the mailing list. Kind regards, Sebastian Karlsson

1 0

operator traits: ready for addition
by Frédéric Bron 11 Oct '11

11 Oct '11

Dear John, Included is are 2 patches vs trunk with operator traits additions: - boost_type_traits.patch.bz2 to be applied in boost/type_traits - libs_type_traits.patch.bz2 to be applied in libs/type_traits I have also updated the sandbox: :http://svn.boost.org/svn/boost/sandbox/type_traits/ This new version addresses all review comments. Tested with gcc 4.6.1 and intel-linux 12.0. Could be nice if somebody could run the tests with msvc. Hope everything is fine. What would be the best way to add it to the trunk? Regards, Frédéric PS: sorry for the long delay but it is very hard to find some free time with a job and a family.

2 2

Re: [boost] [proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Eric Niebler 11 Oct '11

11 Oct '11

On 10/10/2011 4:50 PM, Joel de Guzman wrote: > Everything's green now, Eric. The problem was not pervasive after > all; just a couple of fixes solved everything. Whew! > There's no need to revert. It makes me wonder though if we've missed > something that will blow up in the future. I'll probably have to > scrutinize classes that use proto::extends and check for overloads. The problem is that Spirit defines its own operator overload(s) that compete with Proto's. The officially sanctioned way of doing this with Proto is to use a grammar to restrict Proto's overloads, and then define your own. Admittedly, Proto's docs could be more clear about best practice here. > You might want to warn other proto users of this potential > breaking change. This will need to be mentioned in the release notes, yes. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] Boost.Algorithm design question
by Joe Mucchiello 11 Oct '11

11 Oct '11

On 10 Oct 2011 10:32:53 +0200, Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: > Den 07-10-2011 20:45, Joe Mucchiello skrev: >> On Fri, 07 Oct 2011 10:30:26 +0200, Thorsten > Ottosen<thorsten.ottosen(a)dezide.com> wrote: >> >>> Den 06-10-2011 18:27, Phil Endecott skrev: >>>> Thorsten Ottosen wrote: >>>>> Even better, don't use vector<const char*>. What o > you need that for? >>> [snip] >>>> >>>> Here's a real motivating example where I want to use > vector<const >>>> char*>. I have a large file containing null-terminated strings > which I >>>> memory map. After opening the file, I construct some sort of index > of >>>> those strings in a sorted vector. Then I search for things using >>>> std::equal_range, std::lower_bound, or similar. >>> >>> That's a good example, I grant you. >> >> >> I actually have a helper class for this called cstrptr which is a typedef > for the template class >> >> basic_cstrptr<char>. It is a "dumb" wrapper around const > char * that provides some std::string >> > > Also, something like iterator_range<const char*> might be somewhat more > handy to store in the vector. Perhaps in the generic case, but as I said, my class is for magic text found in programs and you practically never need to run generic algorithm against lists of magic text. The value in my class is that it is basically the same size as a pointer to char and has a near nop constructor. But my class might be too specific for boost based on the lack of any reaction to the concept. It is just a little fluff class. Joe

1 0

Re: [boost] [proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Eric Niebler 10 Oct '11

10 Oct '11

On 10/10/2011 2:08 AM, Joel de Guzman wrote: > On 10/10/2011 1:52 PM, Joel de Guzman wrote: >> On 10/10/2011 12:38 PM, Eric Niebler wrote: >>> >>> Bummer. I suggest adding an rvalue ref overload of operator%= that >>> shares an implementation with the const lvalue one. Should just be a few >>> lines of code. Is that a problem? >> >> Not really a problem. But, %= is just an example of the problems >> (plural with an s). We suspect that it is more widespread. I'll >> see how pervasive the changes need to be and get back to you. > > Ok, adding the %= for rvalue refs for Qi and Karma fixed a lot of > the failing tests. However, I am not sure how to fix the tests > involving Lex (crashes on VC10 but OK on GCC). The compiler > tutorial I am working on also got broken. I am not sure what else > in the examples got broken. It's quite difficult to ascertain > where the problem is because the code builds without errors > but either crashes or does not work as expected at runtime. > This is an insidious critter. > > Hartmut, I committed the fix for Qi and Karma. Can you please > take a look at the Lex regressions? There's a good chance > that the problem with the examples is also related to the Lex > problem. I just ran the spirit_v2/lex and spirit_v2/lex_regressions test suites on msvc-10.0, and everything passed for me. Is this fixed already? Let me know asap so I know whether to revert my Proto changes. (Note: If they don't make it in this time, these Proto changes will eventually go back in for next release, so Qi/Karma/Lex will need to be fixed eventually.) -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Mathias Gaunard 10 Oct '11

10 Oct '11

On 10/10/2011 11:08, Joel de Guzman wrote: > Ok, adding the %= for rvalue refs for Qi and Karma fixed a lot of > the failing tests. However, I am not sure how to fix the tests > involving Lex (crashes on VC10 but OK on GCC). The compiler > tutorial I am working on also got broken. I am not sure what else > in the examples got broken. It's quite difficult to ascertain > where the problem is because the code builds without errors > but either crashes or does not work as expected at runtime. > This is an insidious critter. Does it work without errors when enabling optimizations? It could be a problem with the lifetime of references.

1 0

multi_index bug?
by Olaf van der Spek 10 Oct '11

10 Oct '11

Hi, I've got this container: typedef boost::multi_index_container< torrent_t, boost::multi_index::indexed_by< // boost::multi_index::hashed_unique<boost::multi_index::member<torrent_t, int, &torrent_t::id>>, boost::multi_index::ordered_unique<boost::multi_index::member<torrent_t, int, &torrent_t::id>>, boost::multi_index::sequenced<> > > torrents_t; I'm using the find() member to find elements. When I use hashed_unique, it seems to be unable to find some elements, while it finds all if I use ordered_unique. This is with Boost 1.46.1.1 (Debian) and gcc version 4.6.1 (Debian 4.6.1-4) Is this a known issue? Olaf

2 2

Re: [boost] Boost.Algorithm design question
by Joe Mucchiello 10 Oct '11

10 Oct '11

On Fri, 07 Oct 2011 10:30:26 +0200, Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: >Den 06-10-2011 18:27, Phil Endecott skrev: >> Thorsten Ottosen wrote: >>> Even better, don't use vector<const char*>. What o you need that for? >[snip] >> >> Here's a real motivating example where I want to use vector<const >> char*>. I have a large file containing null-terminated strings which I >> memory map. After opening the file, I construct some sort of index of >> those strings in a sorted vector. Then I search for things using >> std::equal_range, std::lower_bound, or similar. > >That's a good example, I grant you. I actually have a helper class for this called cstrptr which is a typedef for the template class basic_cstrptr<char>. It is a "dumb" wrapper around const char * that provides some std::string functions to the normally even dumber bare pointer to char. It's designed for holding those magic strings that creep into production code all the time. sizeof cstrptr == sizeof const char* is always true so the constructor has very little overhead. The calling code is responsible for ensuring the lifetime of the ptr exceeds the lifetime of the cstrptr instance. It implements all the comparison operators against std::basic_string and const char*. It implements a const operator[] and an O(N) length() function. It only implements assignment and copy constructor to allow containers to hold them. I've wondered whether it was worth submitting to boost. It is so small I can't imagine it sitting on its own as a "library".

2 1