Skip to content

Conversation

@rschoene
Copy link

Here I fix 2 things:

1: There is now a CMake File that kindof builds (at least on my system). It also fetches allegro.
2: It changes some windows-specific calls to C++ standard calls that also work on linux

@maxim-zhao
Copy link
Collaborator

The C++ issues are not so much Windows-specific as MSVC-specific. I think however that the MSVC _s functions promise to leave you a null-terminated string result whereas the replacements here do not, so maybe some extra wrapping is needed?

emu2413/sample.cpp is not actually needed, it would be better to exclude it from CMake or even delete it...

As all the source is compiled as C++, isn't it more correct to #include <cstdint>?

The CMake parts are mostly fine, it might be better to peg the Allegro version to what we use in Windows though? The way it gets zlib, freetype etc is more Unixy and thus the CMake build in Windows may not work so well, but then I guess that's not the goal here.

case 'd':
// Signed decimal
formatted_length = sprintf_s(buffer, buffer_size, "%d", is_byte ? (s8)data : (s16)data);
formatted_length = snprintf(buffer, buffer_size, "%d", is_byte ? (s8)data : (s16)data);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe we should be thinking more C++20 and use std::format here? I know Omar is somewhat allergic to std::string though...

Copy link
Author

Choose a reason for hiding this comment

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

The code looked pretty C, so I wanted to stick with it. Converting to C++ is not the main thing of this MR.

I'd guess such an MR would be significantly bigger 😉

I also did not care too much about the return value on failures. buffer is always != NULL , buffer_size is more then sufficient and the format is also always valid. The remaining code also seemed not to care about negative return values...

Copy link
Owner

Choose a reason for hiding this comment

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

We can simply wrap snprintf. And I believe it is more convenient to use than std::format yes.

I sometimes use my own helper https://github.com/ocornut/str May drag this into the codebase eventually.

As all the source is compiled as C++, isn't it more correct to #include

It provides no added value, and traditionally any C++ headers even the simplest wrapper stuff makes compilation a little slower.

@rschoene
Copy link
Author

Regarding emu2413/sample.cpp: You're right, that's why it's not in CMakeLists.txt. However, when fixing the MSVC stuff, I stumbled over it.
Regarding

isn't it more correct to #include <cstdint>

Yes, it is, but the whole code is pretty C'ish and that would conflict (style-wise) with all the other includes.

Regarding

it might be better to peg the Allegro version to what we use in Windows though

I will look into it

@rschoene
Copy link
Author

I added more "these packages should be installed for allegro", how the pacakages can be installed in win and mac. I'd need a certain label or commit hash to what you use usually to include it in the cmake file...

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.

3 participants