- Why does vector::reserve() not grow exponentially ? - 20 Updates
- [ #include <stack> ] What's the difference? - 2 Updates
- good reference on threads - 3 Updates
| Ian Collins <ian-news@hotmail.com>: Jun 13 01:01PM +1200 On 12/06/2021 21:24, Öö Tiib wrote: >> 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? You do realise that you are arguing with someone who can't even learn to quote? -- Ian. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 13 07:31AM +0200 > Once more: what "people expect" is immaterial. ... It's realistisc. Rest of your stupid stuff unread. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 13 07:31AM +0200 > What "many people expect" is immaterial. ... It's the most realistic assumption. |
| MrSpook_t0Y6kgpd5@3dryi7no.gov: Jun 13 08:39AM On Sat, 12 Jun 2021 18:59:38 -0400 >The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. >To open this message correctly you will need to install E-mail or Usenet >software that supports modern Internet standards. Or not. Anyway... >w =20 >is implemented in terms of malloc. Too bad if someone's expectations were =20 >otherwise. Hardly surprising given that C++ might us used on systems where malloc() doesn't exist. Some people forget there are more platforms in the programming world than just Windows or *nix. |
| Richard Damon <Richard@Damon-Family.org>: Jun 13 07:48AM -0400 On 6/13/21 1:31 AM, Bonita Montero wrote: >> What "many people expect" is immaterial. ... > It's the most realistic assumption. Maybe a reasonable assumption on many platforms, but an incorrect one, and one that can lead to hard to find bugs when it isn't true. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 13 02:03PM +0200 > Maybe a reasonable assumption on many platforms, but an incorrect > one, and one that can lead to hard to find bugs when it isn't true. No, this doesn't imply any possible bugs. |
| Sam <sam@email-scan.com>: Jun 13 08:09AM -0400 Bonita Montero writes: >> Once more: what "people expect" is immaterial. ... > It's realistisc. Realistically, people are also always going to whine when they relied on unspecified behavior, and their code breaks. Also realistically: nobody will care. > Rest of your stupid stuff unread. I believe you 100%, just like I believe that you will not read every character of this post. |
| Sam <sam@email-scan.com>: Jun 13 08:10AM -0400 Bonita Montero writes: >> What "many people expect" is immaterial. ... > It's the most realistic assumption. Has anyone happen to mention what happens when you assume, all the time? |
| Sam <sam@email-scan.com>: Jun 13 08:11AM -0400 Bonita Montero writes: >> Maybe a reasonable assumption on many platforms, but an incorrect >> one, and one that can lead to hard to find bugs when it isn't true. > No, this doesn't imply any possible bugs. Ok, you go ahead and write some code that depends on it, then wait when it breaks, inevitably, after a compiler/library upgrade, then get back to us. We'll figure out whether it's a bug, or not, at that time. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 13 02:12PM +0200 >> It's realistisc. > Realistically, people are also always going to whine when > they relied on unspecified behavior, and their code breaks. That's sth. totally different here and I told whether it's the most reasonable assumption: there are many people that expect their alloca- tions to be globally replaceable. Because of that C++ memory-allcoation also indiretly bases on malloc() in some way. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 13 02:12PM +0200 > Ok, you go ahead and write some code that depends on it, then wait when > it breaks, inevitably, after a compiler/library upgrade, then get back > to us. Tell me the bug when you install a malloc()-replacement ... |
| Sam <sam@email-scan.com>: Jun 13 09:50AM -0400 Bonita Montero writes: > reasonable assumption: there are many people that expect their alloca- > tions to be globally replaceable. Because of that C++ memory-allcoation > also indiretly bases on malloc() in some way. Those expectations are based on overriding operator new and delete. Both must be overridden, otherwise the behavior is unspecified. As I've documented: the C++ standard does not require operator new to use malloc. Therefore, if an application wants to use custom memory allocation and wants to be portable it must override both new and delete. If someone's expecting to be able to override only operator new, then use the default operator delete, then since the default operator delete is "expected" to use free, the overridden operator new has no choice but to use malloc too. Wonderful, but then what? What possible value-added can operator new, in addition to mallocing? There's nothing else to do. Perhaps one wants to override malloc in order to simply log memory allocations in order to detect leaks. But then you have no choice but to override operator delete and log it too. So, no matter which way you turn, any kind of "expectations" must override both. But then, whether new/delete uses malloc/free becomes a moot point, and the default implementation does not need to use it, because anyone woh overrides them will, by necessity, have to override both. And that's why you're wrong. You are welcome to prove me wrong by offering your own example of a practical override of operator new, and operator new only, and actually doing something useful, "expecting" that delete will simply call free. But you will probably just not read any of this, right? |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 13 04:05PM +0200 > As I've documented: the C++ standard does not require operator new to > use malloc. ... But that's what a lot of developers expect and because of that standard -libaries are implemented in that way. ... rest of your stupid stuff unread. |
| "Öö Tiib" <ootiib@hot.ee>: Jun 13 07:39AM -0700 On Sunday, 13 June 2021 at 04:02:14 UTC+3, Ian Collins wrote: > > Continuing to prove that you do not know what you talk about? > You do realise that you are arguing with someone who can't even learn to > quote? Oh, I knew it very well ... just as it was Saturday I answered to it but now it is degraded to typical pathetic snip and run. |
| Sam <sam@email-scan.com>: Jun 13 11:21AM -0400 Bonita Montero writes: >> Ok, you go ahead and write some code that depends on it, then wait when it >> breaks, inevitably, after a compiler/library upgrade, then get back to us. > Tell me the bug when you install a malloc()-replacement ... Who said that I want to replace malloc? Nobody's talking about replacing malloc, but replacing only operator new, and nothing else. |
| Sam <sam@email-scan.com>: Jun 13 11:23AM -0400 Bonita Montero writes: >> malloc. ... > But that's what a lot of developers expect and because of that standard > -libaries are implemented in that way. All the voices in your head does not translate to "a lot of developers". It's still only you. > ... rest of your stupid stuff unread. Did I call it, or what? # But you will probably just not read any of this, right? Damn, I'm good. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 13 06:55PM +0200 > Who said that I want to replace malloc? > Nobody's talking about replacing malloc, but replacing only operator > new, and nothing else. No, we're talking about replacing malloc() and thereby changing how C++-implementations allocate at last. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 13 06:56PM +0200 > All the voices in your head does not translate to "a lot of developers". > It's still only you. There are no good reasons to do it in a different way. |
| Sam <sam@email-scan.com>: Jun 13 01:37PM -0400 Bonita Montero writes: >> All the voices in your head does not translate to "a lot of developers". >> It's still only you. > There are no good reasons to do it in a different way. Just because you can't think of any doesn't mean there isn't. |
| Sam <sam@email-scan.com>: Jun 13 01:38PM -0400 Bonita Montero writes: >> and nothing else. > No, we're talking about replacing malloc() and thereby changing > how C++-implementations allocate at last. Noone is replacing malloc. It's still there. It's the operator new/delete that gets replaced with code that uses an alternative allocator that offer container-specific optimizations. |
| MrSpook_mlauoyv4F_@o18rpnvgrx0dq.co.uk: Jun 13 08:34AM On Sat, 12 Jun 2021 20:06:53 +0200 >> 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, One would hope that a modern compiler would optimise out the temporary however so there shouldn't actually be any difference between emplace() and push() in practice. |
| "Öö Tiib" <ootiib@hot.ee>: Jun 13 04:31AM -0700 > One would hope that a modern compiler would optimise out the temporary however > so there shouldn't actually be any difference between emplace() and push() > in practice. Take something bit less trivial than int (that is more common in practice): struct WordCount {std::string word; size_t count;}; I do not think there is any compiler that compiles equal code to emplace("blah", 1) and push(WordCount{"blah", 1}). Also I do not think there is way how conforming compiler can do it even in theory. By my understanding of standard the * When copy (or move) constructors and destructors do not have side effects (like it is with int) then those can be elided by as-if rule. * Copy (or move) elision is allowed during initialization of object with temporary. * It is mandatory since C++17 when temporary is used as return value (RVO). * It is allowed when automatic, named, non-volatile, non-function-parameter, non-catch-clause-parameter is used as return value (NRVO). * Rest of cases allowed are about constexpr, throws, catches and coroutines. Did I miss some? WordCount allocates and throws in constructor and is function parameter of push() so as-if rule does not work nor none of other cases when copy can be elided. |
| Cholo Lennon <chololennon@hotmail.com>: Jun 12 11:06PM -0300 On 6/11/21 12:03 AM, Lynn McGuire wrote: > I found "C++ Concurrency in Action, 2nd Edition" by Williams, Anthony. > Has anyone read this and found it to be a good education on threads ? > https://www.amazon.com/C-Concurrency-Action-Anthony-Williams/dp/1617294691/ I have the 1st version of that book, it's a very good one on the subject. AFAIK it is "the" book about C++ multi-threaded programming. Regards -- Cholo Lennon Bs.As. ARG |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 12 09:47PM -0700 >> https://www.amazon.com/C-Concurrency-Action-Anthony-Williams/dp/1617294691/ > I have the 1st version of that book, it's a very good one on the > subject. AFAIK it is "the" book about C++ multi-threaded programming. Amazon doesn't have it in Kindle format, but the second edition (2019) is available from the print, ebook, and audio formats. I haven't read it, so I can't comment on how good it is. https://www.manning.com/books/c-plus-plus-concurrency-in-action-second-edition -- 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 */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 12 09:49PM -0700 >> subject. AFAIK it is "the" book about C++ multi-threaded programming. > Amazon doesn't have it in Kindle format, but the second edition (2019) > is available from the print, ebook, and audio formats. I meant "available from the publisher". -- 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 */ |
| 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