|
Boost : |
From: Fred Bertsch (fred.bertsch_at_[hidden])
Date: 2006-02-07 16:37:01
This is a fairly minor point, in my opinion, and I don't think I can
say which way is better for shmem, but I'll try to explain it a bit
better.
For example, named_shared_object can only be created through its
default constructor. Once created this way, you probably can't
actually use your named_shared_object. Instead, you can complete the
construction of the object by using open, create, or one of the other
methods that "construct" the object. An error is indicated by the
return value of these member functions. I don't actually know the name
of this technique, and I suspect my point would be clearer if I knew
its name.
The alternative technique is to have several constructors or static
member functions in named_shared_object. These would create an opened
or created named_shared_object if nothing bad happened, and they would
throw an exception if an error came up.
I mostly brought this up because few things in boost use the first
technique, so someone might have a strong opinion about it.
-Fred
On 2/7/06, Ion Gaztañaga <igaztanaga_at_[hidden]> wrote:
> Hi fred,
>
> > First, there tends to be a create and object member function of a lot
> > of objects in the library. This forced Ion to create partially
> > constructed objects with the constructor, but it allows the use of
> > return values instead of exceptions for error handling. I personally
> > do not like partially constructed objects, and I do not mind
> > exceptions that are thrown if there's a serious problem detected. I'm
> > curious what the rationale was for that decision. Do the create/open
> > functions fail frequently in typical use cases?
>
> Can you elaborate a bit on this? I can't understand well what you are
> trying to point out.
>
> Thanks
>
> Ion
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
-- F
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk