Yes, these are of course all viable options, so long as one maintains discipline and strives for consistency that's the best we can hope for.

But there are potential gremlins, the memcmp option would probably perform a byte by byte compare of the memory block since it wants to establish equality or greater/lesser, that's a large cost when all we want to know is "are these the same" rather than "how do these differ".

The following however would exploit the "short circuiting" inherent in the evaluation of logical expressions and exploit the fact that multi-byte integer compares are efficiently implemented as single instructions on most if not all, processors.

    // This is the MCU's unique ID, these addresses are specific to the F4 family.

    unsigned long ID0 = (*(unsigned long *)0x1FFF7A10);
    unsigned long ID1 = (*(unsigned long *)0x1FFF7A14);
    unsigned long ID2 = (*(unsigned long *)0x1FFF7A18);

    if (ID0 == board1.fields[0] && ID1 == board1.fields[1] && ID2 == board1.fields[2])
    {
        known = 1;
        return known;
    }

So as soon as any equality check evaluates as false the remainder of the expression is not evaluated, I suspect then that this would require less CPU cycles. If we're really concerned about overall performance of code that might be many thousands of statements, then the effect of relying on memcmp and so on might be quite detrimental especially when we factor in the cost of call/return which involves stack frame management, another cost.

One could craft a compare macro that was sophisticated enough to examine the size of the block and if a multiple of 4 or 8, then iterate over the memory blocks using an int or long pointer and compare that way, that could end up being pretty quick, I've done stuff like this before myself (on minicomputers and Windows) but its reinventing the wheel and a developer's time should ideally focus on the problem domain rather than making up for language deficiencies - IMHO !

 

Yes, these are of course all viable options, so long as one maintains discipline and strives for consistency that's the best we can hope for.

But there are potential gremlins, the memcmp option would probably perform a byte by byte compare of the memory block since it wants to establish equality or greater/lesser, that's a large cost when all we want to know is "are these the same" rather than "how do these differ".

The following however would exploit the "short circuiting" inherent in the evaluation of logical expressions and exploit the fact that multi-byte integer compares are efficiently implemented as single instructions on most if not all, processors.

    // This is the MCU's unique ID, these addresses are specific to the F4 family.

    unsigned long ID0 = (*(unsigned long *)0x1FFF7A10);
    unsigned long ID1 = (*(unsigned long *)0x1FFF7A14);
    unsigned long ID2 = (*(unsigned long *)0x1FFF7A18);

    if (ID0 == board1.fields[0] && ID1 == board1.fields[1] && ID2 == board1.fields[2])
    {
        known = 1;
        return known;
    }

So as soon as any equality check evaluates as false the remainder of the expression is not evaluated, I suspect then that this would require less CPU cycles. If we're really concerned about overall performance of code that might be many thousands of statements, then the effect of relying on memcmp and so on might be quite detrimental especially when we factor in the cost of call/return which involves stack frame management, another cost.

One could craft a compare macro that was sophisticated enough to examine the size of the block and if a multiple of 4 or 8, then iterate over the memory blocks using an int or long pointer and compare that way, that could end up being pretty quick, I've done stuff like this before myself (on minicomputers and Windows) but its reinventing the wheel and a developer's time should ideally focus on the problem domain rather than making up for language deficiencies - IMHO !

True, a member-by-member comparison would probably be twice as efficient. In the beginning at least, when you are first "stubbing out" the program, that is when to break out that old toolbox of ugly macros...and just go to town! Once things are up and running, sure, start looking into necessary optimizations. (But if it ain't broke, don't fix it.)

 

True, a member-by-member comparison would probably be twice as efficient. In the beginning at least, when you are first "stubbing out" the program, that is when to break out that old toolbox of ugly macros...and just go to town! Once things are up and running, sure, start looking into necessary optimizations. (But if it ain't broke, don't fix it.)

Yes indeed, premature optimization is a cause of many a headache.