Parse Errors in Obj-C
Post: #1
I'm getting a few errors I can't figure out. It might be (probably is) my small knowledge of Obj-C or something. Can anyone solve this tiny problem so I can keep going on my project? I've tried so many things.
Code:
Mesh.h:26: error: parse error before "Vertex"
Mesh.h:30: error: parse error before "Vertex"Code:
#import <Cocoa/Cocoa.h>
#define MAX_VERTICES 10000
#define MAX_FACES 10000
struct Vertex
{
GLfloat x,y,z;
};
struct Face
{
int v[4];
};
@interface Mesh : NSObject
{
Vertex v[MAX_VERTICES];
Face f[MAX_FACES];
}
- (void)draw;
- (void)setVertex:(int)i as:(Vertex)v2;
- (void)setFace:(int)i as:(Face)f2;
@end
Post: #2
That's because you're using OpenGL commands without the required headers
Last login: Sat Aug 6 09:15:05 on console
Welcome to Darwin!
Matt-Chelens-Computer:~ matthew$
Post: #3
That's not it. I just added
to the top and I still get the errors.
Code:
#import <OpenGL/OpenGL.h>
#include <OpenGL/gl.h>
#include <OpenGL/glu.h>
Post: #6
If you don't typedef it, then you must use the struct keyword whenever you refer to it. For example:
- (void)setVertex:(int)i as:(struct Vertex)v2;
The typedef assigns it to a new type, so you don't need the keyword anymore.
- (void)setVertex:(int)i as:(struct Vertex)v2;
The typedef assigns it to a new type, so you don't need the keyword anymore.
Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath the clear blue sky?
Post: #8
I see. I've always used C++ so I've never seen the need for that. Thank you for enlightening me.
Post: #9
Sorry to ressurect this but wanted to post this for those that don't know.
Change your Objective-C file extension to .mm to gain the benefits of C++ structs and array allocation using new or stick with .m for C style structs and having to use malloc.
Change your Objective-C file extension to .mm to gain the benefits of C++ structs and array allocation using new or stick with .m for C style structs and having to use malloc.
Post: #10
NO! That compiles like... molasses.
just do:
just do:
Code:
typedef struct _ver
{
GLfloat x, y, z;
} Vertex;It's not magic, it's Ruby.
Post: #11
Not that I've noticed. I currently have 34 .mm classes (all of the classes in my project have become .mm's). If I do a clean it can take a little bit but the partial compiles have been just as fast as straight .m files.
I guess instant gratification is all the rage these days.
(Edit miscounted have 34 .mm files not 23).
I guess instant gratification is all the rage these days.
(Edit miscounted have 34 .mm files not 23).
Post: #12
Actually it can also cause you problems because C++ has a stricter type system than C. At least I had some issues because of that (unfortunately I can't remember what they were now...). I've since sworn off .mm files except where I absolutely need them.
Post: #13
Stricter typing is only a problem if you've been using types loosely in your programming.
For example the following code compiles fine (with the default C compiler options) but under C++ gives a warning by default (not an error):
unsigned char *buffer;
buffer = malloc(1024);
To fix it either do this:
buffer = (unsigned char *)malloc(1024);
which is actually more proper standard C code (I used to program like this all the time in C by default)
Or do this:
buffer = new unsigned char[1024];
For example the following code compiles fine (with the default C compiler options) but under C++ gives a warning by default (not an error):
unsigned char *buffer;
buffer = malloc(1024);
To fix it either do this:
buffer = (unsigned char *)malloc(1024);
which is actually more proper standard C code (I used to program like this all the time in C by default)
Or do this:
buffer = new unsigned char[1024];
Post: #14
Actually a perfect example. I have a friend who trolls comp.lang.c and comp.lang.c++, and he says that the hard core guys on there debate constantly about whether casting the return value of malloc is good practice or not (despite whether it needs to be done or not). It was so arcane on the reasoning (like most stuff on those groups) that I can't remember why... 
But smart guys debate whether it's a good thing or not. I assume they would write their C code that way too.
EDIT: Here 'tis:
http://www.cognitiveprocess.com/~rjh/prg...sting.html
Scroll to the bottom for the discussion on malloc() casting.
But smart guys debate whether it's a good thing or not. I assume they would write their C code that way too.EDIT: Here 'tis:
http://www.cognitiveprocess.com/~rjh/prg...sting.html
Scroll to the bottom for the discussion on malloc() casting.
Post: #15
Just FYI that article is from a C perspective. You have to put the casts in for C++ code (and this is mentioned in the article). But if you are using C++ anyway you should just use new instead of malloc anyway.
I was giving tips to make working with Objective-C++ code so that you might have more success next time you give it a try (if you do).
I was giving tips to make working with Objective-C++ code so that you might have more success next time you give it a try (if you do).
