November 2014 - Boost - lists.boost.org

GDB-like debugger for template metaprograms
by Abel Sinkovics 03 Dec '14

03 Dec '14

Hi, Metashell 2.0.0 has a template metaprogram debugger with a GDB-like interface (thanks to András Kucsma), which can be useful for Boost developers. It can show you how your metaprogram is executed step-by-step. You can set breakpoints, step into or over the metafunction calls and inspect the "template metaprogramming stack trace" at any point during this: the chain of recursive template instantiations that lead to that point. Here is an example: > #include <boost/mpl/transform.hpp> > #include <boost/mpl/vector_c.hpp> > #include <boost/mpl/plus.hpp> > #include <boost/mpl/lambda.hpp> > #include <boost/mpl/int.hpp> > using namespace boost::mpl; > #msh mdb transform<vector_c<int, 1, 2, 3, 4, 5>, plus<_1, int_<1>>>::type For help, type "help". Metaprogram started (mdb) rbreak ^boost::mpl::plus Breakpoint "^boost::mpl::plus" will stop the execution on 25 locations (mdb) continue Breakpoint "^boost::mpl::plus" reached boost::mpl::plus<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (Memoization) (mdb) bt #0 boost::mpl::plus<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (Memoization) #1 boost::mpl::quote_impl<boost::mpl::plus<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na>, true> (TemplateInstantiation) #2 boost::mpl::quote5<plus, mpl_::void_>::apply<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (TemplateInstantiation) #3 boost::mpl::apply_wrap5<boost::mpl::quote5<plus, mpl_::void_>, mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (TemplateInstantiation) ... #19 transform<vector_c<int, 1, 2, 3, 4, 5>, plus<_1, int_<1>>>::type You can try Metashell from your browser: http://abel.web.elte.hu/shell Or you can install it on your computer: https://github.com/sabel83/metashell#version-200 Binary installers are available for a number of Linux distributions, Windows and Mac OS X. Feedback is welcome. Regards, Ábel

7 15

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