I have such codee:
struct Foo {
unsigned attr : 7;
std::pair<char *, unsigned> f() {
char *ch = nullptr;
return std::make_pair(ch, static_cast<unsigned>(attr));
}
};
MSVS2013 give me something like this error:
can not convert 'unsigned int' to 'unsigned int&'
While gcc 4.8 and clang 3.3 compile such code without errors.
Is this MSVS compiler bug? If so, where I should report it?
Compiles and works just fine in VS2010. Must be a bug. Report it to Microsoft Connect: https://connect.microsoft.com/VisualStudio
Related
I am trying to compile some library code and ran into an error; I simplified the example and I have the following MVCE which fails to compile with MSVC 2019 with the error
error C2440: 'return': cannot convert from 'const char *' to 'const char (&)[20]'
static constexpr const char somethingWeird[] = "Well, that's odd...";
void fail() { throw 0; }
// This doesn't work
constexpr const char(&checkNullTerminatedGood(const char(&a)[20]))[20]{
return a[19] == char(0) ? decltype(a)(a) : (fail(), decltype(a)(a));
}
static constexpr const auto somethingElseNew = checkNullTerminatedGood(somethingWeird);
When I convert the ternary operator to a proper if-statement, the code compiles well:
static constexpr const char somethingWeird[] = "Well, that's odd...";
void fail() { throw 0; }
// This works
constexpr const char(&checkNullTerminatedGood(const char(&a)[20]))[20]{
if (a[19] == char(0)) {
return decltype(a)(a);
} else {
return (fail(), decltype(a)(a));
}
}
static constexpr const auto somethingElseNew = checkNullTerminatedGood(somethingWeird);
Is this a bug in MSVC? The first snippet compiles with GCC and Clang.
A bit of googling shows this is know problem which is claimed to be fixed (but it is not).
C++ Overly aggressive decay of static array to pointer in ternary operator - Developer Community
Solution
by Leo Zhang [MSFT] Sep 07, 2017 at 02:35 AM
Thank you for your feedback! This issue has been fixed and it will be available in the next update to Visual Studio 2017. Thank you for helping us build a better Visual Studio!”
I have an std::array<unsigned, 3> defined inside a class. I want to initalise it inside the constructor, like this:
MyClass::MyClass(std::map<std::string, std::string> const&data)
{
MyArr[0] = (unsigned)(std::atoi(data["one"].c_str()));
MyArr[1] = (unsigned)(std::atoi(data["two"].c_str()));
MyArr[2] = (unsigned)(std::atoi(data["three"].c_str()));
}
By compiling this code in the latest MSVC release with
cl /EHsc /O2 /std:c++17 main.cpp
I get
error C2397: conversion from 'int' to 'unsigned int' requires a narrowing conversion
it points to the line 2 if the snippet.
Use the appropriate function to convert string to an unsigned integer:
char* end;
MyArr[0] = std::strtoul(data["one"].c_str(), &end, 10);
You might also need to define your array as std::array<unsigned long, 3>.
I want to debug a third-party c++ lib, is it possible to cast a pointer to a printable type?
I have tried
(lldb) expr static_cast<AGInfo*>(0x0000002fcdccc060)
but it shows an error of
error: cannot cast from type 'long' to pointer type 'mxnet::Imperative::AGInfo *'
Is there any way of doing that?
Thanks
lldb uses clang for its expression parser, so it adheres pretty strictly to C++ with only a few modifications. clang won't allow you to do what you were trying in source code:
> cat foo.cpp
struct Something
{
int first;
int second;
};
int
main()
{
Something mySomething = {10, 30};
long ptr_val = (long) &mySomething;
Something *some_ptr = static_cast<Something *>(ptr_val);
return some_ptr->first;
}
> clang++ -g -O0 -o foo foo.cpp
foo.cpp:12:25: error: cannot cast from type 'long' to pointer type 'Something *'
Something *some_ptr = static_cast<Something *>(ptr_val);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
So it won't work in lldb either.
Fortunately, C++ is less strict in C-style casts, so the same code but with:
Something *some_ptr = (Something *) ptr_val;
compiles in actual source, and will work in the lldb expression parser.
While adding a detailed answer, I noticed that GCC does not warn the following code while Visual C++ complains.
#include <cstring>
int main()
{
const char CONSTSTR[] = "foo/bar/foobar.txt";
char *nonconst = std::strrchr (CONSTSTR, '/');
// cannot convert from 'const char *' to 'char *'
*nonconst++ = 'B';
*nonconst++ = 'A';
*nonconst++ = 'D';
}
I have tested three different GCC versions:
4.1.2 on Red Hat (Linux)
4.5.3 on Cygwin (Windows)
4.7.2 on MinGW (Windows)
But all these three GCC versions compiled this code without any warning/error:
> g++ -Wall -Wextra -pedantic -ansi test.cpp && echo "success"
success
While Microsoft compiler v16 complains:
> cl -c test.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
test.cpp
test.cpp(5) : error C2440: 'initializing' : cannot convert from 'const char *' to 'char *'
Conversion loses qualifiers
(from my office, I do not have access to ideone/codepad/... to test it using other versions)
As this code uses std::strrchr, I do not understand why GCC does not complain.
const char* strrchr( const char* str, int ch ); //the code above uses this declaration
char* strrchr( char* str, int ch );
My question: Why does g++ successfully compile this code without any warning/error? Is it a bug? a feature? a miss-configuration on my side?
Actually your g++ does not accept the conversion from 'const char *' to 'char *', it's just that on your version std::strrchr() returns a char* (incorrectly, instead of a const char*).
To verify the first part of my statement, try to compile the following on your GCC versions, I predict that all will correctly issue an error:
int main()
{
const char* p = "foo";
char* q = p; // error, invalid conversion from 'const char*' to 'char*'
}
Now for the second part, I tried to compile the following minimal code, whose actual aim is to trigger an error in order to list the declared overloads of std::strrchr:
#include <cstring>
void (*p)() = &std::strrchr; // error here, with "candidates are: ..."
int main() {}
Well, with gcc 4.7.2 the message shows the expected "all non-const" and "all const" overloads:
prog.cpp:2:21: error: no matches converting function ‘strrchr’ to type ‘void (*)()’
In file included from /usr/include/c++/4.7/cstring:44:0,
from prog.cpp:1:
/usr/include/string.h:249:1: error: candidates are: char* strrchr(char*, int)
/usr/include/string.h:255:1: error: const char* strrchr(const char*, int)
i.e. the prototypes
char* strrchr( char* , int );
const char* strrchr( const char* , int ); // Question's code will use this one (-> error)
But with gcc 4.3.2 the message was different:
prog.cpp:2: error: no matches converting function 'strrchr' to type 'void (*)()'
/usr/include/string.h:171: error: candidates are: char* strrchr(const char*, int)
/usr/include/c++/4.3/cstring:118: error: char* std::strrchr(char*, int)
i.e. the overloads were
char* strrchr( const char* , int ); // Question's code would use this one (-> no error...)
char* strrchr( char* , int );
(the second one is the C++ non-const overload; but the first one is the old C version, and should instead be the C++ const overload).
This it seems that the headers (<cstring> and/or <string.h>) were incorrect on this version, and I suspect that it's the same on yours.
Edit: I found for example a discussion, a blog post and a bug report (for strchr not strrchr but it's the same story).
I have been developing a library that is getting pretty large, and now I am adding some template-based parts that use C++0x features. So I tried to compile my library (which compiled entirely without warnings on the current standard) with the flag -std=c++0x using gcc version 4.4.5 (on Linux). Now I got a huge influx of error messages related to the conversion of "temporaries" variables to non-const references. The problem is, they are not temporary!
Here is a small piece of code that reproduces the error:
#include <iostream>
#include <map>
struct scanner {
scanner& operator &(std::pair<std::string, int&> i) {
std::cout << "Enter value for " << i.first << ": ";
std::cin >> i.second;
return *this;
};
};
struct vect {
int q[3];
void fill(scanner& aScan) {
aScan & std::pair<std::string, int&>("q0",q[0])
& std::pair<std::string, int&>("q1",q[1])
& std::pair<std::string, int&>("q2",q[2]);
};
};
int main() {
vect v;
scanner s;
v.fill(s);
return 0;
};
If you compile this with the current standard (no c++0x flag) it will compile and run as expected. However, if you compile it with -std=c++0x, it will throw the following error at compile-time:
/usr/include/c++/4.4/bits/stl_pair.h:94: error: invalid initialization of non-const reference of type ‘int&’ from a temporary of type ‘int’
I really can't figure this out. I have looked over the web and SO, but none seem to have this problem. Is it a bug in std::pair? I would really like to know what the problem is.. thank you for any insight you can give.
PS: don't complain about the "quality" or "stupidity" of the code above, it is not real code.. just an example that shows the error.
Your code is not valid C++03, comeau gives (after adding a return statement to op&):
"stl_pair.h", line 44: error: qualifiers dropped in binding reference of
type "int &" to initializer of type "const int"
pair(const _T1& __a, const _T2& __b) : first(__a), second(__b) {}
^
detected during instantiation of "std::pair<_T1, _T2>::pair(const
_T1 &, const _T2 &) [with _T1=std::string, _T2=int &]" at
line 17 of "ComeauTest.c"
...
The problem is a reference inside a pair. If I remember correctly, it is a gcc extension that allows this. Gcc does accept it with -std=gnu++98, which is the default for C++, but with -std=c++98, gcc 4.4.3 gives:
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:66,
from /usr/include/c++/4.4/algorithm:61,
from PREAMBLE:7:
/usr/include/c++/4.4/bits/stl_pair.h: In instantiation of ‘std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int&>’:
<input>:5: instantiated from here
/usr/include/c++/4.4/bits/stl_pair.h:83: error: forming reference to reference type ‘int&’
...
There are LOTS of bugs in gcc C++0x support, it's very much unfinished and development is ongoing. This is doubly true for a version as old as gcc-4.4.5. If you're serious about starting C++0x development before the standard is ratified, you need to use the bleeding-edge version of the compiler and standard library.
It compiles fine both with and without -std=c++0x with GCC 4.5.2.
I guess GCC 4.4.5 doesn't support C++0x that much to get this working.
Except for the missing return *this; in scanner& operator &(std::pair<std::string, int&> i), your code is valid C++0x.