Questions

idaydream
Unregistered
 
Post: #1
I feel sorry for always posting questions not answers.
My first question is

1. When you use xcode for OpenGL programming why do we need "carbon application" for project target and "cocoa framework" for framework (why not carbon framework?) in addition to GLUT and OpenGL framework?
(what is carbon and what is cocoa?)

http://onesadcookie.is-a-geek.net/~keith/XcodeGLUT/

2. When I do OpenGL coding one of my source file has class "Point" defined and it conflicts with class "Point" inside MacTypes.h from carbon application header. In other words, when I compile the code it says:

error: redefinition of 'class Point' --- Point.h
error: previous definition of 'class Point' --- MacTypes.h

Is there any solution to this problem except changing the name of 'class Point'?

Thanks in advance.

idaydream
Quote this message in a reply
Vertizor
Unregistered
 
Post: #2
In OSX, what makes an application an "application" is that it's in a bundle with a signature 'APPL' that tells the OS what to do with it when the user double clicks it. Only bundles with the APPL signature will be launched as an application.

When in XCode, you select a Carbon or Cocoa Application as a template just to get you started and the dev environment set up so you can build this bundle into something that will run when the file is double clicked upon.

As for getting into OpenGL:

- GLUT is a framework that is aware of creating a window who's entire client area is an OpenGL viewport. It also provides keyboard/mouse message processing. So it's basically a RAD tool for OpenGL.

- OpenGL.framework itself, is where all the OpenGL rendering definitions are contained. This is the material the OpenGL Architecture Review Board people decree as the "OpenGL Standard." Apple basically wrapped all those standard rountines into this framework, and threw in CGL.

- CGL is a library that lets you work with either fullscreen or offscreen OGL context.

- AGL is a library that lets you work with either fullscreen or windowed OGL context.

- Carbon is a C API library to develop apps for MacOS. It is provided as legacy support for older apps prior to OSX. You still run them in Classic mode, but if developers so desired, they can easily port their source code to the newer updated CarbonLib and allow their programs to run natively in OSX, as well as take advantage of new features.

- Cocoa is basically the NeXTStep OS's API. It's written and used in Objective-C language. This is the prefered "native" development environment for OSX.

Just because Cocoa is preferred over Carbon, that does not mean Cocoa is faster. It may offer more features but the two are not competitors. They simple offer different features that complement each other very well.

You generally don't intermix Carbon and Cocoa. So if you start out with a Carbon app template, you'll stick to the Carbon lib and use OpenGL solutions (CGL/AGL) available to it. A Cocoa app template will use the Cocoa library. However, since Objective-C is a superset of C, and can use C libraries and semantics, you could import CarbonLib and use it within your Cocoa program.
Quote this message in a reply
Member
Posts: 111
Joined: 2002.06
Post: #3
To answer question #1, you need to add the Cocoa framework with GLUT because the GLUT framework on Mac OS X was written with Cocoa. If you don't add the Cocoa framework, the compiler won't be able to use the GLUT framework either.

To answer question #2, there isn't a solution besides changing the class name. Class libraries normally use prefixes with class names (QPoint, JLevel, ZRect) to avoid the problem you're having.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #4
Actually, you could use namespaces to prevent name clashes with the OS in C++. But be aware of its pitfalls. For ObjC, use prefixes as suggested above.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #5
Vertizor Wrote:You generally don't intermix Carbon and Cocoa.
You generally don't mix Carbon and Cocoa for UI or event handling.

However, you are perfectly free to mix Carbon and Cocoa for other functionality, and in some cases it's necessary. For example, try using QuickTime from Cocoa.

Much of the functionality in Cocoa is built on top of CoreServices, which contains things like the old Resource Manager. So when you #import <Cocoa.h> you are actually already getting some Carbon stuff.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #6
I must agree with arekkusu on this one, as Carbon and Cocoa go very well hand in hand, just not when it comes to UI. In that case, you should chose one of the two, mostly it will depend on if you are willing to use ObjC, or want to stick with plain old C/C++.

If you do know ObjC, then by all means do the UI with Cocoa & ObjC, it's just a lot less frustrating than making the UI in Carbon, most of the time.

And, Cocoa also uses Carbon for much of what is going on under the hood. Nobody wants to reinvent the wheel. Nothing stops you from using parts of Cocoa for UI and parts of Carbon for whatever else you want to do.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #7
Vertizor Wrote:- Carbon is a C API library to develop apps for MacOS. It is provided as legacy support for older apps prior to OSX. You still run them in Classic mode, but if developers so desired, they can easily port their source code to the newer updated CarbonLib and allow their programs to run natively in OSX, as well as take advantage of new features.

I think you're giving the wrong impression here. The Carbon API is still fully supported and used by Apple, and won't be going away any time soon. It's every bit as viable as Cocoa for developing new applications.

Alex Diener
Quote this message in a reply
anonuser
Unregistered
 
Post: #8
Alex is right.
Carbon isn't going anywhere.
And Cocoa still needs Carbon, for some of Cocoa still maps to Carbon.
Quote this message in a reply
Vertizor
Unregistered
 
Post: #9
I didn't say Carbon was being phased out did I? Why else would Apple include CarbonLib in OSX if not for backwards compatibility and worst case scenario apps would be somewhat source code compatible.

Ok maybe I should have been more clear. But I do realize that Carbon is just as good as Cocoa. Yes there is a general misconception about Carbon in the world of OSX and I've been explaning the same things we're all saying here to other people in other forums.

At least in my mind, it sounds kinda silly to have 2 APIs in an OS, so my comments were aiming to illustrate the major differences between Carbon and Cocoa, to show that they're not competing with each other but rather complementary to one another.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #10
Carbon and Cocoa, for those parts in which they overlap, which is >90% IMO, do actually compete. What makes this competition idea silly is that Cocoa can only be used with ObjC, and that Cocoa is as much part of the language as the C stdlib is part of C.

Without Cocoa, ObjC would be pretty damn useless. Cocoa is not only an OS API, but also a standard library similar to stdlib or the STL for C++. Just as much as Java would be useless without its integrated functions and data types, so would be ObjC.
Quote this message in a reply
Member
Posts: 196
Joined: 2003.10
Post: #11
DoG: GnuStep fills the role of Cocoa for cross-platform.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #12
blobbo Wrote:DoG: GnuStep fills the role of Cocoa for cross-platform.
Huh? Did I say anything about cross-platform issues? Besides, not all of Cocoa is supported by GNUStep, and not exactly in the same way, either. It is not (yet) a viable cross platform alternative.
Quote this message in a reply
idaydream
Unregistered
 
Post: #13
Thank you guys for generous and extensive replies.

It answered my curiosity about the relation of carbon and cocoa stuff.
However, it looks lke the only way to solve redefinition compliation error is to change the class name.

error: redefinition of 'class Point' --- Point.h
error: previous definition of 'class Point' --- MacTypes.h

I have tried

#define Point NewPoint

in all of my original files which uses Point class, but it gave me another bunch of compilation error which looks like below:

error: candidates are: __gnu_cxx::__normal_iterator<NewPoint*, std::vector<NewPoint, std::allocator<NewPoint>.......

I guess my last option is try using namespace but I just don't know how.
Since I am not able to change coding for MacTypes.h because it is built in class (Xcode does not allow me to change it) and even if I can, wouldn't it make more compilation error because it is affects all CarbonCore coding?
Is there any other way I can do coding without using CarbonCore?
Is there anything that looks like Borland JBuilder in C++ for OSX?

Again, thank you for your time and effort.
It is always good to know that there always is someone who wants to help my problem.

Best,
idaydream
Quote this message in a reply
idaydream
Unregistered
 
Post: #14
using,

static Pvector nullv;
#undef NULL
#define NULL nullv.end()

I was able to fix all the compile errors related to

error: candidates are: __gnu_cxx::__normal_iterator<NewPoint*, std::vector<NewPoint, std::allocator<NewPoint>.......



Now, I only have one compilation error which is,

error: cannot convert: __gnu_cxx::__normal_iterator<NewPoint*, std::vector<NewPoint, std::allocator<NewPoint>....

it seems similar to the previous errors but the heading ("cannot convert") is different.
How should I solve this problem?

Thanks.

idaydream
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #15
I dont think it was a good idea to re-define NULL. Show us the code where that compilation error occurs, maybe we can help then.

And, with Xcode, you can easily do a find-and-replace search for Point in all your project files, so it should be easy to change Point to NewPoint (or MyPoint or whatever) everywhere. Do it.
Quote this message in a reply
Post Reply