- Overuse of 'auto' - 19 Updates
- Christmas Quiz 2022 - 1 Update
- "Why ISO C++ Is Not Enough for Heterogeneous Computing" by Intel - 3 Updates
- sizeof() - 1 Update
- Sometimes optimization *does* matter - 1 Update
| Tony Oliver <guinness.tony@gmail.com>: Dec 19 04:38PM -0800 On Monday, 19 December 2022 at 20:55:13 UTC, Paavo Helde wrote: > > string += c_utf8::from_utf16(utf16arg); > And what does 'c_' mean? Apparently another "universally understood > abbreviation" which I would not know without context. +1 |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 19 07:11PM -0800 On 12/19/2022 1:15 AM, Juha Nieminen wrote: > compressed into a small space full of letters and non-ascii characters. > There's literally no reason to prefer "tpr" over "test_point_right". > There are no benefits of any kind, there are only drawbacks. Oh, man. Didn't you know? tpr stands for: topographic_perspective_recognition Got it? ;^o |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 19 07:18PM -0800 On 12/19/2022 12:54 PM, Paavo Helde wrote: >> string += c_utf8::from_utf16(utf16arg); > And what does 'c_' mean? Apparently another "universally understood > abbreviation" which I would not know without context. Ala c_str? not sure. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 19 07:20PM -0800 On 12/19/2022 10:28 AM, Keith Thompson wrote: >> (But even then... Why? What's the advantage? I see no advantage.) > The advantage is that using 'i' follows an established convention that > has been in use for the better part of a century. Yes. i is widely understood as an index for a loop. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 19 09:09PM -0800 On 12/8/2022 4:31 AM, Juha Nieminen wrote: > in gitlab. Try reviewing code when you can't even see what the types > being used are. > Man, have I learned to hate the overuse of 'auto'... Here is some older work of mine, are the variable names too verbose? https://pastebin.com/raw/Ky6KzwDp (read all...) Not a full program, but the recursive version of one of my ball bearing algorithms. An example: https://youtu.be/DrPp6xfLe4Q |
| Juha Nieminen <nospam@thanks.invalid>: Dec 20 05:58AM >>now. You cannot make what I have seen clearer and easier to understand > Wow, a whole several years. I've been doing it since the mid 90s and I suspect > others on here much longer than that. You have been writing unit tests for existing software, trying to achieve 100% code coverage (something that *really* requires understanding what every single line of code is doing) as your full-time job, 40 hours a week, non-stop, since the 90's? You must have the most boring life I can imagine. Or, alternatively, you don't know what you are talking about. When I say that I have been having to read and understand other people's code for several years now, I really mean it. I do not mean that occasionally I have had to review what someone has done. I really, really mean it. Every. Single. Line. Of. Code. Full time job. You can't write unit tests for existing code unless you really, really understand what the code is doing. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 19 10:05PM -0800 On 12/19/2022 9:58 PM, Juha Nieminen wrote: > really mean it. Every. Single. Line. Of. Code. Full time job. > You can't write unit tests for existing code unless you really, > really understand what the code is doing. For instance, hey everybody, this function in my own personal code plots an n-ary unit cube in one of my experimental vector fields. Can you automatically get it? Or, so you need some/any clarifications, crap code, or what? Keep in mind that is personal... glm is the following opensource header only lib: https://github.com/g-truc/glm ___________________________ // GRID!!!!! :^D Okay, let's go... void build_field_grid_data( field_data& fdata, unsigned long grid_n ) { // double check { /* // front face fdata.m_field.push_back({ {-1, -1, 1, 0}, -1, {1, 0, 0, 0} }); fdata.m_field.push_back({ {1, -1, 1, 0}, -1, {0, 1, 0, 0} }); fdata.m_field.push_back({ {1, 1, 1, 0}, -1, {0, 0, 1, 0} } ); fdata.m_field.push_back({ {-1, 1, 1, 0}, -1, {0, 1, 1, 0} }); */ } glm::vec3 grid_min = { -1, -1, -1 }; glm::vec3 grid_max = { 1, 1, 1 }; glm::vec3 grid_dif = grid_max - grid_min; float normal_base = 1.f / grid_n; unsigned long grid_iter_n = grid_n + 1; for (unsigned long z = 0; z < grid_iter_n; ++z) { for (unsigned long y = 0; y < grid_iter_n; ++y) { for (unsigned long x = 0; x < grid_iter_n; ++x) { glm::vec3 normal = { x * normal_base, y * normal_base, z * normal_base }; glm::vec3 p0 = grid_min + grid_dif * normal; glm::vec4 field_p0 = { p0, 0 }; float field_mass = -1; fdata.m_field.push_back({ field_p0, field_mass -1, { normal.x, normal.y, 1 - normal.z, 0} }); } } } fdata.m_field.push_back({ {-3, 0, 0, 0}, 500, {1, 1, 1, 1}}); fdata.m_field.push_back({ {3, 0, 0, 0}, 500, {1, 1, 1, 1} }); } ___________________________ The same code I used to plot the field points in: https://youtu.be/KRkKZj9s3wk |
| Juha Nieminen <nospam@thanks.invalid>: Dec 20 06:09AM > Making code readable and understandable does not mean making everything > obvious in every line. If you want to understand a piece of /my/ code, > I expect you to have done some basic homework first. And here we come to the crux of the entire problem: You are writing the code for yourself, and expecting the reader to do the "homework" in order to understand it. The onus is on the reader to do the work to understand the code. Good code, however, does the opposite: The onus is on the *writer* to make it as easy for the reader to understand the code as possible. The work to make the code understandable is done by the writer, not the reader. > Perhaps you expect too much from people's code? You are looking to be > spoon-feed on every line, regardless of how much worse the code is for > people who want to have a better understanding of the code as a whole. It still baffles my mind how someone can think that making the code more understandable makes it less understandable. There's an amazing amount of cognitive dissonance here. Either you are... well, I don't want to be explicitly offensive... or you are just arguing for the sake of arguing. I'll give you the benefit of the doubt and assume the latter. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 20 06:12AM >> (But even then... Why? What's the advantage? I see no advantage.) > The advantage is that using 'i' follows an established convention that > has been in use for the better part of a century. I don't see "following an established convention" as some kind of "advantage". It's simply following a custom. Believe it or not, long held customs can be negative. It has been a long held custom to write "using namespace std" at the beginning of every single C++ source and even header file since at least 1998, probably even earlier. Does that make it good practice? No. I don't care if using a single letter for a loop index has been a custom. I care about code readability. If the code consists of nothing but single-character names and symbols, it becomes extremely compressed and thus, often, harder to decipher. When variables actually state out what they represent or what they are doing, the code becomes easier to read and understand. |
| red floyd <no.spam.here@its.invalid>: Dec 19 10:13PM -0800 On 12/19/2022 7:20 PM, Chris M. Thomasson wrote: >> The advantage is that using 'i' follows an established convention that >> has been in use for the better part of a century. > Yes. i is widely understood as an index for a loop. For throwaway loop indices, I actually use "j", as it's an easier grep. Though I guess I could use "grep -w i". |
| Juha Nieminen <nospam@thanks.invalid>: Dec 20 06:16AM > HDMI or cos mean (although supposedly they all should have had learned > the latter in school). With GPS it's maybe better, but still they think > it contacts the satellite first. Most people who write and read code (which is what we are talking about here) don't know what HDMI is? Right. What's with this arguing-for-the-sake-of-arguing? It still baffles my mind how what I have written is *so* controversial that people need to heavily oppose it and present every single stupid counter-argument they can think of, just for the sake of arguing. I'm sorry, but you are not going to convince me to write less readable code by arguing that "most people I know don't know what HDMI is". I cannot even understand why you are presenting such a stupid argument. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 19 10:20PM -0800 On 12/19/2022 10:13 PM, red floyd wrote: >> Yes. i is widely understood as an index for a loop. > For throwaway loop indices, I actually use "j", as it's an easier grep. > Though I guess I could use "grep -w i". :^D Well, I have seem several interpretations of a complex number. j as a component comes to mind. I can understand them. is j is to i as the imaginary part? uv in textures as xy? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 19 10:23PM -0800 On 12/19/2022 10:13 PM, red floyd wrote: >> Yes. i is widely understood as an index for a loop. > For throwaway loop indices, I actually use "j", as it's an easier grep. > Though I guess I could use "grep -w i". I could read it, no problem. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 20 06:23AM >> also an insult. > I am a native English speaker. Yes, "Get into your thick skull > ..." is an insult. Well, it was not originally my intent to use it as an insult. However, by this point I'm actually changing my mind. I just cannot believe why people are arguing for the sake of arguing, against something that should be extraordinarily non-controversial like "name your variables and functions clearly". Such a sentiment seems so highly controversial that now people are resorting to petty "you are now insulting me!!!" whining. What's wrong with people? This is absolutely insane. >> insulting. >> Maybe you also have a thin skin in addition to a thick skull... > Also an insult. Then so be it. I don't care anymore. This entire thing is completely insane. > Nobody here is saying "clearer variable and function naming is a bad > thing". Actually they are. There are people here who in all seriousness are claiming that cryptic acronyms are literally easier to read and understand than names consisting of full words. I'm sorry, but I am not going to be convinced of that. I'm not insane. (There's another "insult", you're welcome.) |
| Juha Nieminen <nospam@thanks.invalid>: Dec 20 06:35AM > Here is some older work of mine, are the variable names too verbose? > https://pastebin.com/raw/Ky6KzwDp > (read all...) Many of the variable names, like "start_angle", "ball_diameter" and "ball_inner_radius", make the code a lot easier to understand (compared to if you had done what a good portion of programmers does, which is to use variable names with 1-3 characters). The meaning of some variables, like "r_i" and "r_max", is less clear. (I don't really think the meaning could even be easily deduced. The "r" probably doesn't stand for "radius", because "radius" is otherwise used unabbreviated in the code. Probably needs more context to know what it is.) At a minimum the code could benefit from some comments explaining what those are, if they can't be written as full words. The parameter name "n" could definitely have been named more clearly, as it's not obvious at all what its role is. In fact, the function name itself, "ct_bearing", could perhaps better tell what it actually does. Personally I'd prefer if you hadn't eschewed the use of the std:: prefix. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 19 11:11PM -0800 On 12/19/2022 10:35 PM, Juha Nieminen wrote: > to if you had done what a good portion of programmers does, which is to > use variable names with 1-3 characters). > The meaning of some variables, like "r_i" and "r_max", is less clear. They are the recursion parameters for this version of ct_bearing. If r_i >= r_max we bail out of the recursion. Yes, they can be better names. For instance, take a look at some more old code of mine, I name them differently: https://pastebin.com/raw/mGar95sa This is a language processing that generates frames for the following rendering: https://youtu.be/4VrMT18Rr84 > used unabbreviated in the code. Probably needs more context to know > what it is.) At a minimum the code could benefit from some comments > explaining what those are, if they can't be written as full words. Agreed. I need to make a heck of a lot more comments. Thank god that the posted code is personal to me. I use pastebin for quick code snippets from time to time. Actually, I have some full programs on there. For instance, can you run this one? It should dump out a list of ppm images for use in a volumetric renderer: https://pastebin.com/raw/v1NNbDRz Some older C99 of mine. When you get some time, does it run for you? > The parameter name "n" could definitely have been named more clearly, It is the n in an n-ary polygon. So, 5-ary would be a pentagon. n = 5 penta. Iirc, this code with its special scales was for a special tiling I did out of the ball bearings. Fwiw, here is an older animation, tiles bearing in a Julia set: https://youtu.be/nrOABous3gc > does. > Personally I'd prefer if you hadn't eschewed the use of the std:: > prefix. I am a C programmer at heart. std::size_t damn it! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 19 11:12PM -0800 On 12/19/2022 11:11 PM, Chris M. Thomasson wrote: > This is a language processing that generates frames for the following > rendering: > https://youtu.be/4VrMT18Rr84 [...] void ct_alien_code_render( int irecur, int irecur_max, float ox, float oy, int imax ) { [...] } |
| Juha Nieminen <nospam@thanks.invalid>: Dec 20 07:22AM >> Personally I'd prefer if you hadn't eschewed the use of the std:: >> prefix. > I am a C programmer at heart. std::size_t damn it! There are several people that I know, and it's my understanding they are far from unique, who fully agree with the sentiment that the 'std::' prefix should always be explicitly used in every name from the standard library, and they do use that prefix every single time... except for 'size_t' and the type aliases from <cstdint>. They consistently and meticulously do not use the prefix with those, ever. They use the prefix with every single other name from the standard library, except with those. I have never heard a good explanation of why. They do it even when are fully aware that those names are officially defined inside the std namespace (and that they are not eg. keywords, or somehow exceptional in that they are officially declared in the global namespace.) (AFAIK that's technically speaking not fully standard-compliant. If I understand correctly, if you just #include <cstdint> those names are not guaranteed to be in the global namespace. In order to guarantee it you have to #include <stdint.h>, or use a 'using' statement. But these people never do either.) |
| David Brown <david.brown@hesbynett.no>: Dec 20 08:23AM +0100 On 19/12/2022 21:54, Paavo Helde wrote: >> string += c_utf8::from_utf16(utf16arg); > And what does 'c_' mean? Apparently another "universally understood > abbreviation" which I would not know without context. I'd guess it meant "C string". But presumably if you had to read or use Scott's code, you /would/ have the context, and then you would know what it meant. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Dec 19 11:40PM -0600 On 12/18/2022 5:43 PM, Chris M. Thomasson wrote: > I have worked on some stuff that would detect a divide by zero condition > and altered it before it occurred. It would log the condition, then > change the denominator. We set the result of all divisions by zero to be zero. Not perfect but usually is a initialization problem. Lynn |
| Lynn McGuire <lynnmcguire5@gmail.com>: Dec 19 06:28PM -0600 >>> Ever had to tow a big boat before? >> I tow a 5,000 lb 35 foot boom lift two or three times a year. I also > A Ford Transit can pull up to 3.5 tons which is 7700lbs. My F-150 can tow up to 13,000 lbs. And has a 38 USA gallon tank for the resulting 8 mpg. Lynn |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 19 07:28PM -0800 > resort to driving a 2.5t pickup to do it and the pickups you do see are usually > work vehicles with company logos on the side. Oh and diesel for obvious > reasons which are probably beyond your average lifestyler. Have you ever towed a boat going down a decent grade? You do not want the boat to be driving you, out of control. Fwiw, there was a big wreck at the bottom of highway 50 going into Carson City. Right by Costco. The big boat got out of control and the driver could not control it. I cannot remember if he had breaks on his trailer or not. Iirc, this is a report of the shit storm: https://www.recordcourier.com/news/2021/nov/15/bail-remains-high-driver-fatal-carson-city-wreck/ An example of person that should not be towing anything! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 19 07:35PM -0800 On 12/19/2022 7:28 PM, Chris M. Thomasson wrote: > report of the shit storm: > https://www.recordcourier.com/news/2021/nov/15/bail-remains-high-driver-fatal-carson-city-wreck/ > An example of person that should not be towing anything! I cannot remember the model of the boat, a Cobalt perhaps? |
| Tony Oliver <guinness.tony@gmail.com>: Dec 19 04:35PM -0800 > oh my! yes I guess one just needs to think. lol, lol > I'm reading a book on C++ and the author I think has gone a bit over board with 'declare a variable right before you need it'. to me it makes the code feel hacked. like, I'm programming while I type, so oh yeah I need this so let me stick it in. plus it, to me, makes the code harder to read. hard to get the overall thought cause he keeps pulling rabbits, variables, out of his hat, so to write. 🤦♂️🙃 memory is plentiful and cheap, relatively speaking. > 😇 You are fir and I claim my £5. |
| red floyd <no.spam.here@its.invalid>: Dec 19 03:45PM -0800 On 12/19/2022 1:11 PM, Marcel Mueller wrote: > I had no such case so far. But I remember an optimization of a monthly > job from 3 weeks - it was challenging to get an interval where none of > the required computers had some maintenance - to some minutes. I had a couple early on in my career. I optimized some code that took 4 hours to run to the point where it only took 15 minutes. It was heavily I/O bound, so I wound up buffering the data. But this was not premature optimization. It came from analyzing where the bottlenecks were. It made it possible for full system builds to be built during working hours, instead of overnight. Another one came from a hardware upgrade. The hardware guys added a SCSI interface to our system (circa 1988/1989), so IPLs, which used to take over 40 minutes only took 30 seconds. This radically changed the way our system test guys worked. Before, if the system indicated some corruption (we had no memory protection on the earlier system), they'd try to go on with the corrupted system, and test other functions. With the 60-fold reduction in program load, they'd restart clean, reload the database, and continue with the testing, guaranteeing a good system. |
| 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