>
> Another point (raised in the past by Nial and others) is to recommend that
> C++ "standard" APIs (such as those provided through "std::"):
> * Prefer APIs that accept memory as-passed-in by the caller, rather than
> rely upon internal allocation semantics, or reliance upon allocators.
> By defining APIs that demanded already-allocated-memory as parameters, we
> could:
> (a) better control latency (e.g., the implementation does not even attempt
> an allocator-call with possibly variable-length duration)
> (b) better leverage hardware-specific resources (e.g., hardware-specific
> APIs are leveraged external to the "std::" implementation)


I second this strongly, and have been wanting this for years in different
real-time and low-latency contexts. (i.e. real-time robotics control and
low-latency financial software.)

Related to this is: how the API should respond when passed in memory is
exceeded should ideally be deferred to the consumer of the library.

For example, if a string concatenation operation would exceed the passed-in
buffer size, then whether it should truncate the string, indicate an error
(and how it does that), or do something else should nominally be specified
by the user of the string.

Currently, I believe std::string will generally try to allocate more memory
or error out if it can't allocate, where in many contexts truncation is
sufficient, so I believe supporting this user-defined response behavior is
an important part of supporting allowing the user to pass in external
memory.

(I am working on a paper describing this issue of what should be considered
an error and error handling, and how languages and libraries should in
general support them. Short version: defer whether any low-level condition
is considered an error to the high-level application wherever possible.)

I've ended up recreating API's like std::list and std::string to get this
behavior, and it seems like a shame that the main API in std:: couldn't be
leveraged to get this on top of an "even more arbitrary" buffer (i.e. one
from the local call stack, supplied by the user) than it already allows
(i.e. via allocators).

Derek


On Wed, May 12, 2021 at 10:56 AM charleyb123 via SG14 <sg14_at_[hidden]>
wrote:

> On Wed, May 12, 2021 at 8:48 AM Michael Wong via SG14 <
> sg14_at_[hidden]> wrote:
>
>> As of the Apr 2021 discussion on low latency general brainstorming
>> chaired by Staffan TjernstrÃm , captured in notes here:
>> https://lists.isocpp.org/sg14/2021/04/0616.php
>>
>> This is a summary of that discussion aiming to elicit more refinement,
>> leading to possible features:
>>
>> 1. - issues/problems of the domain in C++
>> 1. need to access hardware features, memory card, I/O controller,
>> DMA, is low latency an upper bound or determinism
>> 2. competing with some OS services but not served by all OS
>> 3. C++ can offer standard APIs to query for facility
>> 2. - Features/proposals for C++
>> 1. thread priorities
>> 2. cache-control
>> 3. scheduling periodic thread intervals or by the deadline
>> 4. CPU pinning like madvise
>> 5. manage memory-mapped files
>> 6. Vulkan-like capability model that fits specific hardware
>> 7. enforce the real-time constraint on a call path or trap at
>> runtime if unable to satisfy
>>
>> Please feel free to add to this discussion with more issues/proposals,
>> and more details with possible proposals.
>>
>
> Another point (raised in the past by Nial and others) is to recommend that
> C++ "standard" APIs (such as those provided through "std::"):
>
> * Prefer APIs that accept memory as-passed-in by the caller, rather than
> rely upon internal allocation semantics, or reliance upon allocators.
>
> By defining APIs that demanded already-allocated-memory as parameters, we
> could:
>
> (a) better control latency (e.g., the implementation does not even attempt
> an allocator-call with possibly variable-length duration)
> (b) better leverage hardware-specific resources (e.g., hardware-specific
> APIs are leveraged external to the "std::" implementation)
>
> --charley
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>