Source code comments, fun or profound.

[roger]

However, I'm assuming (perhaps wrongly) that the compiler will respect the declaration if at all possible.

No, register is deprecated in practice, and the next C++ standard officially deprecates it. I don't think any modern compiler implements it. Maybe some Cray compiler does.

caveat: register forbids you from taking the address of the variable, and that is enforced by the compiler. But they absolutely do not pass on the information to the assembly code generator pass - it already optimizes for this sort of thing, and does it better than you can.

For example, Microsoft documentation states:

The compiler does not accept user requests for register variables; instead, it makes its own register choices when global register-allocation optimization (/Oe option) is on. However, all other semantics associated with the register keyword are honored.

 

[roger]

Of course, newer compilers shouldn't allow that sort of off-by-one error, but it still makes me nervous about assuming that the release version will work just like the debug version.

I don't think anybody* makes the claim that the program is guaranteed to run the same in debug and release versions.


* for reasonable values of 'anybody'.

 

[Paul C. Anagnostopoulos]

While assertions are nice for catching problems in your code, I find they are even more useful just as an additional discipline - you are forced to think about the correct range of every variable, what would happen if the range was wrong, etc. It often forces you to go back to the calling routines and upgrade them for correctness. Yes, you should be doing that anyway, but the discipline of putting them in your code creates a very strong habit.

Absolutely. And I leave my assertions in the released code. Of course, these days I'm not writing any that's too performance critical.

I can understand some people poo-pooing the discipline aspect of this. After all, you should be writing robust code this way anyway. All I can say is that in practice I have found writing asserts helps me think through these things, ...

You have to think through these things anyway, so you might as well document your thought process and make the code more robust.

All hail ASSERT!

~~ Paul

 

[SkepticScott]

As others have pointed out, when you compile for release the macro generates an empty statement. However, if your customer can tell you "a message box popped up stating 'assertion on line 73433 of rogerscrappycode.cpp; index < 0'", that can be really handy for tracking down the problem, vs "it crashed".

That would be nice, but most of the products I've worked on don't have a display (e.g., http://www.epinions.com/review/Play..._Don_Interactive_Asteroid/content_64034672260). Many of them won't even have a UART, and that can cause problems if you try to read from non-existent hardware (as part of a serial I/O ISR, for instance).

Another issue is if you are only supplying a component. You often don't have a choice of making the customer's product look bad by popping up an error box. You've got to let their error-handling code handle it and keep presenting a nice interface to the end-user.

I find they are even more useful just as an additional discipline

Yes! That's a benefit I hadn't thought of before.

   ASSERT (MIL1553Bus.isRunning());

I'd never do that. You don't know what MIL1553Bus.isRunning() does; it could access hardware and not accessing that hardware in the production code could cause a problem. Better would be

bool IsMBusRunning = MIL1553Bus.isRunning();
assert( IsMBusRunning );

You may have to declare it "static volatile bool..." at the module level instead of locally to prevent the compiler from optimizing it out once the asserts are disabled.

 

[dasmiller]

I don't think anybody* makes the claim that the program is guaranteed to run the same in debug and release versions.


* for reasonable values of 'anybody'.

FWIW, I write internal engineering analysis tools, and the users are all fellow employees. I simply leave the test code in; if a user wants to run the unit tests, they can.

That's probably not an option for commercial code, though, or for imbedded stuff like SkepticScott described.

 

[roger]

I'd never do that. You don't know what MIL1553Bus.isRunning() does; it could access hardware and not accessing that hardware in the production code could cause a problem. Better would be

bool IsMBusRunning = MIL1553Bus.isRunning();
assert( IsMBusRunning );

You may have to declare it "static volatile bool..." at the module level instead of locally to prevent the compiler from optimizing it out once the asserts are disabled.

Yes, this is another way in which compiling debug vs release can cause different behavior.

The compiler would not optimize out the isRunning() call in your example, would it? How would it know what isRunning() does? It would only optimize away the variable.


Incidentally, I've done plenty of embedded code; as you say, the discipline is rather different.

 

[SkepticScott]

Roger,
You're right. Perhaps I'm being a little too paranoid in embedded code vs. compilers.

 

[dasmiller]

BTW, Roger, from a project I did a few years ago:

    class M1553
    {
        M1553BC m_BusController;
        M1553RT[] m_RemoteTerminals= new M1553RT[nMaxRTs]; // but note that 
            // RT31 is "special" - used for broadcasts

        public M1553(M1553BC BusController)
        {

etc . . .

So your code snippet brought back some fond memories . . .

 

[SkepticScott]

I'm trying to understand a 2400-line program with only 65 comments. The only thing worse than a useless comment is a comment that's wrong. For instance, would you comment the line
++received_packet_count;

I wouldn't since it's obvious why you're doing that (*). However, this author did:
/* increment count of sent packets */
++received_packet_count;

Luckily that line is in a receive_packet() routine so it was obvious which was correct.

* Note: I'd put a comment by the declaration describing how I'm using received_packet_count, perhaps something like "Count packets received so I can compare it to send_packet_count in the send() thread".

 

[SkepticScott]

It's only a test program, but still

We mentioned assert() in this thread. I found this bit of code in a test program

/* check for valid data */
for( i = 0; i < size; ++i )
    assert( sent[i] == received[i] );

OK. It's only a test program and probably never will be compiled with -D NDEBUG, but still! Come on! If it fails, it's not a very useful message. How hard would it be to have written

    if( sent[i] != received[i] )
        printf( "Invalid data at entry %d, received 0x%X, sent 0x%X\n",
                i, received[i], sent[i] );