I am upgrading an existing code base that use OpenCV 2 and 3 to be compatible with my Ubuntu 20.04 that uses OpenCV 4. One error I encountered when compiling is:
error: ‘HAAR_DO_CANNY_PRUNING’ is not a member of ‘cv’; did you mean ‘CASCADE_DO_CANNY_PRUNING’?
Should I accept the change proposed by the compiler and change cv::HAAR_DO_CANNY_PRUNING to cv::CASCADE_DO_CANNY_PRUNING for all occurrences?
Should I accept the change proposed by the compiler?
Yes.
The values of the 4 CASCADE_* symbols match the ones of the old HAAR_* symbols, as #DanMasek commented.
You can check the enums in Enumeration Type Documentation and OpenCV-2_2 Reference, page 795.
Related
I am new to C++ programming. I am trying to compile another person's program, and the software reported a bug that I don't know how to solve (the software I use is Visual Studio 2019).
The line of code with bug is:
swap(allBeamPoints, unordered_map<int, vector<LidarPoint>>());
The definition for variable allBeamPoints is:
unordered_map<int, vector<LidarPoint>>allBeamPoints
The error information is:
Error C2665 'std::swap': none of the 2 overloads could convert all the argument types
and
Error (active) E0304 no instance of overloaded function "swap" matches the argument list
However, if I type the following codes, no bug will be reported:
unordered_map<int, vector<LidarPoint>> allBeamPoints_new;
swap(allBeamPoints, allBeamPoints_new);
Does anyone know what the problem is? Did I fail to link some of the required libraries? How should I check those libraries?
The older MSVC compilers allowed the binding of an anonymous temporary to a non-const reference function parameter. That's not standard C++.
So
swap(allBeamPoints, unordered_map<int, vector<LidarPoint>>());
which had the effect of clearing allBeamPoints was reasonably idiomatic in code that only targeted Microsoft platforms.
It's wrong and not portable as you now observe. Use
allBeamPoints.clear();
instead to clear the map. Your second snippet compiles since allBeamPoints_new is not an anonymous temporary.
When I run my code I get the following error for all the statements that have the following format. Is there any problem with the type statement? If yes kindly provide me with a solution. I running my code on a Ubuntu 14.10 system. The program is very long hence I am not posting it now however if required I can surely send it.
recfunk_ascii.f:622.12:
type *,'enter back-azimuth limits ib1,ib2 (integers!)'
1
Error: Invalid character in name at (1)
Type is an obsolete and completely non-standard statement (see http://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vnbi/index.html). It is not portable because many compilers do not recognize it. It should be changed to a PRINT statement, as #francescalus suggest in the comment.
print *,'enter back-azimuth limits ib1,ib2 (integers!)'
Have following code which is working under Linux but gives error for MSVS
#if (false)
....
#endif
The error is: fatal error C1017: invalid integer constant expression
I found this report on Microsoft's web:
http://msdn.microsoft.com/en-us/library/h5sh3k99.aspx
While the info described there differs a little bit compared to my case as I didn't use the "#define"
So my question is:
Is there any way to make it working for MSVC without changing code ?
If the code must be updated, what's the best solution for this kind of case?
It looks like your version of MS compiler does not support false as a built-in constant. This is not surprising, because Microsoft has a spotty record of supporting standards for C and C++.
One way to make this work without changing the code is to pass command-line parameters to the compiler to define false as 0 and true as 1:
-Dfalse=0 -Dtrue=1
Is there any way to make it working for MSVC without changing code ?
Not really. Defining a macro for false is forbidden by the standard for good reasons, [macro.names]/2:
A translation unit shall not #define or #undef names lexically
identical to keywords, to the identifiers listed in Table 3, or to the
attribute-tokens described in 7.6.
And I don't see any other way.
If the code must be updated, what's the best solution for this kind of
case?
Substitute 0 for false.
This similar ill-fated question
got comments and short answers, before it was closed, to the effect: Because that's
how the language is defined. Here I am asking for the evidence within the
C++ Standard that it is so defined.
gcc 4.8.1 and clang 3.3 alike, with default diagnostic options or stricter,
give errors for extra qualification or explicit qualification on
code such as:
struct x
{
int x::i; // Error: gcc/clang: "extra"
};
int ::y; // Error: gcc: "explicit", clang: "extra"
gcc has diagnosed such errors since v4.1. But popular compilers are not
unanimous about these errors. MSVC++ 2012 (Nov CTP)
gives an error at int ::y; but even with /Wall, gives no diagnostic at all
int x::i; - the kind of case that the ill-fated questioner was raising -
and that difference suggests deliberation by the MS compiler writers.
How are these errors warranted by the Standard, if they are? References to the C++11
Standard will suffice.
An answer might be "They follow from grammar". In that case,
please try to show how they follow from the grammar and feel free to use
the Standard's grammatical classifications. I have a copy and will re-read it
to understand the explanation.
A qualified name in C++ always must refer to a previously declared name. This is specified in clause 8.3 and 3.4.3.2.
You cannot firstly declare a variable or member by using a qualified name - it will end up in a "cannot resolve identifier"-liky compiler error. Such qualifiers are designed to be used for redeclaration. Hence the requirement that these names must find previously declared entities.
It is a bug in the Microsoft compiler to allow x::i within the definition of struct x. There are several of these errors in the MSVC front end, and have been reported to Microsoft but they get closed without being fixed (see similar but different error reported here: https://connect.microsoft.com/VisualStudio/feedback/details/783433/c-compiler-accepts-explicit-constructor-call#details and https://connect.microsoft.com/VisualStudio/feedback/details/794504/keyword-struct-before-constructor-name).
The reason it is invalid is because you are both trying to declare a variable int i and provide a scope using x::i. The scope of the variable is dictated by where it is declared, so trying to declare something with a scope specification is trying to declare it somewhere else, which is invalid.
Hi i have to port some stuff written on c++ from unix bases os to windows visual studio 2008.
The following code implements array data type with void ** - pointer to the data.
struct array
{
int id;
void **array; // store the actual data of the array
// more members
}
When i compile with g++ on Unix it's ok but when i try with MSVS 2008 I get the error - error C2461: 'array' : constructor syntax missing formal parameters. When i change the member from 'array' to something else it works, so it seems that the compiler thinks that the member name 'array' is actually the constructor of the struct array. It's obviously not a good practice to name the member like the struct but it's already written that way. Can i tell the MSVS compiler to ignore this problem or i should rename all members that are the same as the struct name.
You are dealing with a bug in GCC compiler. C++ language explicitly prohibits having data members whose name is the same as the name of the class (see 9.2/13). MS compiler is right to complain about it. Moreover, any C++ compiler is required to issue a diagnostic message in this case. Since GCC is silent even in '-ansi -pedantic -Wall' mode, it is a clear bug in GCC.
Revison: What I said above is only correct within the "classic" C++98 specification of C++ language. In the most recent specification this requirement only applies to static data members of the class. Non-static data members can now share the name with the class. I don't know whether this change is already in the official version of the revised standard though.
That means that both compilers are correct in their own way. MS compiler sticks to the "classic" C++98 specification of the language, while GCC seems to implement a more recent one.
I'd say that if you're doing something that you yourself describe as "not a good practice", then you should change it.
I would rename your attribute to not have the same name as the class. This will make your code more portable. If you have to move to yet another compiler in the future, you won't run in to this problem again then.