Best Free Carbon C++ Framework

[davecom]

What's the best free Carbon C++ framework? I've heard MacZoop is supposed to be good. I already have significant experience in Java, Cocoa(with Obj-C and Java) and a lot of C experience. I'm starting to get serious about C++ now.

[OneSadCookie]

Waitwaitwaitwaitwait... you've tried Objective C/Cocoa and you want to go back to C++???

Wow.

But seriously, MacZoop is quite simple, but I didn't really like the design (YMMV); I found PowerPlant to be easier, and more resources available. When Carbon came out, though, I found that the Toolbox API had been cleaned up to the point where I didn't really need a framework...

[davecom]

But PowerPlant isn't free unless you get CodeWarrior and I'd prefer to stay with Project Builder. I am more a fan of MVC myself. Even better would be a free cross platform(meaning Windows and OS X) C++ framework that uses the MVC paradigm.

[OneSadCookie]

QT isn't free unless your project is open-source, but I think it's about the only thing that's going to meet your requirements. We looked into this at work recently, and we decided that there were only really three contenders for cross-platform application framework -- Cocoa/GNUStep, Java/Swing and QT. GNUStep doesn't work on Windows, we couldn't find a decent GUI builder for Swing, and QT isn't free. You win some, you lose some.

[Sacha]

Good luck with the MFC. It's an ugly beast of a framework. (3+ years of working with it thaught me this...) Anyway, MFC uses the Document/View paradigm and it gets ugly quite fast once you try to build a clean MVC architecture on top if it.

[davecom]

Then what do you propose as an alternative to MFC under Windows?

[ChrisD]

Take a look at CPLAT, $50 for all source runs on Mac/Win/Linux. All very modern C++, XML streaming for all objects in and out... visual RAD tool if you want it.

[ChrisD]

Hmm I don't know...

How about cross platform portability...
Templates and generic programming...
Speed...
Operator overloading...
STL...

I can think of lots of reasons to not use C ever...

Now layering Cocoa on top of C++ sounds like a good choice.
Or layering it on under cocoa and MFC would be fine.

[ChrisD]

Whats wrong with using C++ back ends and Cocoa and MFC etc on top of that? Why would you want to use plain C? Cocoa does work with C++ just fine now.

[davecom]

CPLAT Looks very interesting! Can I get any other reccomendations of CPLAT? Is it MVC in nature?

[wadesworld]

Although it's not a framework per se, don't forget about WxWindows as a cross-platform GUI library.

[OneSadCookie]

How about cross platform portability...

(semi-)portability to Linux, and eventually to Windows (again).

Templates and generic programming...

Usually unnecessary with the looser type rules. I occasionally miss the STL containers, but seldom. I don't ever miss std::string!

Speed...

In the few cases where the speed is really an issue, I'll rewrite in C (or C++ for that matter).

Operator overloading...

A red herring... usually makes C++ programs harder to read rather than easier.

STL...

Foundation provides more functionality than the STL, and is generally easier to use. AppKit integrates seamlessly (so the environment as a whole feels consistent) whilst providing more GUI stuff than you could ever want.

The STL is nice, but it just doesn't compare with Cocoa.

And before you ask, I write C++ at my day job where portability and efficiency are constant concerns, but I go home and write Objective C/Cocoa, or C if I'm looking for portability. I've had too many problems with different C++ compilers, and with trying to link the output of multiple C++ compilers to call C++ "portable".

[davecom]

Lets be realistic, Cocoa for Windows is not a solution since it doesn't exist, and even if GNUStep were running under Windows, I can't require my users to install it.

I don't care that much about Linux, although ofcourse its addition is always welcome.

I'm going to look into CPLAT and WXWindows. Both look enticing at first.

[ChrisD]

1. In the past I never could get WXwindows working...
It LOOKED really nice and easy to use the the Mac port was WAY behind the othere versions.... Guess you can try it I have not looked at it in over a year etc...

2. CPLAT... well its mostly set up for runnin under CW on Mac/Win/Linux.
Classes seem mature. I ahve been follwing it for a year or more..
It gets updates every major 3 months or so.
CPLAT can be a bit messy to get to compile in the first place.
There is a mailing list...
Best thing you could do is join the mailing list for these frameworks and ask question there.

[ChrisD]

A big problem with these conversations is a lack of scope.

Example... what is good for one type or project will not be the best for another... etc...

AKA a 3D engine is not a server etc... Soooo with that in mind...

Also Im just relplying in general on these topics...

Originally posted by OneSadCookie
[B]How about cross platform portability...

(semi-)portability to Linux, and eventually to Windows (again).


Last time I looked at GNU step that was just the foundation classes really...


Templates and generic programming...

Usually unnecessary with the looser type rules. I occasionally miss the STL containers, but seldom. I don't ever miss std::string!


SCOPE - for a game enigine - SCOPE
STL would be much faster the foundation classes.
all STL code can also be inlined nicely... This is very important.
An example is my 3D engine that uses STL lists, and vectors for most things.
Inlining C++ functions give arond 1/3 increase in FPS.

std::string....
You mean the STL::string class...

I love it.... cause its like basic... BUT.... err I spent the last 7 days at working tracking down a threading bug caused by STL and string global memory pooling...

Every one else at work look at the code too...
The problems was simple... I did not know that STL on unix/OS-X needed to
be told to be thread safe... Ah what a waste.

So there are differences bewteen STL impmentations... But I would say they are small and time should be invested in learning what a particular implementation does per platform...

Same with stdlib... which is eerr not so standard on different platforms in both API calls and in implmentation performance.

Take a look at most UNIX open source prijects... servere etc...
to see what I mean.

Speed...

In the few cases where the speed is really an issue, I'll rewrite in C (or C++ for that matter).

Operator overloading...

A red herring... usually makes C++ programs harder to read rather than easier.

Yes is used poorly it is awful.

SCOPE - for a game enigine - SCOPE

Of a C++ game in engin it is wonderful for most vector/matrix/math routines...
Now out side of that I don't think I have ever used it for anything at all.


STL...

Foundation provides more functionality than the STL, and is generally easier to use.


I aggree with functionality..
But STL is like stdlib.. it is now part of C++.
Foundation is a API and should be treated that way.
It is not ObjC.

Mixing C++/STL/Cocoa would seem to be thet best of all worlds.

AppKit integrates seamlessly (so the environment as a whole feels consistent) whilst providing more GUI stuff than you could ever want.

Again its an API and can be called from C++ just fine.

One problem I see with STL is no one I know really knows how to use it...
Using it is easy. Teaching it is easy... Learning it in school... well your lucky if any one teaches it
learning it from a book most don't cover it only very lightly which does not teach you its possible short comings etc.
There seems to be a lot of miss information about it floating around... much like it is looked at as some strange magical part of C++...
Possibly from the lack of teaching and books and the fact it is all templates which are just ugly as hell in C++ and you need to be
high up the C++ learning curve to to try and tackle the STL/ headers...

STL the missunderstood fruit ;-)

The STL is nice, but it just doesn't compare with Cocoa.
Its not meant to :) it s not an API.

And before you ask, I write C++ at my day job where portability and efficiency are constant concerns,

SCOPE--- We are missing scope here... Not to rant but I would like get all forum posters to be more aware of this... for those who are reading who don't know are back grounds etc....

What kind of apps are you writeing at work?
What OSes do they run on?
What kind of hardware do they run on?


but I go home and write Objective C/Cocoa,

- same questions as above -

or C if I'm looking for portability. I've had too many problems with different C++ compilers, and with trying to link the output of multiple C++ compilers to call C++ "portable".

That I understand...

Personally Im sticking with CW on all platforms for games.

PB is what we are using all client/server work.
But currently PB makes CRAPPY code.
aka... you will get much faster code using CW at this time...
But... errr you do get what you pay for :-)
Yes I know apple is promiseing much better compilers down the road...
Maybe some of that nice Mr C tech will roll into GCC etc.

[peacha]

Maybe we could make one designed specifically for games... just an idea.
I was working on a MacZoop-like lib during my "Classic days": if anyone wanted to make one I would be interested... well, maybe not immediately (I have my exams next week).

P.S. If only Mr. C were open sourced ... I mean, what does Apple have to lose from open-sourcing it?

[ChrisD]

Originally posted by peacha
Maybe we could make one designed specifically for games... just an idea.
I was working on a MacZoop-like lib during my "Classic days": if anyone wanted to make one I would be interested... well, maybe not immediately (I have my exams next week).

P.S. If only Mr. C were open sourced :rolleyes:... I mean, what does Apple have to lose from open-sourcing it?

Well if there was a good one today I would call it SDL...
Have you looked at that?

www.libsdl.org

[OneSadCookie]

STL would be much faster the foundation classes.

Yes, ...

all STL code can also be inlined nicely... This is very important.

Not only can, but is. Yes, ...

An example is my 3D engine that uses STL lists, and vectors for most things. Inlining C++ functions give arond 1/3 increase in FPS.

Unsurprising. Yes, the STL will be faster than Foundation. It may even be faster than a na�ve implementation you write yourself. If you really want all the speed you can push, though, you won't use the STL. You'll write a class which is optimized for your specific case.

So there are differences bewteen STL impmentations... But I would say they are small and time should be invested in learning what a particular implementation does per platform...

Well, let me give you some specific examples:

CppUnit uses a string compare function. The arguments to this function are in a different order on each platform we have looked at.

GCC doesn't provide a wstring class. Indeed, the 2.95 STL had a bug in it which prevented std::basic_string being instantiated with CharT as anything other than char. GCC 3's STL has so many preprocessor macros preventing you using wstring that we gave up on getting it enabled.

Of a C++ game in engin it (operator overloading) is wonderful for most vector/matrix/math routines...

It's precisely in vector, matrix and other math classes where it tends to be most abused. How many times have you seen somebody use operator ^ for vector cross product? For dot product? So I never know when I'm looking at a piece of code like that what it means. If they'd just used words, even if they had to type three more characters per dot product, the code would be a whole heap more understandable.

The worst abuse of operator overloading, of course, comes from the STL itself, in the iostream classes.

But STL is like stdlib.. it is now part of C++.
Foundation is a API and should be treated that way.
It is not ObjC.

True, it's not part of Objective C. On the other hand, there is no official standard for Objective C -- if you look, you'll be pointed at Apple's language reference documentation.

On all the platforms where Objective C was ever a real choice for development (NeXT, MacOSX, maybe GNUStep), Foundation has been available.

AppKit integrates seamlessly (so the environment as a whole feels consistent) whilst providing more GUI stuff than you could ever want.

Again its an API and can be called from C++ just fine.

It can be called from Objective C++ -- but try and use it from C++ without writing any Objective C code and you'll soon know the meaning of pain ;)

But currently PB makes CRAPPY code.
aka... you will get much faster code using CW at this time...
But... errr you do get what you pay for

GCC 3.1 is supposed to be much better... and you don't always get what you pay for -- we experimented with the Intel C++ compiler at work to see what kind of performance benefit it would give, but GCC 3.1 produces consistently better code for a grand total of $0.

[ChrisD]

So there are differences bewteen STL impmentations... But I would say they are small and time should be invested in learning what a particular implementation does per platform...

Well, let me give you some specific examples:

CppUnit uses a string compare function. The arguments to this function are in a different order on each platform we have looked at.


Ok you did find a bad one...
Hmm makes me wonder... I assume the STL is supposed to have a defined
standard for all functions?

Or STL is part of C++ now... so what do the specs actually cover.

Of a C++ game in engin it
(operator overloading) is wonderful for most vector/matrix/math routines...

It's precisely in vector, matrix and other math classes where it tends to be most abused. How many times have you seen somebody use operator ^ for vector cross product? For dot product? So I never know when I'm looking at a piece of code like that what it means. If they'd just used words, even if they had to type three more characters per dot product, the code would be a whole heap more understandable.


Yes I have seen that done a lot actually.
Yeah I aggree that can be a problem since there is no... standard naming for
dot and cross etc. I do spend time looking it up my self..
and sometimes even in my own code... hmm maybe I should changed that
one..

ButThe worst abuse of operator overloading, of course, comes from the STL itself, in the iostream classes.

Yes.... looks neat though :-) ... <<

But STL is like stdlib.. it is now part of C++.
Foundation is a API and should be treated that way.
It is not ObjC.

True, it's not part of Objective C. On the other hand, there is no official standard for Objective C -- if you look, you'll be pointed at Apple's language reference documentation.

On all the platforms where Objective C was ever a real choice for development (NeXT, MacOSX, maybe GNUStep), Foundation has been available.

AppKit integrates seamlessly (so the environment as a whole feels consistent) whilst providing more GUI stuff than you could ever want.

Again its an API and can be called from C++ just fine.

It can be called from Objective C++ -- but try and use it from C++ without writing any Objective C code and you'll soon know the meaning of pain ;)

[Red Wolf]

Originally posted by peacha
P.S. If only Mr. C were open sourced :rolleyes:... I mean, what does Apple have to lose from open-sourcing it?

My understanding is that parts of mrc was licensed from a third party.