| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 03:30PM +0200 > You have already established that what /you/ personally expect is a > different thing from what languages, compilers and tools document that > they do, ... No, because of what I said you can rely on this. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 03:31PM +0200 >> It's not specified how I described it, but it's expected that >> the containers _indirectly_ allocate via malloc() so that the > Maybe you expect that, but not anyone who actually understands C++. That's not a matter of how C++ is defined but how its actually imple- mented. As many people expect the whole memory-allocatoin to be replaceable via exchanging malloc() and free() the major C++-runtimes are all implemented in that way. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 03:34PM +0200 > overloads of delete which open the possibility of having more efficient > memory allocation systems than traditional malloc/free as the heap no > longer has to track the sizes of the allocated objects. .. There aren't no such special implementations since the allocations only have to adhere to maxalign_t. > of the memory actually allocated (since it knows all the details of the > heap implementation), and make that available to other implementation > code such as the C++ container library. malloc() has to be replaceable - that's what a lot of developers expect because they want to exchange the memory-allocators to faster implemen- tations. Because of that the major C++ runtimes are all built on top of malloc(). |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 03:43PM +0200 >> Extremely unlikely. > Whether it is unlikely or not, it's perfectly doable. A lot of people expect the C++-container indirectly base on malloc() to have replaceable memory-allocation to install a faster allocator like mimalloc. Therefore it's the most realistic assumption to say that everything in the standard-library indirectly bases on malloc(). |
| Sam <sam@email-scan.com>: Jun 12 06:43PM -0400 Bonita Montero writes: > imple- mented. As many people expect the whole memory-allocatoin > to be replaceable via exchanging malloc() and free() the major > C++-runtimes are all implemented in that way. What "many people expect" is immaterial. As long as an implementation is in compliance with the C++ standard, if it goes against their expectations, well, too bad so sad. |
| Sam <sam@email-scan.com>: Jun 12 06:59PM -0400 Bonita Montero writes: > to have replaceable memory-allocation to install a faster allocator > like mimalloc. Therefore it's the most realistic assumption to say > that everything in the standard-library indirectly bases on malloc(). Once more: what "people expect" is immaterial. As long as a particular implementation is in compliance with the C++ standard, then that's the end of it. And I'm afraid that is not the case. The C++ standard explicitly states that it does not specify whether operator new uses malloc. # 17.6.2.1 Single-object forms [new.delete.single] # # [[nodiscard]] void* operator new(std::size_t size); # # [[nodiscard]] void* operator new(std::size_t size, std::align_val_t alignment); # # … # # Whether the attempt involves a call to the C standard library functions # malloc or aligned_alloc is unspecified. The C++ standard authoritatively asserts that it's unspecified whether new is implemented in terms of malloc. Too bad if someone's expectations were otherwise. Now, I don't actually see what that has to do with the original proposition of std::vector::reserve()'s optimization, but since (for some odd reason) you chose to sidetrack into your expectations of new's behavior, I have to set the record straight: The C++ standard does not require that operator new must be implemented in terms of malloc. Feel free to "expect" otherwise. Your expectations may not be realized, unfortunately. The End. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 12 02:41PM -0700 On 6/11/2021 4:03 AM, Paavo Helde wrote: > user, it can send an event to the main thread queue containing the > message. The main thread would check in a MFC OnIdle() function if there > are any events in the queue, and process them in the main thread. Oh I missed the MFC usage. Actually used it a couple of times in the early to mid 90's. Hummm, well, for a multi_producer-to-single_consumer relationship, if one can get over a LIFO order, this construction might be of use to the OP: https://groups.google.com/g/comp.lang.c++/c/1gppAtQpIQk/m/XX8-VDoMBgAJ One can also reverse the LIFO to get a FIFO. |
| olcott <NoOne@NoWhere.com>: Jun 12 04:30PM -0500 On 5/23/2021 9:59 AM, Kaz Kylheku wrote: > diagonal consists of incorrect answers or non-halting. Since for every > decider there is a diagonal entry, every decider is associated with a > test case it does not handle. void P(u32 x) { u32 Input_Halts = H(x, x); if (Input_Halts) HERE: goto HERE; } int main() { H((u32)P, (u32)P); } https://en.wikipedia.org/wiki/Halting_problem#Sketch_of_proof Now that I have studied the diagonalization method much more thoroughly I can say that its error is that is assuming that H must return a value to P. It fails to consider this possibility: (1) The simulating halt decider H aborts the simulation of its input P before ever returning any value to P. (2) It does this on the the basis that P is calling H in infinite recursion. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Manfred <noname@add.invalid>: Jun 12 08:06PM +0200 On 6/11/2021 7:55 PM, SIMON wrote: >> myStack.emplace(30); > It does the same thing as far as I can see but surely there must be > something that I don't know about these two methods. push() takes a reference to an object that has already been constructed, and pushes it on the stack. This operation involves a copy or move operation. emplace() constructs the object on the stack in-place, using the arguments supplied. This can save a copy or move operation. For 'int' there is no difference. Scott gave you a good reference for the details. |
| Kli-Kla-Klawitter <kliklaklawitter69@gmail.com>: Jun 12 08:12PM +0200 > For 'int' there is no difference. The external storage of an int could be moved. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment