Funny, I was just thinking the same thing. There are several advantages to using XML based (config) files:
the basic layout is widely known and understood
the file structure can be documented and validated (to a greater or lesser degree depending on dtd/xsd usage) using reusable parsing engines, not custom parsers for each app.
It is relatively easy to add new tags/attributes to an xml schema when enhancing file formats in the future.
What worries me about MacOS X is the whole new Objective C interface.
My feeling about this is that when builing a GUI app using some one elses application framework it's the design of the framework that's important, not the implementation language.
I had a NeXT for a few years, and the application builder was really good - way ahead of its time. There are very few comparable mainstream environments available today (and they didn't exist then) -Borland C++ Builder and Delphi: Delphi is Object Pascal, C++Builder uses the pascal GUI library and makes heavy use of the borland __closure extension. The Smalltalk environment would be another example. None of these use straight, portable(?) C++.
I don't think you can compare the NeXT/Apple application framework to QT, MFC, MOTIF etc (ie current C/C++ frameworks.) because of the dynamic / graphical nature of the NeXT/Apple GUI design environment
Besides, late binding (a significant feature of Objective C) can be good for GUIs.
Sounds like you need some Extreme-Programming (XP) style courage.
If you're dealing with scary code and you havn't read "Refactoring - Improving the Design of Existing Code" by Martin Fowler then do yourself a favour and get this book, it' great!
The Refactoring book is a catalog of techniques for reworking code. All of the examples are in Java but apply equally to C++ (I'm a C++ programmer myself.) In addition the the catalog of refactorings this book presents an attitude towards dealing with an existing body of code which is really inspiring.
I used to think of my existing code base as frozen, difficult to maintain and change - but it can be much more dynamic than that. Martin Fowler promotes the idea of refactoring as you go - if you're implementing a feature and it dosn't really fit with the existing design, change the design, then implement the feature. Working incrementally like this you can rapidly move towards making things much less scary. Once you realise that there is light at the end of the tunnel you will make freinds with your code again.
Slashdot Mirror
My feeling about this is that when builing a GUI app using some one elses application framework it's the design of the framework that's important, not the implementation language.
I had a NeXT for a few years, and the application builder was really good - way ahead of its time. There are very few comparable mainstream environments available today (and they didn't exist then) -Borland C++ Builder and Delphi: Delphi is Object Pascal, C++Builder uses the pascal GUI library and makes heavy use of the borland __closure extension. The Smalltalk environment would be another example. None of these use straight, portable(?) C++.
I don't think you can compare the NeXT/Apple application framework to QT, MFC, MOTIF etc (ie current C/C++ frameworks.) because of the dynamic / graphical nature of the NeXT/Apple GUI design environment
Besides, late binding (a significant feature of Objective C) can be good for GUIs.
If you're dealing with scary code and you havn't read "Refactoring - Improving the Design of Existing Code" by Martin Fowler then do yourself a favour and get this book, it' great!
here's the amazon link
The Refactoring book is a catalog of techniques for reworking code. All of the examples are in Java but apply equally to C++ (I'm a C++ programmer myself.) In addition the the catalog of refactorings this book presents an attitude towards dealing with an existing body of code which is really inspiring.
I used to think of my existing code base as frozen, difficult to maintain and change - but it can be much more dynamic than that. Martin Fowler promotes the idea of refactoring as you go - if you're implementing a feature and it dosn't really fit with the existing design, change the design, then implement the feature. Working incrementally like this you can rapidly move towards making things much less scary. Once you realise that there is light at the end of the tunnel you will make freinds with your code again.