- Boost - lists.boost.org

[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