Initializer lists should be supported since gcc 4.4 (and I could also use them in other places without problems), yet when I try to compile this with MinGW 4.5.2 I get a "bad array initializer" error. I do compile with -std=c++0x. "points" is just a Vector2D[4].
What am I doing wrong?
BoundingBox::BoundingBox(float width, float height, float posX, float posY) :
points{
Vector2D{posX,posY},
Vector2D{posX+width, posY},
Vector2D{posX+width, posY+height},
Vector2D{posX, posY+height}
} //error: bad array initializer
{
}
Try adding parens:
points({Vector2D{posX, posY}, ...})
instead of
points{Vector2D{posX, posY}, ...}
I don't have a compiler at hand to check it.
Your code compiles with gcc 4.6.1 (linux).
So if there was a bug it has been fixed.
Related
I bought a Surface Go 2 today, and installed Visual Studio 2019. I loaded my project, that successfully compiled on my previous PC, also in VS19.
The first problem that I noticed is that the VS editor displays Unicode characters (Cyrillic) in my .cpp files as hieroglyphs:
card->NewTextW(L"Çàãðóçêà", ...
Instead of:
card->NewTextW(L"Загрузка",
Then I tried to compile the project, but got more then a hundred errors, and all of them were about the compiler can't convert from const wchar/char * to wchar/char *, although, I repeat, that earlier, in another PC, everything compiled successfully. This error appears to almost all types of strings, and for strings with wrong encoding, like mentioned above, and without.
Specific example of error
card->NewTextW(L"Çàãðóçêà", 3, r.right/2-50, r.bottom / 2 - 350 / 2 - 80 + 350 + 60, 10, 20, RGB(0, 0, 0));
card->NewText("eng-string", 4, r.right/2-50, r.bottom / 2 - 350 / 2 - 80 + 350 + 60, 10, 20, RGB(0, 0, 0));
Where card is a pointer to an object of interface virtual class ICard:
class ICard
{
public:
...
virtual void NewTextW(wchar_t *text, int id, int x, int y, int divid, int j, COLORREF col) = 0;
virtual void NewText(char *text, int id, int x, int y, int divid, int j, COLORREF col) = 0;
...
}card*;
Specific example of no error
MessageBoxA(NULL, "aga", "uogou", MB_OK);
Cannot covert from 'const char*' to 'char*' in VS19, although earlier version could
According to the doc: /permissive- (Standards conformance)
By default, the /permissive- option is set in new projects created by
Visual Studio 2017 version 15.5 and later versions. It's not set by
default in earlier versions. When the option is set, the compiler
generates diagnostic errors or warnings when non-standard language
constructs are detected in your code. These constructs include some
common bugs in pre-C++11 code.
As far as I'm concerned, this is a good explanation of why this error did not appear in the earlier version.
It seems like the code is working as is for me on godbolt.org
https://godbolt.org/z/nGz3hcG3c
Not needing to change parameters to const or anything else...
I do get warnings using gcc but not msvc
This looks like a compiler issue on your end, not with msvc19
I wonder if your VS install has a setting that treats warnings as errors?
Check out https://stackoverflow.com/a/66485736/496405 to disable this option.
Using gcc (4.7.2 here) I get warnings about unused auto variables, but not about other variables:
// cvars.h
#ifndef CVARS_H_
#define CVARS_H_
const auto const_auto = "const_auto";
const char const_char_array[] = "const_char_array";
const char * const_char_star = "const_char_star";
const char use_me = 'u';
#endif // CVARS_H_
//---
//comp_unit.cpp
#include "cvars.h"
void somef()
{
//const_auto // commented out - unused
use_me; // not using any of the others either
}
// compile with $ g++ -std=c++11 -Wunused-variable -c comp_unit.cpp
// gcc outputs warning: ‘cvars::const_auto’ defined but not used [-Wunused-variable]
// but does not complain about the other variables
Is this an inconsistency in GCC?
1.1 If so, what should happen in all cases, warning or no warning?
1.2 If not, what is the reason for the difference in behavior?
Note: Concerning 1.1, I imagine no warning should be printed in this case (this is what clang does). Otherwise, any compilation unit including a constant-defining header but not using all the constants within would contain lots of warnings.
These warnings are entirely up to the implementation, so there is no "should". But, yes, I agree: constants would ideally not generate these warnings even when declared using auto.
Since I can reproduce your observation in GCC 4.7 and GCC 4.8.0, but not in GCC 4.8.1 or 4.9, I'd say the guys over at GNU would agree too. In fact, I believe you're seeing bug 57183.
I understand that VLAs are not part of C++11 and I have seen this slip by GCC. It is part of the reason I switched to Clang. But now I am seeing it Clang too. I am using clang 3.2 (one behind the latest) and I am compiling with
-pedantic and -std=c++11
I expect my test to NOT compile yet it compiles and runs.
int myArray[ func_returning_random_int_definitely_not_constexpr( ) ];
Is this a compiler bug or an I missing something?
In response to the comment here is the random_int_function()
#include <random>
int random_int_function(int i)
{
std::default_random_engine generator;
std::uniform_int_distribution<int> distribution(1,100);
int random_int = distribution(generator);
return i + random_int;
}
Yes, variable length arrays are supported in clang 3.2/3.3 contrary to
the C++11 Standard (§ 8.3.4/1).
So as you say, a program such as:
#include <random>
int random_int_function(int i)
{
std::default_random_engine generator;
std::uniform_int_distribution<int> distribution(1,100);
int random_int = distribution(generator);
return i + random_int;
}
int main() {
int myArray[ random_int_function( 0 ) ];
(void)myArray;
return 0;
}
compiles and runs. However, with the options -pedantic; -std=c++11 that
you say you passed, clang 3.2/3,3 diagnoses:
warning: variable length arrays are a C99 feature [-Wvla]
The behaviour matches that of gcc (4.7.2/4.8.1), which warns more emphatically:
warning: ISO C++ forbids variable length array ‘myArray’ [-Wvla]
To make the diagnostic be an error, for either compiler, pass -Werror=vla.
Simply plugging the snippets you posted into IDEone, without putting the array declaration into a function, I get
prog.cpp:12:39: error: array bound is not an integer constant before ‘]’ token
Adding a main() function around it results in success, as you observed.
Since C++11 doesn't allow for array declarations that are legal in main but not namespace scope, and that is a property of VLAs, it is reasonable to conclude that is what you are seeing.
Update: courtesy Coliru.org, the message from Clang is
main.cpp:12:9: error: variable length array declaration not allowed at file scope
So that's fairly definite.
Use these options:
-Wvla to warning vla uses
-Werror=vla to consider vla an error.
This works in both the clang and gcc compilers.
Good time of day!
I compiled this code with g++ 4.7.2 on Ubuntu successfully, but I have problems with compiling it on Windows with Mingw.
Simplified Code:
size_t string_length=some_size;
char arr_symb[string_length+1];
char *outputde=arr_symb;
iconv_t type=iconv_open("UTF-8","WINDOWS-1251");
char output[some_size];
char *p1=arr_symb;
char *p2=output;
if ( iconv(type, &p1,&string_length, &p2, &output_length ) == -1 )// here
// is mistake, it doesn't like pointers p1 and p2 but I wonder why
log_info("something went wrong");
On Linux with G++ it can be compiled and works fine as it should. With Mingw I get errors:
I wonder, if it works fine with g++ , why does mingw treat it like it's mistaken?
Thanks in advance!
ADDITION
My Mingw version is 4.4.0
GCC version is 4.7.2
Thanks all for your attention, problem is solved, but it's all strange to me (it's still unclear )
Although the function has such prototype,
With MinGW it should be called so:
So, the problem is that input string for MinGW should be passed as constant (also it doesn't have such prototype).
See these declarations:
int a[10];
int* b = malloc(10 * sizeof(int));
Looks and feels the same, but:
A pointer to an array of ints (*b) is NOT the same as an array of ints (a)! So a pointer to an array (*) is also not the same as a pointer to a pointer (**)!
The dereferencing for the pointer needs one more level!
I have the following snippet:
#include <boost/random/lognormal_distribution.hpp>
#include <boost/random/lagged_fibonacci.hpp>
int main() {
const double mean = 0.0;
const double sigma = 1.0;
boost::lognormal_distribution<double> lognorm_dist(mean, sigma);
boost::lagged_fibonacci44497 engine;
// the following line give error in GCC 3.3
const double value = lognorm_dist.operator() <boost::lagged_fibonacci44497>((engine));
}
It compile fine under
i686-apple-darwin9-g++-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)
But under:
g++ (GCC) 3.3.3 (SuSE Linux)
It gave the following error:
Mycode.cc:10:error: `operator()' not defined
How can I fix the problem?
Why not just lognorm_dist( engine );? Providing "function-like" syntax is the whole point of operator(). That said, lognorm_dist.template operator() <boost::lagged_fibonacci44497>((engine)) should solve your compilation issues if I am not mistaken.