Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@mjvankampen
Copy link
Contributor

These are the only two required extension for compilation of flatbuffers using -std=c++11 instead of gnu++11. This makes it explicit where and why these extensions are required.

These are the only two required extension for compilation of
flatbuffers using -std=c++11 instead of gnu++11.
@googlebot
Copy link

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@mjvankampen
Copy link
Contributor Author

@googlebot I fixed it

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@aardappel
Copy link
Collaborator

Can you point to documentation why these defines are needed, and why the headers can't work without them when using -std=c++11 ? This seems strange, never seen this needed before. What OS/compiler are you on?

@vglavnyy have you seen this before?

@vglavnyy
Copy link
Contributor

vglavnyy commented Sep 26, 2019

Probably this connected to CYWIN (MinGW).
Library sys/stat.h isn't part of C/C++ standard however all main compilers have it.
The MAX_PATH/PATH_MAX is the same.

Can we replace char abs_path[MAX_PATH] by std::vector<char>(32768)?
AbsolutePath called once in the Parser::Message.

@mjvankampen
Copy link
Contributor Author

mjvankampen commented Sep 26, 2019

Indeed these items are not part of the C++ standard. This means that if you compile according to strict C++ compilation will fail. By setting these feature macros you can enable parts again for a specific file. I think this is a better approach than bluntly enabling all GCC extensions, which is what happens a lot. This way you make clear what part of your program is pure C++, what is POSIX, etc.

As for my use case, I want to use flatbuffers for communication between some industrial equipment and an HMI. For the software on the equipment you want to maximize portability and minimize the amount of non-standard stuff you pull in. This means we compile all code using pure C++.

As for OS and compiler I am on Windows compiling with GCC to QNX. But I would expect that you see this with every compiler. Why most of the times you do not notice this is because CMake uses -std=gnu++11 instead of -std=c++11 when you set a standard using CXX_STANDARD as compiler specific extensions are enabled by default: https://cmake.org/cmake/help/latest/prop_tgt/CXX_EXTENSIONS.html#prop_tgt:CXX_EXTENSIONS

https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html#tag_02_02

@aardappel
Copy link
Collaborator

Fair enough, I'll merge it then!

@vglavnyy we can use a larger buffer for _WIN32, but realpath seems hardcoded to use MAX_PATH buffers?

@aardappel aardappel merged commit 625338d into google:master Sep 26, 2019
LuckyRu pushed a commit to LuckyRu/flatbuffers that referenced this pull request Oct 2, 2020
* Adds XOPEN_SOURCE for PATH_MAX and POSIX 1993 for stat

These are the only two required extension for compilation of
flatbuffers using -std=c++11 instead of gnu++11.

* Sets _XOPEN_SOURCE to 600 and enable POSIX2001 for fseeko
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.

4 participants