- Open letter to Mr Stroustrup - 1 Update
- Question on app safety - 4 Updates
| jacobnavia <jacob@jacob.remcomp.fr>: Jun 21 12:50AM +0200 Dear Sir: In article https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/ you say: <quote> Consider the C++11 range-for loop: for (int& x : v) ++x; // increment each element of the container v where v can be just about any container. In C and C-style C++, that might look like this: for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v <end quote> That surprised me... since I remember that <quote> All standard containers provide a size() method that returns the number of elements they actually contain. <end quote> So, the "C-style C++" should be written: for (int i=0; i<v.size(); i++) ++v[i]; // increment each element of the array v What is wrong with this way of writing software? 1) It is very clear 2) No new construct is needed. In your article you complain that C++ should remember a top heavy danish ship that sank after a few minutes sailing. True, but the C++ ship sailed a long time ago. It is this endless complexifying of simple things that makes it so indigest for the mind. The new syntax was supposed to be eaasy to use, but it is not, since it introduces yet another way of specifying the same thing that you have to remember. And that for NO REASON... the "old" way was as good as the new one. Obviously if you put a hard wired preprocessor symbol instead of using the standard size() function it looks ugly. But you shouldn't have to do that in C++... The only reason you put that MAX symbol there, is to make it ugly. Or you aren't aware of that function? Of course you are but you need justifying "YAST": Yet Another Syntax Trash that you have to remember. Avoiding top heavy languages means cutting unnecessary, redundant features such as this one. Yours sincerely Jacob Navia Progammer |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 20 05:17PM -0400 On 6/20/2018 4:39 PM, Ben Bacarisse wrote: > } > printf("common code for pass %d\n", pass); > } I think the goal is to not get past the error condition without crashing, but rather to diagnose it when/if it occurs. In addition, your logic does not match my logic. In my case, pass will be 4 when it exits the loop (provided there is no error). > It's not free from potential problems either (what code is?) but there's > no need to add error cases that don't otherwise naturally arise. I disagree. There should never be a case where a non 1..3 value is encountered, but if there is it should be flagged. In fact, for this purpose I think I will add an opcode to my CPU that enables a global catch-all function for this kind of unexpected error, that does reduce code density and allows it to be setup generically. > with a default case label, and in case it is not clear, I still prefer > to use functions. You get all sort of benefits from adding functions, > not least of which is having more and simpler testable units.) I appreciate your model. I disagree with it. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 20 05:20PM -0400 On 6/20/2018 4:42 PM, David Brown wrote: > The default clause there makes the code continue on - hiding the problem far > better than a crash would. If the default clause were to print an error > message an exit, you would have a point. That's the idea, David. The default: clause calls some function which then essentially logs the error condition and prepares to exit the program because it never should have occurred. In CAlive, it will enter a state called an "inquiry" where it basically traps to a debugger-like environment at runtime and allows the user to interrogate the machine and fix anything or examine or capture anything that's needed to track down the error. And if you're running it from inside the CAlive debugger, you can change your code and data and keep going. I think the inquiry state will be my greatest contribution to computer programming for rapidly developing applications. It allows the edit- and-continue (I called it LiveCode) model to be front-and-center, allowing applications with errors to still compile and run, and only trap to the inquiry state when that code is encountered. > But even if you did that, it is still a bad technique... > [snip] Yup. Have a nice day, David. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 20 05:23PM -0400 On 6/20/2018 5:10 PM, David Brown wrote: > Here I would use: > for (int pass = 1; true; pass++) { > "pass > 0" is a tautology - it is always true - but it looks like a test. It is a test in this case. If pass were ever 4 (which, as Ben pointed out, it could (should) be changed to default:), it would set the value to -1 and loop, causing it to then exit. >> with a default case label, and in case it is not clear, I still prefer >> to use functions. You get all sort of benefits from adding functions, >> not least of which is having more and simpler testable units.) I don't see the advantage of using Ben's solution over mine. I think his suggestion of default: is better, but I don't think issuing a "continue;" is desirable. I think the condition should trap to some function which causes a breakpoint where the developer is notified, or the runtime logs information about itself and politely exits under the error condition. -- Rick C. Hodgin |
| gazelle@shell.xmission.com (Kenny McCormack): Jun 20 10:22PM In article <7f3a4596-ae0a-4f48-b020-b3bd6af4274d@googlegroups.com>, >> If it so easy for RCH to lie about Professor Dawkins, well, that >> says much about RCH. >I have not lied. In an interview with Ben Stein for the movie "No One imagines this alternative universe in which both RCH and DJT don't lie all the time. It takes some doing, though. -- The book "1984" used to be a cautionary tale; Now it is a "how-to" manual. |
| 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