Re: Cocoa/Windows parallel dvlpmt
Re: Cocoa/Windows parallel dvlpmt
- Subject: Re: Cocoa/Windows parallel dvlpmt
- From: Allan Odgaard <email@hidden>
- Date: Tue, 3 Feb 2004 00:29:56 +0100
On 2. Feb 2004, at 16:03, John Stiles wrote:
Or should I use STL lists or vectors, and then in Cocoa have
a model object which owns the STL list of raw C++ objects, and do
likewise in Windows.
One of the great things about STL is that you try to abstract away the
actual storage, instead you always deal with sequences given as a
first/last iterator.
So if you want to print all elements in a sequence you can write a
function like:
template <typename _Iter>
void print_elements (_Iter first, _Iter last)
{
for(; first != last; ++first)
cout << *first;
cout << endl;
}
We can call this function with normal C-style arrays:
int a[] = { 1, 2, 3, 4 };
print_elements(&a[0], &a[4]);
STL vector:
vector<int> v;
v.push_back(1); v.push_back(2);
v.push_back(3); v.push_back(4);
print_elements(v.begin(), v.end());
Or (using CocoaSTL) with NSArray:
NSArray* array = [NSArray arrayWithObjects:
[NSNumber numberWithInt:1], [NSNumber numberWithInt:2],
[NSNumber numberWithInt:3], [NSNumber numberWithInt:4], nil];
print_elements(beginof(array), endof(array));
The beginof/endof functions is from CocoaSTL and also exists for
C-style arrays and STL containers, so we could also have used them in
the first and second example -- they return "iterators" appropriate for
the given container (e.g. raw pointers for C-style arrays).
As I understand it, you can't use STL in Cocoa code. If nothing else,
you'll have problems with templates because of the "<>" bracket
syntax, if I recall correctly.
There has been and still are a few problems with mixing C++ features
and Objective-C code.
Currently I think it boils down to sending Obj-C messages in template
functions, which gives an internal compiler error, and sending an Obj-C
message to a user defined type which can be converted to 'id', which
gives a warning message (but the code is actually correct, and with a
typecast, the warning is gone).
The former should rarely be needed, since algorithms (i.e. functions)
should generally not be templated *and* assume that the arguments in
some way expose Objective-C objects.
When necessary, there is a few workarounds, either use the C functions
for sending Objective-C messages or use helper functions like:
template <typename _Iter>
void release (_Iter first, _Iter last)
{
for(; first != last; ++first)
release(*first);
}
void release (id obj)
{
[obj release];
}
Such a workaround has the advantage that the algorithm will work with
other types, given different overloads of 'release' (in this example).
E.g. we can also have:
void release (MyObject* obj)
{
if(--obj->retainCount == 0)
delete obj;
}
And we can call "release(first, last)" where the sequence could either
contain Objective-C objects or objects derived from MyObject.
Obviously you can't pass a vector<> to something that expects an
NSArray*, etc, but there is no reason why STL can't be used in a Cocoa
app.
Actually, using CocoaSTL one can actually mix it the other way around,
e.g.:
NSArray* array = ...;
std::random_shuffle(beginof(array), endof(array));
Or similar... so most Cocoa containers can be passed to generic
algorithms, also to store results from an "algorithm", e.g.:
int indices[] = { 0, 2, 4, 6, 8 };
NSMutableIndexSet* indexSet = [NSMutableIndexSet indexSet];
std::copy(beginof(indices), endof(indices), back_inserter(indexSet));
My largest Cocoa-based project is actually C++ at its core [...]
Personally I also try to write as much code as possible in
self-contained C++, only using STL as a "third party library" (which
actually is the Standard C++ Library).
Besides making it more platform independent, it has two other
advantages, 1) testing is much easier when one just have a lot of
algorithms which are not wired to particular object collections and 2)
re-factoring is also much easier, because algorithms can much easier be
rewritten, re-used etc. because they have close to no dependencies on
other parts of the project.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.