- Boost-users - lists.boost.org

[Repost][Boost][Serialization] ASSERT triggered during reading 1.40 binary archive w/ Boost 1.47
by Marc Perso 03 Aug '11

03 Aug '11

Let me forward this message posted few days ago since nobody has confirmed that the issue described hereafter exists. I would really appreciate if someone could take a look (maybe Mr Robert Ramey) and give some advice on this subject. Best regards, Marc Viala ------------------------------------------------------------------------ Hello Booster, We are trying to jump from Boost 1.40 to Boost 1.47 but we are facing an issue: an ASSERT is raised in debug mode when reading back binary archive generated by Boost.Serialization 1.40 with the Boost.Serialization 1.47. This ASSERT is at line 116 in basic_archive.hpp: BOOST_ASSERT(t_ <= boost::integer_traits<base_type>::const_max) And it occurs with the following platform: MSVC 8.0 and Windows XP/32bits or Win7/64bits. Looking at the load_override and save_override implementations for class_id_type in #1.40, they seem loading and saving an 'int_least16_t' (equiv. to a short for our platform) while load_override(class_id_type) for #1.47 attempts to read an 'int' (file: basic_binary_iarchive.hpp @ line 98). My questions are: - This assert suggests that we can't read back previous binary archives (#1.40 at least) with Boost.Serialization 1.47, is this a known pending issue for Boost.Serialization? - If yes, how we can manage that and how we can complete the migration to 1.47 in our case (it should be noted that we must be able to read back our 1.40 binary archives)? Is there any known patch for this problem? Any assistance will be greatly appreciated. Best regards, Marc Viala PS: I'm not sure but ticket #5567 seems already opened on this issue but has not been yet fixed (https://svn.boost.org/trac/boost/ticket/5567)

1 0

Time management using posix time
by Sarkar, Arup 03 Aug '11

03 Aug '11

Hi: This is what is I am trying to achieve. I would like to run the program for 6 minutes, within the six minutes I would like to toggle for 2 minutes data operation and for 1 minute trade operation, so there will be 2 cycle of data operation and 2 cycle of trade operation. I am setting and getting the ptime outside the main program, but what is happening is that the getPtime of the template class is always return the +2 minutes of the current time, that is why diff is never reducing less than 2 minutes, why is that happening, the setter have been instantiated only once. I would really appreciate if someone can help me out. [code] // boost_example.cpp : Defines the entry point for the console application. // #include "boost/date_time/posix_time/posix_time.hpp" #include <iostream> #include <stdio.h> #include <stdio.h> #include "windows.h" using namespace std; template <typename ptime_type> class timeManagement { private: ptime_type tradingTime; public: timeManagement(){}; void setPtime (const ptime_type& _val){tradingTime = _val; } ptime_type const& getPtime() {return (tradingTime);} ~timeManagement(){}; }; int main() { bool btradingIndicator = false; std::ostringstream msg; using namespace boost::posix_time; const ptime start = second_clock::local_time(); time_duration td = minutes(6); time_duration tdDataCollection = minutes(2); time_duration tdTrading = minutes(1); bool bTradingIndicator = false; const ptime end = start + td; const ptime tTimeWindow = start + tdDataCollection; int i = 0; int switchTime = 0; timeManagement <ptime> tradingWindow; tradingWindow.setPtime(tTimeWindow); //std::cout << tradingWindow.getPtime() << std::endl; while(second_clock::local_time() <= end){ ptime currentTime = second_clock::local_time(); time_duration diff = tradingWindow.getPtime() - currentTime; if(diff.total_seconds() >= 0 && !bTradingIndicator){ std::cout << "Data.) " << currentTime << "|" << tradingWindow.getPtime() << "|" << diff << std::endl; }else{ const ptime tTimeWindow1 = currentTime + tdTrading; tradingWindow.setPtime(tTimeWindow1); bTradingIndicator = true; } if(diff.total_seconds() >= 0 && bTradingIndicator){ std::cout << "Trade.) " << diff << std::endl; }else{ const ptime tTimeWindow2 = currentTime + tdDataCollection; tradingWindow.setPtime(tTimeWindow2); bTradingIndicator = false; } } std::cout << "Start Time: " << start << std::endl; std::cout << "End Time: " << end << std::endl; std::cout << "Time Now: "<< end << std::endl; return 0; } [/code] Regards, Arup *"I don't need to know everything, I just need to KNOW where to find it, when I need it"*. -*Albert Einstein *

1 0

Re: [Boost-users] What's wrong with this simple multithreaded function that uses regex?
by Andrew Yancy 03 Aug '11

03 Aug '11

>I don't see anything obviously wrong with that. My only question, is you >say BOOST_HAS_THREADS is defined, are you defining it, or is Boost.Config >defining it (if Boost.Config *isn't* setting it, then your project >settings >are wrong for multithreaded code)? Are you selecting the regex lib to >link >to manually or letting the auto-linking code do it's work (for minimum >chances of bad things happening you should let the auto-linking code >select >the correct binary)? >HTH, John. >You should use _beginthread or _beginthreadex to start C++ thread when >using >MSVC. >CreateThread is too low level and does not do the per thread >initialization >required. If you read MSDN documentation it explain why CreateThread >cannot >be use with C++ program. >Daniel Anderson Thanks for the replies John and Daniel. I've reinstalled boost 1.47 making sure that all the multithreaded options were built and am using _beginthreadex() now, but the exact same problem seems to occur where the code snippet below crashes if and only if boost::regex_match() is called. I am not defining BOOST_HAS_THREADS in my code, it is defined automatically although I'm not sure how exactly. Also, as far as I know I am not manually linking to the necessary libraries; all I do is tell MSVC to look in "C:\Program Files\boost\boost_1_47_0\stage\lib" for additional libraries so presumably it chooses whichever one it needs. There are no thread or boost-related warnings in the build. Any other ideas? I really appreciate the help~ ... static const boost::regex expression("^[0-9]+"); ifstream myfile(x); //x is a different file name for every thread string line; if(myfile.is_open()) { while(myfile.good()) { getline(myfile, line); if(boost::regex_match(line, expression)) { //do stuff } } myfile.close(); } ...

2 2

[program_options] Best practices, esp. for multi-app-projects?
by Carlos Franke 02 Aug '11

02 Aug '11

I am wondering if there is a recommended way how the boost::program_options library should be integrated in a (relatively) complex project. To be more specific, these are my situation and my requirements: – A C++ project consisting of several applications, which are to share many, but not all options. – The interface to the options used in each app's code should be as boost-unspecific (i. e. abstract) as possible, so that I could later switch to another option library without having to edit much more than one file. – The option data should be somehow encapsulated. After pondering on this task for quite some time, I came up with this: – A single header file "options.h" shared by all the applications, providing a function read_options(int argc, char* argv[], const po::options_description& local_options = 0) , which scans the command line and the usual configuration files* for the common options (which are defined in the same header file, of course) as well asoptional app-specific options, and saves them (next paragraph). *(There is of course the problem of each app's name being part of its config-file's name. I found a solution for this, but I am not sure if it is relevant here. Or is it?) – Regarding the encapsulation, I found any kind of class or struct containing the options (possibly with get and set methods) unsuitable or overkill, as I would have to deal with instantiation and possible problems of multiple instantiation (singleton?). Also, I did not feel the need for the security provided by get and set methods. So what I did is: put all option variables in one namespace, like this: namespace options { int option1; std::string option2; ///... } A namespace has the further great advantage of being extendable after creation. Programme-specific options can be added easily. So in the end, in each programme I only have to do: //optional: define local options namespace options { /* . . . */ } po::options_description my_options /* . . . */ ; //read and save options: options::read_options(argc, argv, my_options) //from now on access the options' values by //options::option1; As I see it, this approach has only two drawbacks: – In each programme's code I have to deal with options twice: 1) declare the storage variables in the options namespace (globally); 2) declare local options_description and call read_options (in the main function). – There is no way to tell if the option variables are in a valid state, unless one is sure that read_options has been called and has set all values (at least to valid default values). I am inclined to tolerate the first issue and resolve the second by: – not using "default_value" in any po::options_description – instead intializing the option variables with their default values. That way, at any time each option variable either stores its default value or the assigned to it from the command line or a configuration file. Oh my, that ended up much longer than I expected. Those of you who read this far: What are your thoughts about using boost::program_options in general and about my particular approach? Regards! Carlos Franke

1 0

[units] derived_dimension<volume_dimension, 1> units showing as "dimensionless"
by Michael Powell 02 Aug '11

02 Aug '11

Units users, I'm sure this is an include I am missing somewhere. I've got a derived physical dimension defined as derived_dimension<volume_dimension,1>, and the corresponding unit<my_dimension,si::system>, however the to_string() of the quantity shows "dimensionless". I am expecting this should be "m^3"? Regards, Michael

1 0

[units] setting up a derived dimensionless with a custom name/symbol
by Michael Powell 02 Aug '11

02 Aug '11

Boost::Units users, How would we go about setting up a custom unit with its own name/symbol? We would derive another unit that incorporates this one and probably one of the built-in ones. So we might have something like "volume per custom units", or "custom units per time". * From the sounds of things, we would need to setup a custom base unit with its own info struct defining name() and symbol()? * Probably starting out included in the SI system to get the thing working; plausibly extending into other systems/views as we get further along. I'm making an effort to keep our local usages/extensions to the boost::units framework in the same style/structure, so as to keep things flowing well into our application. I am also using meter as a template, but I'm not sure that's quite the template which would get us what we need? Yes, no, maybe? Any insights? Thank you... Regards, Michael

1 0

Building boost::posix_time with nano second support
by Matthias Dörfelt 02 Aug '11

02 Aug '11

Hello, I want to use nanoseconds from boost::posix_time but as stated in the reference, you have to define BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG to make that work. Unfortunatelly I don't have any idea where i have to define that variable in the build process. I build boost 1.47.0 like this on osx snow leopard: ./b2 macosx-version=10.6 link=static address-model=32_64 threading=multi stage So, where do I have to define the discussed variable to enable nanosecond support? Offtopic: I also noticed that adress-model=32_64 does not seem to work since all the produced static libs are x86_64 only.- Any ideas about how to fix that? Thank you!

1 0

Delayed/Lazy Function Call
by John M. Dlugosz 02 Aug '11

02 Aug '11

Consider something like this: typedef std::tr1::function<void ()> CapsuleFunc; class worker_thread_queue; class forwarder { worker_thread_queue* queue; const NotifyFunc f; public: forwarder (worker_thread_queue* queue, const NotifyFunc f) : queue(queue), f(f) {} void operator() (uint32_t extended_ID, State_t newstate, State_t oldstate); }; class worker_thread_queue { // doesn't really work, just for illustration public: worker_thread_queue() { // really, would create a thread and thread-safe FIFO } // Calling submit will put f in a queue, and that queue is processed by the // worker thread. It removes each item in FIFO order and executes them. void submit (const CapsuleFunc& f) { /* but it's just an example */ } // Calling wrap will return another function that when executed will call submit(f) on this instance. NotifyFunc wrap (const NotifyFunc& f) { forwarder x (this, f); return x; } }; void forwarder::operator() (uint32_t extended_ID, State_t newstate, State_t oldstate) { CapsuleFunc x= std::tr1::bind (f, extended_ID, newstate, oldstate); queue->submit (x); } // later... worker_thread_queue work_queue; work_queue.wrap(&foo); Presuming a compiler that doesn't have Lambda functions supported, is there some nicer way to acheive the effect shown by 'wrap'? Given a function object f and a object q, I want to create a new function object that when invoked will bind its arguments and call q->submit with the bound-up form. I've seen forwarders throughout Boost; is there a publicly available one that I can use? Or some kind of "delayed apply" that can be called like bind, with the thing to be built up? I recall there is a full heavy duty library for lazy evaluation but don't recall its name. But I'm also wondering if there is a specific (lighter weight or already being used within the Boost libraries I'm already using) mechanism for this. —John

1 0

access violation with asio
by Gianni Ambrosio 02 Aug '11

02 Aug '11

Hi All, can anybody explain me please why I get an access violation in the following code? And why if I enable the std::cout in the stream_handler destructor the code work fine without exception? I'm developing on windows XP, VS 2005. Regards Gianni Here is the code: #include <boost/asio.hpp> #include <boost/bind.hpp> #include <boost/thread.hpp> #include <boost/date_time/posix_time/posix_time_types.hpp> #include <iostream> typedef boost::shared_ptr<boost::asio::ip::tcp::socket> tcp_socket_ptr; class stream_handler { public: stream_handler() : acceptor(io_service) { boost::asio::ip::tcp::endpoint endpoint = boost::asio::ip::tcp::endpoint(boost::asio::ip::tcp::v4(), 22222); acceptor.open(endpoint.protocol()); acceptor.set_option(boost::asio::ip::tcp::acceptor::reuse_address(true)); acceptor.bind(endpoint); acceptor.listen(); socket = tcp_socket_ptr(new boost::asio::ip::tcp::socket(io_service)); acceptor.async_accept(*socket, boost::bind(&stream_handler::handleAcceptForDebug, this, boost::asio::placeholders::error)); work = boost::shared_ptr<boost::asio::io_service::work>(new boost::asio::io_service::work(io_service)); thread = boost::thread(boost::bind(&boost::asio::io_service::run, &io_service)); } virtual ~stream_handler() { //std::cout << __FUNCTION__ << std::endl; io_service.stop(); } private: boost::asio::io_service io_service; boost::shared_ptr<boost::asio::io_service::work> work; boost::asio::ip::tcp::acceptor acceptor; boost::thread thread; tcp_socket_ptr socket; void handleAcceptForDebug(const boost::system::error_code& iError) {}; }; int main(int argc, char** argv) { stream_handler tcpsocket; return 0; }

2 3

Bizarre problem with range/adaptor/transformed.hpp
by John M. Dlugosz 02 Aug '11

02 Aug '11

I've traced a problem in my program to the inclusion of #include "boost/range/adaptor/transformed.hpp" Nothing is using the features in it (such things are removed from the test case build I'm using to get to the bottom of it). It compiles just as well with or without the line. But if the file is included, the program is broken. If I omit it, then the program works fine. Any suggestions would be welcome.

3 6