- Boost - lists.boost.org

Boost regression notification (2006-10-13 [RC_1_34_0])
by Douglas Gregor 13 Oct '06

13 Oct '06

Boost Regression test failures Report time: 2006-10-13T10:29:08Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 71 failures in 13 libraries filesystem (2) io (1) iostreams (8) mpl (6) parameter (6) program_options (9) python (5) random (1) rational (5) serialization (18) spirit (7) test (2) utility (1) |filesystem| mbcopy: sun-5.8 wide_test: sun-5.8 |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 example_test: vc-6_5-stlport finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 zlib_test: msvc-7.1 msvc-8.0 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 vector_c: sun-5.8 |parameter| optional_deduced_sfinae: sun-5.8 preprocessor_deduced: sun-5.8 python_test: qcc-3.3.5_gpp sun-5.8 sfinae: borland-5_8_2 vc-6_5-stlport |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test_dll: borland-5_8_2 cw-9.4 winmain_dll: cw-9.4 |python| numpy: darwin-4.0.1 gcc-3.3.6 gcc-3.4.4 slice: gcc-3.3.6 gcc-3.4.4 |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 sun-5.8 vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_contained_class_binary_archive_dll: gcc-3.2.3_linux test_contained_class_xml_archive: gcc-3.2.3_linux test_non_default_ctor2_text_archive: qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |spirit| action_tests: qcc-3.3.5_cpp qcc-3.3.5_gpp action_tests_debug: qcc-3.3.5_cpp qcc-3.3.5_gpp mix_and_match_trees: sun-5.8 typeof_iterator: intel-vc8-win-9.1 msvc-8.0 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

Re: [boost] Boost super_string
by Greer, Joe 13 Oct '06

13 Oct '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of loufoque > > Those functions are perfectly grouped in string_algo, which is a very > explicit name. But why should I look there? string has replace/find_first_of/etc. Obviously it has higher level manipulations, why should I think to look further? > > > > For better or worse, C++ is > > documented as a OO language and not as a procedural language. > > C++ isn't a OO language. > There isn't a C++ Standard Library official documentation, but from all > the ones I have seen it's certainly not documented that way. Have you looked at the standard? Basic_string is documented very much like a object and there is no mention of external algorithms for manipulating it anywhere near the documentation for it. > > Anyway, my point is that it is a huge documentation difference when it > > comes to being able to see what is available to be done to a string. I > > have seen a few attempts to treat string specially in the documentation > > and lump things together. However, this is generally inconsistent with > > all the other objects and for no better reason than C++ has a lame > > string class. > > It's not very good, indeed, but I wouldn't call it lame. Well, given the differences between std::string and std::vector<char>, I would. Add the STL algorithms and most everything can be done with the vector that can be done with the string. I think that makes string pretty lame. joe

1 0

Re: [boost] Boost super_string
by Greer, Joe 13 Oct '06

13 Oct '06

> On Behalf Of Martin Adrian > > Why is > > boost::super_string ss(s) > ss.trim() > > easier than > > boost::trim(s) > Well, because boost::trim(s) isn't "object oriented". It's procedural and if I am looking up operations to do on a string via the string's documentation, I won't see an external function named trim. This makes it very difficult for people to find out what the available operations are. This is very different than basic or other procedural languages in that procedural languages make an effort to group related functions in their documentation whereas oo languages do not. For better or worse, C++ is documented as a OO language and not as a procedural language. Furthermore, if we were to say the strings should be manipulated via functions, then we need to yank methods out of the string class so that we don't have a multiple personality disorder going on. AFAICT, the current situation buys us nothing good and cause people to seek a more rational language. I use this language every day, but I have to say that there is a certain love/hate relationship with it. There is just so much you just have to *know* with no consistent way of finding it if you don't. Google is really your friend in many cases. Anyway, my point is that it is a huge documentation difference when it comes to being able to see what is available to be done to a string. I have seen a few attempts to treat string specially in the documentation and lump things together. However, this is generally inconsistent with all the other objects and for no better reason than C++ has a lame string class. Just my opinion and experience, joe

2 1

bgl subgraphs
by Brian Makin 13 Oct '06

13 Oct '06

With respect to boost graph library. Is anyone using subgraphs? What are they being used for? Is there functionality which is needed wrt subgraphs? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Boost super_string
by shams 13 Oct '06

13 Oct '06

Hi, Sometime ago there was discussion about an "enhanced" Boost.String (super_string) library from Jeff. Has there been any interest in this as-of lately? Is there possibilility that it will be get included in Boost? It sure will attract the attention of c++ novices. Also Jeff: Are most of the interfaces for string_algo implemented in your super_string library from RC_1.34? Thanks Shams

6 18

[multi_index] Relationship Table
by Joe Gottman 13 Oct '06

13 Oct '06

One pattern that seems to come up pretty often is the relationship table. Suppose I have 2 classes, Employee and Skill. An Employee can have any number of Skills, and a Skill can be possessed by any number of Employees. But an Employee can have a given Skill only once. The user would need to be able to search for which Skills a given Employee has, and which Employees have a given Skill. What is the best way of using a multi_index_container to model this use case? Suppose, in addition, that every Employee who has a Skill has a numerical rating at that Skill. How would you do a multi_index_container in that case? Joe Gottman

2 1

[type-traits] much dead code in integral_constant.hpp
by Ronald Garcia 13 Oct '06

13 Oct '06

Howdy, A large amount of code in boost/type_traits/integral_constant.hpp appears to be #if'ed out. Can that code be safely removed from the file or is it a work in progress? Thanks, ron

3 2

Re: [boost] Geometry/Vector Lib
by brangdon＠cix.compulink.co.uk 13 Oct '06

13 Oct '06

In-Reply-To: <4528E0F8.1070503(a)yar.nu> macke(a)yar.nu (Marcus Lindblom) wrote (abridged): > The point I'm trying to make is that there is as almost much opinion on > member-access on vectors as there are on code indent size. So, whatever > we make ought to support everything, if we want it to be acceptable to > a large audience? And I was making the more-or-less opposite point, that the interface doesn't matter too much as long as it doesn't expose the representation. The core question is whether encapsulation matters for a class like this. With emphasis on the "like this" - I'm sure we all love encapsulation normally, and the issue is whether this is one of the rare exceptions. If we support the v.x syntax we can't store vectors in polar representation, or add checks or instrumentation to accesses, or have values that are calculated on demand, or use any number of other techniques which rely on information hiding. Does it matter in this case? It's ultimately a judgement call, and I don't think my own opinion should carry any special weight, so I will try to stop posting about it after this and let you get on with it. -- Dave Harris, Nottingham, UK.

2 1

GIL Review - Extended to October 25
by Tom Brinkman 13 Oct '06

13 Oct '06

As review manager of the GIL library, I believe that there is sufficient interest to warrent extending the formal review period by another 10 days, until October 25. Of course, I will accept reviews after that date as well. GIL is an Adobe sponsered graphics library and part of the ASL (Adobe Source LIbraries). Its being developed by some very talented graphics developers at Adobe and clearly deserves much more attention than it has received so far. Please, please get your reviews in. I need alot more feedback. Tom Brinkman Review Manager

1 0

Re: [boost] [mpl] BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS Problems
by Jared McIntyre 13 Oct '06

13 Oct '06

I just realized I misunderstood the documentation. Assuming Visual Studio can support more than 50 parameters, how would one go about building out the source so that they could use an mpl::map with more than 50 parameters? I actually have a needs for several hundred, but have a feeling I will be splitting those up into multiple maps (or some other technique). Even with splitting it up, I'd like to try to increase the number in each if possible. Jared >I have an extremely large mpl::map who's size doesn't fit in the pre >defined map files. I'm trying to get mpl to >process the map without using the preprocessed file. I've added a >BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS define to the >atdafx and a BOOST_MPL_LIMIT_MAP_SIZE where map is defined. It >continues to want to use the file associated with >BOOST_MPL_LIMIT_MAP_SIZE. BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS is >definitely being defined before any mpl header >files are loaded. Any thoughts? This is Boost 1.33.0 if that makes >any difference. The attempt to load the file is on >line 36 of map.hpp. > >Jared

1 0