Uninitialized variable not flagged

[DavidWhite]

Can you explain why the failure to initialize variable "I" is not flagged by the compiler?

Thanks,

David

[jimdempseyatthecove]

David, "uninitialized variable" check is a run-time test.

The compiler should have caught "Undefined" variable at compile time. Since the compiler can detect Unused variables, it should be able to detect used but not defined variables. Anything to catch bugs earlier would be a good thing.

Jim Dempsey

[andrew_4619]

I had a whinge about this topic a few weeks back. It really would be a helpful check that would have  saved me a lot of hours of pain.

[DavidWhite]

Thanks, Jim.

I realized that the uninitialized check occurs in runtime after I submitted the post.

As you remark, catching errors earlier would be best.  For my code, since it is part of a DLL called from Excel, runtime testing in debug mode is not always easy to do. This is compounded by having the application having an embedded security system which means I cannot test in debug mode in the VS project folders.

I realized this error before I even tried running it. It made me wonder if I have any other similar errors anywhere else.

Thanks,

David

[andrew_4619]

The inspector thing can find them I believe but I do not have that option.

[jimdempseyatthecove]

If Excel is calling your DLL you have a whole bunch of other things to worry about. You should be able to wring out the simple Fortran coding errors in the restrictive Debug environment. In Release environment you will not have (as much) control over the contents (or lack thereof) of what the Excel sheet is passing into your dll. Therefore, it may behoove you to have a conditional compile option that produces code that emits diagnostic information into the application Event Log. This way you can have at least some feedback as to what went wrong. The final release code can winnow down the event postings to those in error.

Jim Dempsey

[DavidWhite]

Actually, Jim, debugging from Excel works well.  It just requires some manual steps that can be (and frequently are) forgotten.

1. Install my latest production version to the required install folder.

2. Build the debug version of the DLL

3. Copy the debug copy of the DLL to the install folder, so that the copies in the Debug folder and the install location are the same

4. From VS, start debug session with the Debug command set to run Excel.exe (requires full path to location)

5. Once Excel starts, open test workbook, or enter commands into cell that will invoke the DLL.

6. After completing all testing, copy back the release version of the DLL into the install folder or reinstall the app.

The trap is, of course, forgetting to copy the DLL over, and then you end up testing an out of date version, so that your latest source changes have no effect :-(

I can't automate the copy, otherwise I end up always using the debug version of the DLL for real calculations.

Regards,

David