- Overuse of 'auto' - 20 Updates
- (PDF) Autoimmune Diseases of the Skin 3rd Edition by Michael Hertl - 1 Update
- "Why ISO C++ Is Not Enough for Heterogeneous Computing" by Intel - 3 Updates
- Vector Fractal Bloom... - 1 Update
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Dec 12 04:00PM -0800 >>a random number generator, not as the result of it. > It's common to seed a PRNG with a random number. Preferably > a true random number. 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). But it's rare to be able to get true random numbers in the first place. > 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. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 12 04:04PM -0800 On 12/8/2022 4:31 AM, Juha Nieminen wrote: > who is reading the code, is that it hides the type in question. When > you see something like: > auto foobar = someFunction(a, b); [...] What about: auto foobar = foobaz(a, b); foobar->execute(); Well, what the hell does execute do? struct missile_command { void execute() { // FIRE! } }; Oh shit! foobaz returns a pointer to missle_command, well, shit happens. Time to go into the bunker... |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 13 12:33AM > On 12/8/2022 4:31 AM, Juha Nieminen wrote: <cut> > }; > Oh shit! foobaz returns a pointer to missle_command, well, shit > happens. Time to go into the bunker... These sorts of example are pure polemic since much of the problem in comprehension comes from the names not the types. auto missile = getLaunchAuthority(nominatedPerson1, nominatedPerson2); missile->launch(); Clearer? -- Ben. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 12 05:13PM -0800 On 12/12/2022 4:33 PM, Ben Bacarisse wrote: >> happens. Time to go into the bunker... > These sorts of example are pure polemic since much of the problem in > comprehension comes from the names not the types. Keep in mind that foobar could be a nullptr! Thank god. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 12 05:25PM -0800 On 12/12/2022 5:13 PM, Chris M. Thomasson wrote: >>> }; >>> Oh shit! foobaz returns a pointer to missle_command, well, shit >>> happens. Time to go into the bunker... Ben keep in mind that missle_command is different than missile_command. struct missle_command { void execute() { // Tell subs to launch. } }; What auto is the right one? |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 13 01:47AM > void execute() { // Tell subs to launch. } > }; > What auto is the right one? What has this got to do with the point I was making? -- Ben. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 12 05:48PM -0800 On 12/12/2022 5:47 PM, Ben Bacarisse wrote: >> }; >> What auto is the right one? > What has this got to do with the point I was making? In my very personal and humble opinion, auto has the ability to send a chill up my spine... |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 12 07:47PM -0800 On 12/12/2022 5:13 PM, Chris M. Thomasson wrote: > Keep in mind that foobar could be a nullptr! Thank god. >> auto missile = getLaunchAuthority(nominatedPerson1, nominatedPerson2); >> missile->launch(); Ahh, you meant getLaunchAuthoritySub right? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 12 07:51PM -0800 On 12/12/2022 7:47 PM, Chris M. Thomasson wrote: >>> auto missile = getLaunchAuthority(nominatedPerson1, nominatedPerson2); >>> missile->launch(); > Ahh, you meant getLaunchAuthoritySub right? getLaunchAuthority for what? getLaunchAuthority_Anti_Satellite Or, auto auth = create_launch_authority_sam_sites(nominatedPerson1, nominatedPerson2); if (auth) { launch(auth); } |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 12 07:53PM -0800 On 12/12/2022 7:51 PM, Chris M. Thomasson wrote: > { > launch(auth); > } lanuch(auth) vs launch_at_will_commander(auth). |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 12 08:08PM -0800 On 12/12/2022 4:33 PM, Ben Bacarisse wrote: > auto missile = getLaunchAuthority(nominatedPerson1, nominatedPerson2); > missile->launch(); > Clearer? You still forgot to check for nullptr: if (missile) missile->launch(); |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Dec 13 02:48AM -0500 On 12/12/22 19:00, Keith Thompson wrote: > scott@slp53.sl.home (Scott Lurndal) writes: ... > 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). It's my understanding that there are indeed hardware sources of truly random numbers based upon some physically random phenomenon such as thermal noise. They are in fact very slow, and as a result are often used to seed much faster pseudo-random number generators. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 13 12:03AM -0800 On 12/12/2022 4:00 PM, Keith Thompson wrote: >> 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. Shake a big box containing a shit load of 16 sided dice up really good... Unplug a hole and shake it until a single die drops out. Hey, we just got a nibble! ;^) Shake and repeat. lol. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 13 08:24AM > identifier are a productivity hit (more difficult > to type, for instance) and have no other redeeming > value. If you want to use camelCase or snake_case that's just fine, as long as it's consistent and readable. That's not the point. > I'll take 'rval' over "returnValue" every time. Exactly my point. Thanks for demonstrating. > long seed = random(); is perfectly readable and self documenting. At least it's using full English words, which is a step in the right direction. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 13 08:32AM > I think he *does* understand, but he disagrees. > It's easy to assume that someone can only disagree with you because they > don't understand what you're saying. I didn't actually meant that he didn't understand what I was saying. My choice of words was poor. I meant it more like "you are missing the point". >> referring to the code itself. > The acronym "KISS" definitely expands to "Keep it simple, stupid", and > has since 1960. Nobody here chose what it means. I know perfectly well what it expands to, and I still maintain that if you deliberately want to interpret it as the "stupid" referring to the person that the sentiment is directed to, it's insulting. I don't care if that's exactly what it originally meant. If it was originally insulting, then it's still insulting. I don't even understand what the person who came up with it was thinking. No wonder there are myriads of alternatives that replace the "stupid" with something less offensive. I kind of give the benefit of the doubt to the original author of the acronym and prefer to interpret it as it referring to keeping the thing "simple and stupid", rather than keeping the thing "simple" and calling the person "stupid". (If this is the interpretation, then "keeping the thing stupid" would mean something like "don't try to make it too clever for its own good". After all "stupid" and "simple" can be thought of as synonyms.) >> Either way, I'd rather code be readable and understandable than simple. > If those goals conflict, I agree. They very often do not conflict. When "simple" is interpreted as "short" (eg. using just one word instead of three) then quite often they are in conflict, especially when speaking about code. |
| David Brown <david.brown@hesbynett.no>: Dec 13 09:42AM +0100 On 12/12/2022 16:59, Juha Nieminen wrote: > I don't think you understand. > The driving principle in writing code should be "this makes it easier to > understand", not "this makes it shorter". Of course I understand, and agree with that principle. The sticking point seems to be that you apparently have difficulty understanding that short code can be easy to understand - easier than long versions. Sometimes it is simply the fact that the code is shorter that makes it easier to understand - people generally write "long" instead of "signed long int" precisely because it is shorter and requires less cognitive effort to understand. "auto", used appropriately, can do the same thing. > code harder for someone else to read. (And in the majority of cases if > you point this out, they will ferociously defend their practice, against > all logic.) Of course they write "ret" instead of "returnValue" - it makes the code easier to understand! Choosing and using good names is an art. There are guidelines, but no fixed rules. Like many stylistic aspects of programming, it can depend significantly on the size of the project, the size of the development group, the lifetime of the code, the type of code, and many other factors. One common rule, however, is that the bigger the scope of an identifier, the longer and more explicit it must be. Inside a short loop, you use an index variable "i" because it is short and /clear/. Calling it "loop_index_counter" makes the code harder to read and understand - longer and more explicit is directly counter-productive. A function that could be called from anywhere in a million-line program, on the other hand, needs a very good and clear name - though that is almost certainly best done via appropriate uses of namespaces (or other structured naming) rather than a long identifier. (C++ is not C.) Compare: int calculate_average_of_vector_of_ints(std::vector<int> vector_of_ints_to_average) { int sum_so_far = 0; for (this_int : vector_of_ints_to_average) { sum_so_far += this_int; } int the_size_of_the_vector_of_ints_to_average = vector_of_ints_to_average.size(); int return_value = sum_so_far / the_size_of_the_vector_of_ints_to_average; return return_value; } with : int average(std::vector<int> xs) { { int sum = 0; for (x : xs) { sum += x; } return sum / xs.size(); } Are you seriously suggesting that the first version is "clearer" or easier to understand, because it has long, explicit names? If I see someone use a variable called "returnValue" in something presented for code review, I'd reject it. It's a name that means nothing (what information does it give you in "return returnValue;" ?) The only conceivable reason to have it is that the function is so long the it is unclear what it is returning - and /that/ is the problem to fix. The same goes for "errorCode". If it is not clear from the code that "err" is an error code, /that/ is the problem - not the name of the variable. If we are talking about functions accessible from far off in the code, then longer names are needed. But not local names. > If 'std::map<std::string, std::string>' makes the code easier to understand > than 'auto', then write the former. There's no need to save disk space. > Shorter is not always better. I fully agree - no one has argued any differently. What people (generalising wildly from myself) are reacting against is your idea that shorter /cannot/ be better, or that longer is /always/ better. When used correctly, shorter most certainly can be better precisely because it is clearer and easier to understand - and it is clearer and easier to understand precisely because it is better. That only applies when it is clear what the identifier means, of course. And that will vary enormously according to the rest of the code. > You are now trying to argue from redundancy. 'signed' and 'int' are > redundant there. They don't add information. There's no need to say the > same thing multiple times. You are being inconsistent. Writing "signed" makes it clear and explicit that we are dealing with signed types - no one has to read "int" or "int64_t" and remember that by default integers are signed in C++. Or are you happy that /sometimes/ it's okay to write short code whose meaning is clear to everyone reading it, and you don't have to write out /everything/ in the longest, most explicit manner? I think it turns out that you too understand that "a happy medium" is the ideal - not too long, not too short, not too explicit, not too implicit. You might have a personal preference towards slightly longer than the preferences of the "average" programmer, but that's detail rather than principle. > Also, those two lines are not equivalent. It's not *merely* about naming > conventions in this example. There's a functional difference. There is - and I know the difference, and stated it. But I actively choose the version that is marginally subpar in the technicalities of what the code means, precisely because the "int64_t" version is clearer and easier to understand, primarily because it is shorter. >> KISS means "Keep it simple, stupid" - not "Keep it stupid". > I suppose you choose to insult your readers then, rather than the second S > referring to the code itself. "KISS" is a well-known acronym and guiding principle throughout engineering (not just programming). The "stupid" is not an insult as such, and is targeted at the developer not the reader - it means it is a stupid idea to make things more complicated than necessary. If you prefer Einstein's version, "make things as simple as possible, but no simpler". > Either way, I'd rather code be readable and understandable than simple. I'd rather it be /both/ - because they are strongly correlated. Simple code is easier to read and understand. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Dec 13 01:11AM -0800 > I didn't actually meant that he didn't understand what I was saying. > 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. > still insulting. I don't even understand what the person who came up with > it was thinking. No wonder there are myriads of alternatives that replace > the "stupid" with something less offensive. That's a valid opinion, but plenty of people use the term, knowing exactly what it means, without meaning to be insulting. It's humor, which can be a very individual thing. I understand that you find it offensive. Please understand that others find it more humorous than offensive, even understanding what it means. If someone directly calls me stupid, I'll be insulted. But as part of a well known saying that's been around for decades, it's different in ways 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. > thing stupid" would mean something like "don't try to make it too clever > for its own good". After all "stupid" and "simple" can be thought of > as synonyms.) It's not at all plausible that Kelly Johnson, cited as the originator of the term, meant "simple and stupid". It's 100% clear that the word "simple" refers to the thing and "stupid" refers to the person being spoken to (implying that they're stupid for not designing the thing to be simple). Again, I understand if you find that insulting, but it's a form of humor that a lot of us find amusing and inoffensive. > When "simple" is interpreted as "short" (eg. using just one word > instead of three) then quite often they are in conflict, especially > when speaking about code. I don't think anyone is arguing that brevity is the only thing that contributes to simplicity. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| Juha Nieminen <nospam@thanks.invalid>: Dec 13 10:20AM > Of course I understand, and agree with that principle. The sticking > point seems to be that you apparently have difficulty understanding that > short code can be easy to understand - easier than long versions. Believe me, by this point in my life I have read enough other people's code to know for a fact that overtly short naming schemes make code harder to understand, not easier. You can claim the opposite until the cows come home, but you cannot erase my personal experience of *actually* having read *tons and tons* of code written by other people, and seeing the difference it makes when things are clearly named vs. when cryptic abbreviations and acronyms are used, or when too few words are used to describe the variable, function or type, or when eg. types are being hidden behind 'auto' keywords for no good reason. (Also, when function overloading is overused for no good reason.) > easier to understand - people generally write "long" instead of "signed > long int" precisely because it is shorter and requires less cognitive > effort to understand. There's absolutely nothing in "signed long int" that makes it harder to understand than "long". It just has a lot of redundancy that doesn't add any relevant information. But compare that to, for example let's say, a function named "generate()". Generate what, exactly? That function name would benefit a great deal from additional words that describe what it's generating (and this information would not be redundant). Or consider a function named "convert()". Convert what, exactly? And into what? This, too, would greatly benefit from having more words telling the reader what it's doing. This is different from "signed long" vs "long", where the additional word doesn't add any new clarifying information and is redundant. But by all means, if you want to specify the 'signed' for extra clarity, go right ahead. It doesn't make it harder to understand. > "auto", used appropriately, can do the same thing. I can't think of many situations where 'auto' actually increases how easy the code is to understand. There might be situations where it doesn't decrease understandability, but not many situations where it actually increases it. > Of course they write "ret" instead of "returnValue" - it makes the code > easier to understand! It absolutely doesn't. It only makes code more compressed and removes useful information. At the very most you could perhaps claim that it doesn't make the code harder to understand. It absoutely does not make the code *easier* to understand. > an index variable "i" because it is short and /clear/. Calling it > "loop_index_counter" makes the code harder to read and understand - > longer and more explicit is directly counter-productive. It being longer doesn't make it harder to understand. In this particular example you are just, once again, adding *redundant* information to it. "index" is better than both "i" (because "index" is an actual English word that expresses what the variable is) and "loop_index_counter" (because it contains useless redundant information). A better name than "index" would be to express what it's indexing. For example "coordinate_index", or "word_index", or "column_index", or whatever it's indexing is better than just "index" because it's actually telling you what it's used for. For the millionth time: It's not about making the names *longer*. It's about making the *clearer*. There's a difference. Do you understand what I'm trying to say? |
| Juha Nieminen <nospam@thanks.invalid>: Dec 13 11:10AM > Believe me, by this point in my life I have read enough other people's > code to know for a fact that overtly short naming schemes make code harder > to understand, not easier. Not that probably anybody is interested, but anyway, after all that I have come up with a few principles when it comes to naming in order to make code easier for a third-party (who has never seen the code before) to read: - Always use full English words instead of contractions and acronyms. "return_value" is better than "ret". "error_code" is better than "err". "generateRandomValue" is better than "genRandVal". "column_index" is better than "i". (An exception is if the contraction or acronym is universally used and understood, like "GPS", "HDMI", "cos", "tan", etc.) - Use as many words as needed to make it clear what the variable, function or type is doing (but in general avoid redundancy, as that doesn't really add any useful information to the name). "error_code" is better than "error" or "code". "convert_to_utf16_from_utf8" is better than "convert". (Note: It's not about making the name longer. It's about making it clearer and more unambiguous, and easier to understand what it's doing.) - Don't use function overloading unless there's an actual good reason to use it (eg. because the function will be used in templated code). Avoid overloading just for the sake of overloading. Always name the functions in a disambiguating descriptive manner and prefer unique names, if possible. (Even when overloading is needed, prefer still implementing the functions with unique names, and make the overloads call those. In code that doesn't need the overloading call the uniquely named versions of the functions.) - Don't overuse 'auto'. Use it only when there's a good technical reason to use it. Don't use it to merely save typing, or as some kind of equivalent to a 'var' keyword in other languages. If there's a type that's extremely long when typed out in its entirety, you could create a 'using' alias that's shorter but still as clear and unambiguous as possible (that still makes it very clear what it is). - Almost always use namespace prefixes when using names inside a namespace, even in code that's inside the same namespace. (This is 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.) |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 13 11:38AM >> missile->launch(); >> Clearer? > You still forgot to check for nullptr: So did you. I left that unaddressed because it has nothing to do with my point. Once again, examples like yours (with or without the nullptr 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. -- Ben. |
| Serena Pascal <serepasca7@gmail.com>: Dec 13 03:10AM -0800 This is the PDF eBook version for Autoimmune Diseases of the Skin 3rd Edition by Michael Hertl (Download link for cheap price) https://booksca.ca/library/ebook-autoimmune-diseases-of-the-skin-3rd-edition-by-michael-hertl/ |
| "Öö Tiib" <ootiib@hot.ee>: Dec 12 05:40PM -0800 On Monday, 12 December 2022 at 22:53:46 UTC+2, Lynn McGuire wrote: > "Why ISO C++ Is Not Enough for Heterogeneous Computing" by Intel > https://www.codeproject.com/Articles/5348333/Why-ISO-Cplusplus-Is-Not-Enough-for-Heterogeneous > That is a lot of custom code. One would hope for more compiler automation. They just want a programming language where all can be burdened upon programmer: 1) figure out what mixture of resources is available in system 2) split the algorithm into components that map well to available resources 3) spread the tasks to the resources 4) schedule it well so bottle-necks are minimal 5) take into account and adapt to different usage patterns of end user 6) be responsible for portability to next gen idiotic system they release year later 7) maintain the mess They either implement compilers and standard libraries that take the heterogenous nature of their garbage architecture into account (and C++ language all that is needed for that) or software just runs weakly on it ... and system of competitor will be bought. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Dec 13 08:55AM +0100 Am 12.12.22 um 21:53 schrieb Lynn McGuire: > "Why ISO C++ Is Not Enough for Heterogeneous Computing" by Intel The Problem is Intel Alder Lake not C++. The covered their problems in chip production by building CPUs that have good single core performance and many cores with as little as possible Silicon. Both parameters look pretty in Datasheets, but they are mutually exclusive. This may be just fine for many _multitasking_ requirements. But it is definitely no good choice for number crunching or other parallel computing. 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. Marcel |
| Juha Nieminen <nospam@thanks.invalid>: Dec 13 08:37AM > "Why ISO C++ Is Not Enough for Heterogeneous Computing" by Intel > https://www.codeproject.com/Articles/5348333/Why-ISO-Cplusplus-Is-Not-Enough-for-Heterogeneous > 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. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 12 11:08PM -0800 On 5/12/2022 12:16 PM, Chris M. Thomasson wrote: > Using my experimental vector field to generate a fractal formation. Here > is generation two: > https://fractalforums.org/gallery/1612-120522191048.png Spiralotica An adventure in vector land... Gotta love C++ and modern opengl. :^) https://fractalforums.org/gallery/1612-131222070556.png |
| 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