- Boost - lists.boost.org

bjam stage forgot symlinks FIX BEFORE RELEASE
by Neal Becker 29 Jul '05

29 Jul '05

I just built from a recent cvs using: ICU_PATH=/usr ICU_LINK="-licuuc -licui18n" PYTHON_ROOT=/usr PYTHON_VERSION=2.3 bjam -sTOOLS=gcc stage I noticed that symlinks are missing. for each lib "x", in stage/lib there is libx.so.1.0.0 (actual binary) libx.so -> libx.so.1.0.0 (link) but there must be also libx.so.1 -> libx.so.1.0.0 This is because (I guess) soname of the library is set to libx.so.1, and when you link to libx then at runtime it will look for libx.so.1 (which it won't find)

2 2

Re: [boost] Interest in an ODBC library?
by Brian Braatz 29 Jul '05

29 Jul '05

Joaquin! Glad you responded and Good to be "talking" with you again :) Below: > On Behalf Of JOAQUIN LOPEZ MU?Z [Brian Braatz Writes:] > > > > 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. > > > [JOAQUIN LOPEZ MUNEZ Writes:] > 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: [Brian Braatz Writes:] If you would please elaborate. (some of us are "slower" than others :) ). is the problem getting to the index objects themselves via inherit_linearly? if you have dynamic data, then I am thinking you also have dynamically applied indices? Maybe I can elaborate- consider the following pseudo code: connection con = db.connect("myserver,root,password,mydatabase"); dynamic_table dt; // the select "*" means bring me back all the fields from that table // even though I don't know what the fields ARE yet dt = query("select * from person"); // ok so now dt has an UNKNOWN number of columns dt.add_index( index("first_name")); // or something along those lines. in this case, the index is applied dynamically. so how does that connect with the things you said ? Thanks, Brian

2 1

[pointer container] new libraries docs?
by David Abrahams 29 Jul '05

29 Jul '05

Why does pointer container appear in both the new and updated libraries section of the main page? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[signals] making Assignable and CopyConstructable
by Rebooted 29 Jul '05

29 Jul '05

In my program I need to store a map of signals, with an integer id corresponding to a signal in the map. Objects can request to be informed when another a specific message is emitted by connecting a member function to the signal in this map at the index corresponding to that message type. However, since boost::signal inherits noncopyable, it cannot be stored in a map. What are the reasons for signal being noncopyable, and is there any chance this could be changed in the future?

4 3

[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