headers
Joel de Guzman | 1 Oct 2007 01:35
Picon
Favicon

Re: Runtime Dynamic Dispatch Library (0.2)

Dean Michael Berris wrote:

> So the only alternative really (or at least the one I see that doesn't
> run into the forwarding problem) is the linear inheritance approach
> I've been mentioning. Now getting towards implementing that approach
> is another discussion and effort in itself -- one I'm still mulling
> around if it's even worth pursuing, given the cases I intend to cover
> with the dispatcher. If at all possible, even an enhancement to
> Boost.Function might be handy which will allow it to contain function
> pointers to multiple signatures -- but I'm not that ambitious (yet) to
> try and hack at Boost.Function to enable multiple signature support
> and compile-time dispatching based on argument type lookup.

I think I've mentioned that I have such a "overloads" library
extension in my HD somewhere. At one point, I asked Doug on
the possibility of adding it to boost.function and he expressed
his interest. Of course that means documentation and stuff.
I'll try to see if I can squeeze some time to get this into
completion. At any rate, I can post the code sans docs.

Regards,
--

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 76 comments |
headers
Tobias Schwinger | 1 Oct 2007 02:08
Favicon

Re: [review] Review of Exception begins today

Emil Dotchevski wrote:
>> I'm not keen on the use of operator<< to add the data to the exceptions.
> 
> I do share your concern, but consider that whatever we use for boost
> exception should support easy composition, because it needs to work
> when used in a throw expression directly:
> 
> throw my_error() <<
>     error_info<tag_errno>(errno) <<
>     error_info<tag_name>(name);
> 
> Instead of << we could use .add:
> 
> throw my_error().
>     add(error_info<tag_errno>(errno)).
>     add(error_info<tag_name>(name));
> 
> This isn't bad, but in my opinion the << syntax is better despite my
> strong dislike for operator overloading.

Maybe a more or less obvious choice will do

    throw my_error() = error_info<tag>(whatever),
        error_info<another_tag>(something_else) // ...

Regards,

Tobias Schwinger
- Review Manager -
(Continue reading)

Permalink | Reply | 6 comments |
headers
Emil Dotchevski | 1 Oct 2007 02:23

Re: [review] Review of Boost.Exception

> > <snip>
> > Sure, there are use cases when you know an error_info must be present
> > in the exception or you have a bug, but in that case it makes more
> > sense to assert on get_error_info.
> >
>
> Far from it. I'm thinking get_error_info(T const &) should not compile
> if the error_info being requested has not been passed to the
> exception.

I don't think this is possible. Consider that a main design goal of
boost::exception is to be able to do this:

try
{
    ---something---
}
catch( boost::exception & x )
{
    x << error_info<my_info>(....);
    throw;
}

In general, when we finally catch the exception object, it may have
my_info or not.

> At any rate, perhaps using something like Boost.Optional as the return
> value (or an additional parameter to get_error_info) mitigates the
> problem you describe. Somehow, for me the following reads a bit more
> coherent if not safer:
(Continue reading)

Permalink | Reply | 10 comments |
headers
Joel de Guzman | 1 Oct 2007 02:25
Picon
Favicon

Dynamic Overloads [ was Re: Runtime Dynamic Dispatch Library (0.2)]

Joel de Guzman wrote:
> Dean Michael Berris wrote:
> 
>> So the only alternative really (or at least the one I see that doesn't
>> run into the forwarding problem) is the linear inheritance approach
>> I've been mentioning. Now getting towards implementing that approach
>> is another discussion and effort in itself -- one I'm still mulling
>> around if it's even worth pursuing, given the cases I intend to cover
>> with the dispatcher. If at all possible, even an enhancement to
>> Boost.Function might be handy which will allow it to contain function
>> pointers to multiple signatures -- but I'm not that ambitious (yet) to
>> try and hack at Boost.Function to enable multiple signature support
>> and compile-time dispatching based on argument type lookup.
> 
> I think I've mentioned that I have such a "overloads" library
> extension in my HD somewhere. At one point, I asked Doug on
> the possibility of adding it to boost.function and he expressed
> his interest. Of course that means documentation and stuff.
> I'll try to see if I can squeeze some time to get this into
> completion. At any rate, I can post the code sans docs.

[CC'ing Doug]

Ok, here's the proof of concept:

     http://spirit.sourceforge.net/dl_more/overload/

Here's the original text I sent Doug:

Boost.function is a very useful library for wrapping function
(Continue reading)

Permalink | Reply | 75 comments |
headers
Emil Dotchevski | 1 Oct 2007 02:36

Re: [review] Review of Exception begins today

> >> I'm not keen on the use of operator<< to add the data to the exceptions.
> >
> > I do share your concern, but consider that whatever we use for boost
> > exception should support easy composition, because it needs to work
> > when used in a throw expression directly:
> >
> > throw my_error() <<
> >     error_info<tag_errno>(errno) <<
> >     error_info<tag_name>(name);
> >
> > Instead of << we could use .add:
> >
> > throw my_error().
> >     add(error_info<tag_errno>(errno)).
> >     add(error_info<tag_name>(name));
> >
> > This isn't bad, but in my opinion the << syntax is better despite my
> > strong dislike for operator overloading.
>
> Maybe a more or less obvious choice will do
>
>     throw my_error() = error_info<tag>(whatever),
>         error_info<another_tag>(something_else) // ...

I don't know, I'd rather use .add(), to be honest.

Also, in an off-list discussion, Peter Dimov pointed out that instead
of layering .add calls directly in the throw expression, we could
write:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Schwinger | 1 Oct 2007 02:34
Favicon

Re: boost::exception questions

Emil Dotchevski wrote:
> On 9/30/07, Tom Brinkman <reportbase <at> gmail.com> wrote:
>>> 3) Support for linking multiple error tags in a single expression
>>> might be useful and help in standarizing errors throughout an application.
>>>
>>> throw boost:::exception() <<
>>> boost::error_info<tag_errorno,tag_filename,tag_size,tag_width>(
>>> (1,"output.txt",100,200);
>>>> Could you clarify what you mean?
>> Well, I could do something like this:
>>
>> typedef boost::error_info<tag_errorno,
>>      tag_filename,tag_size,tag_width> error_t;
>>
>> throw error_t(1,"output.txt",100,200);
> 
> You probably mean:
> 
> throw my_error() << error_t(1,"output.txt",100,200);
> 
> In my opinion what you're describing is better accomplished like this:
> 

<snip lot's of code>

It's not at all obvious why using that much boilerplate is better.

> I think it is a mistake to standardize globally on the info you want
> to stuff into the exception at the time of the throw. What if you
> detect an error condition that matches the my_error semantics
(Continue reading)

Permalink | Reply | 24 comments |
headers
Tobias Schwinger | 1 Oct 2007 02:38
Favicon

Re: [review] Review of Exception begins today

Tobias Schwinger wrote:
> Emil Dotchevski wrote:
>>> I'm not keen on the use of operator<< to add the data to the exceptions.
>> I do share your concern, but consider that whatever we use for boost
>> exception should support easy composition, because it needs to work
>> when used in a throw expression directly:
>>
>> throw my_error() <<
>>     error_info<tag_errno>(errno) <<
>>     error_info<tag_name>(name);
>>
>> Instead of << we could use .add:
>>
>> throw my_error().
>>     add(error_info<tag_errno>(errno)).
>>     add(error_info<tag_name>(name));
>>
>> This isn't bad, but in my opinion the << syntax is better despite my
>> strong dislike for operator overloading.
> 
> Maybe a more or less obvious choice will do
> 
>     throw my_error() = error_info<tag>(whatever),
>         error_info<another_tag>(something_else) // ...
> 

Forgot to say: See Boost.Assign.

Making 'add' a function template might be another alternative:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Emil Dotchevski | 1 Oct 2007 02:57

Re: [review] Review of Exception begins today

> <snip>
> Making 'add' a function template might be another alternative:
>
>      throw my_error()
>          .add<tag::errno>(errno)
>          .add<tag::name>(name)
>          // ...

Right, this syntax look better than my "add". If there is a consensus
that the operator<< overload should be removed, I'd be voting for the
syntax above.

Emil Dotchevski
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Felipe Magno de Almeida | 1 Oct 2007 02:59
Picon

Re: [review] Review of Boost.Exception

On 9/30/07, Emil Dotchevski <emil <at> revergestudios.com> wrote:
>

[snip]

> In the particular case of Boost Exception, any speed overhead it adds
> should be compared to the overhead of throwing an exception. You have
> stack unwinding and destructor calls, etc. anyway. I don't think that
> optimizing Boost Exception for speed makes any sense.

I agree with this.

> Optimizing the memory allocations made by Boost Exception when info is
> added to exception objects can not be dismissed as easily, but I would
> not call those allocations unnecessary. :)

But I believe that we should be able to allow not making any heap
allocation within some measure. Using a custom pre-allocated heap
should make *some* information to be held without any allocation.
Types that use heap on construction/copy-construction we don't have
much choice anyway.
It could be disabled/enabled and the size could be customized.

> Consider that all of these allocations happen immediately before or
> during stack unwinding, and at that time the rest of the code doesn't
> usually allocate memory. When the exception is finally handled, all
> this memory is reclaimed, and assuming that no other memory was
> allocated during the stack unwinding, we don't get fragmentation
> either.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Emil Dotchevski | 1 Oct 2007 03:55

Re: boost::exception questions

> <snip>
> I see. This feature is most valuable. However, so is Tom's suggestion
> and I don't think both are mutually exclusive (that is if we let go of
> using the template-id 'error_info' for the latter):
>
>      typedef boost::custom_exception<tag::
>          errno,tag::filename,tag::size> file_error;

Consider this code:

void read_file( char const * filename )
{
    something_unrelated();
    ....
    if( file_failure )
        throw file_error() << error_info<tag_filename>(filename);
}

If I understand correctly, you are concerned with making sure all
file_error exceptions pack a file_name.

But what if "something_unrelated" throws? Isn't the filename known to
our function relevant to that other failure too? It sure is, despite
that we have no idea what exceptions "something_unrelated" could
throw.

So, I'd write that function like this:

void read_file( char const * filename )
{
(Continue reading)

Permalink | Reply | 23 comments |

Gmane