- Boost - lists.boost.org

[ptr_container] Inappropriate behaviours
by Allen 29 Jul '05

29 Jul '05

I am using the ptr_container library (the version in the CVS) in my current project recently. I am really suprised by the strange behaviour of nullable ptr containers. If someone is using nullable ptr containers, there always are needs to construct a ptr container with specific size and filled in with all null pointers. However, I found that the ptr container can only "reserve" specfic sized buffered, but cannot be constructed with specific size: ptr_vector<nullable<int> > v(10); Instead, I have to write this: ptr_vector<nullable<int> > v(10); for (int i = 0; i < 10; i++) v.push_back(0); It is really a superise in my opinion, and write a loop (or use an STL algorithm) to fill the container manually is awkward and unnecessary. I think it is more intuitive and natural that the above constructor constructs a ptr_vector of size 10, with 10 null pointers inside. If the container is not nullable, it could default-construct 10 objects (or clone 10 from a given one) instead. Another superise is it seems that the iterator returned by associative ptr containers are not std::pair like STL containers do, but the values in the associative container. I cannot see the reason for this incompatibility with STL, nor can I find any documentation or examples on this. Am I missing something? Comments are welcome. Best regards, Yao, Zhen

2 1

Request for more detailed change history with releases
by Russell Hind 29 Jul '05

29 Jul '05

I think the current change history for boost releases isn't adequate. It appears that libraries get changed (small and big changes) between releases but many of these aren't documented. A couple of reasons I'd like this to be changed are: 1. New functionality added to libraries my go un-noticed. e.g. I recently found out from c.l.m.c++ that bind now supports == and other comparison operators. Peter Dimov has now added this to index.html after my request, but if it wasn't there, we may have never realised that functionality existed which would be a shame as possibly only new users to the library would know about these changes. 2. Compatibility. e.g. ublas stopped supporting Borland C++Builder in 1.32. In 1.31 we used ublas and then tried to move to 1.32 but there was no indication of this in the changes history and this is quite important. Significant amounts of time can be invested trying to use the new release of boost only to find you can't because one library that is core to a user may have been deprecated for that compiler without any warning. It seems to me that there is no easy way to tell this for an end user. Yes there are reqression test results, but these would require the user to look at the regression tests for both 1.31 and 1.32 and compare the two, but I would expect most end users to ignore the regression tests, especially once they are already using a version of boost. I'd really like to see these addressed, especially as we are coming towards a 1.33.0 release and we are currently wondering how much effort to put in to see if 1.33.0 will work in our current environment which is working well with 1.32.0. I'd really like to see this sort of information on the front page of boost but at a minimum I'd like to see library authors keep a change history for each release such as that for date-time at http://www.boost.org/doc/html/date_time/details.html#date_time.changes Thanks Russell

2 1

Boost regression notification (2005-07-28)
by Douglas Gregor 29 Jul '05

29 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-28T15:44:28Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 117 failures in 9 libraries: filesystem (2) graph (1) program_options (4) python (4) random (2) serialization (92) test (5) thread (1) wave (6) |filesystem| operations_test_dll: mingw-3_4_2 path_test_dll: mingw-3_4_2 |graph| graphviz_test: intel-win32-8_1 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin |python| iterator: vc-7_1 map_indexing_suite: vc-7_1 pointer_vector: vc-7_1 vector_indexing_suite: vc-7_1 |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux msvc vc-6_5 vc-7_1 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr_dll: msvc vc-6_5 vc-7_0 test_diamond_binary_archive: cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mi_binary_archive_dll: intel-win32-8_1 test_mult_archive_types_dll: msvc vc-6_5 test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_shared_ptr_132_xml_archive_dll: intel-win32-8_1 |test| errors_handling_test: cw-9_5-darwin test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |thread| test_thread: vc-6_5 |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0

2 1

Re: [boost] singleton design plan
by Hickerson, David A 28 Jul '05

28 Jul '05

Have you checked out the loki library on SourceForge? It has a singleton implementation along the lines you are trying implement. If you have not read this paper about multi-threaded singletons, I suggest you do. http://erdani.org/publications/DDJ_Jul_Aug_2004_revised.pdf Dave -----Original Message----- From: Jason Hise [mailto:chaos@ezequal.com] Sent: Thursday, July 28, 2005 3:17 PM To: boost(a)lists.boost.org Subject: Re: [boost] singleton design plan Michael Goldshteyn wrote: >What is: > >namespace boost >{ > const class > { > >??? > const class { ... } null; Defines a global variable named null, which is constant and of an unnamed type defined by the class declaration. I think this is standards conforming, but now that you mention it I'm not positive. I will have to check with other compilers to make sure. -Jason _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

indeterminate tribool to bool
by Fernando Cacciola 28 Jul '05

28 Jul '05

Hi, I'm reading a draft of a proposal to standarize interval arithmetic (from the authors of Boost.Inverval). They propose to include the specialization "interval<bool>" to represent "false<->maybe<->true", that is, a tristate boolean expressed as an interval in the "lattice" range [false,true] They specifically mention that they propose interval<bool> instead of Boost.TriBool becasue they argue that conversion from indeterminate to bool shouldn't be false but fail with an exception. It turns out that in any actual case I can think of, throwing when trying to narrow an indeterminate tribool into true or false is indeed much prefered than returning false. The tribool documentation says that you should write: if ( b ) certainly_true(); else if (!b ) certainly_false(); else uncertain(); The authors of the proposal argue that even though you should follow that pattern, if you don't, so your code is written like: if ( b ) certainly_true(); else certainly_false(); then if b is indeterminate the false branch should not execute because that's hardly what the programer intended in the case of a tri-state logic. >From my own experience I cannot but agree. If you're implementing a complex triboolean predicate that nests child triboolean predicates (various levels down), you can rightly decide to use the simplified pattern (with just the 2 certain branches) and let the exception mechanisms wind up the "uncertain answer" up to the caller; but for this you need ideterminate->bool to fail... Of course there is always the choice of using the "correct" pattern that properly test for "certainly false". So, why doesn't tribool throw in this case? Fernando Cacciola SciSoft

1 0

Re: [boost] singleton design plan
by JOAQUIN LOPEZ MU?Z 28 Jul '05

28 Jul '05

----- Mensaje original ----- De: Jason Hise <chaos(a)ezequal.com> Fecha: Jueves, Julio 28, 2005 11:25 pm Asunto: Re: [boost] singleton design plan > Michael Goldshteyn wrote: > > >What is: > > > >namespace boost > >{ > > const class > > { > > > >??? > > > It worked with VC, but I just checked it with comeau and it failed > to > compile. To fix it, I had to provide a name for the class and an > explicit default constructor. Naming the class null works, > because then > the class name is hidden by the global variable name and thus > other > instances of type null cannot be declared. You can still gain access to the class type by typing "class null": class null other_null; Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Interest in an ODBC library?
by JOAQUIN LOPEZ MU?Z 28 Jul '05

28 Jul '05

Hello Brian, ----- Mensaje original ----- De: Brian Braatz <brianb(a)rmtg.com> Fecha: Jueves, Julio 28, 2005 10:34 pm Asunto: Re: [boost] Interest in an ODBC library? > If you are interested in collaborating, I have wanted to (for some > timenow) build the table<> aspect of what you are working on. > > My goals: > 1- functional drop in replacement for ADO recordset > 2- Dynamic and static "views" and indexes > 3- binding model that does NOT force you to use the bindings supplied > with the library > this is something ADO lacks, and something I have had to work > around to great frustration > 4- the ability to COPY from one table<> to another table<> > * ADO does NOT ALLOW you to copy recordsets. (brilliant no?) > > > Additionally - > > I am not sure if he is still interested, but Joaquin Munez and I > exchanged emails awhile back about collaborating on such a beast. > > The general idea was to take the functionality in multi-index > containerand make it work dynamically. > I am still interested, and it is my plan to implement a dynamic_multi_index_container in the future, if there's interest in such a thing --serving as the foundation for a DB table structure would be a very exciting application, undoubtedly. Let me sketch what I have in mind: The part of adding/removing indices at run time is not too hard: I haven't written any actual code, but the design of that feature seems reasonably straightforward to me. Some speed/space performance will be lost, but I guess this is expected. The hard part, IMHO, is how to gain access to such indices. Clearly some kind of runtime polymorhpisn is involved for a dynamic_multi_index_container to have any use: otherwise, the user code would have to know the exact type of the index it is retrieving. So we need something more powerful than the current static get<> interface. A possibility is to retrieve indices by mean of *interfaces* as defined in Jonathan Turkanis' BIL library: http://www.kangaroologic.com/interfaces/libs/interfaces/doc/ This interface concept provides the needed run-time polymorphism without having to cast the index classes into a rigid abstract hierarchy. This would allow the user to tune the polymorphic functionality exposed by indices from the most general (iteration) to the most concrete (for instance, set-like functionality, so restricting the type of acceptable indices that can go into the container) only by defining the interface to which the indices must conform. Of course, this is just a bunch of random thoughts and the BIL library is not part as of yet of Boost, so I don't think I'll be ready to provide something until mid 2006 or so. Moreover, it's still to be seen whether a dynamic_multi_index_container is of interest to the Boost community. > > I am working on something unrelated to this discussion that could > form a > good foundation for table<>. I should have something to share > middle of > next week. > > Just let me know if you are interested in putting our heads together. > Sure! I'll be reading your table<> material as soon as you make it available. Soon I'll be on a three-week vacation, so I might have some time to write my ideas about a dynamic_multi_index_container in a more structured way. Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[1.33.0] Branch for release
by Doug Gregor 28 Jul '05

28 Jul '05

We've now branched for the 1.33.0 release. The branch is RC_1_33_0. The main trunk is open for changes, now, but I'd urge everyone to be somewhat cautious while we're dedicating our testing resources to the branch. Doug

3 2

MPL: for_each missing from ref manual
by Brian Braatz 28 Jul '05

28 Jul '05

sorry, (for the poor timing) I just noticed mpl::for_each does NOT seem to be in the MPL reference manual. it does appear in mpl_paper.pdf, but I could not find it anywhere else (grepped the html)

1 0

Re: [boost] MPL:Possible Placeholder problem with transform & if_(?)
by Brian Braatz 28 Jul '05

28 Jul '05

On Behalf Of Aleksey Gurtovoy > Brian Braatz writes: > > Either something strange is happening with arg<> and transform or I did > > not write this code correctly. ( :) ) > > The latter :). > By requesting '::type' on a metafunction you are immediately > instantiating it with the placeholder argument(s), which is not what > you want. Try > > typedef mpl::transform< > vec_t > , mpl::if_< > , boost::is_same<mpl::_1, A> > , YES< mpl::_1 > > , NO< mpl::_1 > > > > >::type result; > [Brian Braatz Writes:] THANK YOU - This is very helpful (in many ways) :)

1 0