- Why does vector::reserve() not grow exponentially ? - 10 Updates
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 16 04:25PM -0700 >>> As usual, you are wrong. It's quite common in some circles. ... >> It's quite stupid to do that. > No, it is quite reasonable to follow the C++ standard. Is it quite reasonable to argue with Bonita? (I only see reponses to Bonita, not Bonita's own posts.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Sam <sam@email-scan.com>: Jun 16 11:17PM -0400 Keith Thompson writes: > > No, it is quite reasonable to follow the C++ standard. > Is it quite reasonable to argue with Bonita? (I only see reponses to > Bonita, not Bonita's own posts.) Who's arguing? Nobody's having an argument here. Just a friendly chit-chat. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 17 07:11AM +0200 >> It's quite stupid to do that. > No, it is quite reasonable to follow the C++ standard. There are some reasonable assumptions about things which aren't specified in the standard. |
| Juha Nieminen <nospam@thanks.invalid>: Jun 17 05:35AM > and so I'm stuck in C++14. My condolences. |
| David Brown <david.brown@hesbynett.no>: Jun 17 09:22AM +0200 On 17/06/2021 05:17, Sam wrote: >> Is it quite reasonable to argue with Bonita? (I only see reponses to >> Bonita, not Bonita's own posts.) > Who's arguing? Nobody's having an argument here. Just a friendly chit-chat. It's like a pantomime. The two of you are going round in circles. We all know what the C++ standards say about allocators here, and that they specifically say there is no requirement that malloc be involved in global allocators. We all know that library implementations can make use of extra knowledge about the implementation, in a way that user code cannot (at least not while remaining portable and avoiding undocumented and unspecified behaviour). We all know there is nothing in the C++ standards or documentation to suggest that you can "replace malloc" and assume that will change the global allocator. We all know that even if there were such a guarantee, it /still/ would not stop an implementation from being able to use additional knowledge about its own malloc when that is being used. I suspect that deep down, Bonita knows it too. Please leave it at that, unless there is actually any new information. This "Oh, no, you can't", "Oh, yes, you can" silliness just annoys people. Bonita is fanatically ignorant. The more you show she is wrong, the more she will dig in and insist that she is right. You cannot convince her - all you can do is make sure that no one else is fooled by her misconceptions, and you've done that already. That was complete dozens of posts ago. It's time to move on. |
| MrSpook_e0mt@hszpo62mi.com: Jun 17 08:31AM On Thu, 17 Jun 2021 09:22:19 +0200 >On 17/06/2021 05:17, Sam wrote: >> Who's arguing? Nobody's having an argument here. Just a friendly chit-chat. >It's like a pantomime. Oh no it isn't! I'll get my coat... |
| Sam <sam@email-scan.com>: Jun 17 09:24AM -0400 Bonita Montero writes: >> No, it is quite reasonable to follow the C++ standard. > There are some reasonable assumptions about things which aren't > specified in the standard. That's only a matter of someone's personal opinion. Others opinions is that it is completely unreasonable. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 17 04:43PM +0200 That's not an opinion but a reliable fact that all C++ standard -libaries actually use malloc() indirectly to make the whole memory-allocation replaceable. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Jun 17 01:45PM -0700 On Wednesday, June 16, 2021 at 4:35:59 AM UTC-4, David Brown wrote: > As soon as ... reflection and metaclasses make it to the > language, I'll be using them too. "As soon as" probably means C++ 2026. And in the meantime, while other languages such as rust see the emergence of a rich library ecosystem, C++ remains comparatively impoverished because of the absence of standard types - no int128, no uint128, no float128, no big_decimal, no big_int, no unicode encoding validators or converters ... And consequently, no comprehensive CBOR or BSON or SQL libraries that map to standard types, no JSON or XML libraries that don't reimplement unicode encoding validation and conversion ... Daniel |
| Real Troll <real.troll@trolls.com>: Jun 17 09:15PM > "As soon as" probably means C++ 2026. > C++ remains comparatively > impoverished because of the absence of standard types In fact C++ remains impoverished because of its bureaucratic process of approving anything to be part of the standard!. When C# had such a body, nothing was achieved and so Microsoft decided to go it alone and now it has become one of the best programming languages. It has a standard called ECMA-334 <https://www.ecma-international.org/publications-and-standards/standards/ecma-334/> but It is not as bureaucratic as ISO or some other standard bodies. I think even Suter and Bjarne Stroustrup have given up on the body currently in-charge of the C++ Standards. Its become a laughing stock of dedicated programmers around the world who have started writing their own standards based on what C++ does but also what other languages are doing. |
| 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