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
};

Let's pretend I didn't forget my semicolons, ya?

NO TOLERANCE

>>3

*Sigh*

Aside from being promoted by Apple, why does /prog/ hate Objective C(++)?

>>4
Isn't that enough of a reason?

>>1
MAC FAG

>>5
No. They didn't create Objective C and they certainly haven't made it any worse.
>>6
There is nothing wrong with using a pure Unix operating system that happens to have a great library of proprietary applications

>>7
Unix
great
/0

I use QUICK Objective Caml++#

>>8
unix sucks but the alternatives are worse

>>10
Windows is a Unix-clone. There're no alternatives.

>>1
Yes.

>>11
No it isn't. And if it is, it's a very bad one. IHBT.

>>13
Windows (NT) is way more of a UNIX clone than most realize.  Compare Windows NT to modern UNIX and you will find that they both have:
* C implementation, C ABI, and C API
* similar process models (each process has its own virtual address space, file descriptors, permissions/owner for security)
* paged virtual memory with the same features available to proceses (shared between processes, memory-mapped files, etc)
* similar threading models (native threads are independently scheduler by the kernel, threads belong to a process share the same address space)
* similar filesystem model (files must be opened by name, all access to that file is through a handle/descriptor, different synchronous and asynchronous ways to perform I/O)
* similar IPC mechanisms (network communication, named pipes, standard input/output, shared memory, message passing)
* similar device, file, and network I/O models (per-process handles or file descriptors are used for device access, accessing files, and network sockets)
* user/group support (NT has very complex Access Control Lists... modern UNIX has ACLs too)
* similar kernel/user functionality split

The APIs and implementations are quite different (generally much more complex in the NT kernel), but the functionality maps nearly 1:1.

>>11, 14
Lisp Machines were defeated by Unix which was defeated by Windows because worse-is-better.

>>14
* Both suck dicks.

>>4
Aside from being promoted by Apple, why does /prog/[sic] hate Objective C(++)?
Don't use a bastardized version of Smalltalk, use Smalltalk.

>>15
worse-is-better
More proof of delusional lisper mindset.

>>18
Do you even know what you're talking about or are you just a circular insulting machine?

>>18
Now this is just...

>>19
You think companies choose things that are bad for them just to annoy you.  Bullshit.  They gave up on lisp because lisp is useless.

>>21
define "useless"

>>21
COBOL
Java
C
C++
Yes, these are much better, especially COBOL. Industrial strength indeed!

>>22
Stop bumping the fucking threads, you moron.

>>21
The reason you don't use it in the ENTERPRISE (some do, but it's rare) is because you need to be able to replace programmers all the time and can't have your company depend on a few critical unreplaceable people, the other reason is because it gives you too much freedom which makes it very easy for someone to make up their own language and make it confusing for the rest of the team. However, for small teams it's perfect. You can call it useless all day long, while I'll be using it to write code dozens of times smaller than the equivalent C, SEPPLES or Java versions in much less time. If it serves my needs it will never be useless to me. It may be useless to you because you either don't know it or don't know how to use it, or maybe you don't program at all or all your programming is entirely low-level or simple enough that you don't need anything more than C or assembly.

>>24
I ask your permission of reposting this every time the ``Lisp is real world'' argument pops out again.

>>25
Permission granted.

>>24
No, no, it's really because it's useless, unreadable and plagued with a 60's version of the world. Grow up, kid.

>>27
Do you find chinese to be unreadable as well?

>>28
Yes.

>>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.

>>30
Considering how slow it will run, you'll have plenty of time to rewrite it in C while it is still running.

>>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.

I'm sorry for >>31. Poor child. >>30,32, you crushed his dreams.

>>33
s/u/a/

>>33
I'm sorry for >>30,32 -- his parens died in a car accident.

also, >>33 is a fucking fag.

>>35
his parens died in a car accident
Why did I laugh so hard?

>>35
I'm sorry for you, but my parens died in a cddaddr accident.