Is there a good reason in C++ to refer to a property without changing it?

I'm using someone else's C++ app as a guide for my own C# application and I've come across a strange pattern:

array[index].property;

No assignment. Nothing evaluated.

I assume this is a vestigial line, left over from when an assignment would have been done here.

But I'm not sure. And seeing as I'm having problems, I'm starting to turn over even the most unlikely rocks.

My question then: does that line do anything? Does it perhaps perform a function akin to touch?

Update - real code

The real code is:

devconfig[fbbloop-1].wAlphaMax;

Where devconfig is an array of the following struct:

typedef struct tagBIRDDEVICECONFIG
{
    BYTE    byStatus;           // device status (see bird device status bits, above)
    BYTE    byID;               // device ID code (see bird devic开发者_开发百科e ID's, above)
    WORD    wSoftwareRev;       // software revision of device
    BYTE    byError;            // error code flagged by device
    BYTE    bySetup;            // setup information (see bird device setup bits, above)
    BYTE    byDataFormat;       // data format (see bird data formats, above)
    BYTE    byReportRate;       // rate of data reporting, in units of frames
    WORD    wScaling;           // full scale measurement, in inches
    BYTE    byHemisphere;       // hemisphere of operation (see bird hemisphere codes, above)
    BYTE    byDeviceNum;        // bird number
    BYTE    byXmtrType;         // transmitter type (see bird transmitter type bits, above)
    WORD    wAlphaMin[7];       // filter constants (see Birdnet3 Protocol pp.26-27 for values)
    WORD    wAlphaMax[7];       // filter constants (see Birdnet3 Protocol pp.26-27 for values)
    WORD    wVM[7];             // filter constants (see Birdnet3 Protocol pp.26-27 for values)
    BIRDANGLES  anglesReferenceFrame;   // reference frame of bird readings
    BIRDANGLES  anglesAngleAlign;       // alignment of bird readings
}
BIRDDEVICECONFIG;

The code you included fits a pattern that I call "This programmer is a goof rocket". The code either does nothing or there is a side effect on which the programmer is depending. In both cases, "This programmer is a goof rocket" is a good description of a programmer who codes like that.

The case of "oh, the previous coder just make a mistake" is mearly a nice variant of "This programmer is goof rocket".

The original developer most likely ran into a bug with the compiler not recompiling some changed files.

This happens fairly often with Visual Studio, less often with more recent versions, when you change some central code and use minimal rebuilds.

Essentially, the compiler will not notice some change and link with old or incorrect object code. The result is some strange behavior that doesn't make sense and is nearly impossible to debug, i.e. a function returning to the wrong address or jumping into the middle of some other function for no apparent reason.

The solution to this is to do a full rebuild, but if the developer doesn't immediately know that this is a mistake on the compiler's side, they might think that the issue is in the code and try to fix it.

Often, introducing a code change that has no actual effect on the functionality of the code will fix the issue. It's also fairly common to see a line that's just 0; used to achieve the same effect. Again, if the developer doesn't know that the issue was caused by the compiler, they might think that this line of code that does nothing is important.

It doesn't do much if the container is indeed an array and index is within array bounds. If the container is is a map, a record will be created for index key.

No, unless the operator [] was overloaded. Even so, it is a weird thing to do. Probably it is a leftover from something else.

No, there's no function to that line. It's a primitive access, so no funky overloading shenanigans going on here. It could be covering up for some compiler bug or error, and it wouldn't be the first time I've seen nonsense lines have to be left in for that reason, but it certainly doesn't serve an actual purpose in the execution of the program.

From your update it looks like the code is just accessing the address of the first item of an array. You can safely remove the line.

Often when you see nonsensical code like that, it was created because programmer wanted to supress some pedantic warning from either the compiler or some static analysis tool.

If you have access to the versioning system, you could maybe go back in time and see during which conditions when it was created...