I'm working on a port from some old Delphi code to VC++ 2013, and I'm encountering an error that I feel should be an easy fix but cannot for the life of me figure out...
The problem is this: I have a number of common utility functions in a local file Utils.h that I am deploying as part of a windows form. Most (90%) of the functions in this header work as normal. GetMsg(...), however, throws a C3861 Identifier not found error...
Utils.h (snippet): GetMsg declared at bottom
#pragma once
/*------------------------------------------------------------------------*
Includes:
*------------------------------------------------------------------------*/
using namespace std;
/*------------------------------------------------------------------------*
Constants:
*------------------------------------------------------------------------*/
#define GET_MSG_TIMEOUT 2
/*------------------------------------------------------------------------*
Typedefs, Structs, Enums:
*------------------------------------------------------------------------*/
typedef union
{
unsigned long ui32;
unsigned char ui8[4];
} UI32_UI8;
typedef union
{
unsigned short ui16;
unsigned char ui8[2];
} UI16_UI8;
typedef union
{
float f;
unsigned char ui8[4];
} F_UI8;
typedef struct
{
string sName;
string sVersion;
string sCompany;
string sCopyright;
} PRODUCT_INFORMATION;
/*------------------------------------------------------------------------*
Prototypes:
*------------------------------------------------------------------------*/
unsigned short SwapShort(unsigned short aShort);
float SwapFloat(float aFloat);
unsigned long SwapLong(unsigned long aLong);
unsigned int ReadLine(unsigned char *msgBuf, SerialPort^ Hdl, bool ReturnLF);
void __stdcall FillTheBuffer(char *buf, String sss, int length);
string __stdcall FillTheString(string sss, int length);
unsigned int __stdcall GetMsg(SerialPort^ Hdl, unsigned char *msgBuf);
GetMsg Definition in Utils.cpp:
//---------------------------------------------------------
unsigned int __stdcall GetMsg(SerialPort^ Hdl, unsigned char *msgBuf)
{
...
}
And, finally, GetMsg usage in form file:
#include "Utils.h"
...
void MainForm::UploadButton_Click
(System::Object^ object, System::EventArgs^ e)
{
...
SwapShort(1); //Works fine, also declared in Utils.h
GetMsg(spCom, inBuf); //C3861 ERROR
...
}
Where spCom is a (SerialPort^) contained, configured, and opened within the windows form. inBuf is a simple array of characters (char*) to buffer the input. I've tried renaming the function, thinking that there may have been an unintentional conflict / overload in other files, to no avail.
Any advice? Thanks, in advance
Solved the problem -- As it turns out I needed to be more explicit in my function definitions. Changing the declaration to read
GetMsg(System::IO::Ports::SerialPort^ Hdl, unsigned char *msgBuf)
eliminated the C3861 error. It would seem that the lack of a specific namespace on the declaration passed Intellisense but confused the compiler, rendering it unable to determine which prototype to use with the function call.
Related
I try to use libbsm/openbsm library and Swift5 in Xcode11.
Why? I can not fine AUDITPIPE_SET_PRESELECT_MODE.
Can I use libbsm/openbsm in Swift?
var mode = AUDITPIPE_PRESELECT_MODE_LOCAL // <- works very well
if ioctl(auditFD, AUDITPIPE_SET_PRESELECT_MODE, &mode) == -1 {
return -1
}
I ran into the same issue with Swift unable to import these complex macros. Quinn “The Eskimo!” pointed me in the direction of declaring them as c constants. So I created them in a c file in my project.
In the .h file I did the following:
#include <stdio.h>
#include <bsm/libbsm.h>
#include <sys/ioctl.h>
#include <security/audit/audit_ioctl.h>
// -- Macros used for creating an auditpipe
extern unsigned long QAUDITPIPE_SET_PRESELECT_MODE;
extern unsigned long QAUDITPIPE_GET_QLIMIT_MAX;
extern unsigned long QAUDITPIPE_SET_QLIMIT;
extern unsigned long QAUDITPIPE_SET_PRESELECT_FLAGS;
extern unsigned long QAUDITPIPE_SET_PRESELECT_NAFLAGS;
// -- End auditpipe macros
And in my .c file i have:
unsigned long QAUDITPIPE_SET_PRESELECT_MODE = AUDITPIPE_SET_PRESELECT_MODE;
unsigned long QAUDITPIPE_GET_QLIMIT_MAX = AUDITPIPE_GET_QLIMIT_MAX;
unsigned long QAUDITPIPE_SET_QLIMIT = AUDITPIPE_SET_QLIMIT;
unsigned long QAUDITPIPE_SET_PRESELECT_FLAGS = AUDITPIPE_SET_PRESELECT_FLAGS;
unsigned long QAUDITPIPE_SET_PRESELECT_NAFLAGS = AUDITPIPE_SET_PRESELECT_NAFLAGS;
So now I can just use QAUDITPIPE_SET_PRESELECT_MODE in my Swift code. Works great!
The current C++ compilers fail to find a suitable overload for std::shared_ptr when using a C-array as a type.
I can make it a real std::array object and that works, but the library I'm linking against (fftw3) has already created the typedef and uses it in all of it's C-API calls.
#include <memory>
typedef double fftw_complex[2];
int main(int argc, char* argv[])
{
fftw_complex bob; //works fine
bob[0]=2; bob[1]=-1; //works fine
std::shared_ptr<fftw_complex> handle; //works fine
std::shared_ptr<double> other(new double[35]); //works fine
handle = std::shared_ptr<fftw_complex>(new fftw_complex[35]);//can't find constructor
return 0;
}
Up until a few months ago this worked fine with all compilers. With the update to gcc to version 7.3, 8.2, and 9 I now get an error when trying to compile the non-void constructor. I suspect it is because of the "improvements" to std::shared_ptr to automatically handle when T is an array type.
I get the error
complex_shared.cpp:12:61: error: no matching function for call to 'std::shared_ptr<double [2]>::shared_ptr(double (*)[2])'
12 | handle = std::shared_ptr<fftw_complex>(new fftw_complex[35]);
and the somewhat difficult to parse error message
note: candidate: 'template<class _Yp, class> std::shared_ptr<_Tp>::shared_ptr(_Yp*)'
139 | shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
| ^~~~~~~~~~
/usr/local/Cellar/gcc/9.2.0/include/c++/9.2.0/bits/shared_ptr.h:139:2: note: template argument deduction/substitution failed:
/usr/local/Cellar/gcc/9.2.0/include/c++/9.2.0/bits/shared_ptr.h: In substitution of 'template<class _Tp> template<class ... _Args> using _Constructible = typename std::enable_if<std::is_constructible<std::__shared_ptr<_Tp>, _Args ...>::value>::type [with _Args = {double (*)[2]}; _Tp = double [2]]':
/usr/local/Cellar/gcc/9.2.0/include/c++/9.2.0/bits/shared_ptr.h:137:30: required from here
/usr/local/Cellar/gcc/9.2.0/include/c++/9.2.0/bits/shared_ptr.h:106:8: error: no type named 'type' in 'struct std::enable_if<false, void>'
106 | using _Constructible = typename enable_if<
it seems you have to let std::shared_ptr know that this is not a normal pointer but is indeed a pointer to an array
#include <memory>
typedef double fftw_complex[2];
int main(int argc, char* argv[])
{
fftw_complex bob;
bob[0]=2; bob[1]=-1;
std::shared_ptr<fftw_complex[]> handle;
std::shared_ptr<double> other(new double[35],[](double* p){ delete[] p;});
std::shared_ptr<double[]> nother(new double[35]); //std::shared_ptr will call delete[]
handle = std::shared_ptr<fftw_complex[]>(new fftw_complex[35], [](fftw_complex* p){ /* special delete logic*/;});
return 0;
}
to be clear, I have to use the fftw_malloc and fftw_free functions for this memory, so I will be providing my own deleter for the fftw_complex type. delete[] is incorrect for these library-provided data elements.
Websource.hpp
#ifndef WEBSOURCE_HPP
#define WEBSOURCE_HPP
#pragma once
class Colour
{
public:
unsigned char _ucRed;
unsigned char _ucGreen;
unsigned char _ucBlue;
Colour(unsigned char i_red, unsigned char i_green, unsigned char i_blue);
Colour(Colour& c);
Colour();
void setColour(unsigned char i_red, unsigned char i_green, unsigned char i_blue);
};
Colour::Colour(unsigned char i_red, unsigned char i_green, unsigned char i_blue)
{
this->setColour(i_red, i_green, i_blue);
}
Colour::Colour(Colour& c)
{
this->setColour(c._ucRed, c._ucGreen, c._ucBlue);
}
Colour::Colour()
{
this->setColour((unsigned char)0, (unsigned char)0, (unsigned char)0);
}
void Colour::setColour(unsigned char i_red, unsigned char i_green, unsigned char i_blue)
{
this->_ucRed = i_red;
this->_ucGreen = i_green;
this->_ucBlue = i_blue;
}
#endif
Website.hpp
#ifndef WEBSITE_HPP
#define WEBSITE_HPP
#pragma once
#include "Websource.hpp"
template <typename T, int N = 16>
class Page {
public:
static Colour c_logo; // logo colour
};
Colour website::Page<double>::Page::c_logo();
#endif
This code leads to Error 0147.
Severity Code Description Project File Line Suppression State Error
(active) E0147 declaration is incompatible with "Colour
website::Page::c_logo [with T=double, N=16]" (declared at line
31 of
"c:\Users\hasler\Documents\ga_design\Website.hpp") ga_design c:\Users\hasler\Documents\ga_design\Website.hpp 88
However, using another constructor works like a charm:
Colour website::Page<double>::Page::c_logo(0,0,0);
And I'm here struggling to understand why one constructor would work and another wouldn't.
To mark the question as answered: "It's a case of the most vexing parse in C++. Using Colour website::Page::Page::c_logo; will work." – R Sahu
I am trying to write a simple matrix operations API using go and expose the APIs as a shared library. This shared library will be used from Java(using JNA) and from C.
The documentation is very sparse about using any data type beyond simple int or string as function parameters.
My requirement is to expose functions with 1 or more 2D slices as parameters AND also as return types. I am not able to figure out if such a thing is supported.
Is this possible? Are there any examples for this?
I think the key point is to have a look to the c bindings of slice,string and int generated by go build tool. I not tried 2D slice, but it should no different to 1D slice with unsafe pointer converter, maybe just be one more time allocation and convertion.
I'm not sure it's the best way, but here's the example for 1D slice:
the go part:
import "C"
//export CFoo
func CFoo(content []byte) string{
var ret []byte
//blablabla to get ret
cbuf := unsafe.Pointer(C.malloc(C.size_t(len(ret))))
C.memcpy(cbuf, unsafe.Pointer(&ret[0]), C.size_t(len(ret)))
var finalString string
hdr := (*reflect.StringHeader)(unsafe.Pointer(&finalString))
hdr.Data = uintptr(unsafe.Pointer(cbuf))
hdr.Len = len(ret)
return finalString
}
compile with -buildmode=c-shared, to get libmygo.so.
I not know JNA, expecting it like JNI. the JNI part as well as pure C part:
#include <stdio.h>
#include <jni.h>
#include <string.h>
typedef signed char GoInt8;
typedef unsigned char GoUint8;
typedef short GoInt16;
typedef unsigned short GoUint16;
typedef int GoInt32;
typedef unsigned int GoUint32;
typedef long long GoInt64;
typedef unsigned long long GoUint64;
typedef GoInt32 GoInt;
typedef GoUint32 GoUint;
typedef __SIZE_TYPE__ GoUintptr;
typedef float GoFloat32;
typedef double GoFloat64;
typedef float _Complex GoComplex64;
typedef double _Complex GoComplex128;
typedef struct { const char *p; GoInt n; } GoString;
typedef void *GoMap;
typedef void *GoChan;
typedef struct { void *t; void *v; } GoInterface;
typedef struct { void *data; GoInt len; GoInt cap; } GoSlice;
JNIEXPORT JNICALL jbyteArray Java_com_mynextev_infotainment_app_myev_Native_foo(JNIEnv* env, jobject obj,jbyteArray content){
JNIEnv ienv = *env;
void * Ccontent = ienv->GetByteArrayElements(env, content, 0);
int Lcontent = ienv->GetArrayLength(env, content);
GoSlice Gcontent = {Ccontent, Lcontent, Lcontent};
if(!gret.n){
printf("jni CDoAESEnc");
return NULL;
}
jbyteArray ret = ienv->NewByteArray(env, gret.n);
ienv->SetByteArrayRegion(env, ret, 0, gret.n, gret.p);
free((void*)gret.p);
ienv->ReleaseByteArrayElements(env, content, Ccontent, JNI_ABORT);
return ret;
}
build it with libmygo.so.
finally you get two so files. one for C which can be used standalone; one for Java which must be used with libmygo.so together.
#include <string.h>
#include <memcopy.h>
#include <pagecopy.h>
#undef memcpy
void *
memcpy (dstpp, srcpp, len)
void *dstpp;
const void *srcpp;
size_t len;
{
unsigned long int dstp = (long int) dstpp;
unsigned long int srcp = (long int) srcpp;
...
This is our familiar lib function memcpy's implementation, but I don't recognize its
signature and I've never seen it before. Can anyone tell me what it is?
This is our familiar lib function memcpy's implementation, but I don't recognize its signature
Which aspect of it don't you recognize? Is it the fact that it is written in K&R (pre-ANSI) C, or something else? Would you have recognized it if it was written that way instead:
void *
memcpy(void *dstpp, const void *srcpp, size_t len)
{
...
}