Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[C++] Are ARROW_DCHECK* and DCHECK* interchangeable? #43209

Closed
zanmato1984 opened this issue Jul 10, 2024 · 3 comments
Closed

[C++] Are ARROW_DCHECK* and DCHECK* interchangeable? #43209

zanmato1984 opened this issue Jul 10, 2024 · 3 comments
Assignees
Labels
Component: C++ Type: usage Issue is a user question
Milestone

Comments

@zanmato1984
Copy link
Contributor

zanmato1984 commented Jul 10, 2024

Describe the usage question you have. Please include as many useful details as possible.

Been developing arrow C++ for a while and I've always been wondering if the ARROW_DCHECK* family and the DCHECK* family are interchangeable. It seems like to be the case from the following straight forward definition:

#define DCHECK ARROW_DCHECK
#define DCHECK_OK ARROW_DCHECK_OK
#define DCHECK_EQ ARROW_DCHECK_EQ
#define DCHECK_NE ARROW_DCHECK_NE
#define DCHECK_LE ARROW_DCHECK_LE
#define DCHECK_LT ARROW_DCHECK_LT
#define DCHECK_GE ARROW_DCHECK_GE
#define DCHECK_GT ARROW_DCHECK_GT

Or is there any subtle convention around them?

Component(s)

C++

@zanmato1984 zanmato1984 added the Type: usage Issue is a user question label Jul 10, 2024
@zeroshade
Copy link
Member

The general convention is that when you are utilizing this from outside of internal Arrow code, you should use ARROW_DCHECK_* to indicate where the macro is coming from. This is the same convention for the RETURN_NOT_OK vs ARROW_RETURN_NOT_OK family of functions.

At least that's my understanding.

@zanmato1984
Copy link
Contributor Author

The general convention is that when you are utilizing this from outside of internal Arrow code, you should use ARROW_DCHECK_* to indicate where the macro is coming from. This is the same convention for the RETURN_NOT_OK vs ARROW_RETURN_NOT_OK family of functions.

At least that's my understanding.

Thanks @zeroshade , that makes much sense. If this is the case, then we should probably put some comments around these macros as a tiny coding guideline.

Let's wait for a while to see if others have any further comments.

pitrou pushed a commit that referenced this issue Jul 16, 2024
### Rationale for this change

I raised my question in #43209 about which I have always been curious. The top answer makes a good sense and after some searching in the code base, I found more evidence like:
https://github.com/apache/arrow/blob/03726178494c8978bf48b9bab15ed9676e7c9196/cpp/src/arrow/public_api_test.cc#L67-L71

So I'm making the following changes to `DCHECK` macro family.

### What changes are included in this PR?

1. Add lint rule for `DCHECK` usage in public headers;
2. Cleanup exisiting `DCHECK` usages in public (probably non-public, but at least not named with `internal`) headers;
3. Add `ifdef` protection for `DCHECK` definition like we did for `ASSIGN_OR_RAISE` (https://github.com/apache/arrow/blob/03726178494c8978bf48b9bab15ed9676e7c9196/cpp/src/arrow/result_internal.h#L20-L22) and `RETURN_NOT_OK` (https://github.com/apache/arrow/blob/03726178494c8978bf48b9bab15ed9676e7c9196/cpp/src/arrow/status.h#L80-L82), to not mess up user code that directly includes `arrow/util/logging.h`.
4. Add comments as guideline.

### Are these changes tested?

No test needed.

### Are there any user-facing changes?

Probably not?

* GitHub Issue: #43209

Authored-by: Ruoxi Sun <[email protected]>
Signed-off-by: Antoine Pitrou <[email protected]>
@pitrou
Copy link
Member

pitrou commented Jul 16, 2024

Issue resolved by pull request 43248
#43248

@pitrou pitrou added this to the 18.0.0 milestone Jul 16, 2024
@pitrou pitrou closed this as completed Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: C++ Type: usage Issue is a user question
Projects
None yet
Development

No branches or pull requests

3 participants