When compiling my app today, I encountered this warning (the code, I think, is irrelevant):
warning C4315: 'MyClass' : 'this' pointer for member 'MyClass::my_data_' may not be aligned 8 as expected by the constructor
I am not able to find any documentation about this warning, in either the online help, my locally-installed help, or via a google search. I did find one link on a MS forum:
No documentation for compiler warning C4315
But no information about the error itself.
Do you have any information about this error? I'm trying to fogure out how to fix it.
I'd look for something (buried in a header?) changing the structure packing from the default.
The warning seems to be saying that whatever type MyClass::my_data_ is expects to be 8-byte aligned, but it's not being placed at that alignment inside MyClass.
Search for #pragma pack(some-number) directives that aren't reset with a #pragma pack().
Using #pragma pack(show) would probably be helpful, too.
Related
I try to build CRF++ in Visual Studio 2013 and get this error in the last line:
array_[begin + siblings[i].code].base =
value_ ?
static_cast<array_type_>(-value_[siblings[i].left]-1) :
static_cast<array_type_>(-siblings[i].left-1);
error C4146: unary minus operator applied to unsigned type, result
still unsigned
Specifically, it is in darts.h, line 189.
I built again in Visual Studio 2015 then there is no error.
How can I fix this in Visual Studio 2013?
C4146 is not supposed to be an error. It is a mere warning. If you see it as an error in your case, it means that someone has configured it this way, most likely unintentionally. This makes no sense.
Find and undo the changes that turned it into an error. Then you can disable it if you wish.
For others I wanted to add another answer in case they stumble into that bug like me.
Even if "Threat warning as error" was off in my compiler, I had to compile my project with #pragma warning(disable:4146) in my header's file that was showing me the error. For you it would had been inside darts.h
Please note disabling the warning globally in my project was not working (compiler /wd4146), the pragma line was needed in the header's file directly.
the siblings variable also has unary minus applied to it, maybe that is the culprit? Also if it's templated code you cannot really be sure value_ is going to be be short, int or long unless that is asserted via static_assert or so. We can only guess as you don't provide information about what types are actually used or something reproducable. Also did you use the exact same project for compilation in VS2015? If not, the warning might just have been disabled there.
Anyway, suppose it is a bug in VS2013, it likely won't ever get fixed anymore so you can try to find a workaround. Start by breaking that statement down into smaller ones until you know exactly which part is the problem (or maybe, by then the problem is gone already as it goes with compiler bugs). Then suppress the warning with #pragma warning ( disable : 4146 ), wrapped in a conditional directive so it only has effect for VS2013 #if _MSC_VER > 1800 && _MSC_VER < 1900 should do fine. Enable the warning again after the statement. Add a comment as to why the warning is disabled and submit the changes as a patch to CRF++.
Try this:
int tmp = static_cast<int>(siblings[i].left);
array_[begin + siblings[i].code].base =
value_ ?
static_cast<array_type_>(-value_[siblings[i].left]-1) :
static_cast<array_type_>(-tmp - 1);
For anyone running into the really confusing part of this:
This isn't supposed to be an error. In fact, there are a bunch of warnings that Visual Studio incorrectly turns into errors by default. Compilers can add warnings for whatever they want, but throwing errors for valid code is just a bug.
The culprit is the "SDL checks" option. It's known for adding things like runtime stack checking, which is fine, but they snuck a bit of nastiness in: "and enables extra security-relevant warnings as errors". That needs to be turned off to have something slightly closer to a standard C++ compiler.
I would like to suppress the warning #858 in g++:
warning #858: type qualifier on return type is meaningless
and possibly others. I know I've done this before (although this topic seems to say you can't), but don't remember how.
I've been trying to look for this warning in this list to see if I could disable it using -Wno..., but none of them seem to fit.
I've compiled the SQLite amalgamation source into my iOS project, and clang throws a warning on this line
mask = (sizeof(long)==8) ? LARGEST_INT64 : 0x7fffffff;
with the following warning:
Implicit conversion from 'long long' to 'long' changes value from
9223372036854775807 to -1
[warn_impcast_integer_precision_constant]
I've enabled -fdiagnostics-show-name to show the name (warn_impcast_integer_precision_constant).
I certainly don't want to change anything in the SQLite source, since I don't want to introduce unforseen side effects, so I'd like to disable this specific warning just for that one line. The warning is certainly valid, but cannot occur anyway with the sizeof check in place.
To make this process reproducible for other warnings and diagnostics, is there a method to find out the specific warning class and disable them for one line? Unfortunately I can't find anything in the so called clang/llvm "documentation".
Any remotely recent version of clang should be printing the flag associated with a given warning along with the warning (in this case -Wconstant-conversion); not sure why you are not seeing this. And to turn it off, you can use #pragma clang diagnostic ignored "-Wconstant-conversion".
as quoted from the user manual lined by sir Chris Lattner:
In the below example -Wmultichar is ignored for only a single line of code, after which the diagnostics return to whatever state had previously existed.
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wmultichar"
char b = 'df'; // no warning.
#pragma clang diagnostic pop
But more importantly, would it not be more prudent to consider the type of variable that 'mask' is, and what 'mask' represents?
Since you're doing something depending on whether the size of long is 8, should it perhaps be of type uint64_t?
What if sizeof(long) is actually 16 instead of 8 or 4 (which I guess you expect it to be when it is not 8)? Is 0x7fffffff then still the mask you need? Or perhaps you really want to assign it LONG_MAX from limits.h rather then the current construction.
The clang user manual is here:
http://clang.llvm.org/docs/UsersManual.html
It discusses various topics related to diagnostics. There are other useful documents in the sidebar of http://clang.llvm.org/
For example, say for some reason I had a piece of code that looked like this:
mutable std::vector<std::vector<std::vector<std::vector<
std::vector<MyNamespace::MyType> > > > > myFreakingLongVectorThing;
and I am getting a warning that looks like this:
C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\xstring(1665) : warning
C4503: 'std::vector<_Ty>::operator []' : decorated name length exceeded, name was truncated
with
[
_Ty=std::vector<std::vector<std::vector<std::vector<std::vector<MyNamespace::MyType>>>>>
]
is there any way I could rewrite that freaking long vector thing to not get that warning? I still want the data structure to be the same, but not get that warning. I don't want to disable the warning. Possible?
Note: This is Visual Studio 2005
....if you're really curious about why I'm working with such a hideous data structure, it's caused by auto-generated code.
If you don't want to see the warning you either have to disable it or use a newer compiler.
The warning is about debug information being limited to 255 characters for the type name. As long as these 255 characters are not identical for two different types, you are ok. And if they are identical, you cannot do much about it anyway!
Just turn it off until you can upgrade the compiler!
This isn't all that different from the error I used to get in Visual C++ 6 anytime I did just about anything with STL maps. You simply need to bite the bullet and tell the compiler to shut up about that warning. It's got a fundamental internal limit on how long a type name can be. As it is, it's a pretty useless warning, just complaining about the compiler/debugger's internal name limit.
#pragma warning(disable : 4503)
And if you're thinking at all about porting to another compiler, just wrap it in a #ifdef for Visaul C++:
#ifdef MSVC
#pragma warning(disable : 4503)
#endif
Is there a way, in VC++ (VSTS 2008), to froce a compiler error for functions that do not explicitly return a value on the default return path (Or any other quick way to locate them)?
On the same issue, is there any gaurentee as to what such functions actually return?
I don't know exactly the warning number, but you can use #pragma warning for enforcing a specific warning to be treated as error:
Example:
#pragma warning( error: 4001)
will treat warning 4001 as error
If you enable max warning level, and treat warnings as errors, you'll surely find what you're looking for. A guess as to what will be returned otherwise: A default-constructed object of the function's return type.
VC will warn about many instances of this problem, but fails to detect some. I've repeatedly caught it missing this problem in function templates, but I've seen int in some plain functions, too. Treating warnings as errors (compiler switch for all warnings or pragma for specifc ones) will make it impossible to overlook those it finds.
For those VC overlooks you have to use more thorough tools. AFAIK in VSTS you can also throw an /analyze switch for the compiler and have it find even more problems.
There's also many versions of lint-like programs.
Using some other compiler helps, too. Porting a VS project to GCC for the first time can be quite hard, but I think Intel's compiler can be used as a drop-in replacement for VC and compile VC projects right away. Comeau C++, too, has switches for being quite VC-compatible and has incredibly good errors messages.