New answers tagged

5

Numbers with limited range arise often enough that (IMO) it's worthwhile adding a type specifically to handle them. I've used something on this order quite a few times: template <class T, T lower, T upper> class bounded { T val; void assure_range(T v) { if ( v < lower || upper <= v) throw std::range_error("Value out ...


3

Don't over-think this. Use an integer. Test your code appropriately. Now move on to the parts of the design that matter. With all due respect, this is a very simple piece of code that seems incredibly unlikely to result in any bugs. There is going to be some code that sets the channel, or increments or decrements it, and this code needs to only allow ...


0

I don't think an enum is ideal for two reasons: It doesn't actually enforce the validity Unless you're hardcoding channel numbers in your source code, it doesn't really give you any safety compared to an integer. You still need to parse user input into a channel identifier, which needs to handle invalid inputs anyways. I'd consider a custom class which ...


1

On the assumption that your code can be tested via an automated test framework on your development machine and that the code can be structured such that the SetChannel function can be mocked/swapped during tests, I'd take the following approach: Use the SetChannel(uint8_t channel) signature. Do no defensive coding in that function; if eg 40 is passed in, ...


1

If it's a number with a limited range, treat it as a number. Make the type of the channel parameter int. Since you can't express the valid range by type, it doesn't make sense to even try. If passing any value other than 0 to 39 is a programming bug, add an assert in your development code so that it gets caught (passing int has the advantage that passing 256 ...


-2

I would go with this: void SetChannel( const int channel ); then check the channel's value. If it is out of range, throw an exception. Having an enum in this case is an awful solution, since it brings nothing into the code clarity.


0

The key to this is to extend the range of the counter that you are using to track time. Just keep a "number of overflows" 32bit counter that you increment each time the millis() value wraps, and use your counter and the millis() value to form a 64-bit counter -- that will give you a wrap time of 50 * 2^32 (or about 200 billion) days -- probably longer than ...


1

If you insist on using millis() to index the array, then you either have to make the array size a factor of the max millis() value, or you have to reset the millis() value to zero when your array wraps. But these seem like bad ideas and I don't understand why you are using millis() to index the array. Think of the array as a circular (ring) buffer. Create ...


3

SCI is not a standard term. Usually it's called a UART, and that's the interface you would use to communicate between the dev board and the PC. SPI is used for communication between chips on a board, supports higher speeds, and has a single master clock. UARTs are used for longer distances, each side asynchronously transmits their own data such that the ...


0

We were able to build OpenSSL for WCE7, same libraries that Linux uses for its application level security. Then we built that into our app. So for your question, we think security wise, it was about the same as Linux. For us, what also helped were tools for debugging, detecting priority inversion problems, and monitoring CPU and memory usage. We found one ...



Top 50 recent answers are included