- Boost - lists.boost.org

[Boost.Lambda] Some new features are suggested: return, iterating yield, & local var
by Huang Huan 06 Jan '12

06 Jan '12

Hi boosters, I'm intrested in Lambda, so I have worked out some new features, and suggest boost lib add them. What can I do next? NEW features: 1. return. why lambda lib do not include this? 2. generate iterator/iteration by lambda using yield return/yield break. 3. local/global var declare and using. 1. return e.g. boost::function<char(int)> f = ( if_ ( _1 >= 0 ) [ return_('a') ], return_('b') ); p.s. return should be supported. 2. iterator/iteration generation by lambda using yield return/yield break const char* p; // we shuld use the local var inside lambda instead of this var p. refer to section 3 iteration<char> it = ( for_(var(p) = _1, *var(p), var(p)++) [ if_(*var(p) != ' ') [ yield_return(*var(p)) ] if_(*var(p) == ';') [ yield_break() ] ] ) ("I love this game; no use"); p.s. The packing iteration interface is very like the yield keyword in C# IEnumeable 3.local/global var declare and using e.g. char a; var_name x, y, z; global_var<int>(y); // put this line inside lambda is ok, just before use it ( ( local_var<int>(x), // local var declare // global_var<int>(y), var(a) = 'a', var<int>(x) = _2, // using local var x ), ( local_var<char>(z), var(a), var<int>(x) = _1, // error! x is not local var here. var<int>(y), // ok for global even if another lambda var<char>(z) = 'b', ) ) p.s. Now, in my work. It's hard to simplify var<T>(x) to var(x). It's a hard template working.

5 14

Re: [boost] [log] Status (was: Is there any interest in a Group of library like to Application System!)
by Andrey Semashev 06 Jan '12

06 Jan '12

On Wednesday, January 04, 2012 09:08:16 Renato Tegon Forti wrote: > Hi Andrey, > > Thanks for your response! What is status of your lib? Do you need any help? The library is moving slowly to v2 release. Right now I'm wrapping up bounded async frontends, I intend to finish them by the weekend. Other things left to be done before the release are: - Port filters and formatters to Phoenix v3. As a part of it, improve error messages in exceptions and make filters and formatters not throw by default. - Introduce "default" sink concept to mitigate problems with trivial and advanced logging coexistence. Trivial logging will no longer initialize the library under the hood. - Implement a common attribute registration mechanism to simplify library extension. This should solve problems with settings file parser not recognizing user-defined attribute types. - Update the documentation. There are many other things to be done but they are not showstoppers for the release. Yes, help would be much appreciated, most notably in the porting to Phoenix v3 part. If anyone is willing to help, please contact me privately or through this list.

3 9

[Graph] Concept check VertexMutablePropertyGraph
by Jens Müller 05 Jan '12

05 Jan '12

Hi, http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/MutablePropertyGraph.ht… (I cannot find docs for VertexMutablePropertyGraph or EdgeMutablePropertyGraph) says that the types boost::graph_traits<G>::vertex_property_type and boost::graph_traits<G>::edge_property_type must exist. However, the concept checks (in boost/graph/graph_concepts.hpp) check for vertex_property_type<G>::type and edge_property_type<G>::type, respectively. Several questions: 1. Should there be separate docs for VertexMutablePropertyGraph and EdgeMutablePropertyGraph? 2. Should there be an actual concept check implementation for MutablePropertyGraph combining the two? 3. Should the concept check look for boost::graph_traits<G>::vertex_property_type instead of ertex_property_type<G>::type? [and the same for edge] 4. For the LEDA adapter, i.e., external adaptation, do I have to specialize vertex_property_type<G> and edge_property_type<G>? Best, Jens

2 3

[graph] VertexListGraph and InputIterator, and LEDA graph
by Jens Müller 05 Jan '12

05 Jan '12

Hi all, I'm currently fixing up leda_graph.hpp so it passes the tests, or indeed, fixing the tests ... A leda::GRAPH<int,int> (=Graph) has to fulfill VertexListGraphConcept. This means that boost::graph_traits<G>::vertex_iterator has to be a MultiPassInputIterator, i.e., also a InputIterator. I cannot read from http://www.sgi.com/tech/stl/InputIterator.html that it must be possible that you can compute the difference between two iterators. But apparently the concept check (which fails) requires a difference type, which must be a signed integer. Is this a bug in the concept check? The vertex_iterator type is defined in leda_graph.hpp using iterator_facade: class vertex_iterator : public iterator_facade<vertex_iterator, leda::node, bidirectional_traversal_tag, const leda::node&, const leda::node*> { public: vertex_iterator(leda::node node = 0, const leda::GRAPH<vtype, etype>* g = 0) : base(node), g(g) {} private: const leda::node& dereference() const { return base; } bool equal(const vertex_iterator& other) const { return base == other.base; } void increment() { base = g->succ_node(base); } void decrement() { base = g->pred_node(base); } leda::node base; const leda::GRAPH<vtype, etype>* g; friend class iterator_core_access; }; Is maybe iterator_facade insufficient? For me, bidirectional_traversal_tag does not indicate that random access is possible ... -- Jens

2 4

[chrono] Possible bug in boost::chrono::process_real_cpu_clock::now() under Windows 32bits
by ivan.lelann＠free.fr 05 Jan '12

05 Jan '12

Hi, As of 1.48 Boost.Chrono contains code below for boost::chrono::process_real_cpu_clock::now() (boost\chrono\detail\inlined\win\process_cpu_clocks.hpp) clock_t c = ::clock(); /* ... */ return time_point( duration(c*(1000000000l/CLOCKS_PER_SEC)) ); duration::rep is int64/nanoseconds, clock_t is long. This is VS2008, Win XP 32bits. I think "c" should be cast to duration::rep before being multiplied. I randomly get negative time_point and this seems to be fixed by replacing "c" with "((duration::rep) (c))" in duration constructor : duration( ((duration::rep) (c)) *(1000000000l/CLOCKS_PER_SEC)) Can someone confirm my view and that the fix is correct ? Regards, Ivan

3 3

Is there any interest in a library for Application System? (Request for comments)
by Renato Tegon Forti 05 Jan '12

05 Jan '12

Some detail (Brainstorm): This library will provide a simple way to create an application that can be: . A Server Application A server application usually starts when system boot, and then remain running as background process, don't matter who is currently logged. In Windows this will a "Windows Service" and in UNIX a "UNIX Daemon", and we can create a "Neutral Application" that is not a daemon and service, but uses "service interface" that will provide methods like an "init", "interrogate", "restart" and so on. Some type of "system global mutex" will be implemented in this flavor, then if user want, he can determine that only one instance of service will run in a system in same time. A web server, data base server and so on area examples. . A Usual Application A usual application is a normal application, that don't need all of features provided by "server application" usually is started by a user and run by a determined period. A command, mail client, MPI master/Slave and so on area examples. . Base Class Both classes will be derivated of environment class that will provide common thinks and proprieties like an "app path", "app name", "app work dir" and so on. For sample: A user that want create a server, extend your class of "server class" and then override methods that want to get needed behavior. // windows service, or daemon class myapp : public boost::application::server{}; // neutral server class myapp : public boost::application::server<neutral>{}; // usual application class myapp : public boost::application::app{}; Note that: 1) Application can be configured using Boost.Program_options 2) I want use Boost.Log to provide log functionality when available. 3) I want create a "service model" then I want use Boost.Extension to provide dynamically late bind extension (Pluf-in System). What Boosters think? This is useful or is fool lib? Boosters think that "this kind of lib" is very specific, and violate: "The library must be generally useful and not restricted to a narrow problem domain." or this kind of system is relevant to boost. Please let me know the correct way to follows! Please make suggestions! What more else? Thanks

2 2

Copyright and authorship notices
by Jens Müller 05 Jan '12

05 Jan '12

Hi all, what is the policy of adding a Copyright notice and entries to the author list when patching existing files? I found http://www.boost.org/development/requirements.html#Ownership, but it is not completely helpful. -- Jens

3 5

[thread] Boost.Thread defines boost::move which conflicts with Boost.Move
by Hartmut Kaiser 05 Jan '12

05 Jan '12

VC10, SVN trunk: #include <boost/move/move.hpp> #include <boost/thread.hpp> int main() { return 0; } Results in: .../boost/thread/detail/move.hpp(28) : error C2995: 'remove_reference<T>::type &&boost::move(T &&)' : function template has already been defined .../boost/move/move.hpp(466) : see declaration of 'boost::move' IMHO, Boost.Thread needs to be changed to rely on Boost.Move for move semantics instead of defining its own implementation for boost::move(). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

4 13

Font used in the current Boost logo
by Mateusz Łoskot 04 Jan '12

04 Jan '12

Hi, I have tried to find what font is used in the Boost logo but without any luck. There seem to be no logo in vector format included in the trunk. The SVG file from the logo variants is not helpful: http://dbp-consulting.com/boostvariantslogo.html Does anyone know where to find the font or vector version of the logo? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 1

[geometry] GGL mailing list moved
by Mateusz Loskot 04 Jan '12

04 Jan '12

Hi, To Whom It May Concern... The Boost.Geometry library mailing list has moved from ggl at lists.osgeo.org server to geometry at lists.boost.org server. All existing subscribers and archives have been moved to the new server. The new list is available at: http://lists.boost.org/mailman/listinfo.cgi/geometry as well as listed on the main page: http://lists.boost.org/ It is also mirrored at Nabble: http://boost-geometry.203548.n3.nabble.com/ (Mirror at gmane.org may be added in future.) The old list at lists.osgeo.org will be wiped out soon. If anyone experiences any problems with the new geometry at lists.boost.org, please contact me directly. I'd like to thank OSGeo Foundation for hosting the first mailing list and the Boost mailman admins for help with the new one. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0