I'm designing a base class for camera classes. The intent is to use a signal to notify the clients of a newly available image. Cameras may have 8- or 16-bit pixels. I'm trying to templatize them as follows:
#include <boost/signals2.hpp>
#include <boost/cstdint.hpp>
template<typename PX>
class ICamera
{
public:
typedef PX pixel_type;
typedef PX const *pFrame;
typedef boost::signals2::signal<void (ICamera &cam, pFrame buffer)> CaptureSig;
typedef CaptureSig::slot_type CaptureSlot; /* error on this line */
virtual boost::signals2::connection AddCaptureListener(CaptureSlot slot) = 0;
};
In MSVS 2008, when I derive a class from ICamera<uint8_t>, there are compile errors on the typedef on slot_type, firstly: "missing ; before identifier CaptureSlot". That is, the CaptureSig::slot_type is not defined at that point.
Is there a way to get beyond this, other than defining the signal and slot in each derived class?
UPDATE:
It's actually not the parameter to the signal that's causing the problem, it's the existence of the signal definition within the template. The same error crops up if the signal's signature is changed to fixed types.
Related
I am migrating code from Objective-C to Swift 4.0. Here I have some float #define constants related to my deviceHeight in Specific Objective-C header class. While accessing this #define giving error "Use of unresolved identifier". When I use Objective-C string #define identifier it's easily accessible within Swift class.
Not accessible in Swift4
#define PHONE_IPHONE10 PHONE_UISCREEN_HEIGHT==812.0f
Accessible in Swift4
#define ERROR #"Some error occured. Please try later."
Help me with your comments or solution.
The reason this imports to Swift...
#define ERROR #"Some error occured. Please try later."
...is that it’s semantically equivalent to a constant declaration. That is, it permanently associates that string-literal value with the name ERROR. The Swift compiler recognizes that you’re using the C preprocessor to define a constant, and translates it to a Swift constant.
(Even though you could—and probably should—define C global constants without the preprocessor, Swift recognizes that there’s a long tradition of using #define instead, and imports it anyway.)
The reason this doesn’t import to Swift...
#define PHONE_IPHONE10 PHONE_UISCREEN_HEIGHT==812.0f
...is that this is a preprocessor macro. It doesn’t statically map a name to a value. Instead, it tells C that wherever it sees your name PHONE_IPHONE10, it should substitute the expression PHONE_UISCREEN_HEIGHT==812.0f. Presumably PHONE_UISCREEN_HEIGHT is itself a macro, so the whole thing expands to a chain of method calls and an equality comparison.
Swift itself doesn’t do preprocessor macros, or anything like such, so it doesn’t import them from C.
A close equivalent would be to redefine this logic using a computed property or function (and the idiomatic way to do that in Swift would be as a static member on a type, not a global symbol). Something like this:
extension UIDevice {
class var isMaybeiPhoneX: Bool {
return false // or some logic based on UIScreen.main.size
}
}
But be warned, the whole idea of conditionally changing your app’s UI or behavior based on a specific screen height check is fraught with peril. Tried Auto Layout?
To achieve similar functionality I created Constants.swift file with this structure:
struct Constants {
struct phoneHeights {
static let PHONE_UISCREEN_HEIGHT = 812.0
//some others consts
}
struct iPhoneX {
static let statusBarHeight: CGFloat = 44
//some others consts
}
}
Or simply:
struct Constants {
static let PHONE_UISCREEN_HEIGHT = 812.0
static let statusBarHeight: CGFloat = 44
}
And for type safety in Swift, you can read here.
The following structure:
struct match_str {
const char* s; // Pointer to string
const uint8_t l; // Length
};
Is intended to be initialized only as follows:
const match_str s = {"200 OK", 5};
and used as normal struct with constant members. During compilation time, I get the following warning:
warning #370-D: class "match_str" defines no constructor to initialize the following: const member "match_str::l"
What can I do with the warning? I get the warning, it makes sense, but I am not sure how to handle it. Basically, this is a safer c-string structure that I use in my code, and each instance is hand written like the const char*
Reference:
Is this warning alright - "#368-D: <entity> defines no constructor to initialize the following:"?
warning #411: class foo defines no constructor to initialize the following:
Just get rid of the const in the struct, and make the instances of the struct const, which will serve the purpose of keeping members constant.
Is it possible to emit a signal on behalf of another QObject? the reason I would like to do this is that it would be very useful when writing mock/test code and simply want to simulate that a certain object emitted a signal.
I tried to use
QMetaObject::invokeMethod(otherObject, "mySignal", Q_ARG(QString, myArg));
because the documentation says:
[...] Invokes the member (a signal or a slot name) on the object obj.[...]
But this does not work for me. The signal is simply not emitted.
You can simply invoke the signal through the class like so:
otherObject.mySignal("Testing!");
Edit
Good point on the thread-safety issue. I got it to work as well with the invokeMethod solution by explicitly setting the connection type. If your objects are in different threads, you'd need to use the QueuedConnection rather than the DirectConnection. Here is my simple test case:
main.cpp
#include <QObject>
#include "Stub.h"
int main()
{
Stub stub;
Stub2 stub2;
QObject::connect(&stub, &Stub::TestSignal, &stub2, &Stub2::TestReceiver);
QMetaObject::invokeMethod(&stub,
"TestSignal",
Qt::DirectConnection,
Q_ARG(QString, "myArg"));
return 0;
}
Stub.h
#ifndef STUB_H
#define STUB_H
#include <QObject>
#include <QDebug>
class Stub : public QObject
{
Q_OBJECT
signals:
void TestSignal(QString s);
};
class Stub2 : public QObject
{
Q_OBJECT
public:
void TestReceiver(QString s) {qDebug() << "Got s:" << s;}
};
#endif // STUB_H
I have to use dlopen() and access functions from shared object in my code. Do I need to include headers of corresponding functions of shared object ?
Because of the way dlopen() and dlsym() operate, I don't see how that would accomplish anything. Very roughly speaking, dlopen() copies the library binary into your program space and adds the addresses of its exported symbols (i.e. global functions & variables) to your program's symbol table.
Because the library was not linked to your program at compile-time, there's no way your code could possibly know the instruction addresses of these new functions tacked on at run-time. The only way to access a run-time dynamically linked symbol is via a pointer obtained from dlsym().
You have to create a function pointer for each and every library definition that you want to use. If you want to call them like regular functions, in C-language you can manually typedef type definitions for the function pointers, specifying their parameters and return values, then you can call the pointers just like regular functions. But note that you have to define all of these manually. Including the library header doesn't help.
In C++ I think there are issues with storing dlsym() output in a typedef'd pointer due to stricter standards, but this should work in C:
addlib.c (libaddlib.dylib):
int add(int x, int y) {
return x+y;
}
myprogram.c:
#include <stdio.h>
#include <dlfcn.h>
typedef int (*add_t)(int, int);
int main() {
void *lib_handle;
add_t add; // call this anything you want...it's a pointer, it doesn't care
lib_handle = dlopen("libaddlib.dylib", RTLD_NOW);
if (lib_handle == NULL) {
// error handling
}
add = (add_t)dlsym(lib_handle, "add");
if (add == NULL) {
// error handling
}
printf("Sum is %d\n", add(17, 23));
dlclose(lib_handle); // remove library from address space
return 0;
}
(Update: I compiled the dylib and myprogram...it works as expected.)
I have following code
ref class A
{
typedef ref struct All
{
std::string x;
}All_t;
};
in my program I am using it in following manner
A::All_t t;
t.X = "H";
This declaration throwing error as
error C4368: cannot define 'x' as a member of managed 'A::All': mixed types are not supported
I understand that I am declaring native varible inside managed code which is not allowed but now I would like to know changes I will need to make to make my structure suitable to managed project.
Thanks.
I'm assuming you originally had std::string x; not std::string *x (since using the pointer to string does not generate that error). You are not allowed to directly embed a native type in a managed type, but you are allowed to indirectly have one (via a pointer) See:
http://msdn.microsoft.com/en-us/library/xhfb39es(v=vs.80).aspx
After I fixed the compiler errors in your sample, it builds without error:
#include "stdafx.h"
#include <string>
using namespace System;
ref class A
{
public:
typedef ref struct All
{
std::string * x;
}All_t;
};
int main(array<System::String ^> ^args)
{
A::All_t t;
t.x = new std::string("H");
return 0;
}