Jake Wrote:Could I first reprogram the Tree class in C++, then make my level class an objective C++ file, and then start replacing things like [trees doMethod] with trees::doMethod(), then keep repeating the process until I get everything class to C++? That way I could do this gradually, and keep making other updates to the mac version while I'm working.

Yeah, that should work. Just a semantic issue here: is trees the class name, or an object? If it's a class name, great. If it's an object, you'll need to use . if it's a stack/global object, or -> if it's a pointer to an object.

Awesome, I'm going to start working on that tonight, I'll probably grab all of the functions and data structures that overlap between all of my code files and make a NNMath.c/h file first and then start replacing the old ones with the NNMath.c functions, something I should have done when I started (but I was 16 and had no C experience before, so I can see why I missed it)

And yeah trees is the class name

Wow, I'm surprised I made it two hours coding in a language I've never actually used before without hitting a roadblock! I now converted one of my lowest level classes from Objective-C to C++, and the game looks EXACTLY the same as before! I had to rename pretty much EVERY file .mm instead of .m, and it looks like they will have to all stay .mm until I get everything out of objective-C (i think). I noticed I made a MESS with #import, so I'm trying to fix that up a little bit. Should I change from #imports to #include, or is #import supported with C++ and the PC?

Thanks for the suggestions and help, I'll probably hit some roadblocks down the road and will probably have to ask some more questions

#import is a GCC-only thing. If you think you might want to compile with MSVC, you should change to #include.

#import was broken for a long time even in GCC. Apple fixed it, but I'm not sure when that change made it to the main line. It's possible that even MinGW for Windows hasn't picked up the change yet.

Jake Wrote:Wow, I'm surprised I made it two hours coding in a language I've never actually used before without hitting a roadblock! I now converted one of my lowest level classes from Objective-C to C++, and the game looks EXACTLY the same as before! I had to rename pretty much EVERY file .mm instead of .m, and it looks like they will have to all stay .mm until I get everything out of objective-C (i think). I noticed I made a MESS with #import, so I'm trying to fix that up a little bit. Should I change from #imports to #include, or is #import supported with C++ and the PC?

Thanks for the suggestions and help, I'll probably hit some roadblocks down the road and will probably have to ask some more questions

Definitely change #import to #include. To add to what OSC said, I've only seen #import used with ObjectiveC. For the extensions, .m is ObjectiveC, .mm is ObjectiveC++, and .cpp is C++.

For all I know, #import works fine with MSVC, at least it did so 2 years ago.

Also: If you're moving from ObjC to C++ without actually knowing C++, I can almost guarantee more pain than giving GNUStep a shot. Lots more pain. If your app is not relying heavily on AppKit's obscurities, it might just work without too much trouble.

Thanks for the feedback about #import!

After spending 3 hours I tried to convert my static model class (for trees) over to C++ code, and it went good and compiled/ran, except only about half the time the trees even show up at all! No compile errors/warnings at all, so its going to be tricky to try to figure out next time I start working again.

DoG, I think you might be right. After spending 5 hours converting 2 smaller classes over to C++ I can tell its going to be a lot of work to get the other classes, then I will have to reprogram a UI in SDL or something for the PC. I'm going to take another look at GNUStep again before I start converting more code, because I don't rely on Appkit much, mostly Foundation

It all depends on how feasible GNUstep is. If it looks like all the classes you're using are available and have all the same functionality, great. Otherwise, you may want to do some simple problems to familiarize yourself with C++, then try again when you have a better handle on the language.

Isn't import like copying and pasting one file into the location of the #import, and #include is something different?

Jones Wrote:Isn't import like copying and pasting one file into the location of the #import, and #include is something different?

I'm pretty sure #import protects from including files that have already been including, therefore eliminating infinite loops where A.h imports B.h, and B.h imports A.h. It makes things simpler but allows for bad programming style because you can get sloppy #imports to compile and work correctly

Wow... they sure didn't make it easy to instal GNUStep and get programs running! After two hours of fiddling last night I managed to download the core packages and instal GCC, and then using MiniGW I build the project editor program (I'm assuming its like Xcode), and tonight I'll build the GUI program (like Interface Builder).

I'm very surprised of how much like OS X everything is, the command line is the same, there is even a Users/Jake Leveto/ director, and Library-System folders around everywhere!

Does anyone know what is needed to actually run the compiled programs on any random PC that downloads it, I wonder if its a DLL or if they have to instal the frameworks or something. I didn't have time to research it last night so I'll have to do it tonight if nobody knows the answer. I'm also going to have to find out how compatible Interface builders NIBs are with whatever GNUStep uses.

Ahh... no more time to do anything now, back to class after lunch

Jake Wrote:I'm also going to have to find out how compatible Interface builders NIBs are with whatever GNUStep uses.

Not at all.

GNUStep has a tool called nib2gmodel which attempts to do a conversion. Whether it works or not is a bit of a crap-shoot.

OneSadCookie Wrote:Not at all.

GNUStep has a tool called nib2gmodel which attempts to do a conversion. Whether it works or not is a bit of a crap-shoot.

Thanks for the tool, I'll definitely take a look at it if I choose to go that rout.


While the forum was down yesterday I tried to debug my C++ class that I converted from an old Objective-C class a few weeks ago, and I had a hell of a time! I finally found the problem, it was because in an Objective-C "int array[10]" was filled with 0's initially, and in C++ it was filled with garbage. BUT it was hard to find because the debugger just listed two thread steps, ?? and ??, instead of finding the right part of the code that was causing the errors. Is this because I'm using Objective-C++ and the debugger was using the wrong language, if so how do I change that in XCode, I looked and couldn't find it!

No, it's unlikely to be a problem with the debugger; more likely that you've turned off debug symbols, or that your bug had corrupted the stack to the point that GDB couldn't tell you anything useful

Debug symbols are on.

OneSadCookie Wrote:or that your bug had corrupted the stack to the point that GDB couldn't tell you anything useful

That sounds like something that I am very, very, capable of