- Why does vector::reserve() not grow exponentially ? - 25 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 04:09AM +0200 > implements an extended interface that's supported by the library and > then use it, if it exists. Otherwise the container template will use > only the standard-specified interface. Extremely unlikely. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 04:10AM +0200 Extremely unlikely that there's a specializartion for std::allocator and a specific std::allocator has that behaviour without exposing it to other users. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 04:11AM +0200 > // use special knowledge > else > // fall-back for user defined allocator Extremly unlikely that such a container-behaviour exists. |
| "Öö Tiib" <ootiib@hot.ee>: Jun 11 10:18PM -0700 On Saturday, 12 June 2021 at 05:10:48 UTC+3, Bonita Montero wrote: > Extremely unlikely that there's a specializartion for std::allocator > and a specific std::allocator has that behaviour without exposing it > to other users. But no one discussed what there exists? How it is argument what the libraries implement? The C++ standard is not meant to be reactive to what libraries implement. It is specification that tries to be visionary and so to allow things that (people keep telling to you) are possible and potentially profitable. So stop arguing with what no one has claimed, and better go fix your garbage code that trashed its performance with misuse of features that you do not understand like reserve and/or shrink_to_fit. Do not use features that you do not understand. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 08:18AM +0200 > to what libraries implement. It is specification that tries to be visionary > and so to allow things that (people keep telling to you) are possible > and potentially profitable. C++ standard-libraries are designed that they indirectly use malloc(). That's while you can replace malloc and change all the allocations in you program. Having such a special allocator that returns the size actually allocated would break that. |
| "Öö Tiib" <ootiib@hot.ee>: Jun 12 01:43AM -0700 On Saturday, 12 June 2021 at 09:18:20 UTC+3, Bonita Montero wrote: > That's while you can replace malloc and change all the allocations in > you program. Having such a special allocator that returns the size > actually allocated would break that. You seem like neither reading what others write nor knowing what you talk about. In what implementation and what calls malloc? Can't it (that what) be replaced globally by programmer? Where did anyone suggest to return size? What it was that was supposed to return size? |
| Bo Persson <bo@bo-persson.se>: Jun 12 10:51AM +0200 On 2021-06-12 at 08:18, Bonita Montero wrote: > That's while you can replace malloc and change all the allocations in > you program. Having such a special allocator that returns the size > actually allocated would break that. Not really. It is true that std::allocator has to use operator new, but this is what the standard says about that operator: "Executes a loop: Within the loop, the function first attempts to allocate the requested storage. Whether the attempt involves a call to the C standard library functions malloc or aligned_alloc is unspecified." http://eel.is/c++draft/new.delete#single-4.1 |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 11:00AM +0200 > You seem like neither reading what others write nor knowing what you > talk about. ... I said that it "indirectly" calls malloc. It calls it via std::allocator. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 11:03AM +0200 > "Executes a loop: Within the loop, the function first attempts to > allocate the requested storage. Whether the attempt involves a call to > the C standard library functions malloc or aligned_alloc is unspecified." Can't you read, moron ? I said that it "indirectly calls malloc", i.e. everything is built on top of malloc(). I.e. new calls malloc, std::allocator<> calls new and the container calls std:allocator. That's what the user expects because in this way you could replace the whole C++ memory-alloction by replacing malloc() like a few memory-allocators like mimalloc, jemalloc, tcmallog e.g. do it. |
| "Öö Tiib" <ootiib@hot.ee>: Jun 12 02:04AM -0700 On Saturday, 12 June 2021 at 12:00:25 UTC+3, Bonita Montero wrote: > > talk about. ... > I said that it "indirectly" calls malloc. > It calls it via std::allocator. What is it? Where and when is std::allocator required to call what? You continue not knowing what you talk about. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 11:15AM +0200 >> It calls it via std::allocator. > What is it? Where and when is std::allocator required to call what? > You continue not knowing what you talk about. std::allocator isn't required to do that, but at last everyone expects it to call malloc() in some way; it doesn't matter if it does this via new or directly. This is to meet the expectations that the memory-allo-ocator is globally replaceable. |
| "Öö Tiib" <ootiib@hot.ee>: Jun 12 02:24AM -0700 On Saturday, 12 June 2021 at 12:15:53 UTC+3, Bonita Montero wrote: > it to call malloc() in some way; it doesn't matter if it does this via > new or directly. This is to meet the expectations that the > memory-allo-ocator is globally replaceable. Continuing to prove that you do not know what you talk about? The std::allocator::allocate is required to get the memory from operator new that programmer can globally replace. And it is specially said in standard that it is unspecified when and how operator new is called for acquiring that memory. AFAIK libc++ even uses that freedom. But default operator new may call HeapAlloc() of Windows if it so wants, that is no way regulated. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 11:30AM +0200 > But default operator new may call HeapAlloc() of > Windows if it so wants, that is no way regulated. It's not specified how I described it, but it's expected that the containers _indirectly_ allocate via malloc() so that the memory-manamgement is replaceable. There are a lot of malloc() -replacemnt like jemalloc, mimalloc, Hoard, tcmalloc or what- ever and to work with these a standard-libary has to work in that way I described - there are a lot of people that expect that so that the writers of the standard-libaries imeplement them in an expectable behaviour. |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Jun 12 12:59PM +0200 On 12 Jun 2021 11:30, Bonita Montero wrote: > that way I described - there are a lot of people that expect > that so that the writers of the standard-libaries imeplement > them in an expectable behaviour. C and C++ are two different languages. - Alf |
| Bo Persson <bo@bo-persson.se>: Jun 12 01:07PM +0200 On 2021-06-12 at 11:03, Bonita Montero wrote: > That's what the user expects because in this way you could replace > the whole C++ memory-alloction by replacing malloc() like a few > memory-allocators like mimalloc, jemalloc, tcmallog e.g. do it. So where does the standard say that "involves a call" only means a direct call? And that an indirect call is still required even when a direct call is not? |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 01:19PM +0200 >> that so that the writers of the standard-libaries imeplement >> them in an expectable behaviour. > C and C++ are two different languages. But a lot of people still expect that C++ memory-allocation indirectly bases on malloc() and is thereby replaceable. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 01:22PM +0200 > So where does the standard say that "involves a call" only means a > direct call? And that an indirect call is still required even when a > direct call is not? The standard doesn't guarantee that, but the standard libary implemen- tors don't use sth. different than indirectly malloc() to make the whole memory-allocation of the code replaceable. If a sandard libary wouldn't be implemented in that way mimalloc, jemalloc, tcmalloc, Hoard ... woudln't work. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 01:27PM +0200 > C and C++ are two different languages. And this isn't absolutely true since most about 95% of the things you can do in C you can do also in C++. And it is very common to use C-code from C++-code with small adaptions. |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Jun 12 01:30PM +0200 On 12 Jun 2021 13:19, Bonita Montero wrote: >> C and C++ are two different languages. > But a lot of people still expect that C++ memory-allocation indirectly > bases on malloc() and is thereby replaceable. Yes, maybe they do. I expected that somewhere in the late 1990's, after I'd started working as a consultant. I'd inadvertently used `free` to deallocate something POD-ish allocated with `new`, it worked, and when someone remarked on it I argued about the same as you do now. I was ashamed when I, much later, understood that I was in the wrong, entirely wrong, that it was not just a formal rule or convention I'd broken. In my defense, I learned C++ from Bjarne's original "The C++ Programming Language", and things were very much more C-ish at that time. - Alf |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 01:39PM +0200 > I'd started working as a consultant. I'd inadvertently used `free` to > deallocate something POD-ish allocated with `new`, it worked, and when > someone remarked on it I argued about the same as you do now. ... That's not what I meant. |
| David Brown <david.brown@hesbynett.no>: Jun 12 02:01PM +0200 On 12/06/2021 11:24, Öö Tiib wrote: > called for acquiring that memory. AFAIK libc++ even uses that > freedom. But default operator new may call HeapAlloc() of > Windows if it so wants, that is no way regulated. And there is, of course, no requirement that things end up as a call to "malloc" here. In particular, since C++14 (IIRC) there are sized 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. (That has always struck me as a poorly considered aspect of C's malloc/free, leading to significant inefficiencies.) And even if Bonita was right that everything ends up in a call to malloc, she would /still/ be wrong. Malloc is part of the implementation - the implementation can have a way to find out the size 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. |
| David Brown <david.brown@hesbynett.no>: Jun 12 02:04PM +0200 On 12/06/2021 13:19, Bonita Montero wrote: >> C and C++ are two different languages. > But a lot of people still expect that C++ memory-allocation indirectly > bases on malloc() and is thereby replaceable. You have already established that what /you/ personally expect is a different thing from what languages, compilers and tools document that they do, and what other programmers expect. This is just another one of your unjustified assumptions based on nothing but your own lack of imagination and inability or unwillingness to learn how C++ and the tools are actually specified. |
| Sam <sam@email-scan.com>: Jun 12 08:50AM -0400 Bonita Montero writes: >> use it, if it exists. Otherwise the container template will use only the >> standard-specified interface. > Extremely unlikely. Whether it is unlikely or not, it's perfectly doable. |
| Sam <sam@email-scan.com>: Jun 12 08:52AM -0400 Bonita Montero writes: > That's while you can replace malloc and change all the allocations in > you program. Having such a special allocator that returns the size > actually allocated would break that. I just explained how this can be done. Nobody has to replace malloc. Just because you are incapable of wrapping your brain around this concept doesn't mean that it cannot be done. |
| Sam <sam@email-scan.com>: Jun 12 08:53AM -0400 Bonita Montero writes: >> Windows if it so wants, that is no way regulated. > 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++. |
| 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