Added Utils for iOS Task Library Backed by C++ APIs

[priankakariatyml]

No description provided.

[khanhlvg]

typo: utils/c/ , not utills

[khanhlvg]

This change makes the repo unbuildable. Could you fix and make sure that these command can run without errors?

bazel build $(bazel query //tensorflow_lite_support/ios/...)

[khanhlvg]

@priankakariatyml
After importing the PR into internal repo, it turned out that this change is too disruptive and we can't proceed without you removing ios:TFCommonUtils entirely and updating it into utils/c:TFLCommonCUtils and utils:TFLCommonUtils. Unlike Bazel OSS build, our internal build system is more strict about dependency management so that you can't use header file that aren't explicitly included in dependency.

I think the disruptive change this refactor brings doesn't worth its effort, so could you just add + (BOOL)checkCppError:(const absl::Status &)status toError:(NSError **)error; into ios:TFLCommonUtils without splitting the C and C++ utils?

[priankakariatyml]

The problem with adding cpp functions into TFLCommonUtils.m is that this will become an ObjC++ .mm file. Any files that use TFLCommonUtils will also have to become ObjC++ files for this reason. Say TFLImageClassifier.m -> TFLImageClassifier.mm.
Is the dependency issue because of inheritance? If so we can keep the three independent, say TFLCommonUtils, TFLCommonCppUtils and TFLCommonCUtils all inheriting from NSObject. I added inheritance so that the classes that use TFLCommonUtils don't have to import both dependencies, say Image Classifier can import TFLCommonCUtils instead of importing both TFLCommonUtills and TFLCommonCUtils. But this is not necessary, if it is causing an issue at your end.
In that way files that use the C library don't need to be ObjC++ files.

[khanhlvg]

Acked the issue with turning the TFLCommonUtils into ObjC++ if we add the C++ code there. What about creating a new class TFLCommonCppUtils that extends TFLCommonUtils?

We can accept the trade-off that the code will not be very neat to reduce the amount of changes needed.

The problem with the current refactoring is that it caused a lot of changes across many files. When importing the code into internal repo, it leads to many unintentional changes that are very tricky to apply, due to the difference between the GitHub codebase and the internal codebase.

[priankakariatyml]

Acked the issue with turning the TFLCommonUtils into ObjC++ if we add the C++ code there. What about creating a new class TFLCommonCppUtils that extends TFLCommonUtils?

We can accept the trade-off that the code will not be very neat to reduce the amount of changes needed.

The problem with the current refactoring is that it caused a lot of changes across many files. When importing the code into internal repo, it leads to many unintentional changes that are very tricky to apply, due to the difference between the GitHub codebase and the internal codebase.

Got it. I'll retain the C functions in TFLCommonUtils and extend it for Cpp. Also, I think I'll have to revert the folder structure changes.

[priankakariatyml]

Acked the issue with turning the TFLCommonUtils into ObjC++ if we add the C++ code there. What about creating a new class TFLCommonCppUtils that extends TFLCommonUtils?

We can accept the trade-off that the code will not be very neat to reduce the amount of changes needed.

The problem with the current refactoring is that it caused a lot of changes across many files. When importing the code into internal repo, it leads to many unintentional changes that are very tricky to apply, due to the difference between the GitHub codebase and the internal codebase.

I have raised a new PR for these changes: #866