- About memory allocators.. - 2 Updates
- Value of s[s.size()] when s is a string - 5 Updates
- Abuse report of Rick C. Hodgin's spam - 7 Updates
- Allocating with new but freeing the memory with free - 1 Update
- What is this constructor? - 1 Update
| Horizon68 <horizon@horizon.com>: Oct 15 03:47PM -0700 Hello... About memory allocators.. I think that mingw uses MSVCRT memory allocator that scales well and that is better than jemalloc and better than hoard, please notice it here on the following benchmark: https://github.com/andremussche/scalemm But GCC on Linux uses ptmalloc2 memory allocator.. I have just took a look at the memory allocator of the GCC C and C++ compiler on Linux that is called ptmalloc2, and on a UMA machine with four 10-core 2GHz Intel Xeon E7-4850 processors supporting two hardware threads per core, the benchmark of the following paper shows that ptmalloc2 is "scaling" decently, so i think that ptmalloc2 is a decent choice. Please read this paper to notice it: https://arxiv.org/pdf/1503.09006.pdf I have used gcc mingw to compile my scalable counting networks that use a lot the MSVCRT memory allocator, thus they are scalable, so my scalable reference counting with efficient support of weak references does too scale very well, and my efficient Threadpool engines that scale very well do scale very well too. You can download them from my website: https://sites.google.com/site/scalable68/ Thank you, Amine Moulay Ramdane. |
| Horizon68 <horizon@horizon.com>: Oct 15 03:59PM -0700 On 10/15/2018 3:47 PM, Horizon68 wrote: > About memory allocators.. > I think that mingw uses MSVCRT memory allocator that scales well and > that is better than jemalloc and better than hoard, please notice it I correct: I mean microsoft MSVCRT memory allocator scales better than jeMalloc and better than hoard. |
| Paul <pepstein5@gmail.com>: Oct 15 12:21PM -0700 I think that, when s is a std::string, s[s.size()] == 0; However, I haven't been able to confirm it. It works like that in my compiler. Is this correct? Thanks, Paul Epstein |
| jameskuyper@alumni.caltech.edu: Oct 15 01:22PM -0700 On Monday, October 15, 2018 at 3:21:46 PM UTC-4, Paul wrote: > Is this correct? > Thanks, > Paul Epstein [Re: std::basic_string<charT> s; s[pos]] "Returns: *(begin() + pos) if pos < size(). Otherwise, returns a reference to an object of type charT with value charT(), where modifying the object to any value other than charT() leads to undefined behavior." (20.3.2.5p2) charT defaults to char, so for typical uses charT() is essentially the same as 0. That will also be true, except for the type of the result, for the other three types that the standard templates are required to be specialize for: char16_t, char32_t, and wchar_t, respectively. |
| Paul <pepstein5@gmail.com>: Oct 15 01:34PM -0700 > same as 0. That will also be true, except for the type of the result, > for the other three types that the standard templates are required to be > specialize for: char16_t, char32_t, and wchar_t, respectively. That seems to read as though s[s.size() + 1] is also 0 but that doesn't appear to be true with my compiler. I tested it with the below. s[s.size()] == 0 but s[s.size() + ..] is not usually 0. Paul #include <string> #include <iostream> int main() { std::string s; for(int i = 0; i < 10; ++i) std::cout << int(s[i]) << "\n"; } |
| jameskuyper@alumni.caltech.edu: Oct 15 02:13PM -0700 On Monday, October 15, 2018 at 4:34:15 PM UTC-4, Paul wrote: > > for the other three types that the standard templates are required to be > > specialize for: char16_t, char32_t, and wchar_t, respectively. > That seems to read as though s[s.size() + 1] is also 0 but that doesn't appear Not quite. 203.2.5p1 says "Requires: pos <= size()." Violating a "Requires" clause renders the behavior undefined. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 16 12:14AM +0200 > same as 0. That will also be true, except for the type of the result, > for the other three types that the standard templates are required to be > specialize for: char16_t, char32_t, and wchar_t, respectively. Worth noting for those using elder C++03 compilers, that until C++11 this guarantee and well-definedness was only offered for the `const` accessor. C++03 §21.3.4/1: "Returns: If pos < size(), returns data()[pos]. Otherwise, if pos == size(), the const version returns charT(). Otherwise, the behavior is undefined." The C++11 guarantees are more clean. But C++03 supported efficient reference counted string buffers, called "COW" strings (copy on write), and used by g++'s standard library implementation, by regarding pointers and references as invalidated by calls to `data` or `c_str`, and by the first call to non-`const` `operator[]`, `at`, `begin`, `rbegin`, `end` and `rend`. In C++11 and later these operations don't invalidate, i.e. C++11 std::string is easier to use correctly, and furthermore indexing is required to be O(1), which rules out a COW buffer copying on first access. C++11 `std::stringview` indexing is correspondingly designed to return a reference to constant `char` instead of the `char` itself, relying on the compiler to optimize away that indirection overhead. What's paid for: that COW strings won't be re-introduced. My impression is that the decision to rule out COW strings was caused by a bug in the g++ implementation. Rather than admit that it was a bug, g++ supporters took the position that a safe implementation was just impossible, and so, implicitly, that the buggy one was a practical trade-off, the best that one could do. They got got downright nasty about the possibility of implementing COW correctly if the standard didn't stand actively in the way. As I recall (this was years ago) I supplied proof in the form of an actual implementation, to no avail. Hardcore fans of this or that are usually immune to facts and logic, and I've encountered that a great many times so I should have known, but. Cheers!, - Alf |
| gazelle@shell.xmission.com (Kenny McCormack): Oct 15 02:48PM In article <pq23jj$2q8o$1@adenine.netfront.net>, >> my labor to, to help you achieve more in this world than you are >> able to do by yourself? >Yes: Stop spamming this newsgroup with off-topic posts. It is quite clear what Ricky could do that would improve all of our lives (*), but he has so far steadfastly refused to do it. (*) It boils down to two words: Go Away! -- I shot a man on Fifth Aveneue, just to see him die. |
| gazelle@shell.xmission.com (Kenny McCormack): Oct 15 02:49PM In article <slrnps99n4.o3q.dan@xps-linux.djph.net>, >To be fair, that guy at least makes good sandwiches. And if it takes >listening to a little bit of preaching while I wait for my turkey club, >well... I think you may have misinterpreted the phrase "sandwich board". -- [Donald] Trump didn't have it all handed to him by his parents, like Hillary Clinton did. - Some dumb cluck in Ohio; featured in Michael Moore's "Trumpland" - |
| Dan Purgert <dan@djph.net>: Oct 15 03:11PM Kenny McCormack wrote: >>listening to a little bit of preaching while I wait for my turkey club, >>well... > I think you may have misinterpreted the phrase "sandwich board". No, he runs a food truck ... -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281 |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 15 07:33PM +0200 Am 14.10.2018 um 18:01 schrieb Mr Flibble: > I've logged into Google Groups and reported his last religious post for > abuse (spam). Could others do the same please? A concerted effort may > result in Google doing something to ban this idiot. You can be pretty sure that Google ignores your messages unless they expect things to become very expensive otherwise, e.g. because it is contrary to US law. So adjust your killfile and everything is fine. Obviously I must have done this before because I initially didn't know what you are talking about. I can't even see the sub-threads. Marcel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 15 06:40PM +0100 On 15/10/2018 18:33, Marcel Mueller wrote: > So adjust your killfile and everything is fine. Obviously I must have done > this before because I initially didn't know what you are talking about. I > can't even see the sub-threads. The likes of Hodgin subsist on inertia such as this; if enough of us use the post reporting feature Google might ban him. /Flibble -- "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." |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 15 11:01AM -0700 On Monday, October 15, 2018 at 1:40:13 PM UTC-4, Mr Flibble wrote: > The likes of Hodgin subsist on inertia such as this; if enough of us use > the post reporting feature Google might ban him. You are wrong, sir. If you were to see me in real life, you'd see me also telling people about Jesus. And most of them respond to me the way you and the other exceedingly rude people do. I don't do it for the hate. I do it for the few people who will be reached by the message. Even one "tiny soul" by the world's eyes, when given over to eternity, will bear much fruit and is worth Christ having died for even that one soul. ----- I pray someday you come to understand this, Leigh. It's not AT ALL about what you think it is about. It's about something else entirely, something that completely escapes you today. -- Rick C. Hodgin |
| scott@slp53.sl.home (Scott Lurndal): Oct 15 06:13PM >If you were to see me in real life, you'd see me also telling >people about Jesus. And most of them respond to me the way you >and the other exceedingly rude people do. Patient: Doctor, it hurts when I stick a fork in my eye. Docter: Then don't do that, idiot. It's exceedingly rude to force your unwanted viewpoint on anyone. |
| legalize+jeeves@mail.xmission.com (Richard): Oct 15 03:33PM [Please do not mail me a copy of your followup] Paul <pepstein5@gmail.com> spake the secret code >The code below is from Hackerrank. It looks suspicious to me because >the memory is allocated with new but freed with free. >Is it ok? No. It is an error to mismatch allocation mechanisms. Commonly mismatched pairs are: - array new, scalar delete - scalar new, array delete - new, free - malloc, delete -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 15 04:04PM +0100 On Mon, 15 Oct 2018 05:17:32 -0700 (PDT) > {} > ... is also thread-safe and typical surprises about how that T with > broken invariant was constructed. ;-) Yes, the technique has its limitations, although I would say that someone who doesn't realize that two operations under separate locking of the mutex are not mutually atomic probably should not be programming with threads. In that kind of case I suppose you are either stuck with default constructing x and y and then assigning to them in the constructor body under the same lock, or putting x and y in a private struct and initializing the struct. Perhaps others can think of other ways. |
| 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