- "Why ISO C++ Is Not Enough for Heterogeneous Computing" by Intel - 3 Updates
- Overuse of 'auto' - 12 Updates
- catgirl onlyfans - 1 Update
| scott@slp53.sl.home (Scott Lurndal): Dec 13 03:06PM >I would not spend much time on building a computer language around this >kind of CPU. Heterogeneous hardware should be up to the OS scheduler, >not a _multi-threading_ applications problem. What "kind of CPU"? The entire article wasn't about enhancing or changing the C++ language. It's just a set of library functions and header files that allow interacting with a GPU using OpenCL. Basically a C++ wrapper on OpenCL/Cuda. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Dec 13 02:15PM -0600 On 12/13/2022 2:37 AM, Juha Nieminen wrote: >> That is a lot of custom code. One would hope for more compiler automation. > Time to create yet another new programming language that's a "better C++"! > And throw it in the same heap as the myriads of other such languages. Isn't that new programming language suppose to be Go and Rust ? Lynn |
| d thiebaud <thiebauddick2@aol.com>: Dec 13 05:03PM -0500 On 12/13/22 15:15, Lynn McGuire wrote: >> And throw it in the same heap as the myriads of other such languages. > Isn't that new programming language suppose to be Go and Rust ? > Lynn And D, among others. I wish D had caught on more. |
| Paavo Helde <eesnimi@osa.pri.ee>: Dec 13 02:39PM +0200 13.12.2022 02:00 Keith Thompson kirjutas: > If you can get a "true random number", you don't need a PRNG > (unless your source of true random numbers is slow or otherwise > resource-intensive). In Linux there are /dev/random and /dev/urandom. The first one ought to be slower and more random (gathers "environmental noise from device drivers") than the other, although /dev/urandom is nowadays supposed to be also good for almost anything, including cryptographic purposes. I once had to fix a bug where my program stalled. It appeared I had thoughtlessly used /dev/random for filling some random pool, and as the program was run in a stripped-down Linux VM without any direct connection to physical hardware, the system ran out of random data for /dev/random and the program hanged indefinitely when trying to read it. |
| David Brown <david.brown@hesbynett.no>: Dec 13 02:10PM +0100 On 13/12/2022 01:00, Keith Thompson wrote: > (unless your source of true random numbers is slow or otherwise > resource-intensive). But it's rare to be able to get true random > numbers in the first place. True random data - or at least high entropy data - is almost always slow. It also often has an awkward distribution (such as Binomial or Poisson, rather than convenient linear distribution). So the standard practice is to use the high entropy data to seed a pseudo-random number generator from your high entropy source. >> It wasn't uncommon in the early days of unix games to seed >> the PRNG with the current time in seconds since the Epoch. > Which is hardly random. It makes no sense to call a seed "random" or not. It can be non-deterministic (and the current time in seconds is non-deterministic enough for a great many purposes - certainly for games). But only a distribution can be random, not a single number. Higher quality seeds with greater entropy combine multiple sources, such as the least-significant bit of temperature measurements, microsecond times between network packets or keyboard clicks, etc. (You have to be careful how you combine them - simply adding them is not a good idea!) |
| David Brown <david.brown@hesbynett.no>: Dec 13 02:31PM +0100 On 13/12/2022 10:11, Keith Thompson wrote: >> My choice of words was poor. I meant it more like "you are missing the >> point". > I doubt that he his, but I'll refrain from further attempts to speak for him. You are doing fine so far :-) Yes, I understand Juha's point, but I disagree with it. At least, I disagree with the level or strength of it. Clear code is vitally important in all but throw-away code. (Remember Heathfield's rule? It's easier to make clear code correct than to make correct code clear. It's easier to make correct code fast than to make fast code correct. So always code for clarity.) And awkward or exaggerated abbreviations make code unclear. They may seem fine at the time to the person writing the code, but it's a different matter a decade later for someone else maintaining it. So I think there is a scale here of some kind, from short, concise or abbreviated at one end and long-winded, explicit and expanded at the other end. I think (unjustifiably speaking for everyone here!) we all agree that being too close to the short end is a bad idea. The disagreement is towards the other end - I say that's bad too, while Juha, AFAICS, disagrees. > I'm not sure I can explain. And I'm at least as likely to apply it to > myself as to others. > See also RTFM. If someone is directly called "stupid", it is insulting. However, it's a different matter if someone says "you're being stupid", or "that code you wrote is stupid", or "you said something stupid". I do not consider myself a stupid person - but like most people, I sometimes do stupid things or say something stupid. If someone gives me a piece of code to review and I return it with "KISS" scrawled across it in big red pen, I am /not/ calling the developer stupid - nor insulting them. I am telling them that I think the code has got out of hand and ended up being too complex - and that they could do a better job if they simplified it. (I haven't done this with a code review, but I did do it once with an electronics design review. The designer was not insulted, and agreed with my point.) |
| Juha Nieminen <nospam@thanks.invalid>: Dec 13 01:42PM > agree that being too close to the short end is a bad idea. The > disagreement is towards the other end - I say that's bad too, while > Juha, AFAICS, disagrees. I don't really understand why this seems to be so hard to explain. I don't want names that are long. I want names that are clear, unambiguous and easy to understand, which convey as well as possible what the name is representing. Overtly short abbreviated names do not convey that, and code that's too compressed and contains too much information packed in too little space does not achieve that. The goal is not to make names or code longer. That's just a side-effect of making code clearer and easier to understand. And yes, it is perfectly possible to go too far in the other direction. But that has nothing to do with what I'm saying. I want clarity, not length. Clarity sometimes requires increasing length a bit, but that in itself is irrelevant, it's just a side effect. Thus I find it ridiculous when people post "counter-examples" that are names that are overly long and contain a lot of rendunancy. I'm not looking for long names. I'm looking for clear names. There's a difference. How hard is this to understand, really? |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Dec 13 06:43AM -0800 On Tuesday, December 13, 2022 at 3:42:32 AM UTC-5, David Brown wrote: > long int" precisely because it is shorter and requires less cognitive > effort to understand. > "auto", used appropriately, can do the same thing. auto can be convenient, very convenient for auto iter = vec.begin(); But it can also be wrong, when auto value = copy of proxy I don't know of another language where var value = foo() is correct in some contexts and wrong in others. Surely some cognitive effort required there. Daniel |
| scott@slp53.sl.home (Scott Lurndal): Dec 13 02:59PM >(unless your source of true random numbers is slow or otherwise >resource-intensive). But it's rare to be able to get true random >numbers in the first place. Well, we do have a TNRG on our chips. And as you point out, TRNG's are generally quite slow, so they're often used to seed PRNG's (either hardware based or software based). >> It wasn't uncommon in the early days of unix games to seed >> the PRNG with the current time in seconds since the Epoch. >Which is hardly random. Not particuarly, no. But effective for the simple purposes used. |
| Muttley@dastardlyhq.com: Dec 13 03:58PM On Tue, 13 Dec 2022 11:10:47 -0000 (UTC) >"return_value" is better than "ret". "error_code" is better than "err". >"generateRandomValue" is better than "genRandVal". "column_index" is >better than "i". Not if you end up with a wall of text like a lot of Java code. >(An exception is if the contraction or acronym is universally used and >understood, like "GPS", "HDMI", "cos", "tan", etc.) 'i' is VERY common as an index value in for(). >because when the namespace appears in the name, it makes it very >clear that the name is from that namespace and not a function-local >name, a class member, or a global name somewhere else.) In that case whats the point of having a namespace at all? You can achieve exactly the same result C style with function naming. Eg: instead of mylib::func() you can just call it mylib_func(). |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Dec 13 08:13AM -0800 On Monday, December 12, 2022 at 11:32:20 AM UTC-5, Ben Bacarisse wrote: > But then I like to program (full disclosure: for fun only these days) in > Haskell which has, to all intents and purposes, a default auto. Types > are almost always inferred rather than stated. But in Haskell cases like this can't arise: std::vector<bool> v = { true,false,true }; auto value = v[1]; value = true; assert(v[1] == false); // fails Were Juha were to inherit a C++ code base that made significant use of matrix libraries, or was written by programmers that had read Scott Meyers' Effective C++ series, and that was also liberally sprinkled with auto, he would have to put some effort into convincing himself that it didn't have "auto value = copy of proxy" landmines. Daniel |
| Muttley@dastardlyhq.com: Dec 13 05:16PM On Tue, 13 Dec 2022 08:13:37 -0800 (PST) > auto value = v[1]; > value = true; > assert(v[1] == false); // fails This is something I've never thought about. So when does auto default to a reference? Because if you change that to an int it doesn't assert eg: std::vector<int> v = { 1,2,3 }; auto value = v[1]; value = 4; assert(v[1] == 2); So in the case of bool its taking a reference, but in the case of int its doing a copy. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Dec 13 11:10AM -0800 > > assert(v[1] == false); // fails > This is something I've never thought about. So when does auto default to a > reference? Because if you change that to an int it doesn't assert eg: bool isSomething = false; auto val = isSomething ; // value auto& ref = isSomething ; // reference Same as for int. That isn't the issue here. The issue is that the index operator for std::vector<bool> returns a proxy rather than the value of a bool. So value1 and value2 in auto value1 = v[1]; bool value2 = v[1]; are both values, but different. Mutating value1 has side effects, mutating value2 does not. Daniel |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 13 01:07PM -0800 On 12/13/2022 6:59 AM, Scott Lurndal wrote: >>> the PRNG with the current time in seconds since the Epoch. >> Which is hardly random. > Not particuarly, no. But effective for the simple purposes used. Fwiw, check this shit out, and experiment in race conditions: https://groups.google.com/g/comp.lang.c++/c/7u_rLgQe86k/m/XiqELOEECAAJ ;^) lol. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 13 01:09PM -0800 On 12/13/2022 3:38 AM, Ben Bacarisse wrote: >>> Clearer? >> You still forgot to check for nullptr: > So did you. Indeed! :^) > side issues) don't help because, very often, the confusion comes from > the neutral and unhelpful names rather than the language feature (in > that case auto) that is being discussed. Humm... Okay, I think that is fair enough. |
| khalid khan <khalidmubarak0302@gmail.com>: Dec 13 05:52AM -0800 If you're a fan of cosplay, then you'll love OnlyFans account catgirl. She's got a killer body and knows how to work it in front of the camera. From skimpy outfits to full-on costumes, she's got a wide range of looks that will tantalize and tease her fans.catgirl onlyfans is all about providing her fans with access to exclusive content. She posts daily updates of photos and videos, including behind-the-scenes footage, candid shots, and more. Whether you're looking for something to get you through your workday or want to get lost in a fantasy world for a while, catgirl onlyfans has what you need.So what are you waiting for? Check out catgirl onlyfans today and see what all the fuss is about. Link Here https://t.co/33UmJzT9lD Come get a behind the scenes look at my OnlyFans account! I'll be posting exclusive content, videos, and pictures that you won't find anywhere else. Don't miss out on this opportunity to get to know me better! |
| 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