After having searched the web for a bit I've come to the conclusion that designated initializers are not part of any C++ standard, yet when compiling this code using g++ (4.7.0)
#include <iostream>
using namespace std;
int main(int argc, char** argv)
{
int test[2][2] ={
[0]={1,2},
[1]={3,4},
};
for (int x = 0; x<2;x++)
{
for (int y = 0; y<2; y++)
{
cout << test[x][y] << endl;
}
}
return 0;
}
it will compile and run fine.
Am I missing something ? From everything I have read C++ should not support this type of code.
Each compiler usually has its own language extensions. It is valid as for g++ and as for example MS VC++. For example in MS VC++ you can use statement for each.
It seems you found a feature of the gcc compiler: an undocumented extension that cannot be suppressed or be warned about by using any options (such as -pedantic -std=XXXX).
If you want to be reasonably certain that your code complies with the standard, I recommend to always use a variety of compilers and make sure your code passes all of them without warnings (and use the most strict warning options). gcc and clang are free, so you can always use at least two compilers (and clang is quite good at standard compliance).
Related
The below code snippet is using nlohmann-json library.
However the output differs between MSVC and GCC compilers (both compiled using -std=c++14).
MSVC outputs:
{"test":[]}
gcc outputs:
{"test":[[]]}
Code snippet:
#include "nlohmann/json.hpp"
#include <iostream>
int main() {
nlohmann::json output;
output["test"] = { nlohmann::json::array() };
std::cout << output.dump() << std::endl;
return 0;
}
The line output["test"] = { nlohmann::json::array() }; is triggering the difference in behavior. Removing the curly brackets around nlohmann::json::array() will align the behavior and always output {"test":[]}.
It seems the initializer list { json::array() } is interpreted by GCC as: json::array({ json::array() }) for some reason.
Could this be a potential bug in the json library, in GCC/MSVC or is there another explanation?
The nlohmann library has an already known issue with brace initialization and different compilers.
They mention this issue in the FAQ.
The workaround the library authors propose is to avoid brace initialization.
Please see below code snippet it is compiled and run fine in C++03/C++11.
#include <iostream>
using namespace std;
int main(){
int a = 0b1111;
cout<<"a:: "<<a<<endl;
int var = 4;
if(var == 0b0100)
cout<<"True----------------\n";
else
cout<<"Flase---------------\n";
return 0;
}
Output:-
a:: 15
True----------------
Please help me what is the difference in C++03 and C++14 binary literal
Even Binary literal could be used in c++03/C++11.
If you use the -Wpedantic compiler option it emits warnings in C++03/C++11 mode:
warning: binary constants are a C++14 feature or GCC extension
Binary constants are a C language extension provided by GCC. Their extensions documentation says "most of them are also available in C++" which explains why it compiles.
I read that array size needs to be known at compile-time. However, when I do this, it compiles and runs just fine without giving any errors...how come?
#include <iostream>
int main() {
int size;
std::cout << "Enter size: ";
std::cin >> size;
int a[size];
return 0;
}
You aren't compiling it as strictly conforming C++, but using an extension borrowed from C99.
Use -Wall -Wextra -pedantic -std=c++14 to make the compiler complain.
And remember that a conforming compiler only needs to output a single diagnostic on encountering a construct the standard deems ill-formed.
Variable length arrays are a reality in C++ and apparently also in C.
https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
This code compiles fine in Bloodshed Dev-C++ 4.9.9.2, but in Visual Studio 2010 I get an error: expression must have a constant value. How do I make an array after the user input about array size without using pointers?
#include <cstdlib>
#include <iostream>
using namespace std;
int main()
{
int size = 1;
cout << "Input array size ";
cin >> size;
int array1[size];
system("PAUSE");
return 0;
}
Use an std::vector instead of an array (usually a good idea anyway):
std::vector<int> array1(size);
In case you care, the difference you're seeing isn't from Dev-C++ itself, it's from gcc/g++. What you're using is a non-standard extension to C++ that g++ happens to implement, but VC++ doesn't.
The ability to size automatic arrays using a variable is part of C, not part of C++, and is an extension that GCC seems to want to foist on us all. And DevC++ is an unholy piece of cr*p, although it is not at fault here. for a change (this is entirely GCC's doing) - I can't imagine why you (or anyone else) would want to use it.
You should really compile your C++ code with GCC with flags that warn you about stuff like this. I suggest -Wall and -pedantic as a minimum.
Or
int array1 = new int[size];
will work aswell I believe (been a month or 3 since I last touched C++)
But indeed, if using C++, go for an std::vector, much more flexible.
So, when compiled with the basic icc bob.cpp -o bob and run, the following code segfaults:
#include <string>
int foo () {
return 6;
}
int main() {
std::string t[foo()];
}
The following two similar programs, however, seem to run fine.
#include <string>
int foo () {
return 6;
}
int main() {
int f = foo();
std::string t[f];
}
and
#include <string>
int foo () {
return 6;
}
int main() {
std::string t[6];
}
I'm a bit confused about what's going on. Apparently, variable length arrays are non-standard, and this was a surprise to me since I've always used g++ which supports it. However, if it's not supported by ICC, why would it compile? Also, why would example 2 "work"?
What is correct code here, and, if the first snippet is incorrect, why does it compile, and then why does it segfault?
I'm using icc (ICC) 12.0.2 20110112 on 2011 x86_64 Intel(R) Core(TM) i5.
Thanks
Well, while it is true that C++ has no variable-length arrays (C99 does though), apparently ICC does support them as an extension, since your code actually compiles (and since your second snippet actually runs without crashing).
If the first version crashes, then it must be a bug in ICC's implementation of that non-standard extension.