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

[build][Suggestion] Enable C++11 support; #198

Open
kingtaurus opened this issue Feb 16, 2015 · 7 comments
Open

[build][Suggestion] Enable C++11 support; #198

kingtaurus opened this issue Feb 16, 2015 · 7 comments

Comments

@kingtaurus
Copy link
Contributor

I was hoping to see if others want to enable using C++11 standard during compilation. Its trivial to enable, however I don't want to start using C++11 features to update the code base until others are okay with it.

@lawlove
Copy link
Contributor

lawlove commented Feb 16, 2015

I'm game, if nothing else just to get familiar with it. What are the
pros/cons?

On Mon, Feb 16, 2015 at 12:16 PM, Gregory King [email protected]
wrote:

I was hoping to see if others want to enable using C++11 standard during
compilation. Its trivial to enable, however I don't want to start using
C++11 features to update the code base until others are okay with it.


Reply to this email directly or view it on GitHub
#198.

@kingtaurus
Copy link
Contributor Author

There are couple of features that I find useful:
(1) auto, decltype - compiler determined type declaration, common usage for auto:

std::vector<int> my_vector;
auto pos = my_vector.begin();//auto pos will be of type std::vector<int>::iterator

int f = 6;
decltype(f) has_the_same_type = 7;

(2) nullptr - equivalent to 0 or NULL but not convertible to integral types (except bool)
(3) std::hash and std::unordered_map - standard containers (note: hash algorithm is implementation dependent)
(4) lambdas - anonymous functions
(5) std::thread (and concurrence features) - standardized interface for thread, mutex types (linux gcc defaults to posix threads and mutex), atomics, futures and promises
(6) static_assert, constexpr - compile time checks
(7) delete, default, override, final within class definitions - allows for control of compiler construction of class members and inheritance. delete, final can be used to guarantee that an object cannot be used for inheritance.
(8) improved random facilities
(9) better smart pointers (auto_ptr is deprecated): std::shared_ptr provides reference counted smart pointer

Disadvantages:
(1) Older compilers may only have some of the features implemented. I believe GCC 4.8 and clang 3.4 have full support, unsure about VS.clang support, gcc support, VS support
(2) auto can make reading the code more difficult
(3) some features can be implementation dependent

There a few other features (but I haven't used them much) and so I will decline to comment (for example, R-Value references and std::move ...).

@lawlove
Copy link
Contributor

lawlove commented Feb 17, 2015

How much porting would be involved or will the current C++ just work? I.e.
is C++ a superset of C++? I was thinking the conversion would be listed
with disadvantages but maybe not...

On Mon, Feb 16, 2015 at 2:16 PM, Gregory King [email protected]
wrote:

There are couple of features that I find useful:
(1) auto, decltype - compiler determined type declaration, common usage
for auto:

std::vector my_vector;
auto pos = my_vector.begin();//auto pos will be of type std::vector::iterator

int f = 6;
decltype(f) has_the_same_type = 7;

(2) nullptr - equivalent to 0 or NULL but not convertible to integral
types (except bool)
(3) std::hash and std::unordered_map - standard containers (note: hash
algorithm is implementation dependent)
(4) lambdas - anonymous functions
(5) std::thread (and concurrence features) - standardized interface for
thread, mutex types (linux gcc defaults to posix threads and mutex),
atomics, futures and promises
(6) static_assert, constexpr - compile time checks
(7) delete, default, override, final within class definitions - allows for
control of compiler construction of class members and inheritance. delete,
final can be used to guarantee that an object cannot be used for
inheritance.
(8) improved random facilities
(9) better smart pointers (auto_ptr is deprecated): std::shared_ptr
provides reference counted smart pointer

Disadvantages:
(1) Older compilers may only have some of the features implemented. I
believe GCC 4.8 and clang 3.4 have full support, unsure about VS.clang
support http://clang.llvm.org/cxx_status.html, gcc support
https://gcc.gnu.org/projects/cxx0x.html, VS support
https://msdn.microsoft.com/en-us/library/hh567368.aspx
(2) auto can make reading the code more difficult
(3) some features can be implementation dependent

There a few other features (but I haven't used them much) and so I will
decline to comment (for example, R-Value references and std::move ...).


Reply to this email directly or view it on GitHub
#198 (comment).

@lawlove
Copy link
Contributor

lawlove commented Feb 17, 2015

is C++ a superset of C++?
should have been
is C++11 a superset of C++?

On Mon, Feb 16, 2015 at 4:00 PM, Lawrence Love [email protected] wrote:

How much porting would be involved or will the current C++ just work? I.e.
is C++ a superset of C++? I was thinking the conversion would be listed
with disadvantages but maybe not...

On Mon, Feb 16, 2015 at 2:16 PM, Gregory King [email protected]
wrote:

There are couple of features that I find useful:
(1) auto, decltype - compiler determined type declaration, common usage
for auto:

std::vector my_vector;
auto pos = my_vector.begin();//auto pos will be of type std::vector::iterator

int f = 6;
decltype(f) has_the_same_type = 7;

(2) nullptr - equivalent to 0 or NULL but not convertible to integral
types (except bool)
(3) std::hash and std::unordered_map - standard containers (note: hash
algorithm is implementation dependent)
(4) lambdas - anonymous functions
(5) std::thread (and concurrence features) - standardized interface for
thread, mutex types (linux gcc defaults to posix threads and mutex),
atomics, futures and promises
(6) static_assert, constexpr - compile time checks
(7) delete, default, override, final within class definitions - allows
for control of compiler construction of class members and inheritance.
delete, final can be used to guarantee that an object cannot be used for
inheritance.
(8) improved random facilities
(9) better smart pointers (auto_ptr is deprecated): std::shared_ptr
provides reference counted smart pointer

Disadvantages:
(1) Older compilers may only have some of the features implemented. I
believe GCC 4.8 and clang 3.4 have full support, unsure about VS.clang
support http://clang.llvm.org/cxx_status.html, gcc support
https://gcc.gnu.org/projects/cxx0x.html, VS support
https://msdn.microsoft.com/en-us/library/hh567368.aspx
(2) auto can make reading the code more difficult
(3) some features can be implementation dependent

There a few other features (but I haven't used them much) and so I will
decline to comment (for example, R-Value references and std::move ...).


Reply to this email directly or view it on GitHub
#198 (comment).

@kingtaurus
Copy link
Contributor Author

I'll try and answer the question:

C++11 is a nearly a superset of C++98/03 (it has a few language extension/new keywords, so using certain features of C++11 can be guaranteed to not compile if forced into C++98/C++03 compliant compiler, I haven't come across much C++98/C++03 (primarily collisions with new extensions/other features) code that doesn't properly compile when using C++11 - further there are a few deprecated features, including auto_ptr<> and throw specifications). This covers most of the features (with small code samples): C++11 FAQ;

To enable using C++11: you can add -std=c++11 (CXXFLAGS). You'll notice a few warnings when compiling with clang (for example- related to the code already and referencing C++98):
(1) warning: variadic macros are incompatible with C++98,
(2) warning: commas at the end of enumerator lists are incompatible with C++98 [-Wc++98-compat-pedantic,Parse Issue]
(3) warning: extra ';' outside of a function is incompatible with C++98 [-Wc++98-compat-pedantic,Parse Issue]
(4) warning: 'long long' is incompatible with C++98 [-Wc++98-compat-pedantic] (this is still valid, provided the compiler supports it, but its non-standard 👍 )

C++ stackoverflow question;

In addition clang/llvm provides tools to migrate to using C++11 idioms.clang-moderize. Documentation of -std compliance mode for clang.

Edit: small corrections;

@lawlove
Copy link
Contributor

lawlove commented Feb 17, 2015

Thanks, that helps. I had looked at that Stackoverflow link but your
specific answer is good to know. And thanks for the other links, the FAQ
and the fact that clang offers a migration tool.

On Mon, Feb 16, 2015 at 5:19 PM, Gregory King [email protected]
wrote:

C++11 is a nearly a superset of C++98/03 (it has a few language
extension/new keywords, so using certain features of C++11 can be
guaranteed to not compile if forced into C++98/C++03 compliant compiler, I
haven't come across much C++98/C++03 (primarily collisions with new
extensions/other features)
code that doesn't properly compile when using
C++11 - further there are a few deprecated features, including auto_ptr<>
and throw specifications). This covers most of the features (with small
code samples): C++11 FAQ http://www.stroustrup.com/C++11FAQ.html;

To enable using C++11: you can add -std=c++11 (CXXFLAGS). You'll notice a
few warnings when compiling with clang (for example- related to the code
already and referencing C++98):
(1) warning: variadic macros are incompatible with C++98,
(2) warning: commas at the end of enumerator lists are incompatible with
C++98 -Wc++98-compat-pedantic,Parse Issue warning: extra ';' outside of a function is incompatible with
C++98 -Wc++98-compat-pedantic,Parse Issue warning: 'long long' is incompatible with C++98
[-Wc++98-compat-pedantic](this is still valid, provided the compiler
supports it, but its non-standard [image: 👍])

C++ stackoverflow question
http://stackoverflow.com/questions/6293075/is-c11-c0x-a-complete-super-set-of-c03
;

In addition clang/llvm provides tools to migrate to using C++11 idioms.
clang-moderize http://clang.llvm.org/extra/clang-modernize.html.
Documentation of -std compliance mode for clang
http://clang.llvm.org/docs/UsersManual.html#differences-between-various-standard-modes
.


Reply to this email directly or view it on GitHub
#198 (comment).

@stevenhoving
Copy link

@kingtaurus, there are even more goodies from C++11. If we would move to C++11 as the default, we can loose the pthread dependency. This means that the vogl_threading_pthreads.h, vogl_threading_win32.h can be removed in favor of a generic one.

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

No branches or pull requests

3 participants