I want to play with constexpr, does any compiler support it yet?
The Apache Stdcxx project has a nice table detailing which C++0x features are supported by which compilers. It's been updated on a regular basis and covers most of the modern C++ compilers.
According to that, only GCC 4.5 supports constexpr (note that that support may be experimental).
Between that list and what has been said in the comments, it appears the answer is "no."
As of July 2011, gcc 4.7 supports constexpr. You need to build it from svn though.
Agreed, g++ 4.5 and 4.6 support the keyword, but ignore the implications. I just compiled a simple factorial program (on both versions using -std=c++0x) with the line:
constexpr fact(int i) { return (i>1) ? fact(i-1)*i : 1; }
and it compiled and ran but when examining the asm source (-S option) it showed the function was called with the parameter instead of being determined by the compiler.
Usage of "constexpr" is really easy. Look at this piece of code:
constexpr int get_five(){
return 5;}
This function returns always 5, so it can be declared with "constexpr" keyword.
But factorial function returns value depending on argument, so its "output" is not always the same.
Related
The following code contains a fold expression, which afaiu is a c++17 feature:
template <typename... T> static bool variable_length_or(const T ... v) {
return (v || ...);
}
bool foo () {
return variable_length_or(true, false, true, false);
}
what I find odd is that both g++ and clang++ seem to be fine with it when building with -std=c++14 (compiler-explorer). They do create a warning:
<source>:2:16: warning: pack fold expression is a C++17 extension [-Wc++17-extensions]
return (v || ...);
This somewhat indicates that what I'm writing is not okay before c++17, but the compilation succeeds and the code seems to do what it should. I would've expected the compilation to fail.
Any explanation about why the compiler accepts my fold expression?
(credit where credit is due: I took inspiration from this question, and I could check if all T are bool similar to what is suggested here)
A conforming C++17 compiler has to provide fold expressions. But that's a useful language feature, is it worth actively disabling it just because you're compiling in a previous language mode?
Implementations are allowed to provide extensions, provided that they do not alter the behavior of well-formed programs ([intro.compliance]/8). Fold expressions in pre-C++17 are just such an extension - they're purely additive. So as a question of utility tradeoff between allowing and disallowing fold expressions in C++14 mode, it seems that both gcc and clang decided to lean towards allowing.
Of course, you shouldn't rely on this - if you want to write C++17 code, you should compile in C++17. If you want help relying on it, you can compile with -pedantic-errors:
Give an error whenever the base standard (see -Wpedantic) requires a diagnostic, in some cases where there is undefined behavior at compile-time and in some other cases that do not prevent compilation of programs that are valid according to the standard. This is not equivalent to -Werror=pedantic, since there are errors enabled by this option and not enabled by the latter and vice versa.
If you don't add something as -ansi -pedantic, to impose a strict conformance to the standard, the compilers are free to adopt some extensions or, in this case, elements of the following standard.
-ansi -pedantic are the options I add for g++ and clang++; other compilers can use different options, obviously.
-- EDIT --
As pointed by Barry (thanks!), -ansi is no more useful and is enough -pedantic.
As pointed by Passer By (thanks!), can be useful the use of -pedantic-error to impose an error, and non only a warning, in case of not strictly conformance.
I think my compiler understands C++11, but maybe not. Instead of trying it on existing messes of source code which are buggy anyway, is there some simple "hello world" level snippet of source code I can try to compile, which if it does compile without error, proves the compiler is reading it as C++11?
Try this one,
auto f = [](){};
or write some code with rvalue reference.
Shortest thing possible:
[]{};
Is's a lambda-expression without argument list.
The Problem is that compiler usually don't support a new standard completely from the start. Meaning, they may support one c++11 feature, but not another.
However, as far as c++11 is concerned, I think VC++ is the only major compiler that doesn't fully support it, even though you may have to enable the c++11 mode manually. For g++ you e.g. have to supply the compiler flag -std=c++11 (or -std=gnu++11) - the same holds true for newer versions like c++14).
My doubt is that does "auto" keyword works in C++4.3.2? I was writing a program to check the presence of a prefix in a word, I wrote something like this --
auto res = mismatch(prefix,word);
And when I compiled it gave the error--
res was not declared in scope
What should I use in place of "auto" in case if "auto" is not available in c++4.3.2.
Here u can see my full code-- http://paste.ubuntu.com/9351873/
#Surayans Tiwari
Return type of mismatch() is std::pair. Please refer following page and correct your usage.
http://en.cppreference.com/w/cpp/algorithm/mismatch
I have the same opinion with #KeithThompson that you are talking about using GCC 4.3.2 instead of using C++ 4.3.2.
Assume that I perceive correctly, the compilation error that you got is due to the auto type is not supported in GCC 4.3.2 yet.
According to the C++11 support in GCC reference,
https://gcc.gnu.org/projects/cxx0x.html
the auto-typed variables is supported since GCC 4.4.
If you wish to try the feature of auto type, you should use a newer GCC compiler.
I was just wondering why this works in Clang 4.0:
unsigned cnt = 42;
int k[cnt];
But this won't:
unsigned cnt = 42;
string bad[cnt];
I just checked C++ primer 5th edition. It says that:
the dimension must be known at compile time, which means that the
dimension must be a constant expression
If that's true, why does the int k[cnt]; work?
Neither snippet works in C++.
However, in C, it's possible to use non-constant expressions as array sizes. Some compilers (for example, GCC without -pedantic option) support that C feature in C++ code.
As for the difference between element types, it's compiler-specific. GCC compiles both. clang++ prohibits non-POD types (such as std::string) in this case.
What compiler are you using, I am using gcc and both const and nonconst works fine.
It is not a matter of c, arrays are not meant to be defined through variables, only macros and const expressions.
It's a matter of compiler's interpretation, I doubt it is related to standards.
Is clang 4.0 actually apple xcode clang? i think that is actually version 3.1. clang offers a nice explanation itself:
warning: variable length arrays are a C99 feature
[-Wvla-extension]
int k[cnt];
What's the difference between g++ 4.0.0.8 and g++ 4.3.2? These two are the most common C++ compilers that I have seen used in various programming competitions.
I tried to google it, but found nothing.
It's really not such a 'huge list', considering you're interested in the C++ changes between the two.
4.0.0.8 is just a patch revision of 4.0, whose release notes are here: http://gcc.gnu.org/gcc-4.0/changes.html
4.3.2 is a patch revision of 4.3, whose release notes are here: http://gcc.gnu.org/gcc-4.3/changes.html
If you look at the differences between them, I think the following list covers the most important differences between GCC 4.0 and 4.3 that you would really care about.
GCC 4.3.2 has (including changes from GCC 4.1 and GCC 4.2):
Experimental support for the ISO C++0x standard (that's a link)
long long is now officially supported in C++ (though it was an extension provided in older GCC anyway)
Template extern is supported
Right angle brackets like you'd see in std::vector<std::vector<int>> are now supported (note the lack of a space between the two > at the end of the declaration).
experimental support for Variadic Template Arguments
Static assertions
and some others
More TR1 library support
<regex> (gcc 4.3), <random> (gcc 4.2), and <complex> (gcc 4.2)
C++ visibility handling has been overhauled. (GCC 4.2)
Restricted visiblity is propagated from classes to members, from functions to local statics, and from templates and template arguments to instantiations, unless the latter has explicitly declared visibility.
The visibility attribute for a class must come between the class-key and the name, not after the closing brace.
Attributes are now allowed for enums and elaborated-type-specifiers that only declare a type.
Members of the anonymous namespace are now local to a particular translation unit, along with any other declarations which use them, though they are still treated as having external linkage for language semantics.
An undocumented template extension was removed in GCC 4.2 (was deprecated in 4.1)
The (undocumented) extension which permitted templates with default arguments to be bound to template template parameters with fewer parameters has been removed. For example:
template <template <typename> class C>
void f(C<double>) {}
template <typename T, typename U = int>
struct S {};
template void f(S<double>);
is no longer accepted by G++. The reason this code is not accepted is that S is a template with two parameters; therefore, it cannot be bound to C which has only one parameter.
Additionally, check the porting to GCC 4.3 guide, where some important stuff is, like:
Backward compatible/deprecated headers have been removed.
Mostly this means a bunch of pre-standard headers have been removed, like <iostream.h> (use the standard <iostream>), <hash_map.h> (use <tr1/unordered_map>) <hashtable.h> (use <tr1/unordered_map> or <tr1/unordered_set> depending on needs), etc. Again, not a big deal.
Stricter enforcement of standards
For example, the signature on main's two-argument form must be correct.
No duplicate function parameter names
void func(int x, int x); // now an error
And there have been various bug fixes, as well as changes I don't think really affect how you'd write competition code (like removal/addition of new compiler flags), and removal of stuff like the <? and >? operators (ever used those?).
All in all I don't think the differences between the two will cause you much grief if you had to write code for both compilers.
You are wondering about the difference between two different version of g++? It's two common version of GNU C++ compilers. Different Linux releases may have different version of g++ shipped with it. Like my current CentOS 5.5 has g++ 4.1.2 with it.
For you feature details, check the link in you comments.
Since the 4.3.2 is newer then 4.0.0.8, it is more standard compliant. For details, you have to check documentation and release changes