- Boost - lists.boost.org

Serialization17 - assert in basic_text_oarchive.hpp
by Jeff Flinn 05 Mar '04

05 Mar '04

Robert, My app is hitting the assertion at line 133 in basic_text_oarchive.hpp with delimiter = 3 when serializing to a text_oarchive. The assertion occurs during serialization of the count for a shared_ptr. There is an access violation when attempting to serialize to a binary_oarchive also. XML serialization in both directions works fine. The odd thing is, if I comment out any usage of xml_oarchive, the assertion is not triggered, and serialization to both text_oarchive and binary_oarchive succeeds. Input from binary/text/xml succeeds in all cases. I'll try to diagnose further. This is all with vc7.1, both the exe and libs are compiled with static multi-threading library flags (/MT). Any thoughts? A quick perusal of the test suite doesn't show any cases using multiple oarchive types within a single test. Thanks, ----------------- Jeff Flinn Applied Dynamics, International

1 0

RE: [boost] whither the order language
by Vesa Karvonen 05 Mar '04

05 Mar '04

Hi, Ronald Garcia wrote: >Where can I find a copy of the Order preprocessor language? The Boost >files section seems to have examples of its use, as well as a manual, >but I don't seem to see the implementation. I removed the Order interpreter implementation from the files section some time ago, because it had changed significantly due to the discovery of a couple of techniques for removing certain practical limitations. The documentation and examples mostly reflect the current Order interpreter, but as I have not been working on the implementation for some time, the interpreter is not ready for publication. If you are really interested, then I could e-mail you a snapshot of the interpreter. The current Order interpreter also uses C99 preprocessor features, namely variadics and placemarkers, so it is not immediately useful for C++ programming. The latest GNU CPP and the Wave library are known to be able to preprocess the Order interpreter. Other preprocessors have not been tested, but it should be possible to port the interpreter to most (more or less buggy) preprocessors that support the C99 extensions. Regards, Vesa Karvonen _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

[serialization] non-conformance in collection_load_imp.hpp
by Joaquín Mª López Muñoz 05 Mar '04

05 Mar '04

"serialization/collections_load_imp.hpp" defines a private template class stack_allocate for stack-based reservation of uninitialized memory. To the best of my knowledge, the way it does so is not std-conformant due to alignment issues. Fortunately, (undocumented) "boost/aligned_storage.hpp" provides a template class named aligned_storage which handles the issue, so I guess the problem can be solved by just using this facility instead of stack_allocate. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: GUI library - another one
by E. Gladyshev 05 Mar '04

05 Mar '04

--- Robert Ramey <ramey(a)rrsd.com> wrote: It seems that my post didn't make it through. I got the Boost post acknowledgement but the message did not appear on the list. I am trying to use another e-mail account. If the mailing list moderators would like to look into this problem, please e-mail me privately so I could give you my account information. Thanks. Anyway back to the GUI stuff. > I believe similar discussions were engaged some time ago and that these > discussions resulted in: > > http://sourceforge.net/projects/notus/ > > What to the participants in these other discussions have to add? Well, I am quite happy with the direction notus is taking but there is a lot to be done. First I'd like to comment on the issue of simplicity. Simplicity is great but IMHO, it should NOT be of concern of the core GUI design. The higher layers could simplify the core interface any way they like. Like another poster pointed out if a feature is missing it could easily be a showstopper. It is like missing a letter in the alphabet. The primary concern of the core GUI design should be consistency, *scalability* and feature support. I think that the discussion of the syntax like using operators '<<' or '[]' and so on is important but it is a secondary issue. I think that what we are missing a consistent fundamental GUI design. All this syntactic sugar or XML support could be added at a latter stage. Most of the GUI frameworks with their endless polymorphic hierarchies and castings are not fun anymore. :) The fundamental GUI library doesn't have to support all possible features right from the start. It is more important to identify all fundamental features and architectures that will let you to scale the framework up with new features. Usually a GUI feature is not a standalone thing. It relies on presence of other features. A good GUI library should identify a set of *fundamental* features and architectures that will let the library grow vertically and orthogonally. Notus is based on what we call MDS (the DDV terminology will be deprecated). Model - application data Display - physical device such as window, button Strategy - user defined behaviors template <typename Model, typename Display, typename Strategies > struct view {...} A typical strategy looks like this struct my_strategy : handle_event<mouse> handle_event<paint> { template< typename View > void on_event( View& v, mouse& e); template< typename View > void on_event( View& v, paint& e); }; As you can see, the strategy event handlers take the event source (View) as a template parameter. So as soon as the View provides the interface that is required by this strategy, it doesn't care what View really is. So strategies can be used as interchangeable components. Strategies can be combined and reused. typedef view< my_data, displays::window, tuple<my_strategy> > my_window; //customize my_window typedef view < my_data, displays::window, tuple<my_customization, typename my_window::strategy> > my_custom_window; //my_custom_window reuses all strategies that are defined in my_window; I'd like to note that notus doesn't have any casting stuff and almost no polymorphism. The idea is to create a *generative* framework where components can be constructed from a set of interchangeable and custom parts. I'd like to touch the issue of ownership. The core Notus doesn't care about ownership at all, the physical devices such as windows, buttons, etc. are represented by Displays. One display can be connected to one or more other displays so that it will get events generated by the displays that it is connected to. So at this level, it is a *network* of display connections not an ownership hierarchy. I anticipate your question about what happens when the display's "physical" owner is deleted. Nothing really except that all the connections to the deleted display are lost. *Important* the displays don't keep direct references to other displays. I appreciate your comments. Eugene

1 0

boost::lexical_cast optimizations
by Val Samko 05 Mar '04

05 Mar '04

At the moment, boost::lexical_cast is about 70 times slower than corresponding C functions (at least with VC++ with all the optimizations enabled) for integer and floating point types (see my benchmark below). Is it possible to add boost::lexical_cast specializations for std::string, integer and floating point types? Val Samko === Benchmark code ==================== Output: VC++ 7.1: atoi: 1297ms vs lexical_cast: 79703ms g++ 3.3.3 (mingw): atoi: 1547ms vs lexical_cast: 148078ms #include <boost/lexical_cast.hpp> #include <iostream> #include <string> #include <windows.h> int main() { std::string s = "25413248"; int r; int REPEATS = 20000000; DWORD c1 = GetTickCount(); for (int i = 0; i < REPEATS; ++i) r += atoi(s.c_str()); DWORD c2 = GetTickCount(); for (int i = 0; i < REPEATS; ++i) r += boost::lexical_cast<int>(s); DWORD c3 = GetTickCount(); std::cout<<"atoi: "<<(c2-c1)<<"ms vs lexical_cast: "<<(c3-c2)<<"ms "<<std::endl; }

1 0

whither the order language
by Ronald Garcia 05 Mar '04

05 Mar '04

hi, Where can I find a copy of the Order preprocessor language? The Boost files section seems to have examples of its use, as well as a manual, but I don't seem to see the implementation. Thanks, ron

2 1

[preprocessor] warnings on VC6
by Jonathan Turkanis 05 Mar '04

05 Mar '04

When I compile the following simple program on VC6: #include <boost/preprocessor/facilities/empty.hpp> #include <boost/preprocessor/punctuation/comma_if.hpp> #define PARAM(has_param) BOOST_PP_IF(has_param, typename Param, BOOST_PP_EMPTY()) #define MACRO(has_param) \ template< PARAM(has_param) BOOST_PP_COMMA_IF(has_param) typename T> \ struct name { }; \ /**/ MACRO(0) int main() { return 0; } I get the following warnings: warning C4003: not enough actual parameters for macro 'BOOST_PP_IIF' warning C4003: not enough actual parameters for macro 'BOOST_PP_IIF_I' warning C4003: not enough actual parameters for macro 'BOOST_PP_IIF_0' It works fine on other compilers. Am I missusing the preprocessor library, or is this a problem with VC6? If the latter, is there a workaround, or should I just turn off warning 4003? Jonathan

3 9

[Threads] Reactive Objects
by scott 05 Mar '04

05 Mar '04

Hi, I have been working on a small library that has become reasonably useful and possibly of interest to someone else. It's also become fairly large. I am quite interested in this library getting "boosted" but even given that there is substance to the library its scope is a bit of a problem; its quite large. It was started as a project with requirements very similar to those associated with the ActiveObject pattern; http://citeseer.nj.nec.com/lavender96active.html (reference from J. Garland) and takes many cues from the concepts and primitives found in SDL; http://www.sdl-forum.org/ Its possible to characterize this library as the basic building blocks for clean, robust multi-threading <ahem>. It could also be characterized as a subset of TAO, i.e. CORBA. While its a very small subset <sheepish grin>, maybe these comments gives scale to the scope issue. A breakdown of the incidental technologies tackled by this library follows; * multi-threading building block classes * network representation of structured data (variants) * saving and loading of network data (persistence) * interactive machines (inter-thread messaging) * stateless and stateful machine representation * code generation of network data and machine skeletons * message forwarding (distributed messaging) * transparent remote machines (proxies for inter-process messaging) * support for multiple encodings, e.g. binary, text, XML... To flesh this list out into something less opaque, a set of file fragments follows. These are the result of applying the library to the test case pushed around in the recent thread "Simple Active Object". They are necessarily abbreviated; // --------------------------------- // db_server.tms (the schema) // record configuration { // Persistent portion of the db_server string data_source integer maximum_workers integer maximum_clients } record open {} // Messages between the server and its clients record close {} record select { string sql_statement } record busy {} state INTIAL, // Pre-defined READY, // Normal operation OVERLOADED, // All workers busy OUT_OF_SERVICE // Something went wrong // Define the messages expected in the // different states transition INITIAL void // Standard startup transition READY open, // Another client connecting close, // Client closing configuration, // Reconfiguration select // An SQL select statement .. // --------------------------------- // db_server.h (auto-generated header) // .. #define db_server_configuration_hash 0x03493ac9 #define db_server_open_hash 0x7a6ffa00 #define db_server_close_hash 0x1093ac66 #define db_server_select_hash 0x004410ac #define db_server_busy_hash 0x74529711 struct typed03493ac9 { .. string &data_source; long &maximum_workers; long &maximum_clients; .. }; struct db_server { .. enum { INITIAL, READY, OVERLOADED, OUT_OF_SERVICE }; typedef typed03493ac9 configuration; typedef typed7a6ffa00 open; typedef typed1093ac66 close; typedef typed004410ac select; typedef typed74529711 busy; virtual int transition( typed_state<INITIAL> ) = 0; // void message virtual int transition( typed_state<READY>, typed_bind<open> & ) = 0; virtual int transition( typed_state<READY>, typed_bind<close> & ) = 0; virtual int transition( typed_state<READY>, typed_bind<configuration> & ) = 0; virtual int transition( typed_state<READY>, typed_bind<select> & ) = 0; int machine( typed_word & ); // The auto-generated switch statements .. }; .. // --------------------------------- // my_server.cpp (application declaration of db_server) // #include "db_server.h" class my_server : public state_machine<db_server> { typed_memory_folder home; db_server configuration; address_group client; virtual int transition( typed_state<INITIAL> ); virtual int transition( typed_state<READY>, typed_bind<open> & ); .. }; // my_server.cpp (application definition of db_server) // my_server::my_server() : home( "configuration\\my_server" ) { try // Persistence { load( home, configuration ); // Recover previous image } catch( ... ) { // Not found. Set factory defaults configuration.data_source = ""; configuration.maximum_workers = 4; configuration.maximum_clients = 100; save( home, configuration ); } } int my_server::transition( typed_state<INITIAL> ) { if( data_source.empty() ) { return OUT_OF_SERVICE; } if( ... ) // Attempt to connect to RDBMS { return READY; } return OUT_OF_SERVICE; } int my_server::transition( typed_state<READY>, typed_bind<open> &s ) { client.insert( sender() ); reply( configuration ); } .. int my_server::transition( typed_state<READY>, typed_bind<select> &s ) { if( ... ) // Find an idle worker { // Submit request to worker .. return READY; } reply( busy() ); return READY; } Hopefully these fragments have been enough to sketch out the intent of the library and where it currently is "at". As a bunch of materials, it is a .lib, headers and a .exe (the schema parser+generator) There are (serious) pretentions to platform independence but current materials are for Windows. I am very happy to work towards a boosted version of a subset of this work cos basically it seems too large to be a prospect otherwise. This subset would be in the area of mutli-threading building block classes, i.e. an "alternate threading model". However, after the recent exchange of related and interesting messages, I felt compelled to "come clean" with some background. So, to Matthew and Mark. Are you interested in dicsussing the possible implementation of; * simple active objects (completion of current alternate threading model) * simple reactive objects (completion of current with two-way calling of methods) * something else? Cheers, Scott

5 12

More versatile any_cast
by David Abrahams 04 Mar '04

04 Mar '04

Someone wanted to be able to put a derived class into a boost::any and use any_cast to get a base class pointer out. Enclosed is a patch to do it, FWIW. Disclaimer: I have no opinion on whether this should be done or not. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

RE: [boost] Re: [Threads] Simple active object wrapper, take 2
by Darryl Green 04 Mar '04

04 Mar '04

> -----Original Message----- > From: Matthew Vogt [mailto:mvogt@juptech.com] > Sent: Wednesday, 3 March 2004 8:44 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: [Threads] Simple active object wrapper, take 2 > > > scott <scottw <at> qbik.com> writes: > > > Yep. All straight now. I know understand your breakdown of calls > > to callbacks is very similar to that inherent in SDL. And > yes, you/we/it > > are fully asynchronous. > > > > I'm assuming you prefer this to the reactive object version? Which > > does a pretty good job of hiding the comms Oh yeah, and doesnt > > require selection of the method to call in either the receipient > > or the client (on response), i.e. at the point of making a method > > call. > > > > Maybe we're down to a matter of taste? > > Yes, I guess it depends on whether you're > familiar/comfortable with the message > passing paradigm, or whether you're more comfortable with C++ > shenanigans to > obscure the messy details. It may be the sign of a warped mind but queueing some form of bound functor-like object has almost always seemed to be (broadly) what I wanted to do in any message passing scheme, whether or not fancy machinery existed to do it. However, there are times when it is useful to have the messaging defined independently of either the sender or the receiver, with both being written to conform to the messaging interface. I've tended to think of the tightly/early bound, just queue a functor, and the message passsing + switch case as 2 completely independent patterns, but maybe they should be built on a common framework (at a level above the detail that they both ivolve queuing some sort of object). The AO pattern doesn't require that you identify the object you want to invoke the method on in the proxy, because you send the proxy to that object, and only that object. So one could drop the "this" parameter from the proxy. That would potentially allow the proxy to be routed/forwarded in a more general reactive object model (I think this was one of Scotts requirements)? I'm not 100% sure how useful this is, but it might be nice for the class of problem where you do want concurrent execution - of as many completely independent instances of the object as is "useful". The client/master doesn't care which instance - the next available one will do nicely. Further, it would seem possible to exclude any binding to a particular member function from the proxy itself and instead allow "free proxies" to be defined. To avoid confusion, I'm going to drop the work proxy for these "free proxies" and call them "messages". These would just define a function signature to match, not a particular (member) function. It is not clear to that the type of the "this" parameter need be defined by the message - excluding it would offer better separation between message sender and receiver. The sender need only know that it wants to notify or invoke something by sending the message. Such message types (just a tuple) could be defined with no reference to the wrapper or receiving object type at all. As you have said, the downside is that there is some form of type-switch implied in the receiver (eg the receiver wrapper would accept a boost::variant<message_type_1, message_type_2...> from the activation list and apply a generic visitor to do the dispatch). Maybe this can be avoided if there is a separate queue per message type? The additonal queue/scheduler complexity would probably wipe out any potential advantage though. So a receiver wrapper generator would need to, given the set of message types and corresponding member function pointers to handle them, generate the variant and corresponding visitor. I certainly like this better than a hand coded switch, and it is something like a simplified/limited form of the compile time (actually code generation time) generation of message demux code that is part of scotts existing framework (I think - I only skimmed scotts descriptions and possibly guessed too much from vaguely similar, but more primitive things I've used before). > I would postulate, however, that wrapping the details to > allow binding at the > call site (or message post) is slightly superior, due to the > removal of the > dispatch. Of course, this minor gain may easily be outweighed by the > contortions required to make it work, and the reduction in > the transparency > of the code... The tightly/call site bound case can be written as a simple layer on top of the lose/late bound system. Message type becomes variant<proxy> and the visitor for the one and only type dispatches to a wrapper function that just does the stuff that was done in the thread_function loop in your AO code. I'm not sure that for a reasonably small (any sane?) interface the performance difference due to the demux will be terribly large anyway, so maybe the specialisation isn't needed for that alone. However I've so far ignored the return value in this - the return type could obviously be defined in the message, but what should define how/where it should be delivered? It seems that the caller should define how/where it wants results delivered at the time of invoking the request - which it can do by passing some sort of result handler object in the message instance. Of course this is what the synch object in your proxy is. Perhaps its interface can be made more generic to allow its operation to be policy based. Broadening the definition from "return value" to "message delivery notification" with the sender supplied message delivery notifier object passed the return value from the handler doesn't feel too weird to include at the low level, and shouldn't cost anything for a void return without notification. Interestingly, the option to generate a a notification that a message with a handler returning void has been processed doesn't seem like a strange feature when looked at this way (a void future is a bit odd though). > > > > I hadn't realised how integral the state machine was to your > > > design until I > > > read your other post. Still, if you are doing dispatch on > > > both message code > > > and object state, it can be simplified to bind the message to > > > a per-message > > > code dispatch function which then dispatches on object state. > > > > Characterizing of reactive objects as a framework for state machines > > would be a little bit sad. I'm not sure it was your intention to say > > that so just in case others are listening, I will elaborate from > > my POV. > > > > Sorry, I read too much into the example code in the other > message. I assumed > the messaging would be an independent layer, but that the > design you were > using must have the communicating objects modelled as state > machines. Thanks > for clearing that up. > This observer didn't see the state machine aspect as the exclusive use, more an important use case reflected in the design. Would that be fair to say? > <snip> > > > The messaging facillity has _no understanding_ of what the > recipient does > > with a message. Proxies and state machines were intended to > highlight > > the benefits of that design. > > > > To summarize; the Reactive Objects that I currently > consider our target > > would communicate via a similar mechansim and there would be no > > assumption that a Reactive Object was a state machine, or a > proxy, or > > anything except an object that accepts messages. My questions that I've been thinking out loud about (always dangerous in public) were: What is a message? What is acceptance? Sorry this was so long - am I barking up the wrong tree here or not? > > Yes, that all sounds good. > > > Cheers, > > Scott > > Matt > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/bo> ost > ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

3 2