Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
get_temporary_buffer synopsis
95 views
Skip to first unread message
Krzysztof Żelechowski
Mar 4, 2012, 5:24:57 PM3/4/12
to
Why does get_temporary_buffer take a signed argument for size?
Why is return_temporary_buffer so awkwardly named? The usual connotation
for "return" is to provide something, not to release something.
Why is there no exception-safe handler for temporary buffers?
--
[ comp.std.c++ is moderated. To submit articles, try posting with your ]
[ newsreader. If that fails, use mailto:std-cpp...@vandevoorde.com ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Why is return_temporary_buffer so awkwardly named? The usual connotation
for "return" is to provide something, not to release something.
Why is there no exception-safe handler for temporary buffers?
--
[ comp.std.c++ is moderated. To submit articles, try posting with your ]
[ newsreader. If that fails, use mailto:std-cpp...@vandevoorde.com ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Daniel Krügler
Mar 6, 2012, 11:50:43 AM3/6/12
to
On 2012-03-04 23:24, Krzysztof Żelechowski wrote:
> Why does get_temporary_buffer take a signed argument for size?
> Why is return_temporary_buffer so awkwardly named? The usual connotation
> for "return" is to provide something, not to release something.
> Why is there no exception-safe handler for temporary buffers?
The "temporary buffer" API is one example of interface, that presumably
> Why does get_temporary_buffer take a signed argument for size?
> Why is return_temporary_buffer so awkwardly named? The usual connotation
> for "return" is to provide something, not to release something.
> Why is there no exception-safe handler for temporary buffers?
should never have been standardized. It was part of the original HP
library and the basic idea was that it should allow implementations to
provide a very low-level wrapper to get access to some memory that can
be accessed without need to actually increase the currently reserved
heap memory buffer e.g. of malloc. Such small memory buckets can be very
useful for some algorithms that can get a significant performance win if
such a buffer is available. The experiment failed, because no vendor did
anything else but call malloc here, so the advantages of the interface
did only exist theoretically. In addition, the usage requires very
careful programming on the user-side. There exists the suggestion to
deprecate the temporary buffer API for the next standard revision, in
this case there would not be much need for providing further fixes to
the broken API.
HTH& Greetings from Bremen,
Daniel Krügler
Krzysztof Żelechowski
Mar 15, 2012, 9:37:20 PM3/15/12
to
Daniel Krügler wrote:
> On 2012-03-04 23:24, Krzysztof Żelechowski wrote:
>> Why does get_temporary_buffer take a signed argument for size?
>> Why is return_temporary_buffer so awkwardly named? The usual
>> connotation for "return" is to provide something, not to release
>> something. Why is there no exception-safe handler for temporary buffers?
>
> The "temporary buffer" API is one example of interface, that presumably
> should never have been standardized. It was part of the original HP
> library and the basic idea was that it should allow implementations to
> provide a very low-level wrapper to get access to some memory that can
> be accessed without need to actually increase the currently reserved
> heap memory buffer e.g. of malloc. Such small memory buckets can be very
> useful for some algorithms that can get a significant performance win if
> such a buffer is available. The experiment failed, because no vendor did
Isn’t it an advantage to skip the default initialisation for POD types? (Of
> On 2012-03-04 23:24, Krzysztof Żelechowski wrote:
>> Why does get_temporary_buffer take a signed argument for size?
>> Why is return_temporary_buffer so awkwardly named? The usual
>> connotation for "return" is to provide something, not to release
>> something. Why is there no exception-safe handler for temporary buffers?
>
> The "temporary buffer" API is one example of interface, that presumably
> should never have been standardized. It was part of the original HP
> library and the basic idea was that it should allow implementations to
> provide a very low-level wrapper to get access to some memory that can
> be accessed without need to actually increase the currently reserved
> heap memory buffer e.g. of malloc. Such small memory buckets can be very
> useful for some algorithms that can get a significant performance win if
> such a buffer is available. The experiment failed, because no vendor did
course, it is then on the programmer not to access unassigned data, but
still?)
> anything else but call malloc here, so the advantages of the interface
> did only exist theoretically. In addition, the usage requires very
> careful programming on the user-side. There exists the suggestion to
> deprecate the temporary buffer API for the next standard revision, in
> this case there would not be much need for providing further fixes to
> the broken API.
incomplete.
Chris
0 new messages