Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There is a lot of duplicate code in cytnx. This patch removes some duplication of code in the file I/O in src/Tensor.cpp, src/UniTensor.cpp, src/backend/Storage.cpp. There are sometimes 3 copies of a function, that differ only by taking a filename as an std::string, a const char*, or an fstream. These should be consolidated to one function. I made a start at this, and also improved some of the error messages.
A reasonable model is:
I also improved some of the error messages, although I notice that I missed the one that I copy-pasted above.
A common pattern I see is code like this:
I wonder if this is partly due to the name cytnx_error_msg -- it is not obvious from the name what this does, does it unconditionally show an error message, or does it do some check, or what? I suggest to rename
cytnx_error_msg
tocytnx_error_if(Condition, Message, ...)
to make it clear that it is doing a test of a condition and it does not need to be enclosed in an if (Condition) statement.
Almost every cytnx_error_msg call has "[ERROR] " at the start of the string. The few calls that do not are probably unintentional. So a nice improvement would be to move the "[ERROR] " part of the message into the implementation of cytnx_error_xxx, so the caller doesn't have to repeat the same string every time.
There are also a lot of cytnx_error_xxx calls that include some information about the sub-module, eg "[ERROR][Trace] invalid Type.%s". A better mechanism would be to specify the sub-module separately, for example something like
which could go at the top of a C++ file (or anywhere else, really), and some macro magic would include the module string in the error message.