For a sequence of
typedef int64_t I64;
I64 i=5;
printf("%"PRIi64",i);
cppcheck gives the warning below:
warning: %lld in format string (no. 1) requires 'long long' but the argument type is 'signed int'.
The makro PRIi64 is resolved by lld, this is correct, but the 64 bit integer type is not accepted as long long int.
I hope there is a way to resolve this, because we get a lot of such warnings in our project and don't see the real bugs anymore.
The latest version of Cppcheck does not shown a warning about following example code:
void f(void)
{
typedef int64_t I64;
I64 i=5;
printf("%"PRIi64",i);
}
Related
I am making program in which i try to make boost packaged_task then take its future in vector and launch it with asio post.
when i try to make packaged_task ,it gives me this error:
Error C2440 'return': cannot convert from 'void (__cdecl &)(boost::asio::yield_context)' to 'void (&)(boost::asio::yield_context)'
this is the relevant code:
typedef boost::packaged_task<std::string(boost::asio::yield_context)> task_t;
boost::shared_ptr<task_t> task = boost::make_shared<task_t>(boost::bind(&HTTPRequest::Execute, mClientRequestsVariables[m_HttpClient_request_name]->shared_from_this() , boost::placeholders::_1, m_HttpClient_request_name, Get_mHTTPClient_Responses_Map_shared_pointer()));
boost::future<std::string> fut = (task->get_future());
mPendingData.push_back(std::move(fut)); // C++11 possible: (std::move(fut) when fut is a unique_future);
mIos.post(boost::bind(&task_t::operator(), task));
and this is the definition of HTTPRequst::Execute :
HTTPRequest::HTTPRequest(boost::asio::io_service& ios, unsigned int id, std::string URL, const HTTPServiceResolve& resolve_addr, boost::shared_ptr<LoggingClass_2> mHTTPRequest_LoggingInstance_shared_pointer)
and the class HTTPRequest is derived from enable_shared_from_this .
the error is in bind.hpp so i find in vs output windows clues to the included part of code.
why is this error happening?and what is the solution??
I have a CGAL::Point_set_3 point set with point normal and color. I would like to save all properties to a PLY file, using write_ply_with_properties() function.
My goal is to make the full version work (see code below), but even the simple version doesn't compile, with the same error as the full version.
I work on Linux with CGAL release 4.14 and gcc 7.4.0.
Here is the code:
#include <CGAL/Exact_predicates_inexact_constructions_kernel.h>
#include <CGAL/Point_set_3.h>
#include <CGAL/Point_set_3/IO.h>
#include <tuple> // for std::tie
#include <fstream>
typedef CGAL::Exact_predicates_inexact_constructions_kernel Kernel;
typedef Kernel::Point_3 Point;
typedef Kernel::Vector_3 Vector;
typedef CGAL::Point_set_3<Point> Point_set;
int main(int argc, char*argv[])
{
Point_set points;
points.insert(Point(1., 2., 3.));
points.insert(Point(4., 5., 6.));
// add normal map
points.add_normal_map();
auto normal_map = points.normal_map();
// add color map
typedef Point_set::Property_map< Vector > ColorMap;
bool success = false;
ColorMap color_map;
std::tie(color_map, success) =
points.add_property_map< Vector >("color");
assert(success);
// populate normal and color map
for(auto it = points.begin(); it != points.end(); ++it)
{
normal_map[*it] = Vector(10., 11., 12.);
color_map[*it] = Vector(20., 21., 22.);
}
std::ofstream out("out.ply");
#if 1
// simple version
if(!out || !CGAL::write_ply_points_with_properties(
out,
points.points(), // const PointRange
CGAL::make_ply_point_writer(points.point_map())))
#else
// full version
if(!out || !CGAL::write_ply_points_with_properties(
out,
points.points(), // const PointRange
CGAL::make_ply_point_writer(points.point_map()),
CGAL::make_ply_normal_writer(points.normal_map()),
std::make_tuple(color_map,
CGAL::PLY_property< double >("red"),
CGAL::PLY_property< double >("green"),
CGAL::PLY_property< double >("blue"))))
#endif
{
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
The compilation error is:
...
/usr/include/boost/property_map/property_map.hpp:303:54: error: no match for ‘operator[]’ (operand types are ‘const CGAL::Point_set_3<CGAL::Point_3<CGAL::Epick> >::Property_map<CGAL::Point_3<CGAL::Epick> >’ and ‘const CGAL::Point_3<CGAL::Epick>’)
Reference v = static_cast<const PropertyMap&>(pa)[k];
CGAL-4.14/include/CGAL/Surface_mesh/Properties.h:567:15: note: candidate: CGAL::Properties::Property_map_base<I, T, CRTP_derived_class>::reference CGAL::Properties::Property_map_base<I, T, CRTP_derived_class>::operator[](const I&) [with I = CGAL::Point_set_3<CGAL::Point_3<CGAL::Epick> >::Index; T = CGAL::Point_3<CGAL::Epick>; CRTP_derived_class = CGAL::Point_set_3<CGAL::Point_3<CGAL::Epick> >::Property_map<CGAL::Point_3<CGAL::Epick> >; CGAL::Properties::Property_map_base<I, T, CRTP_derived_class>::reference = CGAL::Point_3<CGAL::Epick>&]
reference operator[](const I& i)
^~~~~~~~
CGAL-4.14/include/CGAL/Surface_mesh/Properties.h:567:15: note: no known conversion for argument 1 from ‘const CGAL::Point_3<CGAL::Epick>’ to ‘const CGAL::Point_set_3<CGAL::Point_3<CGAL::Epick> >::Index&’
How can I fix it?
The problem in your code is that you are using the method points() of CGAL::Point_set_3 which returns a range of points of type CGAL::Point_set_3::Point_range, whereas the property maps that you use (points.point_map(), etc.) are directly applied to a type CGAL::Point_set_3.
So you should simply call the write_ply_points_with_properties() on points, not on points.points().
Note also that if you store your colors on simple types (for example, using three Point_set_3 properties typed unsigned char), you can take advantage of the function CGAL::write_ply_point_set() that will automatically write all the simply-typed properties it finds, which makes it quite straightforward to use (just do CGAL::write_ply_point_set(out, points) and you're done).
One last thing that is really a detail not related to your problem, but you should avoid using the CGAL::Vector_3 for storing anything else than an actual geometric 3D vector (like colors in your case). That makes your code harder to read and is also quite an ineffective way to store colors if they are encoded as integer values between 0 and 255 (which is what unsigned char is for).
I am using wxWidgets 2.9.4 in Visual Studio 2012 and I keep getting these two error messages:
Error 1 error C2664: 'MessageBoxW' : cannot convert parameter 2 from 'const char *' to 'LPCWSTR'
IntelliSense: argument of type "const char *" is incompatible with parameter of type "LPCWSTR"
My code is:
#ifdef _WIN32
std::string msg;
StringFromFormatV(&msg, format, args);
retval = IDYES == MessageBox(0, msg.c_str(), "ERROR! Continue?", MB_ICONQUESTION | MB_YESNO);
You are compiling your project using multi-byte characters as default. You can change that in your project's properties, or you can use msg.wc_str(), or even enforce the use of MessageBoxA instead of using the macro MessageBox.
Basically, my problem is a signed char to int and string conversion in cocoa.
I found this piece of code in an open source cocoa bluetooth application and am trying to apply it to my own.
Basically, I get a signed char output from the variable "RSSI", and want to convert it to an int and a string, the string for outputting to the log and the int for further calculation. However, no matter what I try, I cannot seem to get it converted, and just get an EXEC_BAD_ACCESS if I try outputting the signed char to the log as it is.
A typical value for the signed char would be " -57 '\307' " quoted directly from the process before it is held up by the NSLog. Here's the code:
- (BOOL)isInRange {
BluetoothHCIRSSIValue RSSI = 127; /* Valid Range: -127 to +20 */
if (device) {
if (![device isConnected]) {
[device openConnection];
}
if ([device isConnected]) {
RSSI = [device rawRSSI];
[device closeConnection];
NSLog(RSSI);
}
}
return (RSSI >= -60 && RSSI <= 20);
}
Thanks in advance.
NSLog() takes an NSString format string as its first argument, and an (optional) variable length list of variables for the format specifiers in the format string after that:
NSLog(#"RSSI: %c", RSSI);
What you've got now (NSLog(RSSI);) is simply wrong. It should be giving you compiler warnings like these:
warning: passing argument 1 of 'NSLog' makes pointer from integer without a cast
warning: format not a string literal and no format arguments
You should always pay attention to compiler warnings, not ignore them. Especially when your program crashes on the same line the warnings refer to, they should be a red flag to you that you've made a mistake.
As an aside, I should mention that NSLog() works very much like printf(). The two major differences are that NSLog's format string should be an Objective-C string literal (#"string"), not a standard C char string ("string"), and that the format specifier for an object is %#. %# is replaced by the string returned by calling the -description method on the object to be printed.
For various implementation reasons, I've defined the following enum:
typedef enum HBSnakeMovementDirection
{
HBSnakeMovementDirectionUp = 1,
HBSnakeMovementDirectionDown = -1,
HBSnakeMovementDirectionRight = 2,
HBSnakeMovementDirectionLeft = -2
}
HBSnakeMovementDirection;
However, if I try to use HBSnakeMovementDirectionRight, I get the following warning:
Implicit conversion changes signedness: 'int' to 'HBSnakeMovementDirection'
It has no problem with any of the other enum values. What's the problem here? I thought it might have to do with mixing negative and positive enum values, but I can't find out anything definitive about this.
(I was able to come up with all positive enum values that allow me to work around this issue, but it still stumped me, so I thought I'd ask about it.)
I should state that, as with all my projects, I enable almost every warning—hence, -Wconversion's complaints—and treat them as errors. (I like to be as strict as possible at compile time.) I'm using LLVM 1.6.
UPDATE 1: Literally any use of HBSnakeMovementDirectionRight results in the preceding warning:
HBSnakeMovementDirection movementDirectionRight = HBSnakeMovementDirectionRight;
I have to cast HBSnakeMovementDirectionRight to HBSnakeMovementDirection to silence the warning.
UPDATE 2: As requested, here is the entire build command that's being issued on my machine:
http://pastie.org/1580957
UPDATE 3: Here is the exact project I'm working on hosted on GitHub:
https://github.com/LucasTizma/Hebi
Specifically, the following tree:
https://github.com/LucasTizma/Hebi/tree/89262e2e53881584daf029e3dd5f1e99dfbd6f96
As Darren said, it does look like a compiler bug, and Dave said it doesn’t happen with Clang 2.0.
I’ve found that the following type definition makes the OP code compile with Clang 1.6:
typedef enum HBSnakeMovementDirection
{
HBSnakeMovementDirectionUp = 1, // Default movement direction upon initialization via -init
HBSnakeMovementDirectionDown = -1,
HBSnakeMovementDirectionLeft = -2,
HBSnakeMovementDirectionRight = 2,
NBSnakeMovementDirectionNone = -3
}
HBSnakeMovementDirection;
(note the additional NBSnakeMovementDirectionNone)
This could be related to LLVM bug 1884, which has been fixed.
I can reproduce this. It certainly looks like a compiler bug to me. The presence of negative values in the enum causes the compiler to mistakenly think that the value of "2" is outside of the range of the enum, hence the warning.
The behavior is the same whether you specify "2" or "HBSnakeMovementDirectionRight": It accepts 1 and rejects 2.
Edit: I tested this in an existing iPhone project, setting the compiler LLVM 1.6 and setting the -Wconversion flag.
typedef enum HBSnakeMovementDirection
{
neg1 = -1,
pos1 = 1,
pos2 = 2,
} HBSnakeMovementDirection;
HBSnakeMovementDirection d = -3; // Warning: Can't convert int to HBSnakeMovementDirection
HBSnakeMovementDirection d = -2; // OK
HBSnakeMovementDirection d = -1; // OK
HBSnakeMovementDirection d = 0; // OK
HBSnakeMovementDirection d = 1; // OK
HBSnakeMovementDirection d = 2; // Warning: Can't convert int to HBSnakeMovementDirection
HBSnakeMovementDirection d = pos2; // Warning: Can't convert int to HBSnakeMovementDirection
Definitely looks like a compiler bug. I opened the project in Xcode 3 and compiled, and got the error. When I opened the project in Xcode 4 and used the clang2.0 compiler, I got no warnings.