Nat!'s Web Journal

I had a really good time reading an article by Bjarne Stroustrup (via Slashdot) about upcoming C++ changes. You know that I think C++ is basically a piece of shit. Nevertheless I do use it and actually make part of my income doing C++ coding.

Regardless.

At the end of his article Stroustrup writes up under Pulling it all together how to use some new language features. The divine words of the giver of language - outside of code - are of course in bold face, while my heretical comments are in the italitzed font. Here we go...

---

template<Container C>
void draw_all(C& c)	
where Usable_as<C::value_type,Shape*>
{
    for_each(c, mem_fun(&Shape::draw));
}

There are assembled so many interesting graphic characters and new keywords and new built-in functions to do what amounts to a lesser version of [container makeObjectsPerformSelector:@selector( draw)]. Why does this start to remind me of Perl ?

vector<Shape*> v = {
    new Circle(p1,20),
    new Triangle(p1,p2,p3),
    new Rectangle(p3,30,20)
};

draw_all(v);

list<shared_ptr<Shape*>> v2 = {
    new Circle(p1,20),
    new Triangle(p1,p2,p3),
    new Rectangle(p3,30,20)
};

draw_all(v2);

I certainly enjoy the obvious necessary addition of shared_ptr there on the v2 list in comparsion to vector as to not make it too easy for the minions. Easy but not too easy. There is a line between simple and stupid. And this is clearly quite safely outside of simple.
Then Bjarne closes with these priceless statements. Priceless they are solely, because they are written by the inventor of C++ the most humongous, kludge of a language ever conceived:

I hope that after looking a bit at this example, your reaction will be "How simple!" rather than "How clever! How advanced!"
Well my reaction is neither. How peculiar.

In my opinion, many people are trying too hard to be clever and advanced.
Nah, really ??? Does he mean those implementors and vendors of C++ compilers ? Though I suspect they need to be this clever and advanced, because C++ has got to be the most difficult language on earth to implement.

The real aim of design and programming is to produce the simplest solution that does the job and express it in the clearest possible way.
This is going into my signature. This from the guy who invented templates, name mangling, references, operator overloading and casting beauties such as B* const localThis = const_cast<B* const>(this); It appears to be so obviously not the case with C++, that statements like this sound as unique as a Pope Benedikt's recommendation for a black metal album would.

The aim of the C++0x design is to better support such simple solutions.
Well, maybe so. An aim is hard to contest.

Somehow I wouldn't be to surprised now if I were to read from John McCarthy : Parentheses, Considered Harmful!".

If you instantiate a top level object in a Nib and you haven't connected it to anything else, the retainCount after load will be 1 and will stay that way.

IBOutlet id   outlet1;
IBOutlet id   outlet2;

If you do the same and connect it to another object, like maybe to the outlet1 instance variable of Files Owner , the retainCount will still be 1! So if you hook up the same instance twice to Files Owner (outlet1, outlet2) you still only have to release it once on the deallocation of Files Owner. The same goes for every other top level object inside the Nib. Non top level objects, do not have that extra retainCount. So if you hook up Files Owner to a view inside a window, you don't release that view.

The big exception is if the destination's outlet is driven by standard accessor methods, which does retain counting. In that case by virtue of the accessor the retainCount will be 2 for top level objects. This is a bit of a mess.

If you don't have any accessors you can deal with this somewhat elegantly by grabbing all toplevel objects off a Nib

   ...
   _toplevel = [NSMutableArray new];
   context  = [NSDictionary dictionaryWithObjectsAndKeys:
      self, @"NSOwner",
      toplevel, @"NSTopLevelObjects",
      nil];
   flag = [bundle loadNibFile:nibFileName
            externalNameTable:context
                     withZone:[self zone]];
   ...

so in the end you release the toplevel array and also release the contained objects one more time.

- (void) dealloc
{
   [_toplevel makeObjectsPerformSelector:@selector( release)];
   [_toplevel release];
   ...

You will run into trouble if some of the windows in the Nib have the releaseOnClose flag set. This function may be useful to weed out the problematic objects before before retaining the toplevel array in an instance variable. Doing the weeding in dealloc is too late, very early in -awakeFromNib seems to be a good idea:

- (void) setTopLevelObjects:(NSArray *) candidates
{
   unsigned int   i, n;
   id             p;
   Class          nsWindowClass;
   
   NSParameterAssert( ! _toplevel);
   _toplevel = [NSMutableArray new];
   
   nsWindowClass = [NSWindow class];
   n = [candidates count];
   for( i = 0; i < n; i++)
   {
      p = [candidates objectAtIndex:i];
      if( [p isKindOfClass:nsWindowClass])
         if( [p isReleasedWhenClosed])
         {
            if( ! [p isVisible]) // assume this meant "visible at launch time")
               NSLog( @"%@ will bring you grief and sorrow", p);
            continue;
         }
      [_toplevel addObject:p];
   }
}

And then again it may not. Because this isn't 100% fool proof. One may want to consider if the window isOneShot also and maybe some other things as well ? It really depends on what you want to do with the windows, and when you want them to dealloc.

Otherwise you need to wire all toplevel objects to your NSOwner (handy connectors inside the Nib will place them there) and release them manually sometime. You have to be careful about connected objects that have been placed there with the use of an accessor, unless you inherited the accessor. They need to be released once more. So it would be:

- (void) dealloc
{
    [self setStupido:nil];
    [stupido release];
    ...
}

Is it obvious, that I haven't read any of the fine recent Cocoa books ? I hope not :)

This is the Mulle stuff that is in the pipe and that I'll try to release this year. As I think there is actually a decent chance that this will happen, even possibly rather soon, I dare lay out this "roadmap".

• MulleAutoreleasePool, this is going to be an article for the optimizing series. I am now using the code from the IMP Deluxe article in a real life setting and did some major changes. When I think it's foolproof I need to write an accompanying article and release it. This has already begun.
• MulleImagePrinter2. Man I tried my best to discourage people to download it, but for whatever reason the original version gets downloaded. A lot. There were 2000 downloads last year. The app doesn't even run on Mac OS X. It ran on Mac OS X Server 1.2! I actually get mail from people that ask me to do a new version. Oh well, what do I know, maybe this app is useful ? I am pretty much through with porting this already.
• The MulleSybaseEOAdaptor will see a final version for Apple EOF. Later versions (released or private) will only work with MulleEOF thereafter. I foreseeably can leave 10.2 behind for good and I see no reason to further support it.
• MulleEOInterface goes 1.0. I did a whole lot of changes, since I am now also using this in real life. This will see further improvements during the year. As this is a source release, it shouldn't be to complicated to retrofit it to Apple EOF, though I won't be testing against it anymore. At the bottom of this entry (or where it says more) I have pasted in the release notes as they are now.

There is a possibility that I will release MulleHashTable as well this year, but it needs quite a bit of polish to make it general purpose. MulleHashTable was written for MulleEOF where large quantities of objects must be handled, a task Foundation traditionally sucks at.

Oops, I noticed that after the IP-Migration I forgot to migrate my project-titmouse.de domain. That should be fixed in the DNS over the next hours.