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

Mass refactor 'unsigned int' ==> 'int' #108

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

Conversation

KevinHake
Copy link
Collaborator

Tried to keep this one only unsigned to int changes. Touches a ton of files. I left libs alone, along with a few things like network_util.

@KevinHake KevinHake requested a review from MHeasell August 11, 2021 04:31
@KevinHake
Copy link
Collaborator Author

KevinHake commented Aug 11, 2021

All the appveyor errors were for spdlog. I don't think this commit touched anything in libs at all, let alone spdlog so I'm not sure what's going on. Everything built for me fine locally, tests passed, the game ran.

C:\projects\rwe\libs\spdlog\include\spdlog\fmt\bundled\format.h(801,1): error C2660: 'std::allocator::allocate': function does not take 2 arguments [C:\projects\rwe\build\librwe.vcxproj]

One difference I have locally is that my spdlog.vcxproj has PlatformToolset set to v142 instead of v140, since I don't have the 140 toolchain installed (I'm using VS2019)

Copy link
Owner

@MHeasell MHeasell left a comment

Choose a reason for hiding this comment

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

Got about half way through here. Vast majority of the changes looked good but there are a couple issues so far that would make me hesistant to merge, in the cob area.

@@ -333,7 +333,7 @@ namespace rwe
auto firstRelevantCommandIndex = (endpoint.nextCommandToReceive - firstCommandNumber).value;

// if the packet is relevant (contains new information), process it
if (firstRelevantCommandIndex < static_cast<unsigned int>(message.command_set_size()))
if (firstRelevantCommandIndex < static_cast<int>(message.command_set_size()))
Copy link
Owner

Choose a reason for hiding this comment

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

message.command_set_size() is already int, could remove this cast altogether?

src/rwe/RenderService.cpp Outdated Show resolved Hide resolved
src/rwe/cob/CobEnvironment.cpp Outdated Show resolved Hide resolved
src/rwe/cob/CobEnvironment.cpp Outdated Show resolved Hide resolved
src/rwe/cob/CobEnvironment.h Outdated Show resolved Hide resolved
src/rwe/cob/CobExecutionContext.cpp Outdated Show resolved Hide resolved
@@ -750,7 +750,7 @@ namespace rwe
}
}

unsigned int CobExecutionContext::nextInstruction()
int CobExecutionContext::nextInstruction()
Copy link
Owner

Choose a reason for hiding this comment

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

instruction opcodes are also probably better left as unsigned? Since they go into a big switch to compare against the opcode literals in OpCode which do make use of the high bit

Copy link
Collaborator Author

@KevinHake KevinHake Aug 25, 2021

Choose a reason for hiding this comment

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

yeah in retrospect I should have left more of the cob stuff alone - I'll change these

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

in fact a few of the headers specify uint32_t so I'll use that explicitly for the returns where it makes sense. Easier to read, and usually when I see those I think of bit masks etc which I think is the right thing here (let me know if I'm wrong)

@@ -120,7 +120,7 @@ namespace rwe
REQUIRE(!r.isAdjacentTo(DiscreteRect(2, -1, 3, 2)));
}

rc::prop("a unit rectangle is adjacent if the point is", [](int x, int y, unsigned int w, unsigned int h, int x2, int y2) {
rc::prop("a unit rectangle is adjacent if the point is", [](int x, int y, int w, int h, int x2, int y2) {
Copy link
Owner

Choose a reason for hiding this comment

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

this will now generate invalid DiscreteRect instances

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This I still need to fix... have to sit down and understand the test better. Reading it quickly I'm confused what's going on

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ah, forgot it's x, y, width, height.
It's a bit strange to me that this test tests the unsigned int rollover behavior for the edges, where intuitively I would think that should never happen in real usage. The game seems to play fine using ints and the asserts don't trigger, so I'll change the test data to only use positive ints.


DiscreteRect() = default;
DiscreteRect(int x, int y, unsigned int width, unsigned int height) : x(x), y(y), width(width), height(height)
DiscreteRect(int x, int y, int width, int height) : x(x), y(y), width(width), height(height)
Copy link
Owner

Choose a reason for hiding this comment

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

I wonder if the constructor should assert or throw if width and height are <0 now that it is possible.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Just brainstorming... So if it is possible they are <0 now, it was possible before that arithmetic errors(?) before would've produced enormous unsigned width/height values. Those also would be bugs, but uncaught. So I guess it could be argued that yes, we should put in an assert, and that is an improvement vs the previous unsigned code. Thoughts @MHeasell ?

Comment on lines 15 to 20
int x;
int y;
GridCoordinates() = default;
GridCoordinates(size_t x, size_t y) : x(x), y(y)
GridCoordinates(int x, int y) : x(x), y(y)
{
}
Copy link
Owner

Choose a reason for hiding this comment

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

I wonder what to do here since GridCoordinates can now hold negative values (and can be default-constructed with them) which is invalid for this struct.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm thinking we can put an assert in the constructor, same reasoning as for DiscreteRect.h

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thinking more, since GridCoordinates and DiscreteRect need the default constructor (as they're used in some other structs that way), the asserts in the non-default constructor don't cover them entirely. I still think the issue is not changed vs unsigned, since the same mistake/error case exists with unsigned (manifesting as enormous numbers with the highest bit set)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Applies to GridRegion and Grid too

@KevinHake KevinHake force-pushed the remove_unsigned_int branch from 34b604e to f495f8e Compare August 26, 2021 23:13
rc::prop("a unit rectangle is adjacent if the point is", [](int x, int y, int w, int h, int x2, int y2) {
rc::prop("a unit rectangle is adjacent if the point is", []()
{
auto x = *rc::gen::positive<int>();
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@MHeasell let me know if this is the right/ideal way to do this

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.

2 participants