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

[kingtaurus]

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]

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 notifications@github.com 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 https://github.com/ValveSoftware/vogl/issues/198.

[kingtaurus]

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]

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 notifications@github.com 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 https://github.com/ValveSoftware/vogl/issues/198#issuecomment-74580834.

[lawlove]

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 lawlove@gmail.com 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 notifications@github.com 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 https://github.com/ValveSoftware/vogl/issues/198#issuecomment-74580834.

[kingtaurus]

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 :+1: )

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]

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 notifications@github.com 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: :+1:])

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 https://github.com/ValveSoftware/vogl/issues/198#issuecomment-74602948.

[stevenhoving]

@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.