- Boost - lists.boost.org

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 04 Dec '09

04 Dec '09

Hi Barend, > First I thought (intuitively) that the eUML was meant for output, but > apparently that is not the case, it is an embedded language for defining > state machines, right Right. It is at the same time syntactic sugar and a way to concentrate more information in the transition table. For designers, it is sometimes helpful to be able to see the whole transition at the same time and in the same place. > Is is somehow possible to export an MSM to a Boost.Graph, either within > the library, or in an example or separate utility headerfile? Yes it is. A transition table is relatively easy to parse and thus it should be possible to generate a diagram from a transition table. As shown at the last BoostCon, I'm working on a tool doing just this, but a graph export might be a nice and useful addition. Regards, Christophe

2 1

[iostreams] input_sequence() questions
by Rob Riggs 04 Dec '09

04 Dec '09

I am attempting to adapt a windowed mmap reader, one which manages its mapping window using iterators, to a boost::iostreams direct source. I wrote this for reading large files via mmap on 32-bit platforms. The documentation shows that input_sequence() returns a pair of char pointers, not iterators. Is that really true or am I misreading the docs? http://www.boost.org/doc/libs/1_41_0/libs/iostreams/doc/concepts/source.html And it also shows that the input_sequence pointers are non-const. Why is that required for sources? Thanks, Rob

1 0

[explore] Extending namespace std
by Jeffrey Faust 04 Dec '09

04 Dec '09

The various threads of discussion have died down. These include the name of the library, whether it's useful or not, if it is useful can it be satisfied by an existing library, whether it should it be part of another library or be a library on its own, and gcc compiler switches. All of these are important and we'll have to address them at some point (except perhaps the compiler switches). One item that was brought up and dismissed is that the implementation relies on extending namespace std. I'd like to visit this item more thoroughly. In my opinion the ideal interface is the most natural, simplest, and the most familiar to C++ developers: 'cout << c;' where c is a container of type C. Going beyond this nominal usage employs stream manipulators, again something that is known. Other forms such as 'print(c);' or 'wrapper(cout) << c;' are inferior interfaces. The former is clumsy and the latter does not extend in a natural way. Whether or not you agree, for the sake of argument, let's start with the statement that 'cout << c;' is the ideal interface for this library. Let's discuss how we can make this work. The only way I know how to make 'cout << c;' work for all cases is to put operator<<(C) in the same namespace as C. For example, variant<C, ...> will not stream if C is in std and operator<<(C) is not. The only way operator<<(variant) can see operator<<(C) is through ADL. If anybody can think of a mechanism where this will work without extending namespace std, please speak up. In regards to extending namespace std, I understand what the standard says and I think I understand the reasons behind it. I could add something to namespace std that conflicts with an existing item, changing the behavior. This is certainly undefined behavior, and the standard is right in restricting it. I don't believe this problem exist for the explore library. If we know that on all supported compilers that extending namespace std in this way behaves correctly, what is the concrete problem of doing so? Thanks for reading, -- Jeff Faust

1 0

FunctionTypes broken in trunk
by Tor Brede Vekterli 03 Dec '09

03 Dec '09

Hi This is just a notice that the FunctionTypes library appears to have been broken since revision 56305, where several of the arity preprocessor files have become corrupted (more specifically, arbitrarily cut off) for some reason or another. The following extremely small test-case should fail to compile: #include <boost/function_types/function_pointer.hpp> int main() {} Best regards, Tor Brede Vekterli

3 2

[msm] Comments
by Nelson, Erik - 2 03 Dec '09

03 Dec '09

I erroneously posted this on boost-users yesterday... Reposting it here today. I'm not competent to present a full review of the Boost MSM library, but I've been following it with interest since I discovered it at BoostCon. I've read very many mailing list exchanges between Christophe and users during this time. The MSM review hasn't generated a ton of traffic, and I'd like to contribute my comments for whatever they're worth. >What is your evaluation of the design? The Boost MSM library seems to be a well-designed implementation of state machine logic that is faithful to the UML standard in most areas and thoughtfully deviates from (or extends) it in a few places. >What is your evaluation of the implementation? I feel like the implementation is a clean example of modern C++ and abstracts state machine concepts quite well. The transition table in particular is implemented elegantly. >What is your evaluation of the documentation? Adequate >What is your evaluation of the potential usefulness of the library? Very useful... I expect to need this library for my work within the next 3-6 months >Did you try to use the library? I have not used the library. >How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Something more than a quick reading, yet well short of an in-depth study. >Are you knowledgeable about the problem domain? Not particularly.. I've handwritten small state machines for GUI programming in the past As an additional comment, I believe Christophe himself typifies the best things about Boost. He has tirelessly worked on MSM and has been very supportive of users, incorporating many suggestions for improvement. MSM should definitely be included in Boost. Thanks Erik

1 0

[explore] Library Proposal: Container Streaming
by Jeffrey Faust 03 Dec '09

03 Dec '09

Jared McIntyre, Danny Havenith, and myself, with support from Jeff Garland have developed a library to stream standard containers to output streams. We would like to submit this for review. The requirements for this library were gathered at the BoostCon 2007 Library in a Week sessions. An initial review was held and further requirements were gathered at BoostCon 2008. Everything can be found in the boost vault <http://www.boostpro.com/vault/> . Here is a direct link to explore.zip <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ex plore.zip&directory=&> . Some quick examples: #include <boost/explore.hpp> # include ... // simple vector example std::vector<int> vi; vi.push_back(1); vi.push_back(2); vi.push_back(3); std::cout << vi; // prints [1, 2, 3] // lets do some containers in containers std::vector<std::vector<int> > vvi; vvi.push_back(vi); vvi.push_back(vi); std::cout << vvi; // prints [[1, 2, 3], [1, 2, 3]] // associative containers std::map<std::string, int> si_map; si_map["hello"] = 1; si_map["world"] = 2; std::cout << si_map; // prints [hello:1, world:2] // containers of complex types std::list<date> dl; // date from boost::gregorian dl.push_back(date(2007, Jan, 1)); dl.push_back(date(2007, Jan, 3)); std::cout << dl; // prints [2007-Jan-1, 2007-Jan-3] // how about some boost container types: boost::array<std::string, 2> sa2; sa2[0] = "one"; sa2[1] = "two"; std::cout << sa2; // prints [one, two] Jeffrey Faust

27 56

[serialization] polymorphic archives runtime failure (was: polymorphic archives ... generates linker errors)
by Christoph Heindl 03 Dec '09

03 Dec '09

Hi, thanks to Roberts help I managed to get the polymorphic archives issue, discussed earlier at http://article.gmane.org/gmane.comp.lib.boost.devel/196984) resolved. However there remains a runtime issue I can't resolve: Based on demo_polymorphic.cpp I've re-created minimal test example, which I think is correct, that fails with the runtime assertion it != m_map.end(), file libs\serialization\src\basic_serializer_map.cpp, line 72 on load. The demo consists of 5 files that create the following scenario: class B inherits from polymorphic base class A. An object of B is allocated on the heap and serialized through a base pointer A using a polymorphic xml archive. Saving runs without problems. Next, B is loaded from the stream through a base pointer to A. This fails with the mentioned assertion. What makes me wonder is that changing the from polymorphic_xml_iarchive to xml_iarchive and from polymorphic_xml_oarchive to xml_oarchive will not produce the named assertion. As mentioned in my previous post, I tested this with boost 1.40.0 and msvc 9.0. I would be really, really, grateful if you could give the demo a try. I've prepared everything so that it is just a matter of copying the files to libs/serialization/example and adding [ demo_bsl_run demo_polymorphic_cheind : cheind_a cheind_b ] The files can be found attached to my lost post at http://article.gmane.org/gmane.comp.lib.boost.devel/197061 Best regards, Christoph

2 4

Re: [boost] Regex allocator support
by Fred Sundvik 03 Dec '09

03 Dec '09

Sorry for the previous message. Somehow I managed to send the message without a reply. A proper reply will follow soon. "Fred Sundvik" <fred.sundvik(a)bugbear.fi> wrote in message news:14525.2590220936$1259836768@news.gmane.org... >>> We recently had to use the regular expression library in conditions >>> where there was no available physical memory, for reporting resource >>> consumption when our console game runs out of memory. This wasn't >>> possible however due to the fact that the basic_regex does some > dynamic >>> allocations and doesn't provide any allocator specialization, > allthough >>> match_results for example does. So we modified the boost code a > little >>> bit and added a new template paramter for the allocator, and made >>> constructors that takes allocators as parameters. >>> >> <snip> >>> >>> So my question is, what are the chances that theese kinds of >>> modificiations gets implemented in the actual library, and possibly > in >>> the next c++ standard library as well? I consider it a quite big > design >>> flaw to not have any control of the internal allocations, so for me > this >>> a quite big thing. >> >> +1; I agree with the OP's sentiments, though I wouldn't say it's >> necessarily a "big" design flaw. However, I've never used the >> Boost.Regex library, and I don't know if the next standard specifies >> allocator parameters. I gather it doesn't? > > Sigh... no. > > The original regex++ library upon which the Boost version is derived > *did* > have allocators for everything. But during review folks felt quite > strongly > that: > > a) It was overkill. > b) Regex should be free to manage it's own memory - it's not a container > - > it's needs are much more complex than that - so it should be free to > optimize memory allocation and caching as it sees fit. > > As a result this facility was removed. Rightly or wrongly, no one on > the > stds committee questioned that design decision. > > Some specific comments on the other issues: > >>The mem_block_cache system was a bit more complicated. Initially we >>disabled >>it completely, but that obviously wasn't the best solution. So we > figured >>out, that we can use a custom allocator as default, instead of >>std::allocator. That custom allocator then had to be specialized for > the >>mem_block_nodes, and the funcion calls to get_mem_block replaced by >>allocator calls. Our implementation isn't ideal, though as we used >>mem_block_node as the specialization, and to pass the correct size to > the >>allocator, we allocate BOOST_REGEX_BLOCKSIZE / sizeof(mem_block_node) > of >>them, this way it works for allocators that don't specialize for >>mem_block_node(but only if the size is dividable by >>sizeof(mem_block_node) ). Better would probably be to make a new type > that >>is BOOST_REGEX_BLOCKSIZE big. > > Can you not just define BOOST_REGEX_RECURSIVE and use the stack based > implementation that does away with that altogether? > >>We also found another problem with allocation, the match_result::format >>functions only takes string_type, that isn't specialized by any > allocator >>as >>they input. This made it impossible to call them with strings using >>different allocators. So we added specializations of those functions > for >>different allocators and traits. There are probably more functions like >>that, but since our code doesn't use them there was no need to change >>anything. > > The current Trunk allows any string, container or character type, plus > function objects to be used as arguments to regex_format/regex_replace > etc, > which should avoid that problem. > >>We recently had to use the regular expression library in conditions > where >>there was no available physical memory, for reporting resource > consumption >>when our console game runs out of memory. > > I'm not sure I understand the issue here, that operator new doesn't > report > out of memory conditions? What does your allocator do that's different > to > operator new, and why not replace global new and delete with calls to > your > custom allocator? Just trying to get a handle on the issue... > >>So my question is, what are the chances that these kinds of > modifications >>gets implemented in the actual library, and possibly in the next c++ >>standard library as well? > > As noted above, I was asked to remove this feature during review, so I'm > not > *that* keen to put it back in! As far as the standard is concerned it's > > basically a done deal at this stage in the process - too late for such a > big > change. WRT Boost I'd really like to get a handle on the issue better > before making judgment - you seem to be one of very few people actually > using custom allocators ;-) > > Regards, John. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Regex allocator support
by Fred Sundvik 03 Dec '09

03 Dec '09

>> We recently had to use the regular expression library in conditions >> where there was no available physical memory, for reporting resource >> consumption when our console game runs out of memory. This wasn't >> possible however due to the fact that the basic_regex does some dynamic >> allocations and doesn't provide any allocator specialization, allthough >> match_results for example does. So we modified the boost code a little >> bit and added a new template paramter for the allocator, and made >> constructors that takes allocators as parameters. >> > <snip> >> >> So my question is, what are the chances that theese kinds of >> modificiations gets implemented in the actual library, and possibly in >> the next c++ standard library as well? I consider it a quite big design >> flaw to not have any control of the internal allocations, so for me this >> a quite big thing. > > +1; I agree with the OP's sentiments, though I wouldn't say it's > necessarily a "big" design flaw. However, I've never used the > Boost.Regex library, and I don't know if the next standard specifies > allocator parameters. I gather it doesn't? Sigh... no. The original regex++ library upon which the Boost version is derived *did* have allocators for everything. But during review folks felt quite strongly that: a) It was overkill. b) Regex should be free to manage it's own memory - it's not a container - it's needs are much more complex than that - so it should be free to optimize memory allocation and caching as it sees fit. As a result this facility was removed. Rightly or wrongly, no one on the stds committee questioned that design decision. Some specific comments on the other issues: >The mem_block_cache system was a bit more complicated. Initially we >disabled >it completely, but that obviously wasn't the best solution. So we figured >out, that we can use a custom allocator as default, instead of >std::allocator. That custom allocator then had to be specialized for the >mem_block_nodes, and the funcion calls to get_mem_block replaced by >allocator calls. Our implementation isn't ideal, though as we used >mem_block_node as the specialization, and to pass the correct size to the >allocator, we allocate BOOST_REGEX_BLOCKSIZE / sizeof(mem_block_node) of >them, this way it works for allocators that don't specialize for >mem_block_node(but only if the size is dividable by >sizeof(mem_block_node) ). Better would probably be to make a new type that >is BOOST_REGEX_BLOCKSIZE big. Can you not just define BOOST_REGEX_RECURSIVE and use the stack based implementation that does away with that altogether? >We also found another problem with allocation, the match_result::format >functions only takes string_type, that isn't specialized by any allocator >as >they input. This made it impossible to call them with strings using >different allocators. So we added specializations of those functions for >different allocators and traits. There are probably more functions like >that, but since our code doesn't use them there was no need to change >anything. The current Trunk allows any string, container or character type, plus function objects to be used as arguments to regex_format/regex_replace etc, which should avoid that problem. >We recently had to use the regular expression library in conditions where >there was no available physical memory, for reporting resource consumption >when our console game runs out of memory. I'm not sure I understand the issue here, that operator new doesn't report out of memory conditions? What does your allocator do that's different to operator new, and why not replace global new and delete with calls to your custom allocator? Just trying to get a handle on the issue... >So my question is, what are the chances that these kinds of modifications >gets implemented in the actual library, and possibly in the next c++ >standard library as well? As noted above, I was asked to remove this feature during review, so I'm not *that* keen to put it back in! As far as the standard is concerned it's basically a done deal at this stage in the process - too late for such a big change. WRT Boost I'd really like to get a handle on the issue better before making judgment - you seem to be one of very few people actually using custom allocators ;-) Regards, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [msm] Review
by Christophe Henry 02 Dec '09

02 Dec '09

Hi Andreas, > It doesn't, but this seems to be beside the point anyway. You wrote (in an > unquoted part) that Msms behavior with respect to storage in states is hard > to emulate with SC. Simon only showed that it isn't (unless Simon and I are > missing something). But (as you wrote yourself in this excellent rationale) if you have to move the data from state to fsm you lose part of the benefit of state-storage, right? OTOH you get the advantage of automatic destruction. Even better would be to allow both possibilities through a policy. For every design decision taken in Msm, you will probably find a case where SC will offer a better solution in some cases and vice versa. At first glance, it seems that state storage is the same in both libraries, but as it turns out, there are subtle differences. > That's good to hear. BTW, is there only a limit on the number of > transitions, or is the number of states limited in some way to? Does the > number or orthogonal regions have an influence? I never managed to break a compiler purely on the number of states (I tried up to 80). The orthogonal regions have very little influence as their metaprogramming needs are very small. Regards, Christophe

2 1