November 2013 - Boost - lists.preview.boost.org

Valgrind andboost::filesystem::path::has_branch_path()
by Miguel Guedes 17 Nov '13

17 Nov '13

Hello list, Valgrind reports invalid reads [0] in a very simple example I've uploaded to pastebin [1]. Is there some funky stuff happening behind the scenes that is causing a false positive or is this really an issue? Using libboost 1.54 on Linux. [0] http://pastebin.com/HmS94cwF [1] http://pastebin.com/h98z2K1Z

2 1

Boost.Application new version available.
by Re 15 Nov '13

15 Nov '13

Hi Brook, Thanks for your commenets. I will try aswer your questions, if any thing is not clear, let me know. First at all, this lib is a working in progress (prototype), and it is open for suggestions and improvements. Feel free to suggest a new feature or change, I'm trying to listen to everyone. And I have tried to implement all the requests that come to me so far. (Obviously, this is limited to my knowledge (which is not big)) >> I am having trouble seeing how it would integrate with Boost.Asio. Well, I use Asio only to support signals. I do not want to expose "ASIO" directly. I do not know if the final version I will use "ASIO" to handle signals or if I remove this dependency. E.g.: In version 0.3 I dont use ASIO. >> I don't see how to control what signal a handler is responding to. Well, here you have to choose in use defaults, or customize. The default will hide all details, and will work on UNIX (Terminal/Daemon) and WINDOWS (Console/Service) without modifications. The default map is: SIGINT, SIGTERM, SIGABRT will call handler defined on callback of termination_handler, check: https://github.com/retf/Boost.Application/blob/master/libs/application/examp le/termination_handler.cpp An exception is the windows service, which is mapped from events of SCM. If you want to customize, you must take into consideration the type of application and platform chosen. E.g. Windows Services dont known anything about SIGNALS, in this case you need customize aspects handlers, on POSIX you can use aspects handlers, signal_manager class, and/or self-pipe aspect, check: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/customization.html#boost_application.customization.customize_signal http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/posix_specifics.html#boost_application.posix_specifics.self_pipe_ >> I also don't really see why you would need to co-opt SIGUSR1; having both USR1 and USR2 available for applications is important in some cases Here user can change this, see: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/customization.html#boost_application.customization.customize_signal Well, I can think in other way to do this here, user other signal. Do you have any idea? Let me know! >> Related to Boost.Asio integration, how would an application make use of all the rest of that library (timers, sockets, etc.). It seems that a core design principle ought to be that the full range of Asio capability would be available. You can have your own io_service, check this sample: https://github.com/retf/Boost.Application/blob/master/libs/application/examp le/uuid_client_server/server.cpp >> I am unclear about "aspects". It seems that in the simplest case any class will work as an aspect. This is true. >> In more complex cases a class must be derived from the aspect_contractor abstract base class. Some aspects are used internally by application mode, then it need follow one interface, that application mode will use. (like a concept) >> Perhaps I missed it, but where is the aspect_contractor interface documented? Sorry, I forgot to document each aspect abstract class interface. Here you can have one idea: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/customization.html >> More fundamentally, under what conditions will which aspect member functions be called. Some aspect member functions are called by application mode internally on lib. >>and what member functions must be provided for "any class" to actually work in this capacity? The abstract contractor class will tell you what you need provide to aspect work internally on application mode. >> Even more fundamentally, can you give some intuition regarding how you see structuring an application in terms of different aspects interacting with each other? Well, this is hard to say (Or better, I do not know the answer). In general form, an application context pool, can have any number and types of aspects, then you can design anything here. Some aspects are needed by application mode, but you can make your own application mode. You have a lot of possibilities here! >> Or, do you envision that the bulk of the application logic is independent of your library classes, i.e., it resides in the user-provided application operator function, and only small bits like termination signals would be handled by the library? At this moment, I want more independent possibly. The use of aspects provide this, we have all pieces separated, and we can tie all, in many ways. E.g. The limit single instance is an aspect. And in future we can have one aspect to TCP/IP for sample, that use asio, or other thing. I dont know. >> I guess I am confused about your vision of how a large, complex application would be structured if it were to make use of your library. If you check lib design, you will see, that lib is composed by a many independents pieces of code, that are tied at run time. http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/design_overview.html The lib provides the more usual features in ready to use form, but you can customize any piece, and tie in any way that you want. If this large application is very complex, you can decompose it in many aspects, and you can make one custom application mode, and you can use some of ready to use aspects on it too. To give you the right answer, I need know more about this application. Is hard to say. In my personal experience (little experience), I already used this lib (0.2, 0.3 and 0.4) on Client service, MPI cluster (for credit card processing), on TCP/IP (ASIO Based) Server (Daemon mode). All using plug-in system (that are provided by library too). >> What would be the division of labor between library-related classes (including user-derived library classes) and independent user-provided code? Check this: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/design_overview.html This clarifies a little? Well, The user can use singularity and get access to context in any location too. >> Finally, note that the links to your example files do not work. This is true, the documentation was generated by quickbook, and dont work on my server, you need check code on github. Sorry! Well, one question. Do you think that this library can be useful? Sorry my english is not very good (is very bad), if any thing is not clean let me know! -- Renato

1 0

[mpl] clang error for narrowing from unsigned int 0xffffffff to long
by Edward Diener 15 Nov '13

15 Nov '13

In the mpl bitwise.cpp test there are lines like: MPL_ASSERT_RELATION( (bitor_<_0,_ffffffff>::value), ==, 0xffffffff ); MPL_ASSERT_RELATION( (bitor_<_1,_ffffffff>::value), ==, 0xffffffff ); MPL_ASSERT_RELATION( (bitor_<_8,_ffffffff>::value), ==, 0xffffffff ); Using clang under Windows with the VC++ RTL ( clang-cl ), clang gives an error of: bitwise.cpp(43,25) : error: non-type template argument evaluates to 4294967295, which cannot be narrowed to type 'long' [-Wc++11-narrowing] MPL_ASSERT_RELATION( (bitor_<_0,_ffffffff>::value), ==, 0xffffffff ); for the bitor_<_0,_ffffffff>::value expression part since the assert_relation template takes two 'long's as its values. Is this an actual bug according to the C++11 standard ? I would have thought that an unsigned int value of 0xffffffff would fit into a long as a -1, but it sounds like the new standard is saying that since the value of 4294967295 cannot be encompassed by a long it is an error. if it is an error how should it be fixed in MPL ?

3 9

typesafe printf with variadic template
by Michael Marcin 14 Nov '13

14 Nov '13

It seems a common example for C++11 and variadic templates is a typesafe printf which is supposed to obsolete things like Boost.Format. However there doesn't seem to be one usable out of the box. If this is really a large improvement shouldn't this facility be in boost?

4 3

Any interest in hashing algorithms SHA and/or FNV1a?
by foster brereton 14 Nov '13

14 Nov '13

I have been working on implementations of the SHA and FNV-1a class of hashing algorithms. Both are header-only. SHA (Secure Hash Algorithms) Implementations for SHA-1, -224, -256, -384, and -512. It does not implement the more recent SHA-3 (Keccak) algorithm. It would not be difficult to add support for 512/224 and 512/256 if they were desired. The routines support bit-level messages, meaning they can correctly digest messages that do not end on a byte boundary. More information here: http://en.wikipedia.org/wiki/Secure_Hash_Algorithm FNV (Fowler–Noll–Vo) The header supports the FNV-1a algorithm, which has better distribution characteristics than its cousin, FNV-1. I have added support for 32-, 64-, 128-, 256-, and 1024-bit variants. This is not a cryptographically secure algorithm, however is much faster than its crypto cousins and as such is a solid algorithm for obtaining unique hash values for e.g., data structures. I have also implemented a constexpr variant of the algorithm (32-bit and 64-bit only) for const char* to further performance when needed by pushing the hash to compile-time computation. More information here: http://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function The algorithms are currently part of the Adobe Source Libraries on GitHub: SHA: https://github.com/stlab/adobe_source_libraries/blob/sha_cleanup/adobe/sha.… (note: the master branch version needs updating to this one.) FNV-1a: https://github.com/stlab/adobe_source_libraries/blob/master/adobe/fnv.hpp Would these algorithms be of general use to the Boost community? If so I would be willing to submit them formally.

7 25

Proposed Boost.Application Library new version available.
by Renato Forti 14 Nov '13

14 Nov '13

Hi Lars, >> I don't know if this has been raised before in the discussion of previous versions, but it's customary to not call something just "Boost.Whatever" if it's not an actual accepted Boost library. Thanks for the warning! >From now on I will always use: "Proposed Boost.Application Library" >> You should probably not use the actual Boost logotype in the documentation either... I used the Quickbook to generate the documentation. Quickbook adds 'boost' logotype automatically. Is there any way I can generate the documentation using the Quickbook, that does not include the 'boost' logotype? >> ... there should be one somewhere with the text "provisional" or "proposed" superimposed on it. On the first page of documentation I have this Caution: "Caution This is not yet an official Boost C++ library. It wasn't reviewed and can't be downloaded from www.boost.org. This beta is available to boost community to know real interest and get comments for refinement. The intention is to submit library to formal review, if community think that it is interesting!" That's not enough? Thanks a lot

2 2

Boost.Application new version available.
by Renato Forti 14 Nov '13

14 Nov '13

Hi All, Last version (0.4.1) of Boost.Application are available. Documentation: <http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html> http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html Code: <https://github.com/retf/Boost.Application> https://github.com/retf/Boost.Application News in this release: * Now we have a self-pipe aspect ready to use for POSIX platform. The documentation of usage: <http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applic ation/posix_specifics.html#boost_application.posix_specifics.self_pipe_> http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/posix_specifics.html#boost_application.posix_specifics.self_pipe_ The sample usage of aspect: <https://github.com/retf/Boost.Application/blob/master/libs/application/exam ple/selfpipe/selfpipe.cpp> https://github.com/retf/Boost.Application/blob/master/libs/application/examp le/selfpipe/selfpipe.cpp * Some fixes on code and docs. Please send your comments!

2 1

[1.55] PDF Documentation build available.
by John Maddock 14 Nov '13

14 Nov '13

The final PDF documentation build for Boost-1.55 is now available at https://sourceforge.net/projects/boost/files/boost-docs/1.55.0/ As ever this only contains documentation for the subset of Boost libraries that use quickbook/boostbook/docbook based documentation. Enjoy! John.

1 0

Is there any interest in a library which provides Application Environment using Aspect Based Design?
by Renato Forti 13 Nov '13

13 Nov '13

Hello everyone, I already asked that question, but how the library has changed a lot since the last inquiry. "Is there any interest in a library which provides Application Environment using Aspect Based Design?" Docs: <http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html> http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html Code: https://github.com/retf/Boost.Application Please expose your interest!

2 1

[range] fat iterators?
by Eric Niebler 13 Nov '13

13 Nov '13

I wrote an article describing the "fat" std::istream_iterator and how it can be slimmed down by giving it an owning istream_range[1]. I see there already is an istream_range in Boost.Range, but it suffers from the fat-iterator problem I describe there. Is there a compelling reason why the implementation of boost::istream_range shouldn't be changed to be more like the one I describe? Also, as a commented pointed out, the same problem exists for the filtered range and the transformed range, too. The trick, of course, will be keeping intermediate temporary ranges alive long enough to avoid lifetime issues when we chain adaptors and assign the result to a local variable. I think a range library that's sensitive to the value category of range objects and makes copies of rvalue ranges would solve this problem. Thoughts? Is it time for Boost.Range 3.0? [1]: http://ericniebler.com/2013/11/07/input-iterators-vs-input-ranges -- Eric Niebler Boost.org http://www.boost.org

11 27