I'm trying to move one of my apps over to using Swift. It contains an OpenGL draw loop (that also contains some Cocoa statements - yes, I realise it's probably a horrible mess of a class) so I've copied the original .m & .h files into my new project and added a *-Bridging-Header.h file. I've also added a build phase to link with the OpenGL.framework (although I'm not sure I needed to and it made no difference to the issue).
Originally I borrowed heavily from Apple's example OpneGL project and within one of the files I'm trying to compile there is:
#include "sourceUtil.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#import <OpenGL/OpenGL.h>
demoSource* srcLoadSource(const char* filepathname)
{
demoSource* source = (demoSource*) calloc(sizeof(demoSource), 1);
// Check the file name suffix to determine what type of shader this is
const char* suffixBegin = filepathname + strlen(filepathname) - 4;
if(0 == strncmp(suffixBegin, ".fsh", 4))
{
source->shaderType = GL_FRAGMENT_SHADER;
}
else if(0 == strncmp(suffixBegin, ".vsh", 4))
{
source->shaderType = GL_VERTEX_SHADER;
}
else
{
// Unknown suffix
source->shaderType = 0;
}
// more code follows
.
}
However, GL_FRAGMENT_SHADER is causing Xcode to stop any build with the error "Use of undeclared identifier 'GL_FRAGMENT_SHADER'" - similarly with the GL_VERTEX_SHADER. I presume there'll be more errors but currently this is what Xcode stops at.
You need: #import <OpenGL/gl.h>
Related
I'm writing some common DML code that contains a fairly complex method, something like:
saved uint32 checksum_ini;
method calculate_checksum(bytes_t data) -> (uint32 sum) {
uint32 result = checksum_ini;
for (int i = 0; i < data.size; ++i) {
result = f(result, data.data[i]);
}
return result;
}
My device calls the function indirectly by reading and writing some registers, which makes it cumbersome to unit test all corner cases of the checksum algorithm.
How can I efficiently write a unit test for my checksum implementation?
One approach is to create a dedicated test module, say test-checksum, containing a test device, say test_checksum_dev, that imports only your common code, and exposes the calculate_checksum method to Python, where it is easy to write tests. This is done in two steps: First, expose the method to C:
dml 1.4;
device test_checksum_dev;
import "checksum-common.dml";
// Make DML method calculate_checksum available as extern C symbol "calculate_checksum"
// The signature will be:
// uint64 calculate_checksum(conf_object_t *obj, bytes_t data)
export calculate_checksum as "calculate_checksum";
The second step is to expose it to Python. Create checksum.h:
#ifndef CHECKSUM_H
#define CHECKSUM_H
#include <simics/base/types.h>
#include <simics/pywrap.h>
extern uint32 calculate_checksum(conf_object_t *obj, bytes_t data);
#endif /* CHECKSUM_H */
(if you also add header %{ #include "checksum.h" %} to the DML file, you will get a hard check that signatures stay consistent).
Now add the header file to IFACE_FILES in your module makefile to create a Python wrapping:
SRC_FILES = test-checksum.dml
IFACE_FILES = checksum.h
include $(MODULE_MAKEFILE)
You can now call the DML method directly from your test:
SIM_load_module('test-checksum')
from simmod.test_checksum.checksum import calculate_checksum
obj = SIM_create_object('test_checksum_dev', 'dev', checksum_ini=0xdeadbeef)
assert calculate_checksum(obj, b'hello world') == (0xda39ba47).to_bytes(4, 'little')
I am using Eclipse Juno updated as two days ago, fresh install and installed C/C++ and linked MinGW into Windows (7 64-bit by the way). Everything works fine, i can build/compile "Hello World" and execute the file generated by eclipse.
Now i have three files,
main.cpp:
#include "functions.cpp"
#include <iostream>
using namespace std;
int main(int){
int a = mult(20,5);
cout << "Twenty times 5 is " << a;
cout << a << "Plus 2 is " << add2(a);
return 0;
}
functions.cpp:
#include "header.h"
int EXPORT add2(int num){
return num + 2;
}
int EXPORT mult(int num1, int num2){
int product;
product = num1 * num2;
return product;
}
header.h:
#ifndef HEADER_H_
#define HEADER_H_
#ifdef BUILD_DLL
#define EXPORT __declspec(dllexport)
#else
#define EXPORT __declspec(dllimport)
#endif
int EXPORT add2(int num);
int EXPORT mult(int num1, int num2);
#endif /* HEADER_H_ */
With this set up in the code i need a DLL file to be generated first and then used when building. If i place these files on my desktop for instance, i can /cd desktop and use this command:
g++ functions.cpp -o functions.dll -DBUILD_DLL -shared -Wl,--out-implib,libfunctions.dll.a
This creates a DLL file and also a .A File, one dynamic one static.
IN SHORT MY QUESTION:
Can i get Eclipse to make a DLL file from functions.cpp before it attempts to build my code into a .exe file? At this stage my code is looking for an DLL file to IMPORT.
I found out how to do this. It may not be the best option for this, however i was able to go to my project Properties-->C/C++ Build--->Settings--->Build Steps.
This seems to work however I am now trying to find a way to set the command to use the source directory of the project instead of me having to use C:/eclipse/workplace etc.
I am trying to add libpng to my iPhone project.
I copied the .c and .h files to their own directory "thirdparty/libpng/" and I included png.h in my texture class:
#ifndef PNG_H
#include "thirdparty/libpng/png.h"
#endif
At this point my project compiles great with no warnings and errors.
Next I tried adding a function to check if a texture is a png, and I get a compile error on png_sig_cmp, even though png.h is included:
#define PNG_BYTES_TO_CHECK 4
int GETexture::CheckIfValidPNGTexture( const char* pTextureName, FILE **ppFp )
{
char buf[PNG_BYTES_TO_CHECK];
/* Open the prospective PNG file. */
if ((*ppFp = fopen(pTextureName, "rb")) == NULL)
return 0;
/* Read in some of the signature bytes */
if (fread(buf, 1, PNG_BYTES_TO_CHECK, *ppFp) != PNG_BYTES_TO_CHECK)
return 0;
/* Compare the first PNG_BYTES_TO_CHECK bytes of the signature.
Return nonzero (true) if they match */
return(!png_sig_cmp(buf, (png_size_t)0, PNG_BYTES_TO_CHECK)); // <- COMPILE ERROR
}
The error I get is: No matching function for call to 'png_sig_cmp'
The header is definitely getting included. If I try to type something random in it like "sdfdd" I get a compile error, showing it is parsing that header file.
Any ideas?
I had exactly the same problem once and what helped me was simple casting - because if you look into png.h header file , png_sig_cmp definition :
png_sig_cmp(png_const_bytep sig, png_size_t start, png_size_t num_to_check)
First parameter is png_const_bytep - which is defined as :
PNG_CONST png_byte FAR * png_const_bytep
which translated really as :
const unsigned char*
I would simple typecast :
return(!png_sig_cmp((png_const_bytep)buf, (png_size_t)0, PNG_BYTES_TO_CHECK));
Hope it helps!
I have a few lines of assembler arm code in an .s file. Just a few routines i need to call. It works fine when building for the device, however when i switch to iPhone Simulator i get "no such instruction" errors. I tried to compile parts of the .s file conditionally with what i know:
#if !TARGET_IPHONE_SIMULATOR
But the assembler doesn't recognize these preprocessor directives (of course) and none of the conditional compilation techniques for assembler that i could remember or find worked, so i'm scratching my head now on how to avoid compilation of that assembler code when building for the Simulator. I also don't see a project option in Xcode that would allow me to compile the file or not depending on the target platform.
SOLVED:
All i was missing was the proper #import in the assembler file. I did not think of adding it because Xcode syntax highlighted any preprocessor directive in green (comment) which made me assume that these commands are not recognized when in fact they work just fine.
This works:
#import "TargetConditionals.h"
#if !TARGET_IPHONE_SIMULATOR
... asm code here ...
#endif
You do do it with a pre-processor macro. They are defined in TargetConditionals.h TARGET_IPHONE_SIMULATOR should be there! (You do need to #include it however.)
Here is code I use to detect ARM vs Thumb vs Simulator:
#include "TargetConditionals.h"
#if defined(__arm__)
# if defined(__thumb__)
# define COMPILE_ARM_THUMB_ASM 1
# else
# define COMPILE_ARM_ASM 1
# endif
#endif
#if TARGET_IPHONE_SIMULATOR
// Simulator defines
#else
// ARM or Thumb mode defines
#endif
// And here is how you might use it
uint32_t
test_compare_shifted_operand(uint32_t w1) {
uint32_t local;
#if defined(COMPILE_ARM_ASM)
const uint32_t shifted = (1 << 8);
__asm__ __volatile__ (
"mov %[w2], #1\n\t"
"cmp %[w2], %[w1], lsr #8\n\t"
"moveq %[w2], #10\n\t"
"movne %[w2], #11\n\t"
: \
[w1] "+l" (w1),
[w2] "+l" (local)
: \
[shifted] "l" (shifted)
);
#else // COMPILE_ARM_ASM
if ((w1 >> 8) == 1) {
local = 10;
} else {
local = 11;
}
#endif // COMPILE_ARM_ASM
return local;
}
I'm writing a bunch of related preprocessor macros, one of which generates labels which the other one jumps to. I use them in this fashion:
MAKE_FUNNY_JUMPING_LOOP(
MAKE_LABEL();
MAKE_LABEL();
)
I need some way to generate unique labels, one for each inner MAKE_LABEL call, with the preprocessor. I've tried using __LINE__, but since I call MAKE_LABEL inside another macro, they all have the same line and the labels collide.
What I'd like this to expand to is something like:
MAKE_FUNNY_JUMPING_LOOP(
my_cool_label_1: // from first inner macro
...
my_cool_label_2: // from second inner macro
...
)
Is there a way to generate hashes or auto-incrementing integers with the preprocessor?
If you're using GCC or MSVC, there is __COUNTER__.
Other than that, you could do something vomit-worthy, like:
#ifndef USED_1
#define USED_1
1
#else
#ifndef USED_2
#define USED_2
2
/* many many more */
#endif
#endif
I use this:
#define MERGE_(a,b) a##b
#define LABEL_(a) MERGE_(unique_name_, a)
#define UNIQUE_NAME LABEL_(__LINE__)
int main()
{
int UNIQUE_NAME = 1;
return 0;
}
... and get the following:
int main()
{
int unique_name_8 = 1;
return 0;
}
As others noted, __COUNTER__ is the easy but nonstandard way of doing this.
If you need extra portability, or for other cool preprocessor tricks, the Boost Preprocessor library (which works for C as well as C++) will work. For example, the following header file will output a unique label wherever it's included.
#include <boost/preprocessor/arithmetic/inc.hpp>
#include <boost/preprocessor/slot/slot.hpp>
#if !defined(UNIQUE_LABEL)
#define UNIQUE_LABEL
#define BOOST_PP_VALUE 1
#include BOOST_PP_ASSIGN_SLOT(1)
#undef BOOST_PP_VALUE
#else
#define BOOST_PP_VALUE BOOST_PP_INC(BOOST_PP_SLOT(1))
#include BOOST_PP_ASSIGN_SLOT(1)
#undef BOOST_PP_VALUE
#endif
BOOST_PP_CAT(my_cool_label_, BOOST_PP_SLOT(1)):
Sample:
int main(int argc, char *argv[]) {
#include "unique_label.h"
printf("%x\n", 1234);
#include "unique_label.h"
printf("%x\n", 1234);
#include "unique_label.h"
return 0;
}
preprocesses to
int main(int argc, char *argv[]) {
my_cool_label_1:
printf("%x\n", 1234);
my_cool_label_2:
printf("%x\n", 1234);
my_cool_label_3:
return 0;
}
I can't think of a way to automatically generate them but you could pass a parameter to MAKE_LABEL:
#define MAKE_LABEL(n) my_cool_label_##n:
Then...
MAKE_FUNNY_JUMPING_LOOP(
MAKE_LABEL(0);
MAKE_LABEL(1);
)
You could do this:
#define MAKE_LABEL() \
do { \
my_cool_label: \
/* some stuff */; \
goto my_cool_label; \
/* other stuff */; \
} while (0)
This keeps the scope of the label local, allowing any number of them inside the primary macro.
If you want the labels to be accessed more globally, it's not clear how your macro "MAKE_FUNNY_JUMPING_LOOP" references these labels. Can you explain?
It doesn't seem possible with a standard preprocessor, although you could fake it out by putting parameters within MAKE_LABEL or MAKE_FUNNY_JUMPING_LOOP, and use token pasting to create the label.
There's nothing preventing you from making your own preprocessing script that does the automatic increment for you. However, it won't be a standard C/C++ file in that case.
A list of commands available: http://www.cppreference.com/wiki/preprocessor/start