Objective C++

Okay, so I'm thinking about working with Obj-C++ as opposed to its base languages, but I'm a little confused as to just how integrated they can be. Can a C++ namespace or class have members which are Objective C classes or types, and can Objective C classes have members which are C++ classes? No, I'm not talking about inheritance, but something like


class someSepplesClass {
NSString* voo
NSUInteger var
};

>>27
You obviously never used it. CL was completly standardized in 1994 (second version). It's more modern than just about any ``modern'' language that I currently use.

Oh, and why would a ``kid'' use ``old'' stuff? Don't kids like modern things?

Not that I care in the least what the likes of you thinks as I just updated to today's nightly build of SLIME and SBCL and updated a tool that I wrote by adding 8 lines to it and have it work perfectly. This tool currently weights about 1600 lines of code, and if I were to rewrite this in C, I could easily see it go 10000 lines and higher, probably some 3000-5000 in Java or C#. It performs some complex manipulations on graphs and all this is described in a very compact and simple DSL. Trying to think of the equivalent manual C code filled with redundancies that I would have to write makes me sick to even consider undertaking such a project by myself. Yet, here I am, I can just think of an idea and just have it implemented in a day or two and have it fully working. So you can keep on trolling, while I'll keep on seeing my ideas turn into real code in realtime.

>>31
It runs just fine. Only about 3 times as slow as the C version.
It processes about 35MB of binary input data in about 10 seconds, generating about 90MB of output metadata. This is the entirety of my dataset, which I'd say is perfectly fine.

Originally the code was slow and it took about a minute to do the entire thing, but after I profiled my code I managed to locate the bottlenecks and optimize them away. In case you didn't know, SBCL and ClozureCL both generate native code. I even added some inline assembly for SBCL/x86 which improves some float-related's operation's performance by quite a good deal. A slightly slower, but portable version is provided for the rest of the implementations (the version is chosen by using the conditional reader macros).

All in all, I'm perfectly happy with this and wouldn't want it anyway else. Had I written this in C, I can see myself cutting corners and maybe even making it slower as algorithmic optimizations are a lot more costlier in C (you have to rewrite a lot more code if you want to make major changes), while here I barely need to rewrite anything, the macros generate a lot of my code, so I only need to make a few changes to the code generators.