A C# Event Primer (for iago!)

[MyndFyre]

Objects are instances of classes. In most languages, they are created with the new keyword (which is equivalent to a malloc() call plus a call to the constructor), and therefore can only exist on the stack as a pointer to the heap.

Except, in C++, you can create an object on the stack.  It'll still have its vtable and all its methods.  I demonstrated how this is done in my previous post.  Which "most" languages are you referring to?

Java's elegance comes from its purity. There speed advantage of keeping an object on the stack (avoiding references to "far" memory locations) is so negligible that it isn't worth justifying in such a high level language. KISS is a founding principle of Java.

It's not a speed advantage for object maintenance.  The real speed advantage is to prevent heap fragmentation.  If you have to allocate a lot of small, short-lived objects frequently, it's better to allocate them on the stack instead of the heap.  In garbage-collected languages this is even more true, because the memory won't be freed until a GC pass, whereas stack-allocated objects are freed as soon as you pop a method from the call stack.

[Camel]

Objects are instances of classes. In most languages, they are created with the new keyword (which is equivalent to a malloc() call plus a call to the constructor), and therefore can only exist on the stack as a pointer to the heap.

Except, in C++, you can create an object on the stack.  It'll still have its vtable and all its methods.  I demonstrated how this is done in my previous post.  Which "most" languages are you referring to?

Structs are not objects! They're groups of variables packed together. The ability of many C compilers to add methods to a struct is a non-ANSI compliant hack.

[edit] Also, in the Java world, if an object is not stored by reference in the heap, it is destroyed marked for destruction when its scope ends. Memory fragmentation is irrelevant; computers are fast, and if you allocate from the heap in a round-robbin fashion, you won't run in to any serious speed pitfalls.

[Camel]

We settled this on AIM. We decided that both languages need a delete operator. Also, x86 should have free pie whenever iago's server goes down.

[Joe]

We settled this on AIM. We decided that both languages need a delete operator. Also, x86 should have free pie whenever iago's server goes down.

And pizza and ice cream.

And soda.

And turkey!

[MyndFyre]

We settled this on AIM. We decided that both languages need a delete operator*. Also, x86 should have free pie whenever iago's server goes down.

*that MyndFyre was correct.

[Camel]

Oh no you didn't!

[iago]

Eww @ how the "new" operator has been redefined. Now it can allocate on the stack or the heap depending on the context. That feels icky. :-/ Now if you need to know how an object is allocated, you have to look up information about the object (whether it's a struct or class), and if it's the wrong one you're outta luck. Doesn't seem right...

[Camel]

That's not even the worst part, iago. They had to overload the new operator to do it!

[MyndFyre]

That's not even the worst part, iago. They had to overload the new operator to do it!

Wait, what?  You can't overload the new operator!  It's not supported!  New operator only exists to invoke the constructor!

Eww @ how the "new" operator has been redefined. Now it can allocate on the stack or the heap depending on the context. That feels icky. :-/ Now if you need to know how an object is allocated, you have to look up information about the object (whether it's a struct or class), and if it's the wrong one you're outta luck. Doesn't seem right...

How often do you need to know how an object is allocated? 

In practice (and I have a lot of it), you rarely define structs.  They have their purpose, but you know when you're using them what you're getting.  They have an enormous speed advantage when it comes to allocation (if I recall my speed tests, a couple orders of magnitude), but they're limited in utility because they're passed by value, unless you explicitly pass them by reference (using ref or out), but then they might as well be classes.

[Camel]

IF YOU LOVE THEM SO MUCH WHY DON'T YOU MARRY THEM?

[edit] Yes, it did take me all of fourth grade to come up with that one.

[iago]

How often do you need to know how an object is allocated? 

Unrelevant! If they're going to make it possible to know where objects are, they should make it consistent. Besides, you do need to know when you're passing it as a parameter. Depending on what the variable type is (whether it's a struct or a class or a base type (int, double)), a variable is passed to a function differently. The only way you can know how (I think?) is by looking up the declaration for that variable type. That's all very icky, there's little consistency!

In practice (and I have a lot of it), you rarely define structs.  They have their purpose, but you know when you're using them what you're getting.  They have an enormous speed advantage when it comes to allocation (if I recall my speed tests, a couple orders of magnitude), but they're limited in utility because they're passed by value, unless you explicitly pass them by reference (using ref or out), but then they might as well be classes.

structs in general feel like a hack.

[MyndFyre]

structs in general feel like a hack.

Only because they do something useful that Java doesn't.

[iago]

structs in general feel like a hack.

Only because they do something useful that Java doesn't.

You just said they're useless!

The difference between a struct in C# and a potential class in Java: the struct is faster and passed by value. Big deal!

[MyndFyre]

You just said they're useless!

Nuh uh!

They have their purpose

[iago]

You just said they're useless!

Nuh uh!

They have their purpose

Yeah, after "you rarely define structs"!

Either way, I think I make a good point.