I've done cooperative multitaskers on a number of platforms (not ARM, but I don't think it should present any unusual problems) and found them to be extremely handy in cases where the set of tasks is fixed. Even if a task would spend most of its time in a loop:

while(!x\_ready)
  task\_spin();

the cost to switch to the task, check x_ready, and then switch to the next task may be less than the cost of a more complicated scheduler trying to decide if it should switch to that task. The biggest design issue with a cooperative task switcher is deciding what invariants are going to hold any time code does a task_spin(). While a preemptive multitasker would require that functions acquire locks before breaking any invariant even temporarily, and re-establish the invariant before releasing the lock, cooperative task switching doesn't require that. More significantly, it doesn't require that tasks do anything special to handle the fact that a lock isn't available. The gotcha is that if an invariant can't be upheld during some operation, and the time required to perform that operation could grow beyond the maximum amount of time one wants to go without a task_spin(), handling that situation may be complicated.

I don't think "register" is a good term to describe a system's smallest addressable storage unit. If you don't like "byte", I'd suggest "smallest addressable storage unit" would be a precise term. In any case, I was responding to the claim that the size of a uint32_t is "set in stone" at four bytes for all conforming implementations, which a reasonable person might interpret as saying that sizeof (uint32_t) is required to be 4. I think it's rather silly that the Standard defines no category of programs between Strictly Conforming programs, a category so narrow as to be almost useless, and Conforming programs, a category so broad as to be essentially meaningless, and only defines two categories of implementations, either of which would be allowed (because of the "One Program" loophole) to behave in arbitrary fashion when given almost any program. If the Standard sought to actually categorize things usefully, separating out common-integer-size implementations from weird-integer-size implementations would make a lot of sense. Unfortunately, the authors of the Standard seem to go out of their way to avoid suggesting that some implementations should be considered inferior to others.

leon de boer wrote:

4 bytes each of 8 bits = 4 x 8 = 32 bits .. its unsigned and a type .... so uint32_t :) 8 bytes of 8 bits = 8 x 8 = 64 bits .... so uint64_t also means 8 bytes. Unlike int, long etc the sizes in bits and bytes are fixed in stone on every C compiler that meets the standard.

The size of "uint32_t" is fixed at four bytes on compilers which implement uint8_t. A conforming compiler where "char" is 16 bits (e.g. because it targets a platform where memory can only be written in 16-bit chunks) and either "int" or "long" is a 32-bit two's-complement integer without padding bits must, however, define type `uint16_t` with a size of 1 and `uint32_t` with a size of two.

Vaclav_ wrote:

Here is something which MAY explain the issue. https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html

I don't think that's the issue here, but it does represent something I wish the Standard would address. Although there may be some platforms and application fields for which gcc's behavior would be reasonable in a quality compiler, there are many purposes for which it is not. On many platforms, it is possible for an access to a volatile location to trigger operations that usefully affect other storage (e.g. starting an "in-place" background I/O operation). For an implementation to be suitable for systems-programming on such a platform, it must provide a way of ensuring that such operations are sequenced relative to other operations on non-qualified storage. An implementation can support systems programmings on such platforms without requiring the use of special directives by treating volatile accesses as triggering a call to an unknown function, and I would suggest that quality implementations for such platforms should provide an option to treat them in such fashion. Unfortunately, even though the Standard has to date expressly avoided quality-of-implementation issues, the authors of gcc seem to think either that the Standard fully describes everything necessary to make something a quality implementation, or that users should not expect gcc to behave like a quality implementation when any of its optimizations are enabled. While there might some cases where it might be unnecessarily expensive to treat volatile accesses as sequenced relative to non-qualified accesses to objects that would be accessible by outside code, in most cases the cost would be negligible, and would be less than the cost of adding "volatile" qualifiers and accesses everywhere else that would otherwise be necessary to ensure correct semantics. When the Standard was written, it may have been reasonable to expect compiler writers to exercise good judgment about how quality compilers intended for various purposes should be expected to behave in circumstances beyond those mandated by the Standard, and for programmers to be reliant upon compiler writers' sound judgment. Such expectation and reliance are no longer tenable. If the authors of the Standard don't want to mandate that all compilers treat "volatile" more strongly, they should at minimum specify a predefined macro to allow programmers to say something like:

#if !(\_\_STDC\_VOLATILE\_SEMANTIC

It may be that the person is using a general pattern of testing whether required input conditions are not met by throwing on their inverse. When preconditions are more complicated, it can sometimes be cleaner say something like:

/* Either foo or bar must be true */
if (!(foo || bar))
throw new InvalidArgumentException("Neither foo nor bar was valid");

Than to say:

/* Either foo or bar must be true */
if (!foo && !bar)
throw new InvalidArgumentException("Neither foo nor bar was valid");

If one habitually writes pre-checks based upon preconditions, code will probably read better if one consistently uses the same style. If there will be any need to test preconditions using throw-if-not-met logic, it may be best to do so consistently. Also, btw, if one is going to be pasting code into something like a web-based forum, it may be helpful to write conditions so as to avoid the less-than sign. My usual rewrite of a less-than-zero condition for web posting would typically be "0 > whatever" rather than "!(whatever >= 0)", but some people may prefer the latter style.

CDP1802 wrote:

It sure does its job, wich itself is not really complicated. So why don't you just post your more fitting version?

How about creating a function to check if any two of the three parameters are equal? Calling that function with a parameter from each display mode along with the "matches anything" constant would perform three 'equals' tests.

I wonder if the code at some point had some different instructions, possibly logging, for the null and non-null cases?

What processor were you using that had a "jump far" instruction whose effect could be simulated with many shorter jumps? Were you using a 68000 and with the "bra" instruction rather than "jmp"? The "near jmp" instruction on the 8088 can't go between segments; were you using something else? BTW, I have done some creative code-rearranging on some cycle-critical stuff for processors where conditional branches were limited to +/-127 instructions and I couldn't afford excessive jmp's. From a design standpoint, a horror, but it made things work which would otherwise take too long.

The for() loops seem a rather verbose way of generating all 37,442,160 combinations of 15 pairs chosen from 28, but I wouldn't say they're necessarily horrible. If it is indeed necessary to enumerate all the combinations, nested 'for' loops seem a verbose but time-efficient way to do it. The w1..w15 calculations seem icky, though. Much better to compute the sum of dis1..dis15, and subtract one item from that computation.

Aside from the preprocessor directives and macros, the formatting of that code reminds me of one of the output from one of my C compilers (which compiles code to an intermediate form, optimizes it, and then shows the equivalent C format).

Jeremy Hutchinson wrote:

Take a look at how you'd be hopping around the code on error conditions with what amounts to goto statements (resume NextTable).

VB6 error handling is icky regardless. Depending upon local variable usage, that 'for loop' style may be reasonable. Not great, but given the lack of nice array initializers in VB6 I wouldn't call it horrible. The alternative would be to have a "select case" statement at the start of the loop to set the table name.

RugbyLeague wrote:

Discarding errors is a great way to give the user the perception that all is right with the world.

Old VB6 provided a more convenient means, though: "ON ERROR RESUME NEXT". Unfortunately, its lack of "Try"-style methods for many things(*) tended to make a more appropriate coding style painful. (*) There are many places where one might want to do an operation which one expects might fail, and not worry if it does; e.g. one may want to create a table if it doesn't exist, but ignore it if it does. Checking for existence before creation won't completely solve the problem, since another client might create the table after the existence check. The nicest way would be to say "do command X, but don't worry if it fails." Unfortunately, the only convenient way to do that is with ON ERROR RESUME NEXT, a concept so ugly Microsoft defined a special statement just for it. Incidentally, if a routine does an ON ERROR RESUME NEXT and then invokes another routine that fails but does not have an ON ERROR statement, that other routine will exit out to the routine which did the ON ERROR RESUME NEXT. Nasty, but not so horrible as ON ERROR RESUME, which would restart the entire statement in the parent routine, likely causing many statements in the called routine to be re-executed.

It may be interesting and illustrative to adapt the algorithm to use a queue rather than a stack. If you do that, you will observe the behavior looks as though the filled area "spreads". People who remember BASICA from way back when may recognize the queue-fill behavior as being something like what BASICA did, except that it scanned horizontal line segments directly rather than enqueueing each pixel thereon. Note that the total number of queue entries required will be proportional to the smaller dimension of the area being filled, whereas a stack-based implementation will require stack depth proportional to the number of pixels.

Publicly exposing a lock, or holding the lock across method calls, is insanely poor design.

Agreed, but if one wishes to allow people to nicely enumerate collections I'm not sure there's always a good way around it. Personally, I wish that Microsoft's contract had allowed collections to be changed during an enumeration subject to some restrictions (basically, things which exist throughout an enumeration must be returned once; things that exist for part of an enumeration may be returned at most once) but that's not how Microsoft specified it. I am well aware that locking a collection during enumeration is a dangerous recipe for deadlock, but there isn't always a practical alternative.

Gary R. Wheeler wrote:

An instance member marked private can be the lock value, manipulated solely by members of the class, like this

In your example, the lock is released between calls to the object's functions. If you used the Monitor.* functions, you could have have your code hold a lock when a function returns, but doing so would be even more dangerous than publicly exposing the lock object. The main danger of publicly exposing a lock object is that there's no way the code for the class to protect against deadlock. Having a function which returns while a lock is held poses a much bigger danger, which is that the lock might be accidentally abandoned while it is held.

If one uses outside code that itself uses the threadpool, one's stuck with implicitly using the threadpool for those things. I'm not sure I see a good rationale for something like SerialPort to use the thread pool. Since serial ports tend to persist for awhile and are relatively limited in number, I would think that having each port create a thread which dies when the port dies would be a better approach than having the port use a threadpool thread that may or may not be available.

In fact you cannot ever safely use Delegate.EndInvoke in most code, which shows that this was a big design mistake in the ThreadPool API. My understanding is that Microsoft explicitly denounced fire-and-forget semantics with Delegate.BeginInvoke (as distinct from Control.BeginInvoke, where fire-and-forget is the norm). I think garbage-collection will usually clear up resources left dangling by fire-and-forget code, but according to Microsoft one is supposed to use EndInvoke. How one can do so safely without deadlock I have no idea. My own approach is to simply not use the system thread pool.

Daniel Grunwald wrote:

That's the only possible explanation.

I'm amazed at how many people seem to think that the way to avoid problems with concurrent access to an object is to arbitrarily pick something kinda-sorta related to that object and lock it. They see all the warnings about the risks of locking publicly-available objects and try to avoid doing that, despite the fact that if a lock must be held between calls to an objects methods or properties, it must be publicly available. To be sure, it's often best if things can be arranged so a lock needn't/won't be held while running 'outside' code, but when it's necessary one shouldn't try to avoid exposing the lock.

The code isn't testing for alphanumeric--just alphabetic. That having been said, I don't see anything overly hideous. I would expect VB to recognize the string with the letters and backspace as a constant, so the code simply searches for an input character in a constant string. Not gorgeous (using a named constant called AllowableKeys or something would help), but the list of allowable characters can be easily adjusted by changing the string. If upper and lower case are going to be handled identically elsewhere, it might have been nice to convert to uppercase and just check against uppercase letters. As for my own style, if I were just checking against one contiguous range of characters, I'd use the >= and <= to check the range. With two ranges, or one range plus one or two other characters, I'd still probably use those. With more than that, I'd likely just search in a string with all valid characters.

Define the DFA "state" of an NDFA as being the list of all states that the NDFA "could" be. Then determine for each possible combination of states, what combinations of states could occur as a result of each possible input character. For example, consider the following NDFA: 1. START STATE. If input is "T", maybe advance to state 2. In any case, maybe stay in state 1. 2. If input is "E", advance to state 3. 3. If input is "S", advance to state 4. 4. If input is "T", advance to state 5. 5. If input is "E", advance to state 6. 6. If input is "R", advance to state 7. 7. ACCEPTING STATE. Stay in state 7 regardless of input. It's possible that the machine will only be in state 1 (call that DFA state "1"). If it's in DFA state 1 and it gets a "T", it could be in state 1 or 2 (call that DFA state "1/2"); if it gets anything else, it can only be in state 1. If it's in DFA state "1/2" and it gets a "T", it could be in state 1 or 2; if it gets an "E", it can be in state 1 or 3 ("1/3"). Anything else, it can only be state 1. If it's in DFA state "1/3" and it gets a "T", it could be in state 1 or 2; if it gets an "S", it can be in state 1 or 4 ("1/4"). Anything else, it can only be state 1. If it's in DFA state "1/4" and it gets a "T", it could be in state 1, 2, or 5. Anything else, it can only be state 1. If it's in DFA state "1/2/5" and it gets an "E", it could be in state 1, 3, or 6. Anything else, it can only be state 1. If it's in DFA state "1/3/6" and it gets an "R", it could be in state 1 or 7 (though state 1 won't really matter); if "S", it can be in state 1 or 4; if "T", state 1 or 2. Anything else, it can only be state 1. If it's in DFA state "1/7", one could evaluate further state transitions, but since "acceptance" is guaranteed, they're moot.