- Boost - lists.preview.boost.org

boost::async documentation
by Aaron Levy 29 Nov '14

29 Nov '14

I did not see any explicit documentation of the boost::async template although I see some mention of it since Boost 1.53. Is there some cohesive documentation which lists: 1. The macros needed to enable the functionality if any. 2. Details of behavior and limitations. 3. Differences in behavior wrt std::async. -- Aaron Levy aaron.levy(a)yandex.com

2 1

boost.context cause strange crash on certan WIN32 API
by microcai 29 Nov '14

29 Nov '14

Hi, I was using Boost.Asio.Spawn happliy until I ported my project to windows. I got stange openssl crash. many debug days speeded and there was nothing wrong with openssl. Strange thing is, openssl didn't crash when used in normal code, unless I used them in asio stackful coroutine. Now I finnally find the root cause and make it 100% reproducible. here is the code that demostrade the crash: <code> boost::context::fcontext_t fcm,fc1; void f1(intptr_t) { HMODULE advapi = LoadLibrary(TEXT("advapi32")); // crash there FreeLibrary(advapi); boost::context::jump_fcontext(fc1, &fcm, 0); } std::thread([](){ boost::context::guarded_stack_allocator alloc; std::size_t size(8192); void* sp1(std::malloc(size)); fc1=boost::context::make_fcontext(sp1, size, f1); boost::context::jump_fcontext(&fcm, fc1, 0); }); </code> the context created in threads other that main thread, can't call certain APIs. If LoadLibrary get called by an context that created in thread, it will crash. 100% reproducible on WIN64 platform with MSVC2013. And nothing wrong on WIN32 !

2 2

[Boost.Convert] Specify input using iterators
by Marius Dobrea 28 Nov '14

28 Nov '14

Hi Vladimir, While reading the Boost.Convert documentation last night there were some questions which came to my mind: Have you considered using iterators (or ranges) to specify input? Would that be in the scope of your library? Also I note that the strtol() function returns the position of the first invalid character (endptr below): long int strtol (const char* str, char** endptr, int base); Could convert() provide the position where the conversion stopped? This would allow single pass parsing of some input data. Would a Converter callable with the following signature be useful? template<typename TypeOut, typename InputIterator> class Result { public: enum Errc { numeric_overflow, empty_range, invalid_character, ...}; // std::expected like function signatures here private: TypeOut value; int errors; InputIterator pos; }; template<typename TypeOut, typename InputIterator> void operator()(InputIterator begin, InputIterator end, Result<TypeOut, InputIterator>& result) const; Please let me know your thoughts. Thanks, Marius Dobrea

2 1

[optional] Safe optional
by Andrzej Krzemienski 28 Nov '14

28 Nov '14

Hi Everyone, I would like to run an idea through everyone in this list. There is a recurring complaint about Boost.Optional that it allows you to do "unsafe" things: 1. Inadvertent mixed comparisons between T and optional<T> 2. Unintended conversion from T to optional<T> 3. "Unchecked" access to the contained object, which causes an UB when performed on an uninitialized optional object. There are valid reasons why optional is defined the way it is defined. But at the same time the complaints above are also valid. This makes some people abandon Boost.Optional and use their own alternative. My idea is to provide another type wrapper, say safe_optional<T>, that would choose different tradeoffs: prefer "safety" to some flexibility and/or efficiency. It would probably be part of Boost.Optional library as the implementation can be reused - only the interface would be changed. One downside of this solution is that we would have two libraries for doing nearly the same thing, which could "scatter" the community. There is a value for standardizing certain things and making them universal. I would like to solicit your feedback. Regards, &rzej

18 84

Explicit conversions to a contextual target type (was [optional] operator<(optional<T>, T) -- is it wrong?)
by Vicente J. Botet Escriba 27 Nov '14

27 Nov '14

Le 26/11/14 12:00, Vladimir Batov a écrit : I have started a new thread to try to clarify what I have in my mind. >> ... I'm looking on how all these conversions can be made safer. >> ... > OK, Vicente, my most humble apologies for snipping all the stuff you typed > that flew right over my head and made me feel stupid. I have to be brutally > honest I did not understand your "idea to state explicitly that you want a > explicit conversion but don't state to what" and your "implicit explicit > conversion thing". You obviously put a lot of thought into it but I > personally did not get *what problem* exactly you are trying to solve. I > personally do not feel there is a conversion-related problem that needs > fixing... On the other hand I do not know Haskell, so it may well be that I > do not know what I am missing. :-) I just hope that other people you'll > present your idea to will be smarter than me to appreciate it. Do you have > any links to slow-pace tutorial/explanation/justification of what you are > trying to propose that I could peruse without hurry? > > I will try again, but I'm not sure I will be clearer this time :( NOTE: this has nothing to be with a library solution, not with the current C++ language, and so it could be out of the scope of this ML. Please, skip this post if you are not concerned by how other language can influence C++. Just 3 references to Haskell * http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictu… * http://en.wikibooks.org/wiki/Haskell/Understanding_monads * https://www.haskell.org/haskellwiki/Polymorphism C++ doesn't takes in account the result type of a function during overload resolution. This has its advantages and liabilities. Consider the following situation. Given void f(W<T>); template <template<class> class B, class A> B<A> make(A v) { return B<A>(v); } It seems reasonable to define a function void g(X x) { f(make<W>(x)); } Here we are conveying the context via the template class W, that is, we are explicit about the context. Consider now a system on which the overload resolution takes in account the target type. Let me use [] instead of () to wrap the function parameters and arguments for this kind of functions so that we can identify them in an easy way. First of all we need to identify the context on which the function has a sens. Let me call this construction just *context*. template <template <class> class B> * context* Builder { template <class T> B<T> make [ T v ]; }; The function 'make' has only one argument, but its result type depends on the context. void g(X x) { f( make[x] ); } The result of make[x] has no sens if we don't know what the target type is. In the expression f( make [x] ) the target of the expression make [x] is W<X> and the context would be W. So the overload that will be taken would be Builder<W>::make[X]. We need to say what Builder<W>::make[X] means, if it would even has a meaning. In order to give a meaning to this expression we need to map W as a builder * template <> context* Builder<W> { template <class T> W<T> make [ T v ] { return whatever_you_want_that_returns_w_t(c); } }; Note that in Haskell the keywords are class for context, and instance for context_map. In some way, we could say that Builder is a type-class having types as instances, and a type belong to this type-class if there is an explicit mapping. This has a lot to be with the abandoned Concept-0x proposal, which was based on signature mapping. The current C++ Concept Lite trend is to have a default mapping for those types that satisfy a set of some syntactical constraint. I think that we could build something similar to Concept-0x on top of Concept Lite, but of course without the help of the language it would be more verbose as we will need to add an indirection. There are also some similarities with the object oriented approach, but instead of having an explicit object you have an deduced context that determines the function to call using static polymorphism. This kind of polymorphism is called ad-hoc polymorphism in the literature an in particular it is used in Haskell and Rust. Another example, this time with a variable * context* ProbablyValued PV { // constructors PV make [ ValueType<PV> v ]; constexpr PV none; // accessors ... }; Ad-hoc polymorphism has its own liabilities also of course. Best, Vicente P.S. I'm not serious. Having another way to do polymorphic calls in c++ is not reasonable, or is it?

1 0

[review] Sort library review manager results
by Edward Diener 26 Nov '14

26 Nov '14

This is the results from the recent review of the Sort library of Steven Ross. First I would like to thank all those who made comments during the review, whether or not they officially gave a final Yes or No vote to whether the Sort library should be accepted as a Boost library. This list includes: Niall Douglas, Julian Gonggrijp, Phil Endecott, Vladimir Prus, Mathias Gaunard, Jeremy Murphy, Peter Dimov, Robert Ramey, Adam Walling, Anthony Polukhin, Phil Endecott, Paul Bristow, Thijs (M.A.) van den Berg Dupuis Etienne, and Frank Gennari If I have missed anyone I do apologize. Secondly I would like to thank Steven Ross for patiently answering all of the review comments to the best of his ability. My tally of Yes and No votes for acceptance are: Yes votes (5) : Niall Douglas ( conditional ), Julian Gonggrijp ( conditional ), Frank Gennari, Phil Endecott, Paul Bristow. No votes (3) : Vladimir Prus, Adam Walling ( conditional ), Anthony Polukhin I believe the condtional Yes vote from Julian Gonggrijp was completely met in the discussions of issues with Steven Ross and the conditional Yes vote from Niall Douglass was almost completely met in the discussion with Steven Ross about the issues mentioned. I want to also mention that the conditional No vote by Adam Walling has an implied Yes vote to it if the Sort library were one among other sort implementations. Since my final decision is not entirely based on the Yes and No votes I want to adumbrate some of the major issues brought up by the review without necessarily focussing on every one of the people who brought them up initially, as well as my own reactions to them as Review Manager. 1) The first major issue was whether a library whose basic merit lies in its algorithm and its speed/space constraints needs better theoretical backing. A number of reviewers discussed this after it was brought up. I tend to agree with reviewers that while the best theoretical basis is always desirable, it is not necessary for a Boost library whose empirical evidence can be and has been measured by its implementor and can be measured by any user. Furthermore Steven Ross has provided an extensive discussion in his documentation, as well as his original paper, about the theoretical merits of his technique. While much of this discussion is probably beyond the understanding of any but sorting experts and afficionados ( I am neither ) enough of it adequately explains the basic ideas behind SpreadSort for those who understand and have knowledge of basic sorting ideas and popular sorting techniques ( that's my province ). 2) An important issue is the need for the Sorting library to provide extensive timing charts/tables comparing SpreadSort to at least std::sort ( and possibly other popular mainstream sorts ) with both different numbers of sort keys and different initial unsorted distributions.

1 1

Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
by Felix Uhl 26 Nov '14

26 Nov '14

Vincente J. Botet Escriba wrote: >I hope it is clear now that I don't want to change optional but see what >the safer optional could be with the ongoing C++ proposals. Fair enough, different users want different behaviour, but how is optional not safe in any way? operator<(optional<T>, T) does not throwing any kinds of exceptions when operator<(T,T) doesn’t, does it? --- Felix Uhl

2 1

[boost config] BOOST_NO_CXX11_HDR_CODECVT question
by Robert Ramey 26 Nov '14

26 Nov '14

I'm building on Mac OS with Xcode. The following test program seems to demonstrate a problem either with config or my understanding of it. <code> #include <codecvt> #include <boost/config.hpp> #ifdef BOOST_NO_CXX11_HDR_CODECVT #pragma message "no C++ codevt support" #endif #include "../../../libs/config/test/config_info.cpp" </code> When I compile the following I get a compile time message "no C++ codevt support" which is NOT what I expect to see. This surprises me since if the message is correct, I would expect the compile would fail at that #include <codecvt> statement. When I run the program I get: Clang version 6.0 (clang-600.0.54) __cplusplus =199711L __STDC__ =1 __GNUC__ =4 __GNUC_MINOR__ =2 __GNUC_PATCHLEVEL__ =1 __GNUG__ =4 __VERSION__ ="4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)" __REGISTER_PREFIX__ [no value] __USER_LABEL_PREFIX__ =_ __EXCEPTIONS =1 __GXX_RTTI =1 __LP64__ =1 __MACH__ =1 __APPLE__ =1 __APPLE_CC__ =6000 __STDC_HOSTED__ =1 ********************************************************************* libc++ version 1101 _LIBCPP_VERSION =1101 ********************************************************************* Detected Platform: Mac OS Type char is signed Type wchar_t is signed byte order for type short =0 8 byte order for type int =0 8 16 24 byte order for type long =0 8 16 24 32 40 48 56 sizeof(wchar_t) =4 sizeof(short) =2 sizeof(int) =4 sizeof(long) =8 sizeof(size_t) =8 sizeof(ptrdiff_t) =8 sizeof(void*) =8 sizeof(void(*)(void)) =8 sizeof(float) =4 sizeof(double) =8 sizeof(long double) =16 CHAR_BIT =8 CHAR_MAX =127 WCHAR_MAX =2147483647 SHRT_MAX =32767 INT_MAX =2147483647 LONG_MAX =9223372036854775807L LLONG_MAX =0x7fffffffffffffffLL LONG_LONG_MAX =9223372036854775807LL ULLONG_MAX =0xffffffffffffffffULL ULONG_LONG_MAX =(9223372036854775807LL*2ULL+1ULL) _POSIX_ADVISORY_INFO =(-1) _POSIX_ASYNCHRONOUS_IO =(-1) _POSIX_BARRIERS =(-1) _POSIX_CHOWN_RESTRICTED =200112L _POSIX_CLOCK_SELECTION =(-1) _POSIX_CPUTIME =(-1) _POSIX_FSYNC =200112L _POSIX_JOB_CONTROL =200112L _POSIX_MAPPED_FILES =200112L _POSIX_MEMLOCK =(-1) _POSIX_MEMLOCK_RANGE =(-1) _POSIX_MEMORY_PROTECTION =200112L _POSIX_MESSAGE_PASSING =(-1) _POSIX_MONOTONIC_CLOCK =(-1) _POSIX_NO_TRUNC =200112L _POSIX_PRIORITIZED_IO =(-1) _POSIX_PRIORITY_SCHEDULING =(-1) _POSIX_RAW_SOCKETS =(-1) _POSIX_READER_WRITER_LOCKS =200112L _POSIX_REALTIME_SIGNALS =(-1) _POSIX_REGEXP =200112L _POSIX_SAVED_IDS =200112L _POSIX_SEMAPHORES =(-1) _POSIX_SHARED_MEMORY_OBJECTS =(-1) _POSIX_SHELL =200112L _POSIX_SPAWN =(-1) _POSIX_SPIN_LOCKS =(-1) _POSIX_SPORADIC_SERVER =(-1) _POSIX_SYNCHRONIZED_IO =(-1) _POSIX_THREAD_ATTR_STACKADDR =200112L _POSIX_THREAD_ATTR_STACKSIZE =200112L _POSIX_THREAD_CPUTIME =(-1) _POSIX_THREAD_PRIO_INHERIT =(-1) _POSIX_THREAD_PRIO_PROTECT =(-1) _POSIX_THREAD_PRIORITY_SCHEDULING =(-1) _POSIX_THREAD_PROCESS_SHARED =200112L _POSIX_THREAD_SAFE_FUNCTIONS =200112L _POSIX_THREAD_SPORADIC_SERVER =(-1) _POSIX_THREADS =200112L _POSIX_TIMEOUTS =(-1) _POSIX_TIMERS =(-1) _POSIX_TRACE =(-1) _POSIX_TRACE_EVENT_FILTER =(-1) _POSIX_TRACE_INHERIT =(-1) _POSIX_TRACE_LOG =(-1) _POSIX_TYPED_MEMORY_OBJECTS =(-1) _POSIX_VDISABLE =((unsigned char)'\377') _POSIX_VERSION =200112L _POSIX2_C_BIND =200112L _POSIX2_C_DEV =200112L _POSIX2_CHAR_TERM =200112L _POSIX2_FORT_DEV =(-1) _POSIX2_FORT_RUN =200112L _POSIX2_LOCALEDEF =200112L _POSIX2_PBS =(-1) _POSIX2_PBS_ACCOUNTING =(-1) _POSIX2_PBS_CHECKPOINT =(-1) _POSIX2_PBS_LOCATE =(-1) _POSIX2_PBS_MESSAGE =(-1) _POSIX2_PBS_TRACK =(-1) _POSIX2_SW_DEV =200112L _POSIX2_UPE =200112L _POSIX2_VERSION =200112L _V6_ILP32_OFF32 =(-1) _V6_ILP32_OFFBIG =(1) _V6_LP64_OFF64 =(1) _V6_LPBIG_OFFBIG =(1) _XBS5_ILP32_OFF32 =(-1) _XBS5_ILP32_OFFBIG =(1) _XBS5_LP64_OFF64 =(1) _XBS5_LPBIG_OFFBIG =(1) _XOPEN_CRYPT =(1) _XOPEN_ENH_I18N =(1) _XOPEN_LEGACY =(-1) _XOPEN_REALTIME =(-1) _XOPEN_REALTIME_THREADS =(-1) _XOPEN_SHM =(1) _XOPEN_STREAMS =(-1) _XOPEN_UNIX =(1) _XOPEN_VERSION =600 ********************************************************************* Boost version 105700 BOOST_USER_CONFIG =<boost/config/user.hpp> BOOST_COMPILER_CONFIG ="boost/config/compiler/clang.hpp" BOOST_STDLIB_CONFIG ="boost/config/stdlib/libcpp.hpp" BOOST_PLATFORM_CONFIG ="boost/config/platform/macos.hpp" BOOST_HAS_THREADS [no value] BOOST_DEDUCED_TYPENAME =typename BOOST_HAS_DIRENT_H [no value] BOOST_HAS_EXPM1 [no value] BOOST_HAS_GETTIMEOFDAY [no value] BOOST_HAS_INT128 [no value] BOOST_HAS_LOG1P [no value] BOOST_HAS_LONG_LONG [no value] BOOST_HAS_NANOSLEEP [no value] BOOST_HAS_NL_TYPES_H [no value] BOOST_HAS_NRVO [no value] BOOST_HAS_PARTIAL_STD_ALLOCATOR [no value] BOOST_HAS_PTHREADS [no value] BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE [no value] BOOST_HAS_SCHED_YIELD [no value] BOOST_HAS_SIGACTION [no value] BOOST_HAS_STDINT_H [no value] BOOST_HAS_UNISTD_H [no value] BOOST_MSVC6_MEMBER_TEMPLATES [no value] BOOST_NO_CXX11_ADDRESSOF [no value] BOOST_NO_CXX11_ALIGNAS [no value] BOOST_NO_CXX11_ALLOCATOR [no value] BOOST_NO_CXX11_ATOMIC_SMART_PTR [no value] BOOST_NO_CXX11_AUTO_DECLARATIONS [no value] BOOST_NO_CXX11_AUTO_MULTIDECLARATIONS [no value] BOOST_NO_CXX11_CHAR16_T [no value] BOOST_NO_CXX11_CHAR32_T [no value] BOOST_NO_CXX11_CONSTEXPR [no value] BOOST_NO_CXX11_DECLTYPE [no value] BOOST_NO_CXX11_DECLTYPE_N3276 [no value] BOOST_NO_CXX11_DEFAULTED_FUNCTIONS [no value] BOOST_NO_CXX11_DELETED_FUNCTIONS [no value] BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS [no value] BOOST_NO_CXX11_FINAL [no value] BOOST_NO_CXX11_FIXED_LENGTH_VARIADIC_TEMPLATE_EXPANSION_PACKS [no value] BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS [no value] BOOST_NO_CXX11_HDR_ARRAY [no value] BOOST_NO_CXX11_HDR_ATOMIC [no value] BOOST_NO_CXX11_HDR_CHRONO [no value] BOOST_NO_CXX11_HDR_CODECVT [no value] BOOST_NO_CXX11_HDR_CONDITION_VARIABLE [no value] BOOST_NO_CXX11_HDR_FORWARD_LIST [no value] BOOST_NO_CXX11_HDR_FUNCTIONAL [no value] BOOST_NO_CXX11_HDR_FUTURE [no value] BOOST_NO_CXX11_HDR_INITIALIZER_LIST [no value] BOOST_NO_CXX11_HDR_MUTEX [no value] BOOST_NO_CXX11_HDR_RANDOM [no value] BOOST_NO_CXX11_HDR_RATIO [no value] BOOST_NO_CXX11_HDR_REGEX [no value] BOOST_NO_CXX11_HDR_SYSTEM_ERROR [no value] BOOST_NO_CXX11_HDR_THREAD [no value] BOOST_NO_CXX11_HDR_TUPLE [no value] BOOST_NO_CXX11_HDR_TYPEINDEX [no value] BOOST_NO_CXX11_HDR_TYPE_TRAITS [no value] BOOST_NO_CXX11_HDR_UNORDERED_MAP [no value] BOOST_NO_CXX11_HDR_UNORDERED_SET [no value] BOOST_NO_CXX11_INLINE_NAMESPACES [no value] BOOST_NO_CXX11_LAMBDAS [no value] BOOST_NO_CXX11_LOCAL_CLASS_TEMPLATE_PARAMETERS [no value] BOOST_NO_CXX11_NOEXCEPT [no value] BOOST_NO_CXX11_NON_PUBLIC_DEFAULTED_FUNCTIONS [no value] BOOST_NO_CXX11_NULLPTR [no value] BOOST_NO_CXX11_NUMERIC_LIMITS [no value] BOOST_NO_CXX11_RANGE_BASED_FOR [no value] BOOST_NO_CXX11_RAW_LITERALS [no value] BOOST_NO_CXX11_REF_QUALIFIERS [no value] BOOST_NO_CXX11_RVALUE_REFERENCES [no value] BOOST_NO_CXX11_SCOPED_ENUMS [no value] BOOST_NO_CXX11_SMART_PTR [no value] BOOST_NO_CXX11_STATIC_ASSERT [no value] BOOST_NO_CXX11_STD_ALIGN [no value] BOOST_NO_CXX11_TEMPLATE_ALIASES [no value] BOOST_NO_CXX11_TRAILING_RESULT_TYPES [no value] BOOST_NO_CXX11_UNICODE_LITERALS [no value] BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX [no value] BOOST_NO_CXX11_USER_DEFINED_LITERALS [no value] BOOST_NO_CXX11_VARIADIC_TEMPLATES [no value] BOOST_NO_MS_INT64_NUMERIC_LIMITS [no value] BOOST_NO_STD_MESSAGES [no value] BOOST_STD_EXTENSION_NAMESPACE =std BOOST_UNREACHABLE_RETURN(0) [no value] BOOST_CONSTEXPR [no value] BOOST_CONSTEXPR_OR_CONST =const BOOST_STATIC_CONSTEXPR =static const BOOST_NOEXCEPT [no value] BOOST_FORCEINLINE =inline __attribute__ ((__always_inline__)) BOOST_NOINLINE =__attribute__ ((__noinline__)) BOOST_FALLTHROUGH =((void)0) Program ended with exit code: 0 which also surprises me as I was under the impression that my compiler implements all of C++11 library standard Any help appreciated, Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/boost-config-BOOST-NO-CXX11-HDR-CODECVT-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 1

Template Help
by john.klein＠genovatech.com 26 Nov '14

26 Nov '14

All, I've gotten rusty over the years and decided to create an application for myself to knock some of the rust off. I've worked with projects that have used boost in the past and I'm wanting to use it as much as possible here. I'm using VS2013 with the 64bit 1.57.0 boost libraries, so I have access to the newer c++ standard. Can someone please show me how to get the following to compile? Please ignore the functionality of the code, this is just something I quickly put together to demo my issue. SafeList.h #pragma once #include <list> #include <boost/thread/mutex.hpp> template <typename dataType> using CallbackType = bool(*)(dataType); template <typename dataType> class SafeList { public: SafeList() : list(), mutex() { } ~SafeList() { boost::mutex::scoped_lock scoped_lock(mutex); } void Add(dataType data) { boost::mutex::scoped_lock scoped_lock(mutex); list.push_back(data); } void Remove(dataType data) { boost::mutex::scoped_lock scoped_lock(mutex); list.remove(data); } void IterateList(CallbackType<dataType> callback) { boost::mutex::scoped_lock scoped_lock(mutex); for (int i = 0, bool flag = true; i < list.size() && flag; i++) { flag = callback(list[0]); } } private: std::list<dataType> list; boost::mutex mutex; }; FileList.h #pragma once #include "SafeList.h" #include "File.h" #include <boost/shared_ptr.hpp> typedef boost::shared_ptr<File> FilePtr; class FileList { public: FileList(); ~FileList(); void Add(FilePtr); void ProcessList(); private: bool ProcessItem(FilePtr); SafeList<FilePtr> safeList; }; FileList.c #include "stdafx.h" #include "FileList.h" FileList::FileList() : safeList() { } FileList::~FileList() { } void FileList::Add(FilePtr filePtr) { safeList.Add(filePtr); } void FileList::ProcessList() { safeList.IterateList(this->ProcessItem); <-- This is the bad guy the compiler complains about and not sure how to resolve. } bool FileList::ProcessItem(FilePtr) { return true; } 1>------ Build started: Project: Download, Configuration: Debug x64 ------ 1> FileList.cpp 1>FileList.cpp(20): error C3867: 'FileList::ProcessItem': function call missing argument list; use '&FileList::ProcessItem' to create a pointer to member ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== Thanks, John Klein PMP(r) CSM(r) Programs/Engineer Manager Phone: (319) 378-8455 Cell: (319) 533-1476 [Description: Genova Tech NEW] www.genovatech.com<http://www.genovatech.com/> 4250 River Center Court NE Suite A Cedar Rapids, IA 52402 This message is covered by the Electronic Communication Privacy Act, 18 U.S.C. Sections 2510-2515, and is intended only for the use of the person to whom it is addressed and may contain information that is confidential. It should not be forwarded to anyone else. If you received this message and are not the addressee, you have received this message in error. Please notify the person sending the message and destroy your copy.

3 2

[optional] operator<(optional<T>, T) -- is it wrong?
by Andrzej Krzemienski 26 Nov '14

26 Nov '14

I moved this discussion from the other thread. > optional<double> Aircraft::weight() > { > if (Impl* impl = get_impl()) > return impl->compute_weight(); > else > return none; > } > > double Aircraft::max_weight() > { > return 10000.0; > } > > bool too_heavy(Aircraft& ac) > { > return ac.weight() > ac.max_weight(); > // this compiles and does the wrong thing > } > 1) When we are bringing T into the optional<T> land, we apply implicit > constructor. For example, we provide T to a function taking optional<T>. > Here, the direction of the conversion is unambiguous. Namely, T to > optional<T>. So, we apply it. > 2) When the direction of conversion is not as clear, we refuse applying it > and leave it to the user. op<(T, optional<T>) would be one such example. > > Oh, c'mon. Cheer up. Things are not as gloomy, are they. :-) Here the > subtlety (IMO) lies in how reasonable it is to add information. Namely, as > I indicated, if we bring T into the optional<T> fold, then we apply > optional<T> rules to T, i.e. apply t to optional<T> conversion. Say, we > have a mandarin and an orange. When we bring the mandarin to an orange > factory, then mandarin-to-orange "conversion" is applied and for all > purposes mandarin is a "small orange". Outside the factory, when we compare > mandarin to orange, it is not immediately clear what should be treated as > what. If we apply mandarin-to-orange "conversion", then it'll be "small > orange vs. big orange". If instead we apply orange-to-mandarin > "conversion", then it'll be "sweet mandarin vs. sour mandarin". Given the > library writer does not know, which it is, we ban it. Still not convinced? > I've spent all munition I had. :-) When you are talking about oranges and mandarins outside the context of C++, I am convinced. the problem I have is with mapping it onto C++ and the design of Optional. (1) In C++ we have the converting constructor. This appears close to what you call "bringing T into the optional<T> land", but I claim it is not the same. And the consequences of these nuance differences result in the problem in question. Perhaps the notion of "bringing T into the optional<T> land" would be better reflected by an explicit constructor, or function make_optional(). I am not saying that the converting constructor is wrong here. I am just saying that the motivation is *slightly* different than "bringing T into the optional<T> land", it is more for syntactic convenience, which is almost the same, but not same. (2) Your philosophy "when the direction of conversion is not as clear, we refuse applying it" -- there is no way to apply it within the definition of optional. We can apply it by poisoning every operation in the world that takes T or optional<T>. But that looks impractical. Back to Vicente's concern: User defining its own function > > void f(optional<T>, optional<T>); > > would need to add the following? > > void f(T, optional<T>) { BOOST_STATIC_ASSERT(); } > void f(optional<T>, T) { BOOST_STATIC_ASSERT(); } > > What if there are 3 optional parameters? We can not say to the user that > they need to program this way. > I do not think it has been addressed.

9 20

[Range] New I/O functions for ranges
by Indiana 25 Nov '14

25 Nov '14

I'm currently putting together a proposal to the standards committee about a set of range I/O functions, but i think they would make a good addition to Boost as well. They would probably fit in the Range library - i don't think they warrant a library all of their own. The stuff i wrote for the standards proposal is available at http://cpp.indi.frih.net/rangeio/ - it goes into quite a bit of detail about the interface, and links to a sample implementation. But here's the executive summary: There is a single output function - currently called "write_all" - that takes a range and, optionally, a delimiter, like this: // BEGIN CODE ///////////////////////// auto const r = std::array<int, 4>{1, 2, 3, 4}; cout << write_all(r); // prints "1234" cout << "{ " << write_all(r, ", ") << " }"; // prints "{ 1, 2, 3, 4 }" // END CODE /////////////////////////// It takes anything that works with range-for, so it works with range adaptors: // BEGIN CODE ///////////////////////// struct is_even { auto operator()(int x) const -> bool { return x % 2 == 0; } }; cout << write_all(r | reversed | filtered(is_even{})); // prints "42" // END CODE /////////////////////////// Note also that the delimiter doesn't have to be a string (there are some examples in the reference of that). Why not just use std::copy() and stream iterators? Several reasons - the most obvious of which you can see above: this syntax is much cleaner, much less error-prone, well-integrated with the existing stream I/O mechanisms, and it produces properly delimited output (unlike the delimited version of ostream_iterator). But also, stream formatting is properly handled: // BEGIN CODE ///////////////////////// auto const r = std::array<int, 3>{1, 2, 3}; std::cout.width(3); std::cout.fill('0'); // --------------------------- // The old way: using std::begin; using std::end; std::copy(begin(r), end(r), std::ostream_iterator<int>{std::cout, ", "}); // even with Boost.Range, this just reduces to: //boost::copy(r, std::ostream_iterator<int>{std::cout, ", "}); // prints: "001, 2, 3, " // --------------------------- // The new way: std::cout << write_all(r, ", "); // prints "001, 002, 003" // END CODE /////////////////////////// And of course this works as expected in chained expressions: // BEGIN CODE ///////////////////////// auto const r = array<int, 3>{1, 2, 3}; cout.width(3); cout.fill('0'); cout << '(' << setw(3) << setfill('0') << write_all(r, ',') << ')'; // prints: "(001,002,003)" // END CODE /////////////////////////// It is also possible to get more information about errors, and react better to them. If there is an error in the formatting or in the stream during an output operation using std::copy() and ostream_iterator, the algorithm will chug merrily along until it's all the way through the range even though it's no longer writing anything. You will have no way to detect where the problem occurred - did it fail after the first element was written, or *before*, or did it fail after the millionth element? If the range is begin lazy-generated, that could be particularly wasteful, or even problematic. By contrast, write_all() stops immediately when there is an error in the output stream. It is even possible get more information about the last range write operation by capturing the temporary object, like this: // BEGIN CODE ///////////////////////// auto const r = array<int, 3>{1, 2, 3}; auto p = write_all(r); cout << p; if (!cout) { cerr << "only " << p.count << " elements written\n"; cerr << "next element would have been " << *p.next << '\n'; } // END CODE /////////////////////////// On the input side, there are 7 functions: * overwrite * back_insert * front_insert * insert * back_insert_n * front_insert_n * insert_n Overwrite simply replaces the contents of a range with whatever is read from input: // BEGIN CODE ///////////////////////// auto r = array<int, 100>{}; cin >> overwrite(r); // reads up to 100 ints // END CODE /////////////////////////// The *insert functions map to the *insert_iterators in the standard library, using push_back(), push_front(), or insert(). In each case: in >> ???insert(r[, i]); is basically equivalent to: copy(istream_iterator<value_type_of_r>{in}, // use braces on the next line, or face the most vexing parse istream_iterator<value_type_of_r>{}, ???inserter(r[, i])); The *insert_n functions are for the common case where you know in advance how many elements will be read, at maximum - or for when you want to limit the amount of elements read in a single read operation. This: in >> ???insert_n(r[, i], n); is conceptually equivalent to: copy_n(istream_iterator<value_type_of_r>{in}, n, ???inserter(r[, i])); except it can handle formatting and errors properly. The reference at http://cpp.indi.frih.net/rangeio/ goes into much more detail, of course. Why add it to Boost? Because these operations (reading/writing ranges) are so common they are almost universal, and there is no standard facility that handles them easily or well. They are not *difficult* to implement, but they are far from trivial - for example, you might think write_all() is just a simple range-for loop or for_each(), and it is... up until you add error checking, the delimiter, and formatting awareness. A sample implementation already exists - it can be implemented portably in pure standard C++11. (Can it be implemented in C++03 with? Good question. It might be possible with some Boost help, but it might require dependencies on libraries other than Boost.Range. If this proposal finds approval, that's something i can look into.) Would there be any interest in adding these functions to Boost.Range?

5 13

[range][extensions] What is happening with the range extensions?
by Viktor Sehr 25 Nov '14

25 Nov '14

I really think boost range should be updated with the range extensions, what is happening with the review here? /Viktor

3 2

[range][extensions] Operator |+, isnt it possible to implement without this operator?
by Viktor Sehr 25 Nov '14

25 Nov '14

Looking at CppLinq, and C++ Streams (http://jscheiny.github.io/Streams/) it seems they both can handle lambda functions via one operator. Isn't it possible to do something like they do in range extensions? /Viktor

2 1

[Serialization] boost/strong_typedef.hpp vs. boost/serialization/strong_typedef.hpp
by Jonathan Jones 24 Nov '14

24 Nov '14

Hi folks, Does anyone know why boost/strong_typedef.hpp still exists with real content? Several years back, the version in the trunk was stubbed out: http://svn.boost.org/svn/boost/trunk/boost/strong_typedef.hpp but this change has not made it into any release. The version in serialization, however, is still being updated. Sincerely, Jonathan Jones

2 3

[dynamic_bitset] capacity(), reserve(), shrink_to_fit()
by Riccardo Marcangelo 24 Nov '14

24 Nov '14

Hi, I have implemented capacity(), reserve(), and shrink_to_fit() for dynamic_bitset. I find these useful and am surprised by their omission. I'm wondering if there is any interest in including them in Boost. Perhaps there are reasons why they're not implemented? Riccardo -- View this message in context: http://boost.2283326.n4.nabble.com/dynamic-bitset-capacity-reserve-shrink-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

Executable files in the boost tree
by Marshall Clow 24 Nov '14

24 Nov '14

Someone recently opened trac ticket #10813 (https://svn.boost.org/trac/boost/ticket/10813) with the description: > I recently updated Boost 1.57, I noticed that a few header files > "parameter.hpp" and some of those in the "parameter" directory has > permission 755 instead of normal 644. Why make these normal header files > executable? Since I built the release tarballs, I took this ticket and did some investigating. The OP is absolutely correct, these files should not have 755 perms. Unfortunately for me, I discovered: 1) These permissions were not modified during the build process, but are marked this way in git. 2) It’s not just the parameter library. I found about 1000 files marked as executable that shouldn’t be, and they were in the following libraries: asio assign bimap chrono concept_check foreach fusion gil graph iostreams lambda mpl msm numeric parameter polygon predef ptr_container python test thread type_traits typeof variant xpressive Some files (such as shell scripts, python sources, etc) *should* be marked executable, but others (.hpp files, jam files, HTML, png, etc) should not. I will deal with the libraries that are currently under the purview of the CMT (concept_check and mpl) I would appreciate if the maintainers of these libraries would clean this up before the Feb release. Also, I will be enhancing the “inspect” tool to report on these this week. — Marshall

1 0

Changes in Boost.Optional
by Dean Michael Berris 24 Nov '14

24 Nov '14

Suppose I have the following type: struct container { boost::optional<uint16_t> optional() const { return value_; } private: boost::optional<uint16_t> value_; }; struct value_wrapper { value_wrapper(const container& c) : c_(c) {} operator uint16_t () { return 1; } operator boost::optional<uint16_t>() { return c_.optional(); } private: const container& c_; }; And that I have the following function: value_wrapper value(const container& c) { return value_wrapper(c); } The following used to work in MSVC 2010: container c; // leave c.value_ alone. boost::optional<uint16_t> some_value = value(c); assert(!some_value); Now with Boost 1.56, this breaks because the constructor for some_value from a temporary optional is now marked explicit. What is the work-around for the previous behavior to be regained? All the following changes cause the assertion to fail: boost::optional<uint16_t> some_value(value(c)); assert(!some_value); // some_value's constructor will use the uint16_t conversion operator, therefore some_value == 1 boost::optional<uint16_t> some_value = static_cast<boost::optional<uint16_t> >(value(c)); assert(!some_value); // same problem as above, the temporary created will favor the uint16_t conversion operator Help? PS. For better context, see https://github.com/cpp-netlib/cpp-netlib/blob/0.11-devel/boost/network/prot…

8 26

[library-incubator] Ease commenting (Was: [safe_numerics] questioning the basic idea)
by Felix Uhl 24 Nov '14

24 Nov '14

Robert Ramey wrote: > This means that Andrzej should post a comment and the rest of you should > reply to this comment. > I realize that is is sort of pain, but, again, I would be very helpful to me > to test the idea of building and maintaining a libraries comment history in > an permanent convenient place. Have you thought about using the boost developers and users mailing list to get comments posted on bli? You could just run a script on a webserver that polls emails in the mailinglist and filters out those with a tag that contains the name of a library on the incubator in the title, which it then posts under said library as an anonymous comment, or a comment under the name of the poster, if he gives his ok in the mail (not the title) with a tag like [PostMyName] or [Name=”Pseudonym”]. The idea is to make commenting easier and less awkward by embedding it in the commenting and discussion framework boost developers and users already use, the mailing list. --- Felix Uhl

5 10

is_lexical_convertible
by endight . 24 Nov '14

24 Nov '14

Is there something like `boost::is_lexical_convertible` (like `boost::is_convertible`)?

3 2

Is there interest in a library for testing existence of a function member of class?
by 胡维 24 Nov '14

24 Nov '14

Hi, I am looking for how to test if a function member of class exist or not in compile time.I did not find a solution by google so I wrote a piece of code for it.Please let me know if it's already in boost. :) Synopsis class Bar { public: Bar(int); }; class Foo { public: Foo(int); int foo(Bar); }; // create struct 'has_foo' which is used to test function member 'foo'.HAS_FUNCTION_MEMBER(foo) int main() { assert((!has_foo<void(Bar::*)(Bar)>::value)); assert((has_foo<int(Foo::*)(Bar)>::value)); return 0; } The code is in my gisthttps://gist.github.com/wehu/1987f716074904d26cf0 The code only checks if the function is compatible with expected, but not require to be exact same. Thanks,Wei

6 11

[bli] category page blank
by Michael Caisse 24 Nov '14

24 Nov '14

I went here: http://rrsd.com/blincubator.com/listed-by-category/ which is blank. As a user, I am going to try and find libraries by category before I use their names. michael -- Michael Caisse ciere consulting ciere.com

2 2

[review] Formal review period for Sort library begins today, November 10, and ends Wednesday, November 19
by Edward Diener 23 Nov '14

23 Nov '14

The formal review of the Sort library by Steven Ross starts today, November 10 and is scheduled to continue through November 19th. About the Sort library ================== The Sort library is a library which implements hybrid sorting algorithms based on a Spreadsort ( http://en.wikipedia.org/wiki/Spreadsort ), of which the author of the library, Steven Ross, is the inventor. The algorithm provides a sort that is faster than O(n*log(n)). The library provides a generic implementation of high-speed sorting algorithms that outperform those in the C++ standard in both average and worst case performance. These algorithms only work on random access iterators. They are hybrids using both radix and comparison-based sorting, specialized to sorting common data types, such as integers, floats, and strings. These algorithms are encoded in a generic fashion and accept functors, enabling them to sort any object that can be processed like these basic data types. Where to get it =============== The library is available on github at https://github.com/spreadsort/sort. The library is in modular Boost format and can be cloned to libs/sort under your local modular boost directory. I have provided as the review manager online documentation at: http://eldiener.github.io/sort Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[sort]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome. I encourage all programmers with an interest or knowledge of sorting algorithms to be part of the review or discussion of the Sort library as your time permits.

13 41

FW:ibbeekman
by Hartmut Kaiser 22 Nov '14

22 Nov '14

http://forum.incadigital.com/iuz/zdhbcmdqmamibsfwolsdjrima.nbhjkshxjngcjxlj… Hartmut Kaiser

1 0

[Boost.DLL] Formal Review request
by Antony Polukhin 21 Nov '14

21 Nov '14

Dear Boost, Some time passed since checking interest in plugin development library and now all the requested features are implemented (self loading, getting symbol location, better docs, automatic platform-specific library decorations append, much more examples, listing library exports and so on...). While there's still some room for minor improvements, library API is stable and the library will benefit greatly from a larger user base and more feedback. So unless someone thinks the library isn't ready or would get rejected right away in its current state for reason X, I am requesting a formal review for Boost.DLL. Library location: https://github.com/apolukhin/Boost.DLL Library Docs: http://apolukhin.github.io/Boost.DLL/index.html -- Best regards, Antony Polukhin

10 40

[review] Formal review period for Sort library continuing through November 19
by Edward Diener 20 Nov '14

20 Nov '14

The formal review of the Sort library by Steven Ross, which started November 10 and is scheduled to continue through November 19th, begins its last 5 days today. We have had some great discussions and reviews so far and I would like to thank everybody involved. I would like to encourage all interested programmers, whether Boost developers or Boost users, to comment on and/or review the library. About the Sort library ================== The Sort library is a library which implements hybrid sorting algorithms based on a Spreadsort ( http://en.wikipedia.org/wiki/Spreadsort ), of which the author of the library, Steven Ross, is the inventor. The algorithm provides a sort that is faster than O(n*log(n)). The library provides a generic implementation of high-speed sorting algorithms that outperform those in the C++ standard in both average and worst case performance. These algorithms only work on random access iterators. They are hybrids using both radix and comparison-based sorting, specialized to sorting common data types, such as integers, floats, and strings. These algorithms are encoded in a generic fashion and accept functors, enabling them to sort any object that can be processed like these basic data types. Where to get it =============== The library is available on github at https://github.com/spreadsort/sort. The library is in modular Boost format and can be cloned to libs/sort under your local modular boost directory. I have provided as the review manager online documentation at: http://eldiener.github.io/sort Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[sort]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome.

6 18