- Boost - lists.boost.org

Re: [boost] [Boost-build] another simple boost build failure
by Jürgen Hunold 25 Oct '12

25 Oct '12

Hi Ronny, On Thursday, 25. October 2012 12:55:10 you wrote: > thanks a lot. I did not know that one has to rebuild everything after > changing the requirements. It seems to work now. Good to hear that everything is up and running. > It is true, I did not read the starting guide thoroughly, I'll do that now > :-). Good, too ;-) > I am a bit confused about the library being a static library. Shouldn't it > be "boost_filesystem-vc90-mt-gds-1_50.lib" instead of > "boost_filesystem-vc90-mt-gd-1_50.lib" then? Or did I get it wrong? Ah, that is the "s" for static runtime. AFAIK the last msvc to provide a static runtime was 7.1. Don't confuse "static library" with "static runtime libraries". The static runtime opens up a new can of worms... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1

[Program Options] terminate parsing after first positional argument
by Evan Driscoll 25 Oct '12

25 Oct '12

This summer there was some discussion on the boost-users list about whether it is possible to use program_options to write an interface like 'xargs' (or time, or env, or nohup, or ssh, or sudo, or valgrind, or Python, or lots of other tools) where any options (--foo) that appear after the first positional arguments are considered positional arguments. In other words,'xargs foo --help' in real Unix behaves the same as 'xargs -- foo --help', rather than 'xargs --help foo', but you can't get this behavior currently from Boost. I proposed a couple patches, and there was a very small amount of discussion, but it sort of petered out (in part because I went away for a couple weeks at an inopportune time). Is there any interest in adopting them? The bug I filed just got another hit from someone else who wants it. https://svn.boost.org/trac/boost/ticket/6991 The following is a summary of the status: The ideal would be to have an 'allow_interspersed' style option which would be set by default (to give the now-usual behavior of "cmd arg --opt" being the same as "cmd --opt arg") but which a client program could unset if they wanted the xargs-like behavior. However, I don't see how to do this, because > If someone says > style_t style = allow_short | allow_slash_for_short > I can't automatically go and set allow_interspersed for them as well. And so without some ugly and not-worth-it coding tricks (changing style_t to a class), unless I'm missing something you can't pick this ideal without breaking backwards compatibility. So I instead suggested a new 'disallow_interspersed' style option, which would be off by default (keeping backwards compatibility) but you could set it to get xargs-like behavior, but this is inconsistent with all the other style flags which are allow_xxx. So what do you want to do regarding this issue? References: Trac issue: https://svn.boost.org/trac/boost/ticket/6991 (includes a patch for both of those options) The previous messages in this discussion, on boost-users: http://lists.boost.org/boost-users/2012/07/75100.php Evan

1 0

Using libc++ when compiling with clang in c++11 mode
by Marshall Clow 24 Oct '12

24 Oct '12

Has come up again: https://svn.boost.org/trac/boost/ticket/7566#comment I'm thinking that having a clang-c++11 toolset (that includes using libc++) might be a good thing. Any other opinions? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 1

Is there a way to specialize how a smart_ptr<T> releases the T?
by David Hagood 24 Oct '12

24 Oct '12

I am trying to wrapper around a C library (specifically, libxml2) so that I can use it within a C++ program. (yes, I am aware of libxml++ - but it doesn't play nice with libxslt). If the core libxml2 objects were internally reference counted, I could use an intrusive_ptr, and have the friend intrusive_ptr_release call libxml2's release function, and all would be well - but unfortunately libxml2 does not internally reference count the objects (at least, not in a way I have seen). If there were a way to specialize smart_ptr<T> such that instead of the destructor calling delete(), it called what I wanted, I'd be set, but I see no way to easily specialize smart_ptr<xmlDoc> in that way - or am I missing something?

8 10

Application using boost libraries (commercial)
by Dominic Amann 24 Oct '12

24 Oct '12

Application: EKKO_Project V1 R1 Company: Sensors & Software Inc, Description: EKKO_Project is the all-inclusive software solution for managing, displaying, processing and interpreting GPR data. It provides easy, highly efficient analysis and integration of GPR data. The software is optimized for Windows 7 and later operating systems. Boost Usage: filesystem, multi-array, smart pointer, date time, iterators, optional, program options, property tree, regex, test, tokenizer, type traits, uBlas. These boost libraries were used extensively in the core program functionality to make a cross-platform library that would allow a thin platform specific GUI to control all basic functionality. URL: <http://sensoft.ca/> Product page: <http://sensoft.ca/Products/Software/Details-Features.aspx#EKKOProject> Thank you, Dominic Amann Software Developer Sensors & Software Inc. 1040 Stacey Court, Mississauga ON. L4W 2X8 Toll Free: 1-800-267-6013 ext. <user ext> T: 905-624-8909 F: 905-624-9365 C: 416-270-4587 E: DAmann(a)sensoft.ca www.sensoft.ca<http://www.sensoft.ca/> subsurface imaging solutions

1 0

[atomic] unconditional cmpxchg8b support
by Tim Blechmann 23 Oct '12

23 Oct '12

hi helge & list, using boost.atomic on ia32/gcc causes me quite some headaches these days, as the cmpxchg8b instruction is enabled via the __i686__ or __x86_64__ macros. however on debian for example, the compiler defaults to generate code for i486. cmpxchg8b has been introduced with the p5 architecture, though, so compiling without specifying a -march flag won't generate the instruction. whatever, i wonder if it would be reasonable to enable cmpxchg8b by default on *all* ia32 platforms, not just on i686. advantage: less trouble, as we can be sure that the instruction is generated. boost.lockfree e.g. is not lockfree on ia32 without. disadvantage: the code won't work on i386 and i486 machines. imo, all ia32 machines without cmpxchg8b should belong to a museum, and we could introduce a macro like BOOST_ATOMIC_NO_CMPXCHG8B if we really care of compiling for any of those machines. thoughts? tim

7 16

In case you missed it
by Ioannis Papadopoulos 23 Oct '12

23 Oct '12

http://pubby8.wordpress.com/2012/10/15/stack-based-template-metaprogramming… A small stack machine using templates.

2 2

[preprocessor] question
by Jorge Lodos Vigil 23 Oct '12

23 Oct '12

This is regarding to BOOST_PP_IS_NULLARY macro. I would like to use it with only 2 types of inputs: 1. Empty parenthesis: () 2. Plain C++ identifier within parenthesis: (identifier) With this input restrictions, is it safe to use BOOST_PP_IS_NULLARY in portable code that must be compiled in different platforms? Thanks in advance. Jorge

2 1

[graph] strange behaviour of relax
by Jan Hudec 23 Oct '12

23 Oct '12

Hello All, Writing special variant of dijkstra's algorithm I wanted to reuse the `relax` function (from boost/graph/relax.hpp) that is used by dijkstra_shortest_paths_no_color_map. And I've notices what I think is mismatch in behaviour between relax and dijkstra_shortest_paths_no_color_map. When the graph is not oriented, the relax function will consider decreasing distance of either target (obiously) or source. However it returns the same true in both cases, so the caller does not know which vertex was updated and the dijkstra_shortest_paths_no_color_map does not expect having to update the source at all. It shouldn't happen, but than why is that condition there? It appears to me that one or the other is wrong. But I don't know the code well enough to tell which. Regards, Jan -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 2

Re: [boost] [system] symbol visibility and GCC vs. Clang
by Mathias Gaunard 23 Oct '12

23 Oct '12

On 22/10/12 23:29, James Walker wrote: > When trying to link a bunch of libraries on OS X, I got this linker > warning: > > ld: warning: direct access in > boost::system::system_error::~system_error() to global weak symbol > vtable for boost::system::system_error means the weak symbol cannot be > overridden at runtime. This was likely caused by different translation > units being compiled with different visibility settings. > > As far as I can tell, everything is compiled using the flags > -fvisibility=hidden -fvisibility-inlines-hidden. > > I'm wondering whether the problem is that some of the libraries were > built using gcc and some were built using Clang. In > boost/system/system_error.hpp, the declaration of > boost::system::system_error is decorated with BOOST_SYMBOL_VISIBLE. In > boost/config/compiler/gcc.hpp, BOOST_SYMBOL_VISIBLE is defined to be > __attribute__((visibility("default"))), whereas > boost/config/compiler/clang.hpp does not define BOOST_SYMBOL_VISIBLE. This looks like a significant bug, POSIX-style symbol visibility doesn't work with Clang. Please file a ticket. Forwarding to developers mailing list.

1 0