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

Fix windows warnings (C4554, C4018) and mark error message constants as constexpr (C26814) #8360

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

Noremos
Copy link
Contributor

@Noremos Noremos commented Dec 24, 2024

No description provided.

@aafemt
Copy link
Contributor

aafemt commented Dec 24, 2024

You should add check that __cplusplus macro has value high enough. They appeared only in C++11.

@sim1984
Copy link

sim1984 commented Dec 24, 2024

You should add check that __cplusplus macro has value high enough. They appeared only in C++11.

inline constexpr is available since C++17. It is used in more than one place, so CXX_STANDARD 17 is effectively the minimum build requirement.

@aafemt
Copy link
Contributor

aafemt commented Dec 24, 2024

Yes, but iberrors.h is a public header. Firebird build requirements are not applied to public headers.

@sim1984
Copy link

sim1984 commented Dec 24, 2024

Didn't notice right away that the public header was affected. In this case, this PR is incorrect. In this case, you will have to split the implementation C++ < 17 and C++ >= 17.

@Noremos
Copy link
Contributor Author

Noremos commented Dec 24, 2024

You should add check that __cplusplus macro has value high enough. They appeared only in C++11.

Yes, I was sure these errors are used only in internal code and did not pay enough attention to the include location of the file.

@aafemt
Copy link
Contributor

aafemt commented Dec 24, 2024

Actually I see no reason to mark integer constants inline (or even constexpr at all). Anybody does?

@TreeHunter9
Copy link
Contributor

Actually I see no reason to mark integer constants inline (or even constexpr at all). Anybody does?

I think if you have C++17 you should mark every constexpr variable in header file as inline constexpr, because it will use external linkage. For visual difference of external and internal linkage of variables in header file you can watch this video.
And about constexpr, it doesn't have any disadvantages and give you permission to use this variable in constexpr function.

@aafemt
Copy link
Contributor

aafemt commented Dec 24, 2024

External linkage is good for complex types such as strings because it leaves only one instance of data in executable image. But integers? They used to be embedded into assembler code directly even if declared with simple const.

@TreeHunter9
Copy link
Contributor

IIRC if someone will try to take an address or pass by reference this const variable it will be allocated in memory, so in this case, inline will do it job.
And I think the right question about inline should be "why not to use it", not "why should we use it", because inline has no drawbacks as far as I know.

@@ -142,7 +142,7 @@ std::variant<FrontendLexer::SingleStatement, FrontendLexer::IncompleteTokenError

while (pos < end)
{
if (end - pos >= term.length() && std::equal(term.begin(), term.end(), pos))
if (static_cast<decltype(term.length())>(end - pos) >= term.length() && std::equal(term.begin(), term.end(), pos))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use a fixed type, please.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed it to FB_SIZE_T

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants