I was updating earlier c code (opencv1.0) to opencv 4 . While i was changing and updating api's everything looked fine , however, at the end i got the error with the above mentioned file as follows,
/usr/local/include/opencv4/opencv2/core/cvstd_wrapper.hpp:45:40: Declaration of constexpr static data member 'check' requires an initializer
/usr/local/include/opencv4/opencv2/core/cvstd_wrapper.hpp:47:31: Constexpr can only be used in variable and function declarations
I am using LLVM 8.1 and uses libc++(LLVM C++ standard library with c++ 11 support) as c++ standard library.
Following is the part of the code that shows error in opencv.
struct has_parenthesis_operator
{
private:
template<typename T>
CV_CONSTEXPR std::true_type check(typename std::is_same<typename
std::decay<decltype(std::declval<T>().operator()(std::declval<Args> .
()...))>::type, Ret>::type*);
template<typename> static CV_CONSTEXPR std::false_type check(...);
typedef decltype(check<C>(0)) type;
public:
static CV_CONSTEXPR bool value = type::value;
};
Related
Googlemock can help build mock classes with which it is possible to detect if one method calls another method and with what parameters, and influence the behaviour of the called method.
E.g., to test that method a() in class UnderTest actually calls method b()
class UnderTest {
public:
/// Method a() calls method b().
virtual void a() {b();}
/// Method b() does nothing.
virtual void b() {}
};
one can write a mock class which overwrites method b()
class UnderTestMock : public UnderTest {
public:
MOCK_METHOD0(b, void());
};
and test if the method b() is actually called after calling method a():
TEST(UnderTest, aCallsB) {
UnderTestMock mock;
EXPECT_CALL(mock, b());
mock.a();
}
Can I use Googlemock like this with C++Builder 11.2?
No, at the moment it is not possible to use Googlemock like this with C++Builder 11.2.
The Googletest project (which includes Googlemock) itself has removed all support for C++Builder in 2019. Embarcadero has since published their own patched version of Googletest in a GetIt package, which includes project files to build Googletest and Googlemock and some usage examples.
The Googlemock-related project files are all somewhat broken, e.g. the gmock.cbproj file inserts a source file into the gmock.a library that performs some unrelated tests on Googletest. These project file errors can all be fixed easily by removing source files from the projects that do not belong there and rebuild.
However, after fixing the gmock.cbproj project file, it turns out that the main feature of Googlemock, the EXPECT_CALL() macro, is not supported by C++Builder 11.2:
This is a simple source file which puts the code pieces from the question together, adds a main function and the required includes:
#include "gmock/gmock.h"
#include "gtest/gtest.h"
#include <tchar.h>
int _tmain(int argc, _TCHAR* argv[])
{
testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
class UnderTest {
public:
/// Method a() calls method b().
virtual void a() {b();}
/// Method b() does nothing.
virtual void b() {}
};
class UnderTestMock : public UnderTest {
public:
MOCK_METHOD0(b, void());
};
TEST(UnderTest, aCallsB) {
UnderTestMock mock;
EXPECT_CALL(mock, b());
mock.a();
}
This sample works fine with Googlemock with other compilers (at most, tchar, _tmain need to be replaced with char, main), however, with C++Builder, some required features are missing from either the compiler or from the C++ standard library. The error message when compiling with C++Builder's clang-based 64-bit compiler is
Build FAILED.
C:\Users\...\Documents\Embarcadero\Studio\22.0\CatalogRepository\GoogleTest-2021.09\googlemock\include\gmock/gmock-nice-strict.h(134,6): C++ warning : __declspec attribute 'empty_bases' is not supported
C:\Users\...\Documents\Embarcadero\Studio\22.0\CatalogRepository\GoogleTest-2021.09\googlemock\include\gmock/gmock-nice-strict.h(174,6): C++ warning : __declspec attribute 'empty_bases' is not supported
C:\Users\...\Documents\Embarcadero\Studio\22.0\CatalogRepository\GoogleTest-2021.09\googlemock\include\gmock/gmock-nice-strict.h(215,6): C++ warning : __declspec attribute 'empty_bases' is not supported
c:\program files (x86)\embarcadero\studio\22.0\include\dinkumware64\type_traits(2686,1): C++ error : no matching function for call to 'invoke'
c:\program files (x86)\embarcadero\studio\22.0\include\dinkumware64\functional(216,10): C++ error : > in instantiation of function template specialization 'std::_Invoke_ret<void, testing::internal::DoDefaultAction &>' requested here
c:\program files (x86)\embarcadero\studio\22.0\include\dinkumware64\functional(165,2): C++ error : > in instantiation of member function 'std::_Func_impl<testing::internal::DoDefaultAction, std::allocator<int>, void>::_Do_call' requested here
c:\program files (x86)\embarcadero\studio\22.0\include\dinkumware64\xmemory0(704,23): C++ error : > in instantiation of function template specialization 'std::_Func_impl<testing::internal::DoDefaultAction, std::allocator<int>, void>::_Func_impl<testing::internal::DoDefaultAction, const std::allocator<int> &>' requested here
c:\program files (x86)\embarcadero\studio\22.0\include\dinkumware64\xmemory0(845,6): C++ error : > in instantiation of function template specialization 'std::allocator<std::_Func_impl<testing::internal::DoDefaultAction, std::allocator<int>, void> >::construct<std::_Func_impl<testing::internal::DoDefaultAction, std::allocator<int>, void>, testing::internal::DoDefaultAction, const std::allocator<int> &>' requested here
c:\program files (x86)\embarcadero\studio\22.0\include\dinkumware64\xmemory0(994,13): C++ error : > in instantiation of function template specialization 'std::allocator_traits<std::allocator<std::_Func_impl<testing::internal::DoDefaultAction, std::allocator<int>, void> > >::construct<std::_Func_impl<testing::internal::DoDefaultAction, std::allocator<int>, void>, testing::internal::DoDefaultAction, const std::allocator<int> &>' requested here
c:\program files (x86)\embarcadero\studio\22.0\include\dinkumware64\functional(376,6): C++ error : > (skipping 6 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
C:\Users\...\Documents\Embarcadero\Studio\22.0\CatalogRepository\GoogleTest-2021.09\googlemock\include\gmock/gmock-actions.h(470,4): C++ error : > in instantiation of function template specialization 'testing::Action<void ()>::Init<testing::internal::DoDefaultAction>' requested here
C:\Users\...\Documents\Embarcadero\Studio\22.0\CatalogRepository\GoogleTest-2021.09\googlemock\include\gmock/gmock-spec-builders.h(909,8): C++ error : > in instantiation of function template specialization 'testing::Action<void ()>::Action<testing::internal::DoDefaultAction, void>' requested here
C:\Users\...\Documents\Embarcadero\Studio\22.0\CatalogRepository\GoogleTest-2021.09\googlemock\include\gmock/gmock-spec-builders.h(1629,12): C++ error : > in instantiation of member function 'testing::internal::TypedExpectation<void ()>::TypedExpectation' requested here
C:\Users\...\Documents\Embarcadero\Studio\22.0\CatalogRepository\GoogleTest-2021.09\googlemock\include\gmock/gmock-spec-builders.h(1284,29): C++ error : > in instantiation of member function 'testing::internal::FunctionMocker<void ()>::AddNewExpectation' requested here
C:\Users\...\Documents\Embarcadero\Studio\Projects\gmocktest\main.cpp(26,2): C++ error : > in instantiation of member function 'testing::internal::MockSpec<void ()>::InternalExpectedAt' requested here
c:\program files (x86)\embarcadero\studio\22.0\include\dinkumware64\type_traits(2664,6): C++ error : > candidate template ignored: substitution failure [with _Callable = testing::internal::DoDefaultAction &, _Types = <>]: no matching function for call to '_Call'
3 Warning(s)
13 Error(s)
The two example projects included in the GetIt package for Googlemock hint that some isolated aspects of Googlemock may be working, like at least one Googlemock matcher works inside the EXPECT_THAT() macro, but none of the examples compiled by the GetIt package make use of the main feature of Googlemock, the EXPECT_CALL() macro.
I have a static library objective c with some C functions that I need to modify the behavior of based on the callers. I looked at https://opensource.apple.com/source/dyld/dyld-210.2.3/include/mach-o/dyld-interposing.h and saw that it could be used to essentially "swizzle" C functions.
My question is - will dyld_interpose also interpose the C function in all libraries / frameworks that contain my interposing code?
eg.
Library1 - had C Function
void foo(int bar) {
...
}
Library2 - Has interposing code. Depends on Library1
void my_foo(int bar) {
...
}
DYLD_INTERPOSE(my_foo, foo);
Will Library3 that depends on both Library1 and Library2 be interposed as well? What if it is attached to an application? I've got some success getting it working on an framework.
I have a snippet of code which compiles in C++ Builder XE8 using the classic BCC compiler. However, in Rad Studio 10 Seattle using the Clang compiler I get the error
'no matching constructor found for initialization of TChoiceItem'
Here is the snippet of code which causes the error.
LISTITEM_BEGIN( sch_TYPE_Choice )
LISTITEM_DATA( sch_TYPE_Daily, "Daily" )
LISTITEM_DATA( sch_TYPE_Weekly, "Weekly" )
LISTITEM_DATA( sch_TYPE_Monthly, "Monthly" )
LISTITEM_END()
Here is the code which defines TChoiceItem
//------------------------------------------------------------------------------
#define LISTITEM_BEGIN( Name ) TChoiceItem Name[] = {
//------------------------------------------------------------------------------
#define INT_LISTITEM_BEGIN( Name ) TIntChoiceItem Name[] = {
//------------------------------------------------------------------------------
#define LISTITEM_DATA( XCode, XText ) { XCode, 0, (char*)XText, 0 },
#define LISTITEM_DATA_NC( XShortText, XText ) { 0, (char*)XShortText, (char*)XText, 0 },
#define LISTITEM_DATA_EX( XCode, XShortText, XText ) { XCode, (char*)XShortText, (char*)XText, 0 },
#define LISTITEM_DATA_EX2( XCode, XShortText, XText, XDesc ) { XCode, (char*)XShortText, (char*)XText, (char*)XDesc },
#define LISTITEM_END() LISTITEM_DATA(0,0) };
I am fairly new to C++ so I am not exactly sure what to call the above method of defining a class/method.
Is this some sort of dated language feature not supported by the Clang compiler? Is there a way to modify the code or definition so the compiler will accept it?
Edit:
I found the actual declaration of the TChoiceItem class.
class TChoiceItem : public TChoiceBase
{
public:
char Code;
char *ShortText;
char *Text;
char *Desc;
};
It does't appear to have any sort of standard constructor at all. But somehow, everything still compiles and works with the classic BCC compiler.
Edit 2:
I found this question which looks to be describing a similar issue. Could it be that I need to include some kind of compiler flag when compiling the code? If so can I add a flag somehow in the embarcadero project compiler settings?
Using a list of values in braces to initialize the individual members of a class or struct is known as aggregate initialization.
As explained on cppreference.com, aggregate initialization isn't permitted if the class has a base class (among other restrictions). TChoiceItem inherits from TChoiceBase, so aggregate initialization isn't allowed (and the "classic" bcc32 compiler shouldn't have allowed it).
You have a couple of choices:
First, you can change the code to not inherit from TChoiceBase.
Second, you can define a constructor:
TChoiceItem(char code, char *short_text, char *text, char *desc)
: Code(code), ShortText(short_text), Text(text), Desc(desc) {}
C++11's uniform initialization means that your macros' syntax doesn't have to change: instead of braces meaning a list of values for individual members, the braces will mean a list of parameters to the constructor, but the result will be the same.
I am having an issue with Luabind that I am unsure of how to fix without some over-simplified solution.
Luabind appears to only allow binding to functions using the __cdecl calling convention. In my current project all of the functionality exposed to extensions/plugins is exposed using __stdcall. This leaves me unable to bind the exposed objects directly and instead I have to make wrappers for the objects exposed. This would be fine but there are a lot of objects that would need to be wrapped.
For example, an object can look like this:
struct IObject
{
void __stdcall SomeFunc1( void );
void __stdcall SomeFunc2( const char* );
};
struct IObjectContainer
{
IObject* __stdcall GetObject( int );
IObject* __stdcall GetObject( const char* );
};
struct IObjectCore
{
IObjectContainer* __stdcall GetObjectContainer();
};
I don't have the option of changing the entire projects calling convention currently so I am seeing if someone has a solution to perhaps patch Luabind to work with __stdcall functions. I am not the best with templates and with boost things, so I'm personally unsure where to even start trying to add the ability to use __stdcall functions.
For reference, I am using:
Lua 5.1.4
Luabind 0.9.1
VS2010
Both Lua and Luabind are stock latest versions of their rev. (Not using Lua 5.2 for project restriction reasons, but if there is a __stdcall fix for 5.2/Luabind I will gladly take that as well.)
I could only find a fix for a very old version of Luabind to do this but the patch floating on the net still for that does not line up with the current Luabind code at all.
If there is any other information needed feel free to ask.
Sadly due to inactivity and no further answers from more searching I spoke with the project developer and have gotten the entire project stripped of __stdcall. So the bindings all work fine now via __cdecl. Not the route I wanted to take but things are working as planned now.
I faced the exact same problem when binding OpenGL (with GLEW functions) to Lua, and solved it using variadic templates.
Now if the function is global and you know its address in compile time, you can be good with something like this:
template<typename Signature>
struct wrap_known;
template<typename Ret, typename... Args>
struct wrap_known<Ret __stdcall (Args...)> {
template <Ret __stdcall functor(Args...)>
static Ret invoke(Args... arguments) {
return functor(arguments...);
}
};
// I know using macro is generally a bad idea but it's just shorter
#define wrap(f) wrap_known<decltype(f)>::invoke<f>
and then, when binding, use the macro like this:
luabind::def("Clear", wrap(glClear)),
luabind::def("Vertex4f", wrap(glVertex4f))
However, in your case, we have a bunch of member functions and not globals like above.
Here is the code for wrapping member functions with __stdcall calling convention:
template<typename Signature>
struct wrap_mem;
template<typename Sub, typename Ret, typename... Args>
struct wrap_mem<Ret(__stdcall Sub::*) (Args...)> {
template <Ret(__stdcall Sub::*functor) (Args...)>
static Ret invoke(Sub* subject, Args... arguments) {
return (subject->*functor)(arguments...);
}
};
#define wrap_member(f) wrap_mem<decltype(f)>::invoke<f>
Use it like this:
struct A {
int __stdcall my_method(double b) {
return 2;
}
};
// ...
luabind::class_<A>("A")
.def("my_method", wrap_member(&A::my_method))
Sometimes, however, you are not that lucky to know the function's address in compile time, and this happens with GLEW for example. For functions like glUniform*f, glGetUniformLocation, the "wrap" macro will not work, so I made another version for wrapping functions known at runtime:
template<typename Signature>
struct wrap_unknown;
template<typename Ret, typename... Args>
struct wrap_unknown<Ret (__stdcall*) (Args...)> {
template <Ret (__stdcall** functor)(Args...)>
static Ret invoke(Args... arguments) {
return (**functor)(arguments...);
}
};
#define wrap_ptr(f) wrap_unknown<decltype(f)>::invoke<&f>
(if above code scares you, it is actually a good sign)
Now you can bind GLEW functions like this:
luabind::def("Uniform4f", wrap_ptr(glUniform4f)),
luabind::def("GetUniformLocation", wrap_ptr(glGetUniformLocation))
Just don't ask me to write another version for binding pointers to members known at runtime :)
If you don't want to use C++11 for some reason, here you can find out how to pass function arguments and return value as template parameters in C++03.
I'm attempting to P/Invoke a C library from F#, and have encountered a peculiar issue. I have a module containing all my extern functions. The underlying C library has two functions with the same name, but different arguments. This, of course, is not allowed in an F# module.
module C =
open System.Runtime.InteropServices
[<DllImport("libc", CallingConvention = CallingConvention.Cdecl)>]
extern int setValue(nativeint source, int value)
[<DllImport("libc", CallingConvention = CallingConvention.Cdecl)>]
extern int setValue(nativeint source, string value)
// the previous function declaration cause the following compile-time error:
// Duplicate definition of value 'setValue'
Is there some special way to work around this? I can not alter the C library.
The EntryPoint attribute should work (e.g. with an ordinal), if MSDN can be trusted (haven't tested in F#). Name your imported functions e.g. setValueInt() and setValueString().