Add list of fields found

[marcoffee]

It would be great to have a vector or set containing the names of the fields that were found when decoding the EXIF data.
Not having it is a problem since the fields have default values that could be valid and (I guess that) it is not possible to detect otherwise.

Another option is to use std::optional on the fields, which may be better, but may break old implementations if/when they update TinyEXIF. Also, it requires C++17.

An example where this problem may arise is when 0, despite being unknown, is a possible input value, and developers will not be able to distinguish between the unknown and the missing.

I just added a branch to my fork of this repository that apply the change above, but I'm unsure if I should create a pull request for it.

[cdcseacave]

most of the values should be set to an invalid default value, so you can check if it was read or not; do you have something in particular you need to know?

[marcoffee]

@cdcseacave I would like to know which fields from the EXIF that were set on the file, even if it had an invalid value.

An example is the Orientation field, which can be 0 on the EXIF data and is set to 0 at clear(). How could I know if this 0 came from the EXIF itself (it means, it is present on the file) or it was default set at initialization?

[cdcseacave]

one way is to modify the code to not set it to 0 by default, but a value that can not exist

[marcoffee]

@cdcseacave here is an use-case where that would not work:

Imagine that an user wants to detect invalid (or corrupt) fields inside the exif.
If we fill those with values that can not exist, the user would never know if the value was in fact invalid on the file or if the value was automatically filled by the application.
When we use std::optional or the list of existing keys, the user may check that the invalid value came from the exif.

Another case scenario is that the user wants to log every key and value (including invalid ones) found inside the exif file.
By using invalid values, the user would not be able to differentiate invalid values from non-existing keys and would probably log all of them, which is incorrect.

Adding to my last proposal of solution for this issue, we could use std::shared_ptr for storing the values. It is valid since C++11 (which extends compiler support when compared to std::optional), and can be checked for null values (indicating the absence of a key). Also, it avoids memory leaks by freeing the data when it is not being used anymore. Another option is to use the std::unique_ptr, which is lighter, but do not allow copying of the struct.