Skip to content

C++14 #236

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.

Sign up for GitHub

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

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

C++14 #236

Show file tree
Hide file tree
Changes from 5 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
db152cf
upgrade to a modern C++ standard
jwmelto Dec 27, 2019
dd0e0d6
clean up the language rules
jwmelto Dec 27, 2019
dab80c8
remove obsolete checks
jwmelto Dec 27, 2019
84c8d5e
Be more conservative. Only go to C++14
jwmelto Dec 27, 2019
d7d458f
removed ShockWaveStrategy warning
jwmelto Dec 27, 2019
1f8f209
remove glu warnings
jwmelto Dec 31, 2019
1a9df5a
remove Known Issues, per macsforme request
jwmelto Jan 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 16 additions & 20 deletions DEVINFO
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -138,19 +138,13 @@ typing explicit references to the "std" namespace. Other namespaces,
especially those defined in BZFlag code, may be introduced with
"using" when it improves code readability.

Only use standard C++ language features, at no time should any
compiler-specific extensions be used (GNU or VisualC++ extensions).
If an extension can not be avoided then it must be able to be disabled
or replaced using a #define in config.h. BZFlag is a cross-platform
application so it is important to remember that not all builds will
use your specific compiler. This also includes not using features
in C99 and C1x as the windows compiler only supports C++11 and
there are some features in the later C versions that were not adopted
by the C++ standard, namely the 'not' and 'or' keywords instead of ! and ||.
Also MSVC seems to be a bit picky about what bits of older standards it
supports. When the windows compiler supports this, we should stick with
a consistent method and not mix AND with &&. Use the same type of operators
that are in the existing code.
Only use standard C++14 language features. Do not use C++17 language
features at this time. Do not use any compiler-specific extensions be
used (GNU or VisualC++ extensions). If an extension can not be
avoided then it must be able to be disabled or replaced using a
#define in config.h. BZFlag is a cross-platform application so it is
important to remember that not all builds will use your specific
compiler.

Formatting
----------
Expand Down Expand Up @@ -224,18 +218,20 @@ The source code serves for examples of the following rules.
should be first, followed by public member functions, protected
member functions, private member functions, and data members.

7) Macro names are all capitals, class names have the first letter
of each word capitalized, all other names have the first letter
of each word except the first capitalized. Only macros may use
underscores, except for in the names of method parameters where
a leading underscore is allowed to make it different from a
member variable.
7) Macro names are UPPERCASE; class names are TitleCase; all other
names are camelCase. All names that begin with an underscore
are reserved to the compiler. The only exception to this is
where a name is scoped (as in a class member). However, BZFlag
does not use this convention. ALL symbols with two consecutive
underscores (FOO__BAR) are reserved to the compiler. Don't use
them. Method parameters may use a trailing underscore to make it
different from a member variable.

#define FOO bar
class MyClass
{
public:
void addStuff(int addMe, int _y) { y = addMe + _y; }
void addStuff(int addMe, int y_) { y = addMe + y_; }

private:
int y;
Expand Down
31 changes: 31 additions & 0 deletions README.macOS
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,3 +20,34 @@ Building BZFlag from Source
---------------------------
BZFlag builds on macOS are now done using premake5 and Xcode 7 (or later).
Please refer to the README.premake5 file for build instructions.


Known Issues
------------
The following warnings can be expected in a MacOS build (for now):

DirectoryNames.cxx:109:13: warning: 'FSFindFolder' is deprecated: first deprecated in macOS 10.8 [-Wdeprecated-declarations]
DirectoryNames.cxx:113:17: warning: 'FSRefMakePath' is deprecated: first deprecated in macOS 10.8 [-Wdeprecated-declarations]

BoltSceneNode.cxx:356:21: warning: 'gluNewQuadric' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
BoltSceneNode.cxx:363:5: warning: 'gluDisk' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
BoltSceneNode.cxx:365:5: warning: 'gluCylinder' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
BoltSceneNode.cxx:416:5: warning: 'gluDeleteQuadric' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
BoltSceneNode.cxx:508:21: warning: 'gluNewQuadric' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]

LaserSceneNode.cxx:152:21: warning: 'gluNewQuadric' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
LaserSceneNode.cxx:160:5: warning: 'gluCylinder' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
LaserSceneNode.cxx:175:9: warning: 'gluSphere' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
LaserSceneNode.cxx:184:5: warning: 'gluDeleteQuadric' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]

SphereSceneNode.cxx:103:27: warning: 'gluNewQuadric' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
SphereSceneNode.cxx:104:5: warning: 'gluQuadricDrawStyle' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
SphereSceneNode.cxx:105:5: warning: 'gluQuadricTexture' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
SphereSceneNode.cxx:106:5: warning: 'gluQuadricNormals' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
SphereSceneNode.cxx:107:5: warning: 'gluQuadricOrientation' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
SphereSceneNode.cxx:112:9: warning: 'gluSphere' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]
SphereSceneNode.cxx:116:5: warning: 'gluDeleteQuadric' is deprecated: first deprecated in macOS 10.9 [-Wdeprecated-declarations]

HUDRenderer.cxx:1117:13: warning: 'gluProject' is deprecated: first deprecated in macOS 10.9 - "Use GLKMathProject" [-Wdeprecated-declarations]
HUDRenderer.cxx:1260:5: warning: 'gluProject' is deprecated: first deprecated in macOS 10.9 - "Use GLKMathProject" [-Wdeprecated-declarations]

24 changes: 5 additions & 19 deletions configure.ac
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -217,18 +217,11 @@ AC_PROG_CXX
if test -z "$CXX"; then
AC_MSG_ERROR([A c++ compiler is required to build BZFlag])
fi
AX_CXX_COMPILE_STDCXX_0X
if test "x$ax_cv_cxx_compile_cxx0x_native" != xyes; then
if test "x$ax_cv_cxx_compile_cxx0x_cxx" = xyes; then
CXXFLAGS="$CXXFLAGS -std=c++0x"
user_CXXFLAGS="$user_CXXFLAGS -std=c++0x" # for --enable-debug
elif test "x$ax_cv_cxx_compile_cxx0x_gxx" = xyes; then
CXXFLAGS="$CXXFLAGS -std=gnu++0x"
user_CXXFLAGS="$user_CXXFLAGS -std=gnu++0x" # for --enable-debug
else
AC_MSG_ERROR([A c++ compiler with C++0x support is required to build BZFlag])
fi
fi

# C++14 is the minimum standard. C++17 isn't widely available
#AX_CXX_COMPILE_STDCXX([11], [noext])
Copy link
Copy Markdown
Member

@allejo allejo Dec 30, 2019

Choose a reason for hiding this comment

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

If we're moving to C++14 being the new minimum, do we need C++11 commented out?

Copy link
Copy Markdown
Member Author

@jwmelto jwmelto Dec 31, 2019

Choose a reason for hiding this comment

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

I left it for comparison but I’m happy to remove it.

Copy link
Copy Markdown
Member

@allejo allejo Dec 31, 2019

Choose a reason for hiding this comment

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

I don't feel strongly either way about this, I was more so curious about its purpose

Copy link
Copy Markdown
Member Author

@jwmelto jwmelto Dec 31, 2019

Choose a reason for hiding this comment

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

It was there in the first place because I wanted to verify that it compiled that way (C++11) vs the old config as a sanity check. As evidenced by the branch name, I intended to go all the way to C++17, but I found the Mac compiler (at least) has insufficient C++17 support). At one time I had flags for all 3 versions. As I tested, I dropped down to just the one. Say the word and this comment is gone.

AX_CXX_COMPILE_STDCXX([14], [noext])
#AX_CXX_COMPILE_STDCXX([17], [noext], [optional])
AC_PROG_CC
AC_PROG_LN_S
AC_CHECK_PROG(AR, ar, ar)
Expand Down Expand Up @@ -531,13 +524,6 @@ else
fi

AC_LANG(C++)
AC_CHECK_TYPES([std::shared_ptr<int>],
[# BZFlag expects std::shared_ptr support by default],
[AC_CHECK_TYPES([[std::tr1::shared_ptr<int>]],
AC_DEFINE([USE_TR1], [1], [Define to 1 to use C++0X TR1]),
AC_MSG_ERROR([[The C++11 std::shared_ptr type is required to build BZFlag]]),
[[#include <tr1/memory>]])],
[#include <memory>])

have_gl=yes
savedLIBS=$LIBS
Expand Down
Loading