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

More C++ warnings cleanup + C++17 changes #3574

Merged
merged 1 commit into from
Sep 4, 2019
Merged

Conversation

grendello
Copy link
Contributor

A small cleanup which deals with a handful of remaining warnings after enable
more extensive diagnostics in our compilers.

Deal with read(2) definition differences between Android+Unix compilers and
MinGW (on *nix the third argument, count, is defined to be of type size_t
while on MinGW it's unsigned int which caused an integer conversion warning
when building for Windows)

Take advantage of the C++17 if constexpr () construct (works similar to the
preprocessor #if{n}def but is part of the language standard and is type-safe)
as well as the more compact (and less of an eyesore) namespace declaration,
instead of:

namespace xamarin { namespace android { namespace internal

we can now use

namespace xamarin::android::internal

C++17 allows one to declare and define certain static constexpr members
directly in the header file, without the need to add the definition of such
member in a source file somewhere. Take advantage of that.

@grendello
Copy link
Contributor Author

/azt run

@@ -600,8 +607,8 @@ AndroidSystem::setup_environment_from_override_file (const char *path)
size_t nread = 0;
ssize_t r;
do {
size_t i = nread;
r = read (fd, buf + i, file_size - i);
read_count_type read_count = static_cast<read_count_type>(file_size - nread);
Copy link
Member

Choose a reason for hiding this comment

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

should we start using auto for instances like this?

A small cleanup which deals with a handful of remaining warnings after enable
more extensive diagnostics in our compilers.

Deal with `read(2)` definition differences between Android+Unix compilers and
MinGW (on *nix the third argument, `count`, is defined to be of type `size_t`
while on MinGW it's `unsigned int` which caused an integer conversion warning
when building for Windows)

Take advantage of the C++17 `if constexpr ()` construct (works similar to the
preprocessor `#if{n}def` but is part of the language standard and is type-safe)
as well as the more compact (and less of an eyesore) namespace declaration,
instead of:

    namespace xamarin { namespace android { namespace internal

we can now use

    namespace xamarin::android::internal

C++17 allows one to declare and define certain static `constexpr` members
directly in the header file, without the need to add the definition of such
member in a source file somewhere. Take advantage of that.
@jonpryor jonpryor merged commit 753c74b into dotnet:master Sep 4, 2019
jonpryor pushed a commit that referenced this pull request Sep 24, 2019
A small cleanup which deals with a handful of remaining warnings
after enabling more extensive diagnostics in our compilers.

Deal with **read**(2) definition differences between Android+Unix
compilers and MinGW: on *nix the third argument, `count`, is defined
to be of type `size_t` while on MinGW it's an `unsigned int`, which
caused an integer conversion warning when building for Windows.

Take advantage of the C++17 `if constexpr ()` construct (works
similar to the preprocessor `#if{n}def` but is part of the language
standard and is type-safe) as well as the more compact (and less of
an eyesore) namespace declaration; instead of:

	namespace xamarin { namespace android { namespace internal

we can now use

	namespace xamarin::android::internal

C++17 allows one to declare and define certain static `constexpr`
members directly in the header file, without the need to add the
definition of such member in a source file somewhere.  Take advantage
of that.
@github-actions github-actions bot locked and limited conversation to collaborators Jan 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants