- Boost - lists.boost.org

[asio] Support for raw sockets and ICMP in latest version
by Carlo Medas 08 Sep '08

08 Sep '08

Dear Asio developers, I've seen with some excitement the new release which announces raw sockets and ICMP support. Since I've not been able to find any new example showing usage of these features, I've tried to investigate the code but I still got the same question: is ICMP packet receive/sending supported? And moreover, are raw data (IP layer?) sockets supported and thus usable? Thanks in advance. Kind regards, Carlo Medas

1 0

Re: [boost] [boost numeric binding] patch
by Michael Gauckler 08 Sep '08

08 Sep '08

Hi Thomas, Under Linux gccxml is setting the __GNUC__ and everything works. Under Windows it is trying to emulate msvc (and therefore not setting __GNUC__), this is why it fails and why this additional check is necessary. Attached again the patch, which also indicates which files needs to be patched. Regards, Michael

1 0

Re: [boost] [boost numeric binding] patch
by Thomas Klimpel 08 Sep '08

08 Sep '08

Hello Michael, I could certainly apply your patch, but why doesn't GCCXML defines __GNUC__ in the first place, when it's effectively just a gcc? Or is it indeed different from gcc, so that I should test that it really works? Regards, Thomas

1 0

[RFC] Boost library name mangling and Microsoft's 'secure STL' feature.
by Jurko Gospodnetić 08 Sep '08

08 Sep '08

Hi all. There have been requests to make Boost Build cleanly support Microsoft's 'secure STL'/'checked iterators' feature. Here's is one suggested implementation and how that will affect building Boost libraries on Windows: We add a new <msvc-checked-iterators> Boost Build feature with values 'off' and 'on' and 'off' being the default. The effect of the feature would be to define the SCL_SECURE preprocessor constant to 1 for feature value 'on' or to 0 for feature value off. This would affect only code compiled using MSVC compiler versions 8.0 & above. Libraries compiled with compilers affected by this setting would have their name mangling changed as follows: * If the setting is 'off' there would be no change. * If the setting is 'on' the name would get en extra letter 'c' added to its 'runtime tag' letter group (together with 's' for statically linked libraries, 'd' for debug, 'p' for the stlport standard library, etc.). Effects this would have on Boost libraries: * If we implement the proposed solution the default Boost library build behaviour will change. Boost libraries built by default will have Microsoft's secure STL (a.k.a. checking iterator) support disabled while currently, when we do nothing explicit about those settings, Microsoft compilers enable that support by default. * Making a complete Boost library build using the MSVC toolset will take twice as long as there may now be twice as many property combinations affecting the build. On the other hand user can always easily choose from the build command line which versions he wants in case he wants a subset. Selecting msvc-checked-iterators=on would get the current default behaviour. Some extra ideas to consider: * Add an additional 'default' feature value which would cause Boost Build to do nothing. This would on the other hand mess up library name mangling unless Boost Build were taught to know exactly what defaults each compiler or compiler version uses. Please give your comments on at least the following: * Feature name. * Any additional values that might be needed. * Any additional compiler flags/options/preprocessor constants that might be related to this. * Default value. * Library name mangling. * Any additional compilers this might affect, e.g. Comeau, Intel, etc. * Any additional runtime libraries this might affect, e.g. stlport. Many thanks for any feedback you can provide. Best regards, Jurko Gospodnetić

12 22

Mixed use of "include" directives with quoted vs. angle-bracketed params, causing havoc
by Victor Vojtech Terber 08 Sep '08

08 Sep '08

I have multiple Boost versions installed in different file locations. I occasionally ran into problems with mixed-up Boost headers. This was due to Boost's use of both quoted and bracketed syntax of the include directive to include its headers. The standard allows for different results for resolving the include directive depending on the chosen form. In particular the angle-bracketed form is narrower than the quoted one (see chapters 16.2.2 and 3). So the point in the file system from where the file will actually be included may legally differ, based on the form of the include directive. I don't mind which alternative Boost uses. But in my opinion it should be consistent inside Boost headers, shouldn't it? With some file system layouts it gets very inconvenient to pre-determine by simple set-up of compiler or environment variables which version will get used. I also fail to see any obvious downside of a unification.

8 15

[dataflow][review] Dataflow.Signals and threading - new docs and examples
by Stjepan Rajko 07 Sep '08

07 Sep '08

Hello, I have added a section on threading to the Dataflow.Signals tutorial: http://tinyurl.com/69subd (my hosting provider appears to be having some intermittent problems today - I apologize to any reviewers impacted by this) This new section summarizes information related to threading, and presents a new example component that uses the Threadpool library by Oliver Kowalke to provide support for asynchronous signals. Here is an excerpt regarding the Threadpool component: The purpose of the component is to make a signal call asynchronous. Instead of the consumer component processing the signal immediately, the signal call will be added to a thread pool and processed later. async_component is a class template, templated on the threadpool type, and the type of the underlying component that will process the asynchronous signal. The three examples provided are: * mixing synchronous and asynchronous signals * assigning priorities to tasks / signals * using asynchronous signals for cyclic networks Thanks to everyone that has participated in the discussion regarding this library so far. I hope this documentation update will provide some additional information on how the library can be used / extended. Stjepan

1 0

[boost numeric binding] patch
by Michael Gauckler 07 Sep '08

07 Sep '08

Hi, I have a little patch (a three-liner, given below) that allows the boost numeric bindings to be parsed by GCCXML. Can somebody with write-access to the sandbox please apply this little patch? Thanks. Best regards, Michael 21a22,23 > #elif defined(__GCCXML__) >

1 0

What's up with the trunk test summary?
by Emil Dotchevski 07 Sep '08

07 Sep '08

This link doesn't quite work for me: http://beta.boost.org/development/tests/trunk/developer/summary.html Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 2

[threadpool] determining whether a Threadpool type uses a priority/attribute
by Stjepan Rajko 07 Sep '08

07 Sep '08

Hello, Suppose I have a Threadpool type, which could for example be either of the following: tp::pool< tp::fixed, tp::unbounded_channel< tp::priority< int > > > -or- tp::pool< tp::fixed, tp::unbounded_channel< tp::fifo > > How do I find out whether Threadpool involves a priority/attribute, and what the type of it is? For example, I am looking for something that would give me: // returns something like mpl::true_ for the first case // returns something like mpl::false_ for the second case has_priority<Threadpool>::type // returns int for the first case priority_type<Threadpool>::type Thanks in advance, Stjepan

3 4

lifetime of ranges vs. iterators
by Arno Schödl 07 Sep '08

07 Sep '08

Hello, some adaptor ranges need certain constant information about their underlying ranges. For example, iterating over a forward "difference_range", the difference between two sorted ranges, requires access to the ends of the underlying ranges. These two additional iterators are constant, they do not change when the difference_iterator is incremented. Now, where should this additional constant information be stored? a) In the difference_range, and each iterator holds a reference to the difference_range? That requires the difference_range to be alive as long as its iterators are alive. This may be difficult to ensure if the difference_range is a temporary. b) In the iterators, so the lifetime of adaptor iterators is independent of the adaptor range. Of course, one can use shared_ptrs and so on, but still the iterators are ultimately responsible to keep that information available. This initially seemed more natural to me, but if implemented naively by storing the additional iterators in the iterator itself, it leads to storage bloat: each difference_iterator needs 4 instead of 2 of its underlying iterators. When stacking difference iterators, the difference in required storage grows exponentially: instead of 2^N, you need 4^N storage... I feel that in order to solidify the range concept, one needs to make a choice whether a) or b) is "standard", because any user of ranges would need to know. Any thoughts on this? Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

7 118