- vector<>::erase-behaviour - 9 Updates
- C++ 2011 threading read/write locking? - 12 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 31 04:08PM +0200 Does anyone know what's the technical reason behind that when I do an .erase() on a vecor all iterators beginning from ther point where I erased and not shifted (excluding the last elements the vector which are the same number of elements I erased)? As the capacity doesn't change the iterators could partitially remain valid but just point to the shifted elements. |
| Juha Nieminen <nospam@thanks.invalid>: Mar 31 05:06PM > are the same number of elements I erased)? > As the capacity doesn't change the iterators could partitially remain > valid but just point to the shifted elements. I'm honestly not trying to be a dick, but the amount of spelling errors in that message genuinely makes it hard to understand *exactly* what you are asking. But if I'm interpreting it correctly, are you asking why the C++ standard declares all the iterators that point to elements that are located on or after the deletion point as invalid, even though there's no technical reason for it? For starters, the iterators are invalid because they won't be pointing to the *same* elements anymore. That's why they are invalid. Even if they are still pointing to *some* valid element in the same vector, that doesn't mean it's somehow valid. It will be a completely different element. Secondly, the standard probably doesn't forbid the std::vector implementation from physically reducing the allocated size of the vector, if it can do that without moving the other elements around. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 31 10:35PM +0200 > For starters, the iterators are invalid because they won't be > pointing to the *same* elements anymore. That shoudln't be a problem since they could partitially point to the shifted elements. That could be guaranteed by the standard withoud any restrictions on the implementation. > Secondly, the standard probably doesn't forbid the std::vector > implementation from physically reducing the allocated size of the > vector, if it can do that without moving the other elements around. I don't know it for sure but I'll bet my right hand that the standard guarantees not to move the allocation in this case or to reduce its capacity but just do everything in-place. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 31 10:05PM +0100 On 31/03/2019 21:35, Bonita Montero wrote: > That shoudln't be a problem since they could partitially point to the > shifted elements. That could be guaranteed by the standard withoud any > restrictions on the implementation. And you had the nerve to call my capabilities into question. Invalid iterators should never be used even if they still "point" to valid objects as this is undefined behaviour according to the standard. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 31 11:22PM +0200 > And you had the nerve to call my capabilities into question. Invalid > iterators should never be used even if they still "point" to valid > objects as this is undefined behaviour according to the standard. If you were able to read you did read that I already know that. But there's a point in which I wasn't certain and where had tomatoes on my eyes: reallocation obviously doesn't occur because the iterators before the erased sequence remain valid. So there's absolutely no obvious coercive necessity for the standard to mandate to invalidate the iterators beginning or behind that sequence. The iterators could point partitially to shifted elements without any restriction on the implementation. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 31 10:52PM +0100 On 31/03/2019 22:22, Bonita Montero wrote: > to mandate to invalidate the iterators beginning or behind that > sequence. The iterators could point partitially to shifted elements > without any restriction on the implementation. The iterator concept dictates that what an iterator refers to never changes unless the iterator itself is changed. What you propose would ruin the iterator concept. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 01 12:21AM +0200 > The iterator concept dictates that what an iterator refers to never > changes unless the iterator itself is changed. What you propose would > ruin the iterator concept. But there's no technical necessity for this concept. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 31 11:32PM +0100 On 31/03/2019 23:21, Bonita Montero wrote: >> changes unless the iterator itself is changed. What you propose would >> ruin the iterator concept. > But there's no technical necessity for this concept. Of course there is: people want to know that an object referred to by an iterators remains stable and they want to know when iterators become invalid so they can design clean robust software; with your proposal all bets are off. The reason iterators are invalidated is the same reason element references are invalidated. The fact that you don't get this leads me to the conclusion that the code you write is a mess. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 31 11:35PM +0100 On 31/03/2019 21:35, Bonita Montero wrote: > That shoudln't be a problem since they could partitially point to the > shifted elements. That could be guaranteed by the standard withoud any > restrictions on the implementation. I see you snipped part of a reply again that you disagree with but cannot argue against, so I will repeat it again here: "Even if they are still pointing to *some* valid element in the same vector, that doesn't mean it's somehow valid. It will be a completely different element." Now reply to this snipped part please, if you can. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| blt_abadcf@h4gtm9uj3i5lygp_c2ioctrq.com: Mar 31 08:53AM Is there any equivalent of the pthreads pthread_rwlock_t in C++ threading? shared_mutex seems to be mentioned but the functionality seems different to me pluts its 2017 only anyway which rules out the compiler I'm using. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Mar 31 09:27AM > Is there any equivalent of the pthreads pthread_rwlock_t in C++ threading? > shared_mutex seems to be mentioned but the functionality seems different to > me pluts its 2017 only anyway which rules out the compiler I'm using. Use pthread_rwlock_t, as you don't have c++17 compliant compiler. What's difference between pthread and C++17 variant, just to start discussion? -- press any key to continue or any other to quit... |
| blt_rHkx@rjrnwk17q3gki8i5ps4p50dlbz.org: Mar 31 10:22AM On Sun, 31 Mar 2019 09:27:34 GMT >> shared_mutex seems to be mentioned but the functionality seems different to >> me pluts its 2017 only anyway which rules out the compiler I'm using. >Use pthread_rwlock_t, as you don't have c++17 compliant compiler. Umm, because I was hoping to use C++ threading as its syntatically tidier than pthreads and getting lambdas to work with pthreads would probably be a PITA (I don't know, never tried). |
| Melzzzzz <Melzzzzz@zzzzz.com>: Mar 31 11:23AM > Umm, because I was hoping to use C++ threading as its syntatically tidier > than pthreads and getting lambdas to work with pthreads would probably be a > PITA (I don't know, never tried). it's easy: eg #include <functional> #include <stdio.h> using std::function; void f(void* lambda) { function<void(int)>* pf = (function<void(int)>*)lambda; (*pf)(5); } int main(){ int j = 5; function<void(int)> l = [j](int){ printf("%d\n",j); }; f(&l); } -- press any key to continue or any other to quit... |
| Sam <sam@email-scan.com>: Mar 31 08:51AM -0400 > Umm, because I was hoping to use C++ threading as its syntatically tidier > than pthreads and getting lambdas to work with pthreads would probably be a > PITA (I don't know, never tried). "Getting lambdas to work with pthreads", whatever that means, is no harder and no easier than getting lambdas to work with anything else. It shouldn't take more than an hour, or so, to write a C++ class wrapper around pthread_rwlock_t that implements similar functionality to the C++17 class. It's not complicated. If you started when you posted your first message in this thread, you would've probably been done by the time you posted your second message in this thread. |
| blt_8u6bgf6@1fcy52bz_kvxxu.net: Mar 31 04:23PM On Sun, 31 Mar 2019 08:51:29 -0400 >> than pthreads and getting lambdas to work with pthreads would probably be a >> PITA (I don't know, never tried). >"Getting lambdas to work with pthreads", whatever that means, is no harder I'll assume English is your second language if you didn't understand that. >class. It's not complicated. If you started when you posted your first >message in this thread, you would've probably been done by the time you >posted your second message in this thread. I could write a class wrapper around pthreads? Wow! Why didn't I think of that?? Truly a savant and nobel prizes surely await you! I guess trying to be a smart ass is more satisfying for you than just giving a simple answer, right? |
| blt_c7qd40zk@x7o.gov: Mar 31 04:25PM On Sun, 31 Mar 2019 11:23:45 GMT > function<void(int)> l = [j](int){ printf("%d\n",j); }; > f(&l); >} And what exactly is the point of using lambda functions if you have to write a wrapper function for them anyway? You might just as well put the code in a standard function. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Mar 31 04:54PM > And what exactly is the point of using lambda functions if you have to write a > wrapper function for them anyway? You might just as well put the code in a > standard function. You said it is difficult. It is not. -- press any key to continue or any other to quit... |
| blt_1bdc2e@cvjfc_s2lr2wbr2y.org: Mar 31 05:12PM On Sun, 31 Mar 2019 16:54:17 GMT >> wrapper function for them anyway? You might just as well put the code in a >> standard function. >You said it is difficult. It is not. Any idiot can wrap a lambda, I meant passing one direct to pthread_create(). Show us your code for that. |
| Sam <sam@email-scan.com>: Mar 31 01:18PM -0400 > >> PITA (I don't know, never tried). > >"Getting lambdas to work with pthreads", whatever that means, is no harder > I'll assume English is your second language if you didn't understand that. You seem to be assuming a great deal many of things. That, understandably, is often the only possible avenue when no other options are available. The statement "Getting lambdas to work with threads" is logically equivalent to "making elephants fly with automobiles". There's nothing unique about POSIX threads that requires employing any unique aspects or attributes of lambdas. Or vice versa. Most fundamental POSIX structures are not copyable; but that's not some earth-shattering property either. Plenty of classes in the C++ library are also not copyable. Like std::ifstream, for example. So the same issues, with regards to captures, apply to POSIX threads as they do to std::ifstream, when it comes to lambdas. There's nothing particularly special about POSIX threads and lambdas. So, your obsession with lambdas and POSIX threads is, pretty much, totally unwarranted. > >posted your second message in this thread. > I could write a class wrapper around pthreads? Wow! Why didn't I think of > that?? That's why I'm here, to help. > Truly a savant and nobel prizes surely await you! I'll decline. I don't like traveling. > I guess trying to be a smart ass is more satisfying for you than just giving > a > simple answer, right? I just did give a simple answer: write a simple wrapper. Can't get any simpler than that. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 31 07:20PM > On Sun, 31 Mar 2019 08:51:29 -0400 > Sam <sam@email-scan.com> wrote: ... > I could write a class wrapper around pthreads? Wow! Why didn't I think of that?? > Truly a savant and nobel prizes surely await you! Please: drop the sarcasm. Your original question was reasonable and you obviously wanted an answer. It was even more interesting than 90% of the postings here. At the same time, you /know/ you're now turning it into the same old flamewar. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Mar 31 02:02PM -0700 > Is there any equivalent of the pthreads pthread_rwlock_t in C++ threading? > shared_mutex seems to be mentioned but the functionality seems different to > me pluts its 2017 only anyway which rules out the compiler I'm using. Fwiw, you just might be interested in the following thread: https://groups.google.com/d/topic/comp.lang.c++/DBIG55vCBSA/discussion Here is my crude C++ code: https://pastebin.com/raw/1QtPCGhV |
| 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