October 2005 - Boost - lists.boost.org

[ptr_container] boost::ptr_map
by Alexey Bakhvalov 10 Oct '05

10 Oct '05

ptr_map<>::insert(key, value) function is taking first argument by non-const reference. Is it missing 'const' there?

5 4

Re: [boost] GUI coordinate units (Was: GUI foundations)
by brangdon＠cix.compulink.co.uk 10 Oct '05

10 Oct '05

In-Reply-To: <4342E0EF.4050601(a)sympatico.ca> seefeld(a)sympatico.ca (Stefan Seefeld) wrote (abridged): > > Maybe there's a reason for that. I'm not saying don't do it, but I'd > > recommend doing some experiments that prove it's actually possible > > before investing too much. > > Definitely, there are reasons. But as with the Y2K bug, it is mostly a > question of how long into the future you plan. Surely it's more a question of how far into the past you support? > Imagine new 200 dpi devices being ready for production but not usable > as no GUIs are available that can deal with that high a resolution. I'm kind-of asking why we will succeed when other people have failed. It sounds like the answer is "anti-aliasing". The GUI will only support devices that have enough colours to do good anti-aliased rending. OK; that may be a reasonable answer. Most modern devices seem to have lots of colours even when they don't have lots of pixels. For example, my phone has only 208x320 pixels but 16 bits of colour. -- Dave Harris, Nottingham, UK.

3 2

Re: [boost] GUI coordinate units (Was: GUI foundations)
by brangdon＠cix.compulink.co.uk 09 Oct '05

09 Oct '05

In-Reply-To: <4342E209.2050006(a)yahoo.com.au> mw8329(a)yahoo.com.au (Martin Wille) wrote (abridged): > Did you look at the examples on the antigrain.com website? They show > that with good anti-aliasing and with subpixel accuracy you get very > good results even when the display resolution is lower than the > resolutions of the details of the displayed objects. The spirals at > http://tinyurl.com/836fe look pretty impressive, IMHO. I hadn't (but have now). I already knew about anti-aliasing, though. I work in desktop publishing. My employers have their own graphics library which uses subpixel accuracy and anti-aliasing. I didn't design it but I work on and with it. It seems roughly similar in functionality to the AGG project, except that we place a lot of importance on text and vectors and I can't find text mentioned on their manual page. We find that for sending output to printer or PDF or whatever, it's important to output text as text as much as possible and only output as bitmaps for features the target device doesn't support. Anyway, yes, anti-aliasing helps, and is the only way to deal with curves, but grid-fitting gives better results where possible. As Stefan Seefeld says later, we can't hide the pixels completely. -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] GUI coordinate units (Was: GUI foundations)
by brangdon＠cix.compulink.co.uk 09 Oct '05

09 Oct '05

In-Reply-To: <di20dn$2lh$1(a)sea.gmane.org> joel(a)boost-consulting.com (Joel de Guzman) wrote (abridged): > Seriously, look at it the other way... most docs and layouts that > need accurate layouts (e.g CAD drawings) are in metric. I don't see this as an argument for metric, but as an argument for not imposing any particular unit system on apps. That said: currently output resolution is described in "dots per inch" - in imperial units. For example, screens are 96dpi or 72dpi, and some printers are 300dpi. Applications which naturally use metric have rounding issues whatever they do; you can't help them. You can help imperial ones by not forcing them to convert to metric as a spurious intermediate step. -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] GUI coordinate units (Was: GUI foundations)
by brangdon＠cix.compulink.co.uk 09 Oct '05

09 Oct '05

In-Reply-To: <434426EF.5030808(a)yahoo.com.au> mw8329(a)yahoo.com.au (Martin Wille) wrote (abridged): > > But you aren't going to draw a PCB on screen with boost.GUI widgets. > > Why shouldn't a good GUI library be prepared for that use case? I think he's saying that the use case would be handled by a different component of the library. I'm coming around to the idea that the library should use ints and device pixels for its core graphics units. Or rather, some fraction of pixels: probably 100 or 256 units per pixel. All other units eventually get converted to this. The conversion is dependant on the device, and if a component needs to be device-independant it uses its own units and defers conversion until it knows what device it is using. Many widget calculations won't care what the units are at all. Some sizing happens top-down. The user drags out a window, the app gives half the space to one widget and half to the other. It doesn't care what the units are, it is just dividing by two. Some sizing happens bottom-up. Often this is driven by text. A button needs enough room to display the word "Cancel" in 12-point text. int height = 12 * device.points_to_gu(); Font font( "Arial", height ); int width = font.width( "Cancel" ); I don't think there is any need to force the width to be in absolute units. Both millimetres and inches would be wrong for someone. A PCB would be laid out with a CAD app, which would measure in millimetres. Part of its rendering pipeline would be a conversion from mm to graphic units. A dialog editor is a different kind of app. It might measure in points and have a different conversion. The Microsoft one uses what it calls "dialog units", which are scaled according to dialog's chosen font, which can in principle be changed by the end-user. We don't need to force the dialog editor to use the same internal units as the CAD app. When they need to communicate, they can use pixels units * 256 a lingua-franc. I do not think the need for a device-independant linga-franca is compelling enough for it to dominate the core GUI. -- Dave Harris, Nottingham, UK.

1 0

Boost regression notification (2005-10-09 [RC_1_33_0])
by Douglas Gregor 09 Oct '05

09 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-09T14:02:08Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 151 failures in 5 libraries: graph (1) iostreams (1) range (3) serialization (141) spirit (5) |graph| graphviz_test: cw-9_4 |iostreams| gzip_test: gcc-4_0-darwin |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_binary_text_archive: vc-7_1 test_binary_text_archive_dll: vc-7_1 test_class_info_save_text_archive: vc-7_1 test_class_info_save_text_archive_dll: vc-7_1 test_demo_xml_load: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 test_demo_xml_load_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_derived_text_archive: vc-7_1 test_derived_text_archive_dll: vc-7_1 test_exported_binary_archive: gcc-3.2.3-linux gcc-4.0.1-linux intel-9.0-linux vc-6_5 test_exported_binary_archive_dll: gcc-4.0.1-linux vc-6_5 test_exported_text_archive: gcc-3.2.3-linux gcc-4.0.1-linux vc-6_5 vc-7_1 test_exported_text_archive_dll: gcc-3.2.3-linux gcc-4.0.1-linux vc-6_5 vc-7_1 test_exported_text_warchive: gcc-4.0.1-linux vc-6_5 test_exported_text_warchive_dll: gcc-4.0.1-linux vc-6_5 test_exported_xml_archive: gcc-4.0.1-linux intel-8.1-linux vc-6_5 test_exported_xml_archive_dll: gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux vc-6_5 test_exported_xml_warchive: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux vc-6_5 test_exported_xml_warchive_dll: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux vc-6_5 test_mi_text_archive: vc-7_1 test_mi_text_archive_dll: vc-7_1 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_non_default_ctor2_text_archive: vc-7_1 test_non_default_ctor2_text_archive_dll: vc-7_1 test_non_default_ctor_text_archive: vc-7_1 test_non_default_ctor_text_archive_dll: vc-7_1 test_non_intrusive_text_archive: vc-7_1 test_non_intrusive_text_archive_dll: vc-7_1 test_null_ptr_text_archive: vc-7_1 test_null_ptr_text_archive_dll: vc-7_1 test_object_text_archive: vc-7_1 test_object_text_archive_dll: vc-7_1 test_primitive_text_archive: vc-7_1 test_primitive_text_archive_dll: vc-7_1 test_registered_text_archive: vc-7_1 test_registered_text_archive_dll: vc-7_1 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 test_split_text_archive: vc-7_1 test_split_text_archive_dll: vc-7_1 test_tracking_text_archive: vc-7_1 test_tracking_text_archive_dll: vc-7_1 test_unregistered_binary_archive: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux test_unregistered_binary_archive_dll: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux test_unregistered_text_archive: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux vc-7_1 test_unregistered_text_archive_dll: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux vc-7_1 test_unregistered_xml_archive: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux test_unregistered_xml_archive_dll: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux test_unregistered_xml_warchive: gcc-4.0.1-linux test_unregistered_xml_warchive_dll: gcc-4.0.1-linux |spirit| bug_000008: gcc-3_4_3-sunos grammar_mt_tests: gcc-3_4_3-sunos owi_mt_tests: gcc-3_4_3-sunos scoped_lock_tests: gcc-3_4_3-sunos scoped_lock_tests_debug: gcc-3_4_3-sunos

1 0

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

09 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-09T05:00:33Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 105 failures in 12 libraries: concept_check (13) foreach (1) functional/hash (1) graph (2) mpl (1) parameter (13) serialization (39) spirit (8) thread (4) tuple (1) typeof (21) wave (1) |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 |foreach| user_defined: msvc |functional/hash| container_fwd_test: msvc |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |parameter| basics: 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 msvc macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: 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: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: 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 test_non_default_ctor_binary_archive: vc-7_1 test_non_default_ctor_text_warchive: vc-7_1 test_null_ptr_xml_warchive_dll: vc-7_1 |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 function_native: cw-9_4 msvc function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 msvc member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 msvc template_type_native: cw-9_4 type_native: cw-9_4 |wave| testwave: gcc-3.3.6-linux

1 0

Still boostbook problems
by David A. Greene 09 Oct '05

09 Oct '05

I've been dealing with this issue (build log below)for a couple of months now. I've updated from the latest CVS, rebvuilt bjam, run the boostbook auto-setup, etc. The only difference from the CVS is that I've added documentation for my named template parameters implementation. This is preventing me from putting NTP up for viewing. Can anyone help? Thanks. -Dave ---------------------- cd ~/src/boost/install/ cd ~/src/boost/doc && ~/bin/bjam --v2 /home/greened/src/boost/tools/build/v2/build/toolset.jam:26: in using *** argument error * rule boostbook.init ( docbook-xsl-dir ? : docbook-dtd-dir ? : boostbook-dir ? ) * called with: ( /home/greened/src/boost/install/docbook-xsl-1.67.2 : /home/greened/src/boost/install/docbook-dtd-4.2 using xsltproc : /usr/bin/xsltproc : : : : : ) * extra argument using /home/greened/src/boost/tools/build/v2/tools/boostbook.jam:63:see definition of rule 'init' being called /home/greened/user-config.jam:63: in modules.load /home/greened/src/boost/tools/build/v2/build-system.jam:115: in load /home/greened/src/boost/tools/build/v2/kernel/modules.jam:261: in import /home/greened/src/boost/tools/build/v2/kernel/bootstrap.jam:172: in boost-build /home/greened/src/boost/boost-build.jam:12: in module scope Compilation exited abnormally with code 1 at Sat Oct 8 14:07:50

2 1

Re: [boost] GUI foundations
by brangdon＠cix.compulink.co.uk 09 Oct '05

09 Oct '05

In-Reply-To: <43426645.30304(a)torjo.com> john.lists(a)torjo.com (John Torjo) wrote (abridged): > And, about usability in code. Why would I want in my program, both: > gui::rect<pc,double> and gui::rect<pc,int> ? For my apps I have found there needs to be two levels. There's a device/raster level, which wants to use pixels and ints, and there's a logical/world level, which uses units like inches or cm and floating point. The device/raster level uses pixels and ints because that's what raster hardware uses. This is not something you can really abstract away from. For example, it's important to scroll by an integral number of pixels else anti-aliasing makes the lines change colour. The logical/world level needs to be device-independant. It probably needs to be scale-invariant too; for example, a rectangle that measures 2x3 needs to keep its aspect ratio if you halve its size. My employers actually use ints and very small units - 1/72000ths of an inch - which are also the units used by Postscript and PDF. That decision now seems dated to me and more and more of my geometry code is moving to floating point. It works better. It may be that boost doesn't need to tackle the logical/world level immediately. The window-manager stuff and the low-level drawing stuff can use pixels and ints. However, at least some programs will want a logical level too when they come to draw. > Just think of the many places you'll need to deal with geometry > (rectangle/point/size), and converting from one type of unit (px to cm, > cm to in, etc) to another. I'd rather explicit conversion than an attempt to abstract away the differences. Typically there is a world-to-device linear transform that does the conversion. A single matrix operation provides rotation, scrolling and zoom in addition to scaling from inches or centimetres or whatever. -- Dave Harris, Nottingham, UK.

3 3

serialization of vector<string>
by Ben Artin 08 Oct '05

08 Oct '05

I am using boost 1.32. When I serialize a string, no metadata is written, as implementation_level<string> is set to primitive_type in serialization/string.hpp. However, when I serialize a vector<string>, I end up with metadata, because implementation_level<vector<string> > is not set anywhere and therefore defaults to object_class_info. Every other primitive type appears to be covered by BOOST_SERIALIZATION_COLLECTION_TRAITS and therefore implementation_level<vector<T> > is object_serializable for every other primitive type. I checked in 1.33 and there don't appear to be any relevant changes, but I could be wrong. My question: is this an omission; that is, should implementation_level<vector<string> > be object_serializable? (And similarly for other collections of strings.) Thanks, Ben -- If this message helped you, consider buying an item from my wish list: <http://artins.org/ben/wishlist> I changed my name: <http://periodic-kingdom.org/People/NameChange.php>

2 1