June 2005 - Boost - lists.preview.boost.org

[shared_ptr] supress warning for BCB6.4
by Pavel Vozenilek 30 Jun '05

30 Jun '05

Borland C++ 6.4 emits a warning (in release mode) for function add_ref_lock() from sp_counted_base_w32.hpp ("cannot expand it inline because of for inside"). I use CVS version few weeks old. Wrapping the function with #pragma helps: ----------------- #include <boost/detail/workaround.hpp> .... #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) # pragma warn -8027 // function with "for" is not expanded inline #endif bool add_ref_lock() // true on success { .... } #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) # pragma warn .8027 #endif --------------------- Could this workaround be applied? - it is a bit annoying and completely useless warning /Pavel

2 1

Re: [boost] Library Proposal: Boost.Geom 2D and 3DGeometricPrimitives
by Hickerson, David A 30 Jun '05

30 Jun '05

I will locate the library this evening and upload it. One this about it was I developed it before I saw Boost and had developed my own conventions. I did this as part of a thesis work in Robotics and will I was working for a 3D Vis company. There are references to robot convension and a graphics convension. This is because the robotics and engineering use a column vector notation and the graphics community uses a row vector convension or least OpenGL does. If those involved with Boost are interested, I would like to donate the code for use in developing the capabilities here. Dave Hickerson -----Original Message----- From: Geoff Carlton [mailto:gcarlton@iinet.net.au] Sent: Wednesday, June 29, 2005 8:22 PM To: boost(a)lists.boost.org Subject: Re: [boost] Library Proposal: Boost.Geom 2D and 3DGeometricPrimitives Hickerson, David A wrote: > I have done some of this in the library I wrote in 97. I'd be curious to see that. I'd like a simple, common set of geom classes. The concept of these traits is a very interesting and clever one, but I don't think its useful in practice. You'd want a simple set of classes, and if they are generically useful then the conversion to library variants is simple: either construct a new temporary, or even a straight reinterpret_cast for performance. In particular, the basics are: 1.) Easy definition Preferably: class point2i; // descended from point2<int> void DoSomething(const point2i& mypoint); Alternatively: template<class T> class point2; typedef point2<int> mypoint2i; void DoSomething(const point2i& mypoint); 2.) Easy instantiation Definitely: point2i pos(1,2); Ideally (somehow): point2i pos2[2] = { { 3, 4 }, { 5, 6 } }; 3.) Very clear class layout So we can know when reinterpreting the object is possible. 4.) Minimum of templates and macros Want this to be compile-able across the board, and simple to understand. 5.) Basic methods in class Length(), LengthSq(), Normalise(), etc 6.) Set of algorithm functions to operate on these types Similar to STL, a separate group of functions. Having written all this, its hard to go past the MagicSoftware library. It defines many basic primitives and then a whole lot of useful operating functions. Hmm.. I should probably just use that in the future. :) Geoff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Boost Installer using NSIS
by Christopher Boumenot 30 Jun '05

30 Jun '05

Greetings, I been following the discussion about the generation of a Boost installer, and decided to take the plunge. I have the beginning of a Boost installer. It's a Perl script that scans an already installed version of Boost and generates a generic XML description. (I envision the release manager building Boost and then uploading the Windows installer to sourceforge.net.) This XML description is fed back into the script, and it generates an NSIS script. I've been doing some testing on my system. Using the free compiler from Microsoft (Windows 2003 Toolkit) and building Boost myself results in about 525 MB of data. Using the NSIS installer brings the entire installation down to 10.5 MB, a sizeable reduction. Not all of the targets are built because the toolkit doesn't ship with all of the necessary libraries. I think people were quoting 700 MB or so, that should still result in a small installer. The XML file is broken up into modules, or libraries. It uses bcp to generate a list of dependencies for each module. Only those files necessary are installed. The list of modules is generated dynamically based on the top-level files located in the include/boost-1_XX/boost. The library directory is also scanned to determine which files correspond to which module. (This is on my TODO list, see boostal.pl for details.) It should be easy to add support for other installers. They can parse the XML file to get all of the information they need. More information can be added as necessary I've placed the script on the Web for perusal: http://www.divebomb.org/proj/scripts/boostal.tgz, and the generated NSIS file is available http://www.divebomb.org/proj/scripts/boost.nsi.gz. I've added more documentation to the script about how it works. I'm also looking at the Boost builder GUI for Windows as well. (Someone had suggested win32gui as a start, and that looks good to me.) Let me know what you think, if this works, what needs to be addressed/fixed/tweak, etc. Christopher

1 0

[OT] Enabling exported templates with Intel for Windows.
by Jonathan Turkanis 30 Jun '05

30 Jun '05

Hi, I know this is OT, but I can't think of a better place to ask. Intel on Linux supports exported templates with the -export and -export_dir options. Supposedly, Intel for Windows also supports exported templates, as an "undocumented and unsupported" feature.(http://www.comeaucomputing.com/iso/promises.html) Could someone tell me how to enable export for Intel on Windows, and how to specify the location of the template implementations? I couldn't find anything about it on the web. Is it a big secret? Jonathan

3 4

RE: [boost] [Ann]: Dox - a C++ documentation tool
by Brian Braatz 30 Jun '05

30 Jun '05

Wow, good job. I like the output. disadvantage: long emails trying to decide which theme to standardize on (grin) Advantage- looks cleaner than doxygen. QUESTION: What tools do you depend on for the program to work? I.e. tcl, perl etc. What are the external dependancies? > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Narech Koumar > Sent: Wednesday, June 08, 2005 3:23 PM > To: boost(a)lists.boost.org > Subject: [boost] [Ann]: Dox - a C++ documentation tool > > Dear all, > > A beta test of a C++ documentation tool, Dox, is transpiring at: > > http://dox.isfotek.se > > Constructive feedback and angry comments are greatly appreciated. > > > Thanks, > > - Narech Koumar > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 2

[filesystem][i18n] missing header file from i18n.zip
by Roman Yakovenko 30 Jun '05

30 Jun '05

Hi. I downloaded new version of boost::filesystem from http://www.esva.net/~beman/i18n/. filesystem/path.hpp has include to "mutable_constant.hpp" file. This file is missing. Roman

2 1

Re: [boost] Boost.config not recognize threading support enabled?
by BRIDGES Dick 30 Jun '05

30 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On > Behalf Of John Maddock > Sent: Tuesday, June 28, 2005 8:26 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Boost.config not recognize threading support enabled? > > > [Dick] Nope, not sure at all. I overlooked "limited to linux on arm". > > (At any given time our "build" currently uses six instances of gcc - > > various PowerPC, x86 look-a-likes, DSPs, etc. - and I'll worry about > > those later.) Yes, your suggestion to put the test in libstdcpp3.hpp > > seems like it would work nicely. As a no-longer-lurking newbie, can I > > do something or do I sit back and wait for someone to add that test? > > Well I can add the test, if you can tell me what defines identify Linux on > arm. [Dick] According to "echo | gpp -dM", (__linux__ | __linux__) && __arm__ should work. <snip> > John. Thanks again for your help. Dick

2 1

Re: [boost] VC8 function template ambiguity problems
by Michael Stevens 30 Jun '05

30 Jun '05

On Wednesday 29 June 2005 19:40, "Peter Dimov" <pdimov(a)gmail.com> wrote: > Michael Stevens wrote: > > template<class V> > > void hard (V &data, const typename vector_range<V>::range_type &r) > > {} > > template<class V> > > void hard (vector_slice<V> &data, const typename > > vector_slice<V>::range_type &r) > > {} > > [...] > > > It thinks the functions 'hard' are ambiguous despite the fact that > > the first parameter is more specialised in the second version. > > The functions do seem ambiguous to me. I see no partial ordering between > them. I'm being a little hard on the compiler here. In the single parameter case. Things are easy, the second template is more specialised. The difficultly is the second parameter. In the first case we have vector_range<V>::range_type in the second vector_slice<V>::range_type The crux of the problem is these two are actually the same type! I think VC is missing this when it performs 'argument deduction against the other function template' to determine if the templates are 'at least as specialized'. See 14.5.5.2 para 4. At least some other modern compilers (GCC4.0, Intel 8.0 CW-9.4) are with on this on this! VC has no problems if we help it by using 'vector_range<V>::range_type' in both cases. Thanks, Michael

1 0

Re: [boost] VC8 function template ambiguity problems
by Michael Stevens 30 Jun '05

30 Jun '05

On Wednesday 29 June 2005 09:34,Rob Stewart <stewart(a)sig.com> wrote: > What about putting them in a class template? Then you could > introduce typedefs to simplify the expressions the compiler must > grok. Rob, thanks for the reply. It stimulated a few ideas and I now have a solution. The actual problem (in uBLAS) was slightly more complex then the 'hard' function as the return value depended also on the template argument. With a few helper classes and a lot a PTS I can deduce the return value and provide apply functions. Now VC only has order overloaded template functions with single arguments and is happy. Thanks, Michael

1 0

[BGL] Help! read_graphviz has syntax error
by Tan Kwee Heong 30 Jun '05

30 Jun '05

Hi, I posted this on the Boost User's group and did not have any response. I'll try again on the Boost Developers' group. On Win2K ( using cygwin g++ 3.3.1 ) using boost_1_32_0, read_graphviz has a syntax error when reading a digraph .dot file. The simplest way to reproduce this is to build a static libbgl-viz.lib and run the libs/graph/example/graphviz on the graphviz_test.dot input data. Note that the bjam reports that the testcase pass, but if you execute the graphviz.exe binary manually, you'll see the syntax error, like so: | > gcc/graphviz ../../../../../../../../../libs/graph/example/graphviz_test.dot | ... | syntax error | The same sources, when built with VC7.1 will pass with the correct output, when run manually. Like so : | > vc7/graphviz ../../../../../../../../../libs/graph/example/graphviz_test.dot | ... | a1 --> a2 b3 | a2 --> a3 | a3 --> end | a0 --> a1 a2 a3 | ... I can provide more information if needed. The basic question I have is whether this is a known problem for g++ 3.3.1 or a simple bug that someone more knowledgeable can take a look/fix. Thanks,

1 0