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@lists.isocpp.org> wrote:
On Wed, May 12, 2021 at 8:48 AM Michael Wong via SG14 <sg14@lists.isocpp.org> wrote:
As of the Apr 2021 discussion on low latency general brainstorming chaired by  Staffan TjernstrÃm  , captured in notes here: 

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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14