September 2005 - Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1292635 ] uBLAS::subslice doesn't work
by SourceForge.net 16 Sep '05

16 Sep '05

Bugs item #1292635, was opened at 2005-09-16 00:27 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=1292635&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: uBLAS::subslice doesn't work Initial Comment: Hello all, I had a problem with compiling a following code for testing subslice() on uBLAS: -- test.cpp #include <boost/numeric/ublas/vector.hpp> #include <boost/numeric/ublas/vector_proxy.hpp> #include <boost/numeric/ublas/io.hpp> int main () { using namespace boost::numeric::ublas; vector<double> v (3); for (int i = 0; i < 3; ++ i) boost::numeric::ublas::subslice (v, 0, 1, 3) (i) = i; std::cout << v << std::endl; } -- end of test.cpp % g++ test.cpp test.cpp: In function `int main()': test.cpp:9: error: no matching function for call to `subslice(boost::numeric::ub las::vector<double, boost::numeric::ublas:: unbounded_array<double, std::allocato r<double> > >&, int, int, int)' I guess this is due to some typos on vector_proxy.hpp. I hope attached patch (from Revision 1.45) helps. Regards, Shun Sakuraba sakuraba {at} cb.k.u-tokyo.ac.jp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1292635&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Fwd: Boost thread library bugs
by Sean Parent 16 Sep '05

16 Sep '05

I don't regularly read the boost mailing list - so please reply directly to me or Mike. Sean Begin forwarded message: > From: "Mike Schuster" <schuster(a)adobe.com> > Date: September 15, 2005 3:42:26 PM PDT > Subject: Boost thread library bugs > > > Here is a summary of several bugs I've discovered over the past few > months in the Boost thread library (version 1_32_0). Sean, please > forward this email to the Boost thread developers. Thanks. > > > > 1) On the PowerPC, the sequence of memory write operations executed > by one processor may be seen by another processor or device in a > different order. This weak write ordering property implies that > when modifying a shared resource, the modifying processor must > execute a sync instruction to make these modifications visible to > all other processors before releasing the lock. I discovered > several situations in the Boost thread library where a sync call is > missing. > > > > call_once: Immediately after the client function returns a lock > variable is set to one. Other processors may see this lock equal to > one before all memory write operations performed by the client > function are completed. A call to __sync() should be made > immediately prior to setting the lock to one. > > > > synchronization class constructors (mutex, read_write_mutex, > condition, etc): Once the class constructor returns, Boost provides > an API where other threads are free to call the synchronization > member functions. However, the memory write operations performed by > the constructor may not have been completed when the member > functions are executed by a different processor. So a call to __sync > () should be made immediately prior to returning from the constructor. > > > > Note that a similar situation occurs between member function calls. > However the MacOS synchronization primitives used by Boost do > perform a sync, so correct operation is guaranteed implicitly as > long the last operation performed by a member function involves an > OS synchronization primitive call. This appears to be the situation > in many places, but there may be places in the Boost library where > this requirement is not met. So someone needs to review all of the > source code for problems of this sort. > > > > 2) On the PowerPC, I have seen situations where call_once deadlocks > in the MPRemoteCall function. I have not been able to diagnose the > problem. Deadlocks occur when call_once is executed by non-main > threads. I believe I have a solution to the problem which uses a > completely different implementation similar to that of the Win32 > version and avoids all calls to MPRemoveCall. Maybe I should submit > this solution to the Boost developers for consideration. > > > > 3) I discovered a deadlock in read_write_mutex. If either of the > alternating scheduling policies are used, the implementation will > deadlock the first reader to arrive when no writers are active. The > deadlock occurs in the function void > read_write_mutex_impl<Mutex>::do_read_lock. If m_state == 0 and > m_num_readers_to_wait == 0 (this holds immediately on > construction), then an arriving reader will hang indefinitely on > m_waiting_readers. There are other related situations where the > BOOST_ASSERT on loop_count fails. > > > > Note I am concerned that such a blatant flaw is present in the > library. This implies that the library has not been very well > tested. This is worrisome especially for a thread library where > threading bugs can be extremely frustrating and hard for uses of > the library to reproduce and diagnose. > > > > -Mike Schuster > > > >

1 0

[ Boost.Timer ] Simple class ...
by rubicant rubicant 16 Sep '05

16 Sep '05

Hey hello people ! I'm new so be nice ;-) I was trying to use boost.timer but it didnt work like i wanted :-) So I made this class wich is very simple and does exactly what one would think it does. // start timer.hpp #include <ctime> class timer { public: timer(); unsigned int elapsed(); // returns elapsed time since ctor or restart() void restart(); // restarts the timer private: unsigned int start_t; }; timer::timer() : start_t(std::time(0)) { } unsigned int timer::elapsed() { return (std::time(0) - start_t); } void timer::restart() { start_t = std::time(0); } // end timer.hpp As you can see its very clean and simple to use enjoy ! ...maybe put it in boost timer ;-D ?

1 0

Re: [boost] Interest in color library.
by Schrom, Brian T 16 Sep '05

16 Sep '05

As was pointed out in the chart thread, the Anti-Grain library (http://www.antigrain.com/index.html) has a lot of features, including classes for a number of different color formats. I'm not sure if they include logical conversions from one space to another. It is a good reference to look at though.

1 0

Re: [boost] Checked Integral Class
by Matt Doyle 16 Sep '05

16 Sep '05

I think I want to disagree with this suggestion. Citing your example a=b should work just fine provided that the value of b will fit within the constraints of a. I think in most situations (but not all) the limits are determined by how the type will ultimately be used and not necessarily on the result of the operation that's taking place. If it doesn't fit, so be it, it's an error. On another note; I liked that earlier suggestion of user definable error handling, I can see where heavy handedness is not always desirable. > also, the type of a binary operator's return value should combine the > intervals of the operands > > e.g. given: > CheckedIntegralValue<int, -10, 100> a; > CheckedIntegralValue<int, -100, 20> b; > > then the type of a+b should be CheckedIntegralValue<int, -110, 120> > > and given: > CheckedIntegralValue<int, -110, 120> sum; > > then sum = a+b, sum = a, and sum = b should all compile just fine > > conversely, a = sum, b = sum, and a = b should not > > this may have been implied, just wanted to make sure > > regards, > > /michael toksvig > <snip> Scanned by Fortigate {X3BTB534}

4 3

[Boost-bugs] [ boost-Support Requests-1292345 ] Linker Problems with VC .NET 2003 / STLPort / Boost
by SourceForge.net 15 Sep '05

15 Sep '05

Support Requests item #1292345, was opened at 2005-09-15 21:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1292345&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adrian Grigore (pluggy13) Assigned to: Nobody/Anonymous (nobody) Summary: Linker Problems with VC .NET 2003 / STLPort / Boost Initial Comment: Hi, I have been trying for over 2 days to install Boost in VC .NET 2003 alongside with STLPort , and despite several different settings, I am always getting the same linker errors. First I tried using STLPort 4.6.1 with boost 1.32. Here's a short, but complete description of what I have tried: First I downloaded and unzipped STLPort 4.61. Then I ran the vcvars batch and installed STLPort with nmake clean all -f vc71.mak nmake install -f vc71.mak Then I Installed boost 1.32 with bjam "-sTOOLS=vc-7_1-stlport" "-sSTLPORT_PATH=C:\...\stlport" "-sSTLPORT_VERSIONS=4.6.1" "-sstlport-iostreams=on" install This takes a while to complete, but seems to work fine except for a few errors with the datetime package, which I am not using anyway. I entered the boost / stlport header and lib directories into Visual studio and made sure they are on top of the other include directories. Then I created a dummy project with the following files: stdafx.h: --->>>> #ifdef NDEBUG # undef _STLP_DEBUG #else # define _STLP_DEBUG 1 #endif #define BOOST_LIB_DIAGNOSTIC #include <iostream> #include <tchar.h> <<<--- and the main.cpp: --->>>> #include "stdafx.h" #include <boost/filesystem/convenience.hpp> #include <vector> using namespace _STL; int _tmain(int argc, _TCHAR* argv) { //forcing native mode in boost paths just to make sure that boost::filesystem has to be linked successfully boost::filesystem::path::default_name_check(boost::filesystem::native); vector<int> test; test.push_back(1); vector<int>::iterator Iter=test.begin(); Iter++; int testint=*Iter; // iterator overrun error just to see if the debug mode is working nicely return 0; } <<<--- When I try to compile it, it fails with the following liker errors: --->>>> Compiling... stlport-boost-test.cpp Linking to lib file: libboost_filesystem-vc71-mt-sgdp-1_32.lib Linking... stlport-boost-test.obj : error LNK2019: unresolved external symbol "public: static void __cdecl boost::filesystem::path::default_name_check(bool (__cdecl*)(class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > const &))" (?default_name_check@path@filesystem@boost@@SAXP6A_NABV?$basic_string@DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@@Z@Z) referenced in function _main stlport-boost-test.obj : error LNK2019: unresolved external symbol "bool __cdecl boost::filesystem::native(class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > const &)" (?native@filesystem@boost@@YA_NABV?$basic_string@DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@@Z) referenced in function _main Debug/stlport-boost-test.exe : fatal error LNK1120: 2 unresolved externals Build log was saved at "file://e:\documents and settings\Wunibald Wunderlich\My Documents\Visual Studio Projects\Finity Engine VS 2003\stlport-boost-test\Debug\BuildLog.htm" stlport-boost-test - 3 error(s), 0 warning(s) <<<--- It is obvious from the compiler output that libboost_filesystem-vc71-mt-sgdp-1_32.lib was linked, yet the compiler complains about unresolved symbols. When I comment out the line related to boost::filesystem from tmain(), it works perfectly. But I need boost::filesystem and quite a few other libraries for my real projects, so this is not an option. Also, I have no problem linking to boost when not using stlport, but I'd really like to take advantage of the neat debuging mode built into stlport. Someone from the STLPort forums suggested that I might try the latest CVS versions for boost and STLPort, so I did this yesterday (14th of Sept. 2005). I made sure that what I downloaded from CVS was indeed STLPort 5.0 / Boost 1.33, I recompiled everything and changed the headers path to the new version, but the problem stayed absolutely the same. I am really clueless on how to proceed. I have also tried posting to the boost and stlport forums, but nobody seemed to be able to help. Any help would be immmensely appreciated. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1292345&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[filesystem] revised function to determine available file system space
by Beman Dawes 15 Sep '05

15 Sep '05

I'm planning to add a filesystem function to determine available disk space. Perhaps something like: struct space { boost::uintmax_t available; // bytes available to user boost::uintmax_t total; // total bytes on volume }; space filesystem_space( const path & p ); Comments? How safe is the assumption that uintmax_t is large enough nowadays for any modern compiler on a system supporting large disks. Better suggestions for the names? --Beman PS: this is slightly revised from a post on the users list.

6 11

Boost regression notification (2005-09-15 [HEAD])
by Douglas Gregor 15 Sep '05

15 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-15T05:00:23Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 263 failures in 17 libraries: algorithm/string (1) concept_check (14) date_time (5) filesystem (8) foreach (7) graph (7) iostreams (1) math (6) mpl (2) parameter (18) python (1) regex (36) serialization (40) spirit (2) thread (24) typeof (87) wave (4) |algorithm/string| regex: gcc-3_3-darwin |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 vc-7_1 |date_time| testlocal_time_iterator: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc testlocal_time_period: gcc-2.95.3-linux msvc |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: msvc |foreach| user_defined: cw-8_3 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-6_5-stlport vc-7_0 |graph| biconnected_components_test: gcc-3.4.4-linux gcc-3_4_3-sunos mingw-3_4_2 graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |iostreams| regex_filter_test: gcc-3_3-darwin |math| octonion_test: gcc-4_0-darwin gcc-4_0-darwin quaternion_test: gcc-4_0-darwin gcc-4_0-darwin special_functions_test: gcc-4_0-darwin gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin gcc-4_0-darwin |parameter| basics: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-4_0-darwin msvc macros: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc unnamed: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |python| data_members: msvc |regex| bad_expression_test: gcc-3_3-darwin captures_example: gcc-3_3-darwin captures_test: gcc-3_3-darwin collate_info: gcc-3_3-darwin concept_check: gcc-3_3-darwin credit_card_example: gcc-3_3-darwin grep: gcc-3_3-darwin icu_example: gcc-3_3-darwin mfc_example: gcc-3_3-darwin object_cache_test: gcc-3_3-darwin partial_regex_grep: gcc-3_3-darwin partial_regex_match: gcc-3_3-darwin posix_api_check: gcc-3_3-darwin posix_api_check_cpp: gcc-3_3-darwin recursion_test: gcc-3_3-darwin regex_config_info: gcc-3_3-darwin regex_dll_config_info: gcc-3_3-darwin regex_grep_example_1: gcc-3_3-darwin regex_grep_example_2: gcc-3_3-darwin regex_grep_example_3: gcc-3_3-darwin regex_grep_example_4: gcc-3_3-darwin regex_iterator_example: gcc-3_3-darwin regex_match_example: gcc-3_3-darwin regex_merge_example: gcc-3_3-darwin regex_regress: gcc-3_3-darwin regex_regress_dll: gcc-3_3-darwin regex_replace_example: gcc-3_3-darwin regex_search_example: gcc-3_3-darwin regex_split_example_1: gcc-3_3-darwin regex_split_example_2: gcc-3_3-darwin regex_timer: gcc-3_3-darwin regex_token_iterator_eg_1: gcc-3_3-darwin regex_token_iterator_eg_2: gcc-3_3-darwin static_mutex_test: gcc-3_3-darwin msvc wide_posix_api_check_cpp: gcc-3_3-darwin |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_barrier: msvc test_barrier_lib: intel-9.0-linux msvc test_condition: msvc test_condition_lib: intel-9.0-linux msvc test_mutex: msvc test_mutex_lib: intel-9.0-linux msvc test_once: msvc test_once_lib: intel-9.0-linux msvc test_read_write_mutex: msvc test_read_write_mutex_lib: intel-9.0-linux msvc test_thread: msvc test_thread_lib: intel-9.0-linux msvc test_tss: msvc test_tss_lib: intel-9.0-linux msvc test_xtime: msvc test_xtime_lib: intel-9.0-linux msvc |typeof| data_member_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux data_member_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ptr_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ref_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lvalue_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_int_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_tpl_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_tpl_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_type_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 type_emulation: borland-5_6_4 cw-8_3 cw-9_4 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux type_native: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

1 0

[config][1.33.1] MinGW improvements?
by Rene Rivera 15 Sep '05

15 Sep '05

In the past few days I've been trying to get Boost using the upcoming STLport-5 release. In the process I've been checking Boost with the latest MinGW 3.4.2 release. And I found that some things have improved. In particular this change... =================================================================== RCS file: /cvsroot/boost/boost/boost/config/platform/win32.hpp,v retrieving revision 1.17 diff -u -r1.17 win32.hpp --- boost/config/platform/win32.hpp 25 Jul 2004 11:56:27 -0000 1.17 +++ boost/config/platform/win32.hpp 13 Sep 2005 05:54:47 -0000 @@ -24,6 +24,12 @@ # define __STDC_LIMIT_MACROS #endif +#if defined(__MINGW32__) && ((__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ >= 4))) +# define BOOST_HAS_MS_INT64 +# define BOOST_HAS_DIRENT_H +# define BOOST_HAS_UNISTD_H +#endif + // // Win32 will normally be using native Win32 threads, // but there is a pthread library avaliable as an option, =================================================================== I.e. it looks like, after running various tests of libraries that use that functionality, that not only are they present but functioning. OK to commit? ...To the 1.33.1 branch? It also looks like C99 wide char functions are also implemented and working. But I guess not enough for libstdc++ to work, but enough for STLport-5 to work. So with one exception, it should be possible to have MinGW+STLport support all wide char ops. The exceptions are that it doesn't have the non-reentrant wide char functions not in C99; AFAIK. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

4 12

[smart_ptr] Easing the use of smart_ptr in case sorting is required
by Loïc Joly 15 Sep '05

15 Sep '05

Hello everybody, Often , when someone creates a collection of smart_ptr, he wants the collection to be sorted by objects, and not by pointer adresses (this is what is used for instance in ptr_containers). To do that, one can provide his functor to the container/algorithm required, but this is burdensome. I do not think that modifying the current behaviour of smart pointers to make the comparison of smart pointers compare objet would be a good idea (even in cases it is possible to compare by objects, people who do not need this sorting would be impacted by the performances of sorting by objects). However, since this a quite a common thing to do, I wonder wether such a functor could be provided inside the smart_ptr headers, so that people who want to use this option can use it directly. What are your feelings about this idea ? Best regards, -- Loïc

4 4