My interpretation: add a library call for memory requests of at-least n bytes, putting the burden of look-ahead allocation on memory allocator implementers.
My opinion: terrible design decision. Advancing this idea to the memory allocator interface would open ways for strange performance differences based on compiler and CRTs, unpredictably so. The MSVC CRT has a long-standing approach of actually GROWING memory in-place, and if that fails going the new-allocation route. But no, don't you misunderstand it, it is not the same as the realloc function call, go research _expand from the MSVC CRT! The developer does get a boolean-feedback if the growing-inplace has succeeded or not, then he can issue a subsequent new-allocation with move-semantics to keep the C++ rules in-check! IMO this is a much better design idea but strange shit does find it's way into the C++ language sometimes anyway. Just like in every software it will take some time to temper and will fade out.
The developer should be poked to make a guess at how much he would need because HE CAN DO THE SMART MATH! Randomly guessing what the developer would need is a terrible fate. My guess is that those strange people that think allocation of 2^n blocks for encapsulation is best approach, those people are driving this addition to the language... I whole heartedly disagree.
How about actually taking ideas from MSVC for once, C++ committee???
Re: C++ Language Design (2021-09-15 21:20 by quiret #88044)
I wonder if the C++ concepts are meant to be friendship-boundary resistant. According to the C++20 friend statement description on cppreference.com, you cannot befriend a concept. But then there are concepts like this one:
According to that website, the std::constructible_from concept depends on the struct/class std::is_constructible_v but this struct is not friendship-boundary resistant. For example, you could have class A and B which are friends of each-other and B has its constructors private. If A where to query B if it can construct it using some parameters, std::is_constructible_v MUST return false because the struct or class has no access to B's constructors. But I wonder, since you cannot befriend concepts, this access denial should not happen by using std::constructible_from? The access check should be done against the location of where the concept is being used and not the point in the source where the concept was defined.
Re: C++ Language Design (2022-02-11 01:17 by quiret #88713)
I did post an argument about a design flaw of the C++ sizeof unary operator where requiring it to be a multiple of the type's alignment is not architecturally necessary. With this unnecessary requirement there come burden to both the memory footprint as well as the performance of programs. You can read about my argument here: