I create a simple test.cpp file in my Xcode project.
#include "MyTest.h"
#include <stdio.h>
int main(int argc, char** argv) {
printf ("Calling MyTest Main\n");
}
It compiles. I think I need to create a Target and Executables before I can launch in XCode.
But I need some help with these questions:
1. What kind of Target i should create for my simple .cpp file? It is not a GUI application.
2. How to specify this main in test.cpp to be the starting point of my Target and Executable?
Thank you.
1) You probably want a Command Line Tool application.
2) When you launch your tool, the mach kernel calls the start() function in the C Runtime Library, which invokes main() with the count of arguments (argc) and an array of argument string pointers (argv). So the main() that you show above is what will run.
You can use a special linker command to designate one of your own functions to be run instead of start(), but almost nobody does.
Related
Edit:
This program compiles. It's only when run does it fail to find iostream. I'm using the libclang.dylib that is bundled with Xcode.
I've written a small tool to begin working with libclang. I'm trying to parse TranslationUnits. The following program is saved in the file tool.cpp. Once compiled and run, it tries to parse tool.cpp as a TU. It's failing to get a clean run with default headers as it cannot find iostream on my Mac. After several attempts to supply arguments that point to the file, it still doesn't work. Any ideas?
#include "tool.h"
#include <iostream>
int main(int argc, char* argv[]) {
CXIndex index = clang_createIndex(0,0);
const char *args[] = {
"-I/usr/include",
"-I/usr/local/include",
"-I.",
"-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include",
//Should be here
"-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1"
}
;
Output:
tool.cpp 6:10: 'iostream' file not found
I've got the same issue. I am trying to add CPP to iOS Objective-C. It's not working. I found that this is about next "pain" from Apple because they do not use standard C++ library anymore. I've tried everything that mentioned on this site but haven't found any solution:
I'm using doctest for the tests in my C++ project.
I would like to put the test code alongside my implementations, as the library says is possible, but I can't seem to figure out what to do with the doctest implementation code.
I have a doctest.cpp file that looks like this:
#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
#include "doctest.h"
A main.cpp that looks like this:
#include "thing.h"
int main(int argc, const char *argv[]) {
do_thing();
}
thing.h is self-explanatory, but thing.cpp looks like this:
do_thing() {}
TEST_CASE("Test thing") {
CHECK(1 == 1);
}
CMake is used to create two executables, a Tests executable and a Main executable.
If I don't include doctest.cpp in my project sources for Main, I get undefined reference errors because it can't find a definition for all the testing stuff in doctest.
However, if I do include it I get errors because there are multiple main() functions in one target.
I can't find any info on this in the doctest documentation.
How are you meant to get around this?
The author of the library gave a good response in this issue:
DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN implements the test runner and also defines a main() function.
DOCTEST_CONFIG_IMPLEMENT implements ONLY the test runner.
If you define your own main() then you should use DOCTEST_CONFIG_IMPLEMENT - have a look at the relevant docs.
You will need the test runner implemented in your main executable (that means doctest.cpp) since you are writing your tests alongside your production code.
You can also define DOCTEST_CONFIG_DISABLE when building the main executable so tests are written in the production code but aren't compiled (you will still need doctest.cpp so it all links). This way you won't need to #ifdef the tests.
You could also entirely remove the test executable and use the main executable for running the tests - docs.
I went with the first option of writing my own main() function.
I encountered the same problem and one workaround is to add -DDOCTEST_CONFIG_DISABLE to the compiler flags when you compile Main.
I've created a cpp file with the main method implementing calls to lua.
When compiling + executing the qt project I receive the following error:
PANIC: unprotected error in call to Lua API (attempt to call a string value)
The problem is that lua cannot find the lua file to be executed (at least I think it is). So I copied the file to all the debug dirs and the main dir but it still didn't work.
Thanks for helping me!
main.cpp
#include <stdio.h>
extern "C" {
#include "lua.h"
#include "lualib.h"
#include "lauxlib.h"
}
lua_State* L;
int main(int argc, char *argv[])
{
/* initialize Lua */
L = luaL_newstate();
/* load Lua base libraries */
luaL_openlibs(L);
/* load the script */
luaL_loadfile(L, "test.lua");
lua_call(L, 0, 0);
/* cleanup Lua */
lua_close(L);
}
and the file test.lua
-- test
print("Hello World")
Given that this is a run-time file operation, the function is likely only looking in the current directory.
It seems like Qt uses the user's directory as default path.
You can validate this with: (thanks Rich)
QDir dir(".");
qDebug() << dir.absolutePath();
When putting the lua script into this folder everything works like a charm.
The working directory can be set with the following command:
QDir::setCurrent()
And in combination with
QCoreApplication::applicationFilePath()
The path can be set to where the exe resigns in.
This is not really related to Qt since you are not using any of the Qt API in your software.
You should check the status returned by the lual_loadfile method like shown in this example. That should give you some additional clues about what is going wrong.
Just in case, there's a QtLua module that could be of interest.
I am trying to use windows dll functionality in Linux.
My current solution is a compilation of a separate wine application, that uses dll and transfer requests/responses between dll and main application over IPC.
This works, but is a real overhead comparing to a simple dll calls.
I see that wine-compiled program usually is a bootstrapping-script and some .so, which (according to file utility) is normal linux dynamically linked library.
Are there any way to link that .so directly to my application? Are there any manual?
You may be able to use Winelib to write a Linux app that can use Windows DLLs.
EDIT:
For future reference:
libtest.c:
#include <stdio.h>
#include <windows.h>
int main(int argc, char* argv[])
{
HMODULE h;
h = LoadLibrary("cards.dll");
printf("%d\n", h);
}
Execution:
$ winegcc -m32 libtest.c
$ ./a.out
536936448
After looking for a way to detect the filetype of a file stream, I found that the Unix file command uses libmagic and I'm trying to make use of the library myself, but I can't get it to work. I've rarely integrated 3rd party code in my own, so that's probably a big part of my problem as well.
Why:
I'm doing this because I have a portable gui image viewing app that will need to detect archive file types (rar, zip, more?) from given filename and then the image file types inside. I'm hoping that I can use libmagic for Windows and Linux (and Mac), so if this isn't the case, stop me now b/c I'll need to find something else.
Attempt:
I found somebody doing something similar, but I can't follow what they're doing, and I've no idea how compile/run anything at all to start messing around.
My first instinct was to do something like:
// fileTypeTest.cpp, placed in file-5.03/src/ (source from link above)
#include <stdio.h>
#include "magic.h"
int main() {
magic_t myt = magic_open(MAGIC_CONTINUE|MAGIC_ERROR/*|MAGIC_DEBUG*/|MAGIC_MIME);
magic_load(myt,NULL);
printf("magic output: '%s'\n",magic_file(myt,__FILE__));
magic_close(myt);
return 0;
}
then compile with something like:
$ gcc magic.c -o magic.o
$ g++ fileTypeTest.cpp -o fileTypeTest magic.o
which (obviously?) doesn't work. I don't even know where to start looking, what questions to ask, or if this is the right direction to go to solve my original problem in the first place.
Edit: Now I have
#include <stdio.h>
#include <magic.h>
int main(int argc, char* argv[]) {
if (argc != 2) {
printf("bad arguments");
return 0;
}
magic_t myt = magic_open(MAGIC_CONTINUE|MAGIC_ERROR/*|MAGIC_DEBUG*/|MAGIC_MIME);
magic_load(myt,NULL);
printf("magic output: '%s'\n", magic_file(myt, argv[1]));
magic_close(myt);
return 0;
}
compiling with:
$ g++ -L/usr/lib -libmagic fileTypeTest.cpp -o fileTypeTest
works. I had to go to synaptic and install libmagic-dev though. I'll have to test to see if I can just copy /usr/lib/libmagic.a into my source directory when compiling my app on Windows's MingW, but that'll be for another question later, I suppose.
__FILE__ is a reserved pre-processing symbol macro used for debugging/logging purposes. Consider this as an example:
// This file is called test.c
char *p = NULL;
if (!(p = malloc((1 * sizeof(char) + 1)))){
printf("Error in file: %s # line %d\n\tMalloc failed\n", __FILE__, __LINE__);
exit(-1);
}
If the call to malloc failed you will see the output in the above example like this:
Error in file: test.c # line 23
Malloc failed
Notice how the code picks up the original source code. The above example illustrates the usage of this.
I think your code should be something like this:
// fileTypeTest.cpp, placed in file-5.03/src/ (source from link above)
#include <stdio.h>
#include "magic.h"
int main(int argc, char **argv) {
if (argc > 1){
magic_t myt = magic_open(MAGIC_CONTINUE|MAGIC_ERROR/*|MAGIC_DEBUG*/|MAGIC_MIME);
magic_load(myt,NULL);
printf("magic output: '%s'\n",magic_file(myt,argv[1]));
magic_close(myt);
}
return 0;
}
The code above checks if there is a parameter that is passed into this program and the parameter would be a filename, i.e. argv[0] points to the executable name (the compiled binary), argv[1] points to the array of chars (a string) indicating the filename in question.
To compile it:
g++ -I/usr/include -L/usr/lib/libmagic.so fileTestType.cpp -o fileTestType
g++ -L/usr/lib -lmagic fileTestType.cpp -o fileTestType
Edit: Thanks Alok for pointing out the error here...
If you are not sure where the libmagic reside, look for it in the /usr/local/lib, and /usr/local/include - this depends on your installation.
See this to find the predefined macros here.
Hope this helps,
Best regards,
Tom.
Where is magic.h in the filesystem? Is the preprocessor finding it? If not, use -I<path>.
I don't know why you think the above "obviously" doesn't work. See How to mix C and C++ in the C++ FAQ for details.
Looks like magic.h has proper extern "C" { } enclosures. So, compiling your code with g++ should work nicely. You can #include <magic.h> in your .cpp file, and use all the libmagic functions.
Is there a particular error you're getting?
I have not checked your use of the libmagic functions.
You need to link with libmagic. Your g++ command needs -lmagic.
Since magic.h is most likely in a standard place, you should use #include <magic.h>.
Tell us what your error is for more specific help.