headers
Jeffrey Bosboom | 1 Dec 2009 01:08
Picon
Favicon

Re: [explore] Library Proposal: Container Streaming

Robert Ramey wrote:
> Jeffrey Bosboom wrote:
>> I've written simple versions of streaming operators (both output and
>> input) for the standard containers as a simple, low-barrier-to-entry
>> form of serialization.  Do you plan to provide the input operators
>>  too? (I understand this would involve some restrictions on the
>> streamed forms of the container elements to prevent parsing ambiguity.)
> 
> how would this be different than just writing a special archive
> class and using boost seriallization?
> 
> Robert Ramey

It didn't require learning to use Boost.Serialization.  Also, in the 
specific case I needed this for, I was running code on a cluster where 
Boost was not available, so it was lighter-weight (although obviously 
far less featureful).

--Jeffrey Bosboom
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 31 comments |
headers
Simon Gittins | 1 Dec 2009 02:23
Picon

Re: [msm] Review

Hi Cristophe

[Advantages/disadvantages of state local storage...]

>+ speed: states don't need to be constructed again and again.
>Constructing a state (and its attributes) each time it becomes active
>can be costly, even if memory allocation can be optimized.

I agree that the feature can be costly.  I don't have a lot of experience with fsms with very tight time
constraints though - SC seems to meet our time requirements (ie the state machine itself is much faster
than the other operations we perform).  

>+ your state data is always available. In my experience, state data is
>not only needed in the entry or when the next event is processed, but
>during a transition or even at some time after a transition. This
>means, that you have, during a transition, access to data from the
>source or the target state.

This is simple to emulate in SC.  The state data can be owned by the outer state, or by the state_machine itself.

The advantage of true state local storage is that it encourages the use of meaningful destructors.  As a
(real life) example, a common strategy in our use of (asynchronous) SC is to instantiate a timer in the
constructor of the state (which may be an inner state of another state which has its own timer).  Since
exiting the state destructs the timer, we don't have to explicitly cancel it (in the exit action for
example).  It's just one less thing we risk forgetting to do.  

>+ combined with the visitor, you can at any time access data from the
>currently active state and build a generic way to do something with
>state data.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Tompkins | 1 Dec 2009 04:01

Re: [regressions][uuid] Can't see all test listed

On Mon, 30 Nov 2009 07:13 -0800, "Steven Watanabe"
<watanabesj <at> gmail.com> wrote:
> AMDG
> 
> Andy Tompkins wrote:
> > I am working on fixes to the uuid library that I have just recently
> > added to trunk.  When I look at the regressions
> > (http://tinyurl.com/yjyezsb) I see 4 test run for the uuid library.  I
> > have created more test than that and I don't know why they are not
> > running/reported.
> >
> > Would someone point me in the right direction to figure this out?
> >   
> 
> You should use the run rule instead of the unit-test rule.

Thank you very much.
Andy Tompkins

> In Christ,
> Steven Watanabe
> 
> 
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Jeffrey Faust | 1 Dec 2009 04:04

Re: [explore] Library Proposal: Container Streaming

Zachary Turner wrote:
> John Bytheway wrote:
> > You could put them in the global namespace?  I think that would
> > conform better to the letter of the rules, without really being any
> > safer in practice.
> I'd rather put them in a library specific namespace in that case, and
> require the programmer to put a using declaration in the translation
> unit.

Below is an example of why that won't work for all cases.  The only way
for variant::operator<< to access operator<<(vector) is to rely on ADL
and put the operator<< in the std namespace.

#include <boost/variant.hpp>
#include <iostream>
#include <vector>

namespace explore
{
   template<typename T>
   std::ostream& operator<<(std::ostream& ostr, const std::vector<T>& v)
   {
      // ...
      return ostr;
   }
}

int main()
{
   using namespace explore;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Faust | 1 Dec 2009 04:20

Re: [explore] Library Proposal: Container Streaming

Jeroen Habraken wrote:
> This reminds me of the repr() function in Python,
> http://docs.python.org/library/functions.html#repr. Maybe
> Boost.Represent would make sense as name for the project, as it shows
> a representation of the data.

That's a good idea.  I like it more than 'explore'.  Still, to me it
sounds like such a big word for something so basic in use.  Unless
you are extending it, there's literally no interface to the library
other than operator<<.

So I was thinking some more about a better name.  What do you think of
Boost.Out?

-- Jeff Faust
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 4 comments |
headers
Jeffrey Bosboom | 1 Dec 2009 04:55
Picon
Favicon

Re: [explore] Library Proposal: Container Streaming

Jeffrey Faust wrote:
> Jeroen Habraken wrote:
>> This reminds me of the repr() function in Python,
>> http://docs.python.org/library/functions.html#repr. Maybe
>> Boost.Represent would make sense as name for the project, as it shows
>> a representation of the data.
> 
> That's a good idea.  I like it more than 'explore'.  Still, to me it
> sounds like such a big word for something so basic in use.  Unless
> you are extending it, there's literally no interface to the library
> other than operator<<.
> 
> So I was thinking some more about a better name.  What do you think of
> Boost.Out?

I agree that 'represent' is too vague a word (I don't think it's any 
better than 'explore', really).

I like the bluntness of Out, but I expect Out to be more general than 
just standard containers.  (It makes me think of a library that was 
described as "the opposite of Spirit" for output formatting, although 
its name is nonobvious enough that I can't recall it.)

How about container_output?  It's not as succinct as 'represent' or 
'out', but it's a more descriptive of what the library actually is, and 
with utility libraries, it's more about making people aware of the 
utility than selling them on using it.

--Jeffrey Bosboom
_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stewart, Robert | 1 Dec 2009 05:42
Favicon

Re: [explore] Library Proposal: Container Streaming

Jeffrey Faust wrote;
> Jeroen Habraken wrote:
> > This reminds me of the repr() function in Python,
> > http://docs.python.org/library/functions.html#repr. Maybe
> > Boost.Represent would make sense as name for the project,
> > as it shows a representation of the data.
>
> What do you think of Boost.Out?

PrettyPrint?

_____
Rob Stewart                           robert.stewart <at> sig.com
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not
the intended recipient, please notify the sender immediately by reply and immediately delete this
message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor
any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or
sell any security or other financial instrument. Neither the sender, his or her employer nor any of their
respective affiliates makes any warranties as to the completeness or accuracy of any of the information
contained herein or that this message or any of its attachments is free of vi
 ruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Michael Caisse | 1 Dec 2009 07:00

Re: [explore] Library Proposal: Container Streaming

Jeffrey Faust wrote:
> 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.
>
>   

I've been trying to think of when I might use such a library. Without
the symmetry (input as well as output) I can think of few instances
where this functionality might come in handy. Other than potential debug
output, what else do you envision? What am I missing?

I'm also finding little improvement over the following example
based on your samples. Here I am using Karma to produce the same
output as Explore. It is a bit more verbose; however, it is infinitely
more flexible.

Best regards -
michael

-------------------------------------------------------------------

#include <boost/config/warning_disable.hpp>
#include <iostream>
#include <vector>
#include <map>
#include <list>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mikael Olenfalk | 1 Dec 2009 09:50
Picon

Re: Notice: Boost.Atomic (atomic operations library)

Hello Helge,

I am trying to use Boost.Atomic in my project but am experiencing the
following two problems:

  - boost/atomic/memory_order.hpp: enum memory_order is redeclared
from boost/memory_order.hpp (1.37)
      + however boost/memory_order.hpp does not define
memory_order_consume, from a quick glance however that enum value
         does not seem to be used (it appears in some switch
statements but only as a fallthrough) so I simply removed
         boost/atomic/memory_order.hpp and removed all uses of
memory_order_consume

  - boost::atomic<T>::atomic() and boost::atomic<T>::atomic(T v)
declare the variable "verify_valid_atomic_integral" but never use it
    which breaks -Werror
      + to fix this I simply added the line
"(void)verify_valid_atomic_integral;" to both constructors

I have not tested the changes, beyond testing that it compiles. A
patch is attached.

With kind regards,

Mikael Olenfalk

On Sun, Nov 29, 2009 at 11:49 PM, Helge Bahmann <hcb <at> chaoticmind.net> wrote:
> Hello,
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Helge Bahmann | 1 Dec 2009 10:36

Re: Notice: Boost.Atomic (atomic operations library)

Hello Mikael,

On Tue, 1 Dec 2009, Mikael Olenfalk wrote:
> Hello Helge,
>
> I am trying to use Boost.Atomic in my project but am experiencing the
> following two problems:
>
>  - boost/atomic/memory_order.hpp: enum memory_order is redeclared
> from boost/memory_order.hpp (1.37)

Yes, I realized that today; the definition in boost/memory_order.hpp is 
outdated, it should be replaced with boost/atomic/memory_order.hpp or 
augmented to include "memory_order_consume" (it is contained in more 
"recent" proposals of the C++0x standard, see 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2643.html).

>      + however boost/memory_order.hpp does not define
> memory_order_consume, from a quick glance however that enum value
>         does not seem to be used (it appears in some switch
> statements but only as a fallthrough) so I simply removed
>         boost/atomic/memory_order.hpp and removed all uses of
> memory_order_consume

it *is* used, to force a memory barrier on alpha (where many other 
architectures don't need one). Don't remove it, this is wrong.

>  - boost::atomic<T>::atomic() and boost::atomic<T>::atomic(T v)
> declare the variable "verify_valid_atomic_integral" but never use it
>    which breaks -Werror
(Continue reading)

Permalink | Reply | 2 comments |

Gmane