| Real Troll <real.troll@trolls.com>: Oct 24 12:40PM -0400 On 22/10/2019 08:28, Frederick Gotham wrote: > std::cout << std::extent<decltype(values)>::value << std::endl; > } > Or is there an even nicer way? values.size(); |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 24 09:43AM -0700 >> absolute sense, only that people will react to it. > When practising etymology, it's quite easy to > come to wrong conclusions. > I think it's likely that the modern use of "troll" on internet forums actually comes from > the doll: https://en.wikipedia.org/wiki/Troll_doll That etymology is inconsistent with the way I've seen it used, and the online dictionaries I've checked agree with the fishing etymology, which is consistent with the way I've seen it used. See <https://en.m.wiktionary.org/wiki/troll#Verb>, meaning #8. |
| David Brown <david.brown@hesbynett.no>: Oct 24 10:44PM +0200 On 24/10/2019 16:16, Bonita Montero wrote: >> ICC does not vectorise the code at all. > Check the ICC documentation ... I have read it. It does not describe a specific set of code patterns that the compiler can vectorize, contrary to your claim. And I have tried Juha's code with ICC, and the compiler does not vectorise it (at least, not using the flags I tested. gcc and clang both vectorised the code nicely with those same flags). |
| David Brown <david.brown@hesbynett.no>: Oct 24 10:44PM +0200 On 24/10/2019 16:23, Bonita Montero wrote: > https://gcc.gnu.org/projects/tree-ssa/vectorization.html That page is not part of the gcc compiler documentation, so it does not fulfil your claims. It does not describe limits of the code patterns that can be vectorised, contrary to your claims. It gives some examples of code that /can/ be vectorised, as part of the development project for adding auto-vectorisation to gcc, which was integrated in the compiler some ten years ago (contrary to your claims that compilers can't auto-vectorise except in some very limited ways). It is quite clear that you don't know about auto-vectorisation in compilers - how well it works, how to write code that works with it, what compilers support it. You were simply trying to look smart by mocking someone who /does/ know about it. Clutching at straws and making up more nonsense, perhaps hoping no one will bother checking your posts or links, will not help. The correct response would be to admit that you were wrong, accept that you have learned something, and apologise for your mocking. |
| David Brown <david.brown@hesbynett.no>: Oct 24 10:52PM +0200 On 24/10/2019 17:27, Frederick Gotham wrote: > https://en.wikipedia.org/wiki/Troll_doll > This makes the most sense to me out of all the possibilities > (including your angling one). It is conceivable that the internet usage of the term "troll" is related to the mythical monster "troll", from Norse mythology (and later inspiring monsters in fictional works like those of Tolkien). Certainly net "trolls" are as unpleasant and disliked as "real" trolls, and it is common to caricature net trolls as real trolls. But the idea that it is related to "Troll dolls" is clearly ridiculous. (My money is still on the fishing term - it fits the usage very accurately, and is confirmed by people who have used Usenet pretty much since its conception.) Rather than argue further, I recommend you take a couple of hours break from Usenet and watch this film. It is time well spent! <https://en.wikipedia.org/wiki/Trollhunter> |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Oct 24 10:39PM +0100 >>(including your angling one). > I've been on usenet for almost forty years; It has always been well > understood that the term derives from the fishing usage. For a lot of people in the UK, the reference that springs to mind will be to Julian and Sandy "trolling about" in Round the Horn. That polari word probably comes from the fishing usage, but that one will be far less well known to many Brits of a certain age. -- Ben. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 24 01:13PM -0700 On 10/24/2019 2:00 AM, Bonita Montero wrote: >> on? Like an ABA counter? If a CAS fails, how far back do you have to >> restart, or unroll if you will? > No, I'm not using ABA-counters. Are you embedding any state with a pointer? bit stealing? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 24 01:14PM -0700 On 10/24/2019 1:13 PM, Chris M. Thomasson wrote: >>> have to restart, or unroll if you will? >> No, I'm not using ABA-counters. > Are you embedding any state with a pointer? bit stealing? It can be fun to align pointers on a large boundary, and use that extra space for meta data. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 24 12:45PM -0700 On 10/23/2019 10:38 PM, Jorgen Grahn wrote: > The software (as I understand it) is Unix-specific; standard practice > there is to have parent--child process relationships, and to use the > wait() family of functions to detect when a child dies. That's fine. Missed the Unix part. Imvho, it would be nice for other processes to be able to ask the Supervisor to shutdown/pause/whatever one of its children. Creating a little webserver per main component of a system can work pretty good. Being able to control the Supervisor from a browser can be nice. |
| Soviet_Mario <SovietMario@CCCP.MIR>: Oct 24 08:15PM +0200 Il 24/10/19 14:25, David Brown ha scritto: >> have both the members and data static and another instance not, just the >> members and data elsewhere, without possibility to know in advance. > Yes. So what? nothing particularly serious. I was just considering that one could not always have the full storage (lifetime) control they expect. I tend to think too much in a C-like mindshape surely -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 24 09:49PM +0300 On 24.10.2019 21:15, Soviet_Mario wrote: > I was just considering that one could not always have the full storage > (lifetime) control they expect. > I tend to think too much in a C-like mindshape surely What makes you think that? Are you maybe afraid that any dynamically allocated pieces in a static std::string object might somehow have shorter lifetime than the std::string object itself? That cannot be, this would ruin all invariants. Or more probably, maybe you think that the lifetime of a static std::string object has already begun before the program start, when it maybe occupies some bytes in some data section of the executable on the disk? No, it isn't, in C++ the lifetime of an object with a non-trivial constructor begins when its initialization is complete. This only happens at run-time. |
| Keith Thompson <kst-u@mib.org>: Oct 24 12:05PM -0700 > The upper limit for "small string" length can be easily found out as > sizeof(std::string)-1 (-1 for the zero terminator byte, which can in > principle also serve as a marker that SSO is in use). That's *an* upper bound, not the least upper bound. A std::string object has to store at least enough information to determine whether it's using the small string optimization or not. A quick experiment shows that sizeof (std::string) is 32 on Ubuntu 18.04, and it uses the small string optimization for lengths up to 15, so 16 of the 32 bytes can be used to hold the string value. On some other systems (Cygwin, OpenBSD), sizeof (std::string) is 8 and the implementation doesn't appear to use the small string optimization at all. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. 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