i am at wit's end trying to make SWI-Prolog play nice with C++. Now, before i start explaining exactly what my problem is, i want to first state what my project is about and what tools i chose in order to develop a solution.
My professor assigned to me the task of developing a GUI program that serves as a frontend to SWI-prolog, and this frontend is to be developed in C++. I chose to use Qt to design the GUI and use C++ as a backend to bridge SWI-Prolog to the application. The user of this application should be able to input some lists and then choose operations to be applied to them through prolog, like if, for example, I input a list of numbers, then by click of a button the user gets another list of all the numbers that are pairs in this list (if there are any). I am developing on a unix OS, more specifically, netrunner rolling release, based on archlinux and manjaro.
I did some research, and it seemed that the best course of action in order to interface SWI-Prolog (may i also mention that my professor also recommended this), is to use the header and source file developed by Volker Wysk; for reference, here is the link to the compressed file that contains these files http://www.volker-wysk.de/swiprolog-c++/index.html
Now here is my problem: if you visited the page i just gave you you will see that this C++ implementation of the SWI-Prolog interface is quite old: last time it was worked on was in the year 2002. I had to modify the header file so that i could get rid of some of the errors, like putting using namespace std or changing #include ostream.h to #include ostream, and so i managed to get the error count to only two which i can't manage to fix and which i think i won't be able to because there are two functions whose implementation i can't find anywhere: the function is declared but the code that it is supposed to run when they are called can't be found.
I will now list the contents of the files i consider to be most relevant. I have the latest version of SWI-Prolog installed, and so the SWI-Prolog.h header is the latest one that comes with the installation of the newest prolog (version 6.6.5).
#-------------------------------------------------
#
# Project created by QtCreator 2014-07-05T12:38:45
#
#-------------------------------------------------
QT += core gui
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = prologFrontend
TEMPLATE = app
SOURCES += main.cpp\
mainwindow.cpp \
../../../../../../../../usr/local/share/swiprolog-c++/prolog.cpp
LIBS += -L/usr/lib/swipl-6.6.5/lib/x86_64-linux -lswipl
HEADERS += mainwindow.h
FORMS += mainwindow.ui
contents of the prologFrontend.pro file (Qt creator project file)
#include "mainwindow.h"
#include <QApplication>
#include <prolog.hpp>
int main(int argc, char *argv[])
{
try {
Prolog_impl::prolog_init(argc, argv);
} catch(Prolog_impl::PlError &error) {
}
QApplication prog(argc, argv);
MainWindow w;
w.show();
return prog.exec();
}
contents of the main.cpp file
I would copy the whole contents of the header and source files made by Volker Wysk, but it's too long to fit in here. You can take a look at them if you download it from the link to his site i already posted. Next are the errors i am getting and the two corresponding code snippets where they happen in the .cpp file that he made:
// part of SWI-Prolog, but not exportet by header file
// /usr/local/src/swiprolog-4.0.9/src/pl-funcs.h
//NOTE: this function is declared here but it's even not to be found in the header file
//prolog.hpp. Its implementation can't be found anywhere using the function definition
//navigation capability of Qt so, basically, its a function that does nothing.
extern "C"{
unsigned long pl_atom_to_term(term_t in_atom,
term_t out_term,
term_t out_bindings);
}
bool Prolog_impl::atom_to_term(const char* text, Term* t, list<Term::Binding>* b)
{
Term in_atom = Atom(text);
Term out_term;
Term out_bindings;
if (!pl_atom_to_term(in_atom.lsi, out_term.lsi, out_bindings.lsi))
return false;
if (t) *t = out_term;
if (b) *b = out_bindings;
return true;
}
And the error that this code throws: /usr/local/share/swiprolog-c++/prolog.cpp:45: error: undefined reference to `pl_atom_to_term'.
//Note that this code has the same issues as the one above: no implementation to be found
extern "C"{
unsigned long pl_copy_term(term_t in, term_t out);
}
Term Prolog_impl::copy_term(Term t)
{
term_t t2 = PL_new_term_ref();
if (!pl_copy_term(t.lsi, t2))
throw LogicError("copy_term(Term)", "failure calling pl_copy_term()");
return Term(t2);
}
and the error that this code throws: /usr/local/share/swiprolog-c++/prolog.cpp:60: error: undefined reference to `pl_copy_term'.
Aside from the changes I had to make to the header file I already mentioned, I had to fix this line of code in the header file:
#include <SWI-Prolog.h>
to this:
#include "/usr/lib/swipl-6.6.5/include/SWI-Prolog.h"
This is because, otherwise, the compiler complains that it can't find that header file.
My guess is that these functions used to exist in an older SWI-Prolog version. I have no real clue about what to do with this task, i tried reading up on other alternatives to using volker's implementation but it's like there is close to none good information on the net about how to interface Prolog with C++.
Thank you so very much for taking your time to read my question. If you have a solution that works, please let me know. It doesn't have to be SWI-Prolog, it could be any other Prolog environment that interfaces nicely with C++ and that uses more or less about the same syntax that SWI-Prolog uses, though i think that the syntax is already standard for all environments.
Package swipl-win is a working SWI-Prolog / Qt interface, portable on Linux,MacOS,Windows. I have many others here, but these are restricted to running on Linux by now...
I wonder why, apart Qt specific problems, have you chosen an old, unmaintained C++ interface, when there is an 'official' one here. This interface is working pretty well, giving parameter validation based on exception handling and automatic type conversion. Then it's easy to add to the interface - for instance, from PREDICATE.h
typedef PlTerm T;
#define LOOP__ { } operator bool() { return next_solution(); }
#define query0(P) struct P : PlQuery { P() : PlQuery(#P, V()) LOOP__ };
#define query1(P) struct P : PlQuery { P(T A) : PlQuery(#P, V(A)) LOOP__ };
...
allows
query1(current_predicate)
void Completion::initialize(QSet<QString> &strings, bool reload) {
Q_UNUSED(reload)
T PRED;
for (current_predicate cp(PRED); cp; ) {
QString p = t2w(PRED);
if (p[0].isLetter())
strings.insert(p);
}
qDebug() << "Completion::initialize loaded" << strings.count();
}
About your specific problems, probably those functions are obsolete, you should stick to C Api (also know as foreign language interface) documented here.
Looking into the Makefile for swiprolog-c++-0.1.0, it looks like a special linker needs to be used, called plld. So you need to use your usual compiler to generate only the object files, then use that linker to create the executable.
The plld line in the makefile looks like this:
main : main.o prolog.o test.pl
plld -o $# -ld $(CC) $^ -lstdc++
The "recipe" line expands to this:
plld -o main -ld gcc main.o prolog.o test.pl -lstdc++
Related
I used QT Desginer to create a finalversion_with_buttons.ui file,
later i converted it to finalversion_with_buttons.h file using the command
uic -o finalversion_with_buttons.h finalversion_with_buttons.ui
in command prompt.
I got to know that we cannot have a .cpp file and .h file contains everything we need, now how do i execute/run this .h file ?
Please check Qt Creator documentation e.g. "Creating a Qt Widget Based Application". It will give you some overview how to setup qmake/CMake project based on UI form files (aka Qt Widgets). The UI files itself may not be used standalone. It is only UI description.
It is always of benefit to create a ".pro" or ".cmake" file that contails all the stuff for the compilation of the project that has several benefits, even for
small programms.
I highly suggest reading through this sites, that helped me a lot in creating/compiling projects:
https://www.cprogramming.com/tutorial/makefiles.html
https://www.cprogramming.com/tutorial/makefiles_continued.html
This is what an automatic generated .pro file of the qt creator contains and I guess self explainatory:
QT += core gui multimedia multimediawidgets
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
CONFIG += c++11
# The following define makes your compiler emit warnings if you use
# any Qt feature that has been marked deprecated (the exact warnings
# depend on your compiler). Please consult the documentation of the
# deprecated API in order to know how to port your code away from it.
DEFINES += QT_DEPRECATED_WARNINGS
# You can also make your code fail to compile if it uses deprecated APIs.
# In order to do so, uncomment the following line.
# You can also select to disable deprecated APIs only up to a certain version of Qt.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000 # disables all the APIs deprecated before Qt 6.0.0
SOURCES += \
main.cpp \
mainwindow.cpp
HEADERS += \
mainwindow.h
FORMS += \
mainwindow.ui
# Default rules for deployment.
qnx: target.path = /tmp/$${TARGET}/bin
else: unix:!android: target.path = /opt/$${TARGET}/bin
!isEmpty(target.path): INSTALLS += target
RESOURCES += \
mainwindow.qrc
If you are working with the qt designer part of the qt creator you got this xml .ui file and the easiest way to compile it would be just clicking on Build->Run or ctrl+R. If your .pro file looks like the above example with the right file names you should be good to go.
Actually it is possible to have just a c++ file and no header files - thats invented to make the projects more modular with classes - thats what c++ is all about compared with c. To quote Bjarne "Classes use to hide the ugly stuff" ..so you can read the programm and understand it without even knowing what the class files contain and do with your code with a proper reference, and you don't should have to care. And thats what qt does - hiding the ugly stuff you would have to do all by yourself in its classes so you can just call QPushButton and it works. (and many more benefits but to keep it simple, qt is just c++ classes)
This is an example for a class in the code without a header file:
[//example from here https://www.cprogramming.com/tutorial/lesson12.html][1]
#include <iostream>
using namespace std;
class Computer // Standard way of defining the class
{
public:
// This means that all of the functions below this(and any variables)
// are accessible to the rest of the program.
// NOTE: That is a colon, NOT a semicolon...
Computer();
// Constructor
~Computer();
// Destructor
void setspeed ( int p );
int readspeed();
protected:
// This means that all the variables under this, until a new type of
// restriction is placed, will only be accessible to other functions in the
// class. NOTE: That is a colon, NOT a semicolon...
int processorspeed;
};
// Do Not forget the trailing semi-colon
Computer::Computer()
{
//Constructors can accept arguments, but this one does not
processorspeed = 0;
}
Computer::~Computer()
{
//Destructors do not accept arguments
}
void Computer::setspeed ( int p )
{
// To define a function outside put the name of the class
// after the return type and then two colons, and then the name
// of the function.
processorspeed = p;
}
int Computer::readspeed()
{
// The two colons simply tell the compiler that the function is part
// of the class
return processorspeed;
}
int main()
{
Computer compute;
// To create an 'instance' of the class, simply treat it like you would
// a structure. (An instance is simply when you create an actual object
// from the class, as opposed to having the definition of the class)
compute.setspeed ( 100 );
// To call functions in the class, you put the name of the instance,
// a period, and then the function name.
cout<< compute.readspeed();
// See above note.
}
And a compiler doesn't see something else after the linker is done than that.
so
"I got to know that we cannot have a .cpp file and .h file contains
everything we need"
is not right because you can as seen in the example above. Just its not how c++ (or c with classes as it was called in the early days) should be used.
But to answer your question:
"how do i execute/run this .h file ?"
like said before, just use the qt creator and click on Run or crtl + R
(it is free for opensource and edu)
create a project file like exampled before and use qmake SampleProject.pro
in the command line. This will create a file by the name of “Makefile” in the project directory.
(like described here https://vitux.com/compiling-your-first-qt-program-in-ubuntu/
than issue the command make in the same directory
(also described here)
Create a make file like described in link 1 and 2.
Everything else is beyond the scope of this question like fiddling out the semantic for using gcc or g++
That being said, you can create QPushButtons and all the stuff with the qt creator or you can create push buttons just in the code without using the .ui xml - file
like described here:
https://www.bogotobogo.com/Qt/Qt5_LayoutNotUsingDesigner.php
But what all of the guys here highly suggest is: Get yourself a goot qt/c++ book or tutorial and learn the foundations about classes and qt and you gonna get to be a really good programmer in no time. I also hope deeply this post is able to clarify a lot of qt programming/compiling for you and you start to have fun and will create really nice applications :) Cheers
The Situation
I am writing a wrapper library for GPIB communications for setting up specific instruments according to a clients specifications to automate some of their processes. I have to use C++ and the old '98 compiler in VC++ 6.0 running on a Windows NT machine to maintain compatibility with some other devices they use regularly.
I am trying to make a class that combines some GPIB commands into easier to remember functions, while also keeping the capability of directly communicating with the instruments. To that end, I have compiled different parts of my project into different libs and dlls, each dll being a different device that they might want to communicate with. I also made a generic dll base class from which all the specific instrument classes inherit, hopefully making the whole setup as modular as possible.
The Problem
So, with all that said, I have an issue when I try to test the different dlls/modules. I created a project to test the generic base class, added the .lib file to the project, which links to the .dll, and also #included the header file for that dll. testGeneric.cpp looks like this:
#include "GENERIC.h"
void main(void) {
GPIBInstrument hp(2); //connects to device at primary address #2
hp.write("*IDN?");
}
Super simple. To be clear, I also have the GENERIC.lib linked in the "Resource Files" folder in VC++ 6.0, and I have GENERIC.dll accessible from the path variable.
Moving on, GENERIC.h looks like this (select parts):
#ifndef GENERIC_H
#define GENERIC_H
#include <string>
#include <windows.h>
#include "decl-32.h"
#ifdef GENERIC_EXPORT
#define GENERIC_API __declspec(dllexport)
#else
#define GENERIC_API __declspec(dllimport)
#endif
...(Inline exception classes)...
class GENERIC_API GPIBInstrument {
...
public:
void write(std::string command);
...
};
#endif
Just showing the relevant methods. Then GENERIC.cpp:
#define GENERIC_EXPORT
#include "GENERIC.h"
...
void GPIBInstrument::write(std::string command) {
ibwrt (handle, &command[0u], command.length());
std::cout << command << std::endl;
if (ibsta & TIMO) {
timeoutError();
}
if (ibsta & ERR) {
error("Unable to write command to instrument: " + command);
}
}
So, looks pretty good right? No issues. Compiles fine. I try running it, and BLAM! I get this: "User breakpoint called from code at 0x77f7645c". So, then I thought, well maybe it would work if I put all the code from GENERIC.h and GENERIC.cpp into one file, and #included that file all as inline code. So I tried it, and it and it compiled nicely, and ran fine.
Question (<-AHA!... But...)
What am I doing wrong!? Something with the way I'm making the .dll? Or the .lib? Or something else entirely?
EDIT (WHY!?)
So, after a bit of debugging, I found that it was something to do with passing a string literal. So I just modified it to:
std::string command = "*IDN?";
hp.write(command);
and it worked fine. My followup question, is why? What's the difference between having a string literal passed, versus assigning that to a variable and then passing it in?
Using complex types such as std::string as a parameter at a DLL boundary is tricky. You must ensure that the exe and the DLL use the exact same instance of the library code. This requires that you build them both to use the same version of the DLL version of the runtime library.
I'm trying to intercept some native library-calls via LD_PRELOAD.
This is working fine for simple libraries written in C, but now I try to go further and override some more complex class-methods from the AOSP written in C++.
Here's my example:
#include <rs/cpp/util/RefBase.h>
namespace android {
sp<MediaCodec> MediaCodec::CreateByType(const sp<ALooper> &looper, const char *mime, bool encoder) {
// TODO this will be implemented by me
return NULL;
}
}
In my Application.mk, I got the following piece of code:
APP_STL := gnustl_static
and inside the Android.mk this one:
LOCAL_STATIC_LIBRARIES += libstlport_static
Sadly, the error I get is the following:
jni/libhook/ld_preload.cpp:88:1: error: 'sp' does not name a type
Anyone an idea how to use sp<..> here? I assume it's not Android-specific but a standard C++-thing - I'm totally new at C++, just started "today" :)
I know this may be bad practice, so I'm welcome for any other idea.
sp<> is Android-specific. sp<> is Strong Pointer, wp<> is Weak Pointer; they came into being as part of the Binder IPC implementation.
The place to start looking for the implementation is the framework RefBase.h, which is a bit twisty for a C++ newcomer. None of what you're fiddling with is part of the public API defined by the NDK, which means it's subject to change between releases, so be aware that what you're trying to do may not work across devices or software updates.
So...I have a kernel mode component and a user mode component I'm putting together using the turnkey build environment of the NT DDK 7.1.0. The kernel component is all .c/.h/.rc files. The user mode component is .cpp/.c/.h/.rc files.
At first it seemed simplest to use build for both, as I saw you could modify the ./sources file of the user mode component to say something like:
TARGETNAME = MyUserModeComponent
TARGETTYPE = PROGRAM
UMTYPE = windows
UMENTRY = winmain
USE_MSVCRT = 1
That didn't seem to cause a problem and so I was pleased, until I tried to #include <string> (or <memory>, or whatever) Doesn't find that stuff:
error C1083: Cannot open include file: 'string': No such file or directory
Still, it's compiling the user mode piece with C++ language semantics. But how do I get the standard includes to work?
I don't technically need to use the DDK build tool for the user mode piece. I could make a visual studio solution. I'm a bit wary as I have bumped into other annoyances, like the fact that the DDK uses __stdcall instead of __cdecl by default... and there isn't any pragma or compiler switch to override this. You literally have to go into each declaration you care about and change it, assuming you have source to do so. :-/
I'm starting to wonder if this is just a fractal descent into "just because you CAN doesn't mean you SHOULD build user mode apps with the DDK. Here be dragons." So my question isn't just about this particular technical hurdle, but rather if I should abandon the idea of building a C++ user mode component with the DDK tools...just because the kernel component is pure C.
To build a user mode program with WINDDK you need to add some variables to your SOURCES file:
386_STDCALL=0 to use cdecl calling convention by default
USE_STL=1 to use STL
USE_NATIVE_EH=1 to add a support for exception handling
Everything else you already have.
I'll put my full SOURCES file for reference:
TARGETNAME = MyUserModeComponent
TARGETTYPE = PROGRAM
TARGETPATH = obj
UMTYPE = console
UMENTRY = main
USE_MSVCRT = 1
USE_NATIVE_EH=1
USE_STL=1
386_STDCALL=0
SOURCES= main.cpp
And main.cpp:
#include <iostream>
#include <string>
using namespace std;
int main()
{
string s = "bla bla bla!";
cout << s;
return 0;
}
Have fun!
Quick Answer
Abandon the idea of building user-mode components with DDK tools (although I find the concept fascinating :-P)
Your kernel mode component should be built separately from the user mode components as a matter of good practice.
Vague thoughts
Off the top of my head, and this really speaking from limited experience...there are a lot of subtle differences that can creep up if you try to mix the two together.
Using your own example of __cdecl vs __stdcall; You have two different calling conventions. _cdecl is all kernel stuff and all of the C++ methods are wrapped around in WINAPI (_stdcall) passing conventions and __stdcall will clean do auto stack clean up and expect frame pointers inserted all over the place. And if you by accident use compiler options to trigger a __fastcall, it would be a pain to debug.
You can definitely hack something together, but do you really want to keep track of that in your user-space code and build environment? UGH I say.
Unless you have very specific engineering reasons to mix the two environments, (and no a unified build experience is not a valid reason, because you can get that from a batch file called buildall.bat) I say use the separate toolchains.
I want to do unit testing for some simple exercises i have done in c++ using Qt. i figured using QtTest seemed like a reasonable place to start.
i have a class that returns an integer and i want to test that the expected result is the same as the actual.
am i right in thinking i make a new c++ source file in the project to use as the QtTest
heres what i have but from reading the Qt documentation i cant work out what i have to do?
#include "Conversion.h"
#include <QtTest/QtTest>
class ConversionTest : public QObject
{
private slots:
void testConvert();
};
void ConversionTest::testConvert()
{
int unit1 = 1, unit2 = 10;
std::string sUnit1 = "stone", sUnit2 = "pound";
double expected = 10.8862;
double actual;
Conversion c;
actual = c.convert(unit1, unit2, sUnit1, sUnit2);
QCOMPARE(expected, actual);
}
QTEST_MAIN (ConversionTest)
#include "conversiontest.moc"
this is what i produced after reading the documentation but now what how do i run it and get the (what i think is) console output that says pass/fail?
any help would be great thanks
You need to create an app with it (QTEST_MAIN(..) builds the main function for you), and specify CONFIG += qtestlib in the .pro file.
When you run it, a console opens that prints out the test results.
I solved this myself the problem was just Qt errors no problem with the code at all, for some reason it didnt like that my project files were in a folder structure of more than one folder before my project files, used the exact same code in a new dir and it worked?? :S