- Boost - lists.boost.org

[gsoc2008] Calendar library
by KTC 20 Mar '08

20 Mar '08

Just wanted to test the waters here. One thing that I've been wanting to do is a calendar library. In my experience, I have found what is available at the moment to be very limited. Either they only have support for Gregorian calendar, plus one or two more if lucky, and or there's serious bugs in its implementation like not taking into account skipped days when converting from Julian to Gregorian. What I would propose could either be an extension to the current Boost.Date_Time library, or a new library using its own design. Main features would be built in support of up to 20 calendar systems, conversion, calculation of secular and religious holidays, days between dates, day of week, and time zones support. Any feedback is appreciated. Kwan Ting Chan (KTC) -- Experience is a good school but the fees are high. - Heinrich Heine

2 1

[1.35][Boost.Test] Lots of broken links?
by John Maddock 20 Mar '08

20 Mar '08

There are currently a lot of broken links in the Boost.Test documentation: doc/components/prg_exec_monitor/compilation.html: *A* broken link: ../../../build/Jamfile doc/components/prg_exec_monitor/index.html: *A* broken link: ../../../../../boost/test/cpp_main.hpp doc/components/test_tools/index.html: *A* broken link: ../../tests/boost_check_equal_str.html doc/components/test_tools/reference/BOOST_CHECK_CLOSE.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html doc/components/test_tools/reference/BOOST_CHECK_MESSAGE.html: *A* broken link: BOOST_MESSAGE.html doc/components/test_tools/reference/BOOST_CHECK_SMALL.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html doc/components/test_tools/reference/tools_list.html: *A* broken link: ../../btl1.gif, *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html doc/components/utf/compilation.html: *A* broken link: ../../../build/Jamfile doc/components/utf/components/index.html: *A* broken link: ../../btl1.gif doc/components/utf/components/test_case/abstract_interface.html: *A* broken link: ../../../btl1.gif doc/components/utf/components/test_case/auto_register_facility.html: *A* broken link: ../../../btl1.gif doc/components/utf/components/test_case/boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp, *A* broken link: ../../../btl1.gif doc/components/utf/components/test_case/class_tc.html: *A* broken link: ../../../btl1.gif doc/components/utf/components/test_case/function_tc.html: *A* broken link: ../../../btl1.gif doc/components/utf/components/test_case/index.html: *A* broken link: ../../../btl1.gif doc/components/utf/components/test_case/param_boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp, *A* broken link: ../../../btl1.gif doc/components/utf/components/test_case/param_class_tc.html: *A* broken link: ../../../btl1.gif doc/components/utf/components/test_case/param_function_tc.html: *A* broken link: ../../../btl1.gif doc/components/utf/components/test_case/tc_template.html: *A* broken link: ../../../btl1.gif doc/components/utf/components/test_log/custom_log_formatter.html: *A* broken link: ../../../btl1.gif doc/components/utf/components/test_log/index.html: *A* broken link: ../../../btl1.gif doc/components/utf/components/test_result/index.html: *A* broken link: ../../../btl1.gif doc/components/utf/components/test_suite/index.html: *A* broken link: ../../../btl1.gif doc/components/utf/index.html: *A* broken link: getting_started/index.html doc/components/utf/parameters/build_info.html: *A* broken link: ../../btl1.gif doc/components/utf/parameters/catch_system_errors.html: *A* broken link: ../../btl1.gif doc/components/utf/parameters/detect_memory_leaks.html: *A* broken link: ../../btl1.gif doc/components/utf/parameters/index.html: *A* broken link: ../../btl1.gif doc/components/utf/parameters/log_format.html: *A* broken link: ../../btl1.gif doc/components/utf/parameters/log_level.html: *A* broken link: ../../btl1.gif doc/components/utf/parameters/no_result_code.html: *A* broken link: ../../btl1.gif doc/components/utf/parameters/output_format.html: *A* broken link: ../../btl1.gif doc/components/utf/parameters/random.html: *A* broken link: ../../btl1.gif doc/components/utf/parameters/report_format.html: *A* broken link: ../../../../../LICENSE_1_0.txt, *A* broken link: ../../btl1.gif doc/components/utf/parameters/report_level.html: *A* broken link: ../../btl1.gif doc/components/utf/parameters/show_progress.html: *A* broken link: ../../btl1.gif doc/examples/unit_test_example1.html: *A* broken link: ../../example/unit_test_example1.cpp doc/examples/unit_test_example2.html: *A* broken link: ../../example/unit_test_example2.cpp doc/examples/unit_test_example3.html: *A* broken link: ../../example/unit_test_example3.cpp doc/examples/unit_test_example4.html: *A* broken link: ../../example/unit_test_example4.cpp doc/examples/unit_test_example5.html: *A* broken link: ../../example/unit_test_example5.cpp, *A* broken link: ../../example/unit_test_example5.input doc/tests/auto_unit_test_test.html: *A* broken link: ../../test/auto_unit_test_test.cpp doc/tests/auto_unit_test_test_mult.html: *A* broken link: ../../test/auto_unit_test_test_mult1.cpp, *A* broken link: ../../test/auto_unit_test_test_mult2.cpp doc/tests/unit_test_suite_ex_test.html: *A* broken link: ../../test/unit_test_suite_ex_test.cpp doc/tutorials/hello_the_testing_world.html: *A* broken link: ../../../../../LICENSE_1_0.txt, *A* broken link: ../execution_monitor/index.html doc/tutorials/new_year_resolution.html: *A* broken link: ../../../../../../LICENSE_1_0.txt Plus one license/copyright missing: test/auto-link-test/auto_link_with_utf.cpp: *C*, *L* Any chance of some fixes for this in time for 1.35 release? Many thanks, John.

4 4

[1.35.0] Attention library maintainers: Broken links
by Beman Dawes 20 Mar '08

20 Mar '08

I've fixed dozens of the most obvious broken links in Boost.Test documentation, both trunk and release branch. There are still 20 or so broken links left. I find it pretty irritating when the release manager and other volunteers have to fix a library's broken links. This is something that maintainers should check periodically, and fix themselves. The Boost "inspect" tool can be run in any directory to find broken links and other problems in that directory and its sub-directories. That makes it easy to check potential fixes without waiting for the full inspection report to cycle. --Beman

2 2

ptr_vector cleanup question
by Robert Dailey 19 Mar '08

19 Mar '08

Hi, Below I have posted code that I'm trying to clean up. I'm specifically trying to clean up the MainFunction() implementation. You'll notice that I'm creating an object on the heap, Initializing it, and if the initialization fails I simply delete the object. However, if it succeeds I proceed to add it to my ptr_vector container and keep it. There are a few things to be cautious about, however: 1) Connect() may or may not throw exceptions, which would ultimately result in a memory leak. 2) The Socket object is not copy constructable. One idea I thought of to clean this up was to define my ptr_vector as a container of shared_ptr<Socket> objects, however I'm not sure if this is recommended. It would definitely solve the problem of exceptions being thrown. Perhaps there's a boost::shared_ptr_vector somewhere I don't know about :) class Socket { public: bool Connect() { /* Assume valid implementation */ return false; } }; boost::ptr_vector<Socket> sockets; void MainFunction() { Socket* mySocket = new Socket; if( mySocket->Connect() ) { sockets.push_back( mySocket ); } else { delete mySocket; } }

2 2

Passing strings as a template parameter (small utility)
by Tom Brinkman 19 Mar '08

19 Mar '08

As you know, you can't pass a string as a template parameter. Nevertheless, I have found that I often need to do just that. This small utility allows you to pass a string as a parameter. I call it "static_string". This could possibly given to one of the google students as an easy project. Otherwise, here an example of what I do to solve this problem. typedef static_string<'H','E','L','P'> help_t; std::string help = help_t(); BOOST_CHECK(help == "help"); template <typename T> void foo() { std::string str = T(); BOOST_CHECK(str == "help"); } foo<help_t>(); template <char a=' ', char b=' ', char c=' ', char d=' ', char e=' ', char f=' ', char g=' ', char h=' '> char i=' '> char j=' '> char k=' '> char l=' '> struct static_string { operator std::string() { char ch[7]; sprintf(ch,"%c%c%c%c%c%c%c%c%c%c%c%c", a,b,c,d,e,f,g,h,i,h,k,l); std::string str = ch; boost::trim(str); return str; } };

3 2

Re: [boost] [Boost-testing] Testing fails on trunk with r43710
by Rene Rivera 19 Mar '08

19 Mar '08

Nicola Musatti wrote: > Hallo, > I've just tried running bjam on Windows with the following arguments: > bjam -a -l600 --v2 --dump-tests toolset=msvc-8.0 1>bjam.log 2>&1 > > My bjam version is: > Boost.Build V2 (Milestone 12) > Boost.Jam 03.1.16 > > The result is the following: > > ../util/test.jam: No such file or directory > Am I doing anythong wrong? Nothing... The problem was this check-in: <http://svn.boost.org/trac/boost/changeset/43691/trunk/libs/serialization/te…> Unfortunately it's a large composite check-in that is just about impossible for me to revert or fix. Robert needs to check in the missing files. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 3

StateChart: Propagating events with orthogonal states
by Peters, Richard 19 Mar '08

19 Mar '08

Hello, While using the Boost.StateChart library, I noticed strange behaviour when orthogonal states are used. Supposed I have a state machine with state A, which contains a state B, and state B has two orthogonal states C and D. Suppose A handles some event E, and D is able to handle the same event E. Now if the statemachine is in state C and D and I send event E, this can happen: E is sent to C, which is unable to handle E. E gets forwarded to B, and then to A. There, it is handled by A. I would expect this behaviour: E is sent to C, it is unable to handle it, and then the event E is forwarded to the next orthogonal state in B, which is D. Then, D is able to handle it. This way, event E ends up handled by D instead of by A. The statechart reference states the current behaviour as the correct behaviour: Class template state_machine, void process_event specifies in point 3: "Select an arbitrary but in this reaction search not yet visited state from all the currently active innermost states." and in 4a: "Searches a reaction suitable for currentEvent, starting with the current innermost state and moving outward until a state defining a reaction for the event is found." So, the implementation matches the specification. But what is the reason that it is not specified that first all orthogonal states are tried before moving outward in search for a reaction? Is this the way the UML standard specifies it? I tried to read the UML standard, but I can't find something relevant for propagating events. best regards, Richard Peters This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

2 1

[serialization] Fix Jamfile
by Vladimir Prus 19 Mar '08

19 Mar '08

Robert, in revision 43697 you have added usage requirements to serialization's Jamfile, as follows: http://tinyurl.com/2hbzyu It appears that this change is not necessary. If any other target depends on serialization, then it will implicitly depend on serialization's dependencies. Adding <dependency> to usage requirements will mean that if I have a library depending on serialization, than that library will also have dependency on ../../config/test//BOOST_NO_STD_LOCALE If my library does not use that, there's no reason why it should have a dependency. Furthermore, due to the way Boost is build, this dependency can be added to basically all libraries, which is hardly needed. Because of that, I have removed usage-requirements setting on trunk. Also, I've noticed that you have about 10 commits, all having the same commit message: Support serialization in DLLS Make thread-safe fix portable binary archives It does not seem a good practice, as it's hard to understand what each given commit was meant to do. Can you try to use descriptive messages for each commit. FWIW, good guidelines on writing commit messages can be found at: http://subversion.tigris.org/hacking.html#log-messages Thanks, Volodya

2 6

[thread] Docs don't build on release branch
by Darren Garvey 19 Mar '08

19 Mar '08

Hi Anthony, The Jamfile.v2 in libs/thread/doc/ seems to be missing a 'using quickbook ;' I quite like the new organisation. Do you have any idea how stable this API is likely to be though, with it tracking the C++0x standard proposals? Regards, Darren

4 9

[gsoc2008] interest for component library?
by Themis Bourdenas 19 Mar '08

19 Mar '08

Hi, I want to propose a project for participation in Google SoC 2008 with boost. My proposal is a software component library for C++. The goal is the creation of a library that assists component based software development, bringing a well defined, existing model to C++. Is there any interest for such a library? nesC is an extension to the C language developed in UC Berkeley to support development in real-time embedded systems running tinyOS. The extensions to the C language are around the notion of components/modules and their orchestration (configuration) in order to deploy a running application. They use a meta-compiler that transforms nesC code to ANSI C, which then actually runs on the motes. Of course the nesC programming model is not tied to real-time systems and translates in large systems as well. My proposal is to provide the same model in a C++ library, without the need of a meta-compiler, but providing a DSEL. If you are unfamiliar with nesC, you can find more in http://nescc.sourceforge.net/, but below I'll give a quick overview and glossary of the terms used in the model and how they can translate in C++. - interface -- an abstract class that defines an API contains commands and events - module -- a class that is a concrete implementation of one or more interfaces, it provides and uses one or more interfaces - provide -- the relationship of a module that provides an interface is similar to the inheritance relationship, the module implements the interface's declared commands and triggers its declared events - use -- a module that uses an interface implies that it requires the existence of a module that implements that interface - command -- an exported function declared in an interface, implemented by a module - event -- a signal declared in an interface, fired by a module - configuration -- a specification of wiring (mapping) of modules to interfaces, constructing an entity that can be considered as a composite module (aka orchestration of components) - wiring -- instantiation of a module and attachment to an interface that is used by another module or configuration The benefits of component based development are obvious; clean architectural dissemination of software, self-containment of modules and orchestration of new services and applications based on already existing ones. I have adjusted the basic concepts behind nesC as presented in its web site to translate to general programming: - separation of construction and composition: programs are built out of components, which are assembled ("wired") to form whole applications. - specification of component behavior in terms of set of interfaces. Interfaces may be provided or used by components. The provided interfaces are intended to represent the functionality that the component provides to its user, the used interfaces represent the functionality the component needs to perform its job. - interfaces are bidirectional; they specify a set of functions to be implemented by the interface's provider (commands) and a set of signals fired to the interface's user (events). This allows a single interface to represent a complex interaction between components (e.g., registration of interest in some event, followed by a callback when that event happens). - components can be statically linked to each other via their interfaces, furthermore components should be linked dynamically (at run-time) allowing modification of program's behavior. Below I give an example of orchestration for an IDE application where you want to setup the environment to handle C++ sources. Setup compilers, source documents, runtime env, source editor etc. configuration cpp_ide { module<ide>.interface<Compiler> -> module<gcc> module<ide>.interface<SourceFile> -> module<CppSource> module<ide>.interface<Editor> -> module<CppEditor> module<ide>.interface<Output> -> module<Console> } In the above simple example we create a configuration of the ide module, namely cpp_ide, wiring its interfaces to some implemented modules. The notation of module<> and interface<> is to help you distinguish between different entities. Alternatively, you could setup the environment for e.g. python given that you implement the proper modules, reusing code from some common modules (e.g. console and the ide infrastructure). I want to support both static configurations like this and dynamic configuration, (e.g. setup an environment depending on configuration files). Of course the true benefits of components come from the fact that they can be dynamically loaded at runtime. I intend to use the boost.extension library, which seems to have reached a stable state, for facilitating this requirement. That would require components to just depend on interfaces instead of actual implementation. In addition, I want to expand the library to interoperate with boost.reflection so that a module's interface can be wired with an arbitrary module as long as it provides the functional requirements set by the interface. In the latter case detection of incompatibilities between modules (i.e. missing functions) are postponed and handled during runtime, as they can not be resolved statically. So, please give me some feedback on whether such a library would be an interesting contribution to boost and if you want me to elaborate on my ideas for the project. Cheers, Themis

1 0