Subject: Re: [boost] [function] function wrappingwithnoexceptionsafetyguarantee
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-11-13 14:45:13
On 11/13/2010 10:39 AM, Daniel Walker wrote:
> On Mon, Nov 8, 2010 at 7:24 PM, Domagoj Saric<dsaritz_at_[hidden]> wrote:
>> "Daniel Walker"<daniel.j.walker_at_[hidden]> wrote in message
>>> On Tue, Nov 2, 2010 at 7:20 PM, Jeffrey Lee Hellrung, Jr.
>>> <jhellrung_at_[hidden]> wrote:
>>>> Would it also be appropriate to measure the "space/call", in addition to
>>>> "time/call" and "space/type"? Or is there no difference, or had this
>>>> addressed already?
>>> Well, a call to boost::function does not cost any additional space.
>> How (or better, why) can you possibly claim something as plainly false as
>> That this is false is obvious to anyone just following the discussion (and
>> all the talk about the redundant if empty then throw logic/code) not to
>> mention to someone that actually poked around the source code or even looked
>> at the generated code....
> boost::function allocates space when it is instantiated and assigned
> (e.g. line 580 of function_template.hpp), but not during a call to
> boost::function. Perhaps, you are referring to stack allocation? Yes,
> a call to boost::function could result in the stack growing, but that
> wasn't the question. If you are referring to the memory in the text
> section of the executable used to define operator() itself, yes,
> that's obvious, this is another space expense per type, but that
> wasn't the question. If you are aware of some other memory which is
> consumed during a call to boost::function, could you please be
> specific and include line numbers?
Actually, my original question was regarding space/call, with "space"
referring to the same thing as your "space/type", i.e., space in the
executable (in this case, the text segment). I believe I clarified this
in a later post (no link handy). Sorry, I thought the context of the
question made the terminology unambiguous.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk