- Strange compiler warning... - 10 Updates
- Halting Problem Final Conclusion [2021 update to my 2004 statement] - 1 Update
- Ridiculously high standards? - 1 Update
- Happy New Year - 1 Update
| spudisnotyourbuddy@grumpysods.com: Jan 02 10:42AM On Sat, 2 Jan 2021 08:21:28 +1300 >> CPU cycles and needlessly slows the program down. >std::array is no less efficient in this situation. The bounds checking >is a compile time operation. Please explain how bounds checking works at compile time for non literal indexing. |
| David Brown <david.brown@hesbynett.no>: Jan 02 01:23PM +0100 >> is a compile time operation. > Please explain how bounds checking works at compile time for non literal > indexing. I can't answer for exactly what Ian meant, but compilers regularly track ranges that variables can have. And with an array of guaranteed known size, they can warn you in at least some cases if you are going outside that range. This is not the same as run-time access checks - it's just a helpful warning for some kinds of errors that can be found cost-free. A std::array also allows checked access (via the "at" operator), which in general involves a run-time check. In many use-cases, however, the compiler can see that the check will never fail and therefore skip it - but that's by compiler optimisation, not guaranteed by design. A compiler can do some of these checks even with a standard C array. But it quickly loses guarantees about array sizes when they are passed around as parameters - even when the parameter is written as an array type rather than a pointer, the compiler can't rely on that information and thus can't give helpful warnings for errors. Using a std::array, or wrapping the C array in a struct (that is, in effect, how std::array works) gives the compiler more information for better compile-time error checking and better optimisation. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 02 01:37PM +0100 On 02.01.2021 13:23, David Brown wrote: > around as parameters - even when the parameter is written as an array > type rather than a pointer, the compiler can't rely on that information > and thus can't give helpful warnings for errors. Uh, say what? void foo( int (*a)[42] ) { // ... size of a is, not reliably known? I would agree that this practice would give more verbose, harder to read code, and possibly also less efficient code, and that it's very rare. But that it wouldn't give the compiler reliable information? Or are you talking about void bar( int a[42] ) ? > wrapping the C array in a struct (that is, in effect, how std::array > works) gives the compiler more information for better compile-time error > checking and better optimisation. Yes yes. :) - Alf |
| David Brown <david.brown@hesbynett.no>: Jan 02 03:07PM +0100 On 02/01/2021 13:37, Alf P. Steinbach wrote: > Or are you talking about > void bar( int a[42] ) > ? I am talking about this second form - an array parameter rather than a pointer to an array - since that's what the thread is about. The OP's code was: void clear_mac(uint8_t a[6]) ... Certainly if you had a pointer to an array (of fixed size), as in your "foo" (and Chris and Ben's posts), the size of the array is known. (I assume you are talking about the size of the array. Even in the "bar" example, the size of "a" is known to the compiler - it is the size of a pointer. And the size of "*a" is also known - it is the size of an int. Neither are the size of the array.) |
| spudisnotyourbud@grumpysods.com: Jan 02 02:53PM On Sat, 2 Jan 2021 13:23:57 +0100 >> indexing. >I can't answer for exactly what Ian meant, but compilers regularly track >ranges that variables can have. And with an array of guaranteed known Thats fine with simply for() loops where the loop variable(s) are unaffacted by external influences because the compiler can calculate all possible value. And in fact thats how we can have constexpr. But when those variables are influenced from outside it quickly becomes an impossible task. >size, they can warn you in at least some cases if you are going outside Warnings along the lines of something may happen are generally fairly useless IME. |
| Bo Persson <bo@bo-persson.se>: Jan 02 04:03PM +0100 > by external influences because the compiler can calculate all possible value. > And in fact thats how we can have constexpr. But when those variables are > influenced from outside it quickly becomes an impossible task. If you let your array index be influenced from outside, you are probably in for a surprise anyway. Especially if it happens in a way that even the compiler cannot sort out. |
| spudisnotyourbud@grumpysods.com: Jan 02 03:17PM On Sat, 2 Jan 2021 16:03:51 +0100 >If you let your array index be influenced from outside, you are probably >in for a surprise anyway. Especially if it happens in a way that even >the compiler cannot sort out. Depends. Anyway I was talking in general. For a MAC address the code to process it would almost certainly be MAC specific and would have no reason to go off the end of the array or to have checks for such so std::array would be overkill. |
| David Brown <david.brown@hesbynett.no>: Jan 02 05:42PM +0100 > by external influences because the compiler can calculate all possible value. > And in fact thats how we can have constexpr. But when those variables are > influenced from outside it quickly becomes an impossible task. A large proportion of loops are made with a loop variable that is not affected by "external influence". You don't /always/ have a counter that starts at one number, then increments or decrements until it reaches a target - but it is extremely common. Optimisations and static analysis that make use of such situations are therefore useful. >> size, they can warn you in at least some cases if you are going outside > Warnings along the lines of something may happen are generally fairly useless > IME. Experiences and opinions vary. Good static analysis will not find all possible bugs, but it can often find many types of mistake. I'd far rather my compiler spotted the errors it can, as early as possible in the write-compile-test-debug cycle. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 02 07:00PM >>As an aside, a std::array<uint8_t, 6> would be a better choice for a > Why? A MAC is a fixed size which will never change. A C array is > efficient and does the job. I know there's been a long discussion about this, but to answer the "why?": as far as I'm concerned, std::array is (since 2011) the default tool for fixed-size arrays. It's the /other/ solutions that need a motivation. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Ian Collins <ian-news@hotmail.com>: Jan 03 10:08AM +1300 >> is a compile time operation. > Please explain how bounds checking works at compile time for non literal > indexing. Clearly it doesn't. That's why std::array has at(). My point was that std::array is no less efficient that a plain array when used as one. -- Ian. |
| olcott <NoOne@NoWhere.com>: Jan 02 12:12PM -0600 On 9/5/2004 11:21 AM, Peter Olcott wrote: > If we construe pathological self-reference as another > error condition, then this does remove the impossibility > of creating a useful tool. I first came up with this update 2018-12-13 @ 7:00 PM at the Westroads mall Omaha NE. void H_Hat(u32 P) { u32 Input_Halts = Halts(P, P); if (Input_Halts) HERE: goto HERE; return; } It turns out that inputs having pathological self-reference can be decided to be non-halting. The invocation of a halt decider that is based on simulating the execution of its input can be decided to be infinitely recursive in the above case. Within the x86 based execution trace of the above user code: H_Hat() calls the same function from the same machine address with the same inputs a second time with no other control flow instructions inbetween. The above program meets the criteria of a program with infinite execution: Any program that would not halt unless its simulation was stopped is a program with the property of infinite execution. -- Copyright 2004 and 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| "Öö Tiib" <ootiib@hot.ee>: Jan 02 06:41AM -0800 > > What about other remarks of Alf? Let me restore: > > * The need for an account number in invocations. Huh. > I took his advice and made my ReadMe a markdown file. Good. Usage of .md files for giving explanations to contents of repo has been standard for a while. > I don't know what to say to "Huh". Accounts are common. These are used for case when I let customers to post content to my site (to block them from annoying other customers) or when they buy something from me for money (to reduce attempts of cheating). No way I would let anyone identify themselves for reading my site or for downloading and trying something I said is free to try there. > support for accounts. It would be nice to be able to > maintain both a CLI and a web interface, but I decided not > to attempt that. I think the CLI is more important. You do not think what is the benefit of others from you. You think about yourself, how you did things. Throw that away, no one cares. That part only makes it hard for you to make successful things. Care about convenience and benefit of others. People think: That guy annoys with accounts. Do I want to test his stuff so badly to make account? FlatBuffers do not require me to make account. Probably it is some kind of scam to get my e-mail or something and then spam me. Should I manufacture some false, throw-away identity to try his garbage? Yuck. See, you have already lost by asking for account. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 01 04:50PM -0800 On 1/1/2021 7:45 AM, Rick C. Hodgin wrote: > Happy 2021 to everyone. 2020 brought much drama and stress. May 2021 > bring peace. [...] Happy New Year. :^) |
| 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