Author Topic: A C# Event Primer (for iago!)  (Read 18332 times)

0 Members and 1 Guest are viewing this topic.

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
A C# Event Primer (for iago!)
« on: October 16, 2007, 03:08:05 am »
This was for iago!!! :)
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Joe

  • B&
  • Moderator
  • Hero Member
  • *****
  • Posts: 10319
  • In Soviet Russia, text read you!
    • View Profile
    • Github
Re: A C# Event Primer (for iago!)
« Reply #1 on: October 16, 2007, 12:18:40 pm »
I don't have time to read it right now (late for work -- damn you x86!), but a big TIA goes out to you for when I finally do.
I'd personally do as Joe suggests

You might be right about that, Joe.


Offline while1

  • x86
  • Hero Member
  • *****
  • Posts: 1013
    • View Profile
Re: A C# Event Primer (for iago!)
« Reply #2 on: October 16, 2007, 12:44:35 pm »
Sweet.

Thanks Mynd.  Although I'm not in a situation where I'm required to familiarize myself with C# for a job or school, as a hobby I always enjoy expanding my scripting and programming language repertoire.

Reading the first couple of paragraphs, it seems like this primer is great for someone like myself too because I'm in the same boat as you when you first started with C# (AP CS and one semester of Java at university, but not any advanced or extensive use of Java).

Thanks again, now I have some reading material for my two hour backseat drive to university.
I tend to edit my topics and replies frequently.

http://www.operationsmile.org

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #3 on: October 22, 2007, 02:37:25 am »
Always remember to check for nullility!

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #4 on: October 23, 2007, 09:33:12 am »
Incidentally, thanks for writing that. I'll read it soon! :)

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #5 on: November 05, 2007, 04:24:00 pm »
All righty!

I started reading it, and realized I was somewhat over my head. So I went and read this tutorial and read it again. Much better the second time around!

The part of the tutorial about events confused me, but after reading your primer I understood. Woohoo!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #6 on: November 05, 2007, 07:37:27 pm »
Awesome, glad to hear it! Are you a convert yet?
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #7 on: November 05, 2007, 11:24:41 pm »
From what I've seen, definitely not. Everything about the language feels icky and hackish. The whole "We need to do this" "We can't" "Find a way!" mindset. I don't like it at all. I hate overloaded operators a lot, and the "properties" thing has the same icky feeling to it that I don't like in overloaded operators.

So yeah, overall, I hate it. I think they had some good ideas, but they made the mistake of trying to make it look like C++. I don't know how I would have done it, but I don't like how they did.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #8 on: November 05, 2007, 11:26:57 pm »
Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline abc

  • Hero Member
  • *****
  • Posts: 576
    • View Profile
Re: A C# Event Primer (for iago!)
« Reply #9 on: November 06, 2007, 09:48:56 am »
Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

Funny, I hate Java, but I love C#.

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #10 on: November 06, 2007, 10:12:32 am »
Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

Funny, I hate Java, but I love C#.

C# has a lot of nice ideas, but I don't like how they were implemented at all.

Offline Warrior

  • supreme mac daddy of trolls
  • Hero Member
  • *****
  • Posts: 7503
  • One for a Dime two for a Quarter!
    • View Profile
Re: A C# Event Primer (for iago!)
« Reply #11 on: November 06, 2007, 10:25:47 am »
Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

Funny, I hate Java, but I love C#.

C# has a lot of nice ideas, but I don't like how they were implemented at all.

What do you mean specifically?
One must ask oneself: "do I will trolling to become a universal law?" And then when one realizes "yes, I do will it to be such," one feels completely justified.
-- from Groundwork for the Metaphysics of Trolling

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #12 on: November 06, 2007, 11:34:35 am »
A lot of different things. But I know better than to get into a discussion about anything Microsoft-related with you, so I'm not going to bite.

Offline Warrior

  • supreme mac daddy of trolls
  • Hero Member
  • *****
  • Posts: 7503
  • One for a Dime two for a Quarter!
    • View Profile
Re: A C# Event Primer (for iago!)
« Reply #13 on: November 06, 2007, 11:39:43 am »
A lot of different things. But I know better than to get into a discussion about anything Microsoft-related with you, so I'm not going to bite.

I won't jump, promise. I genuinely want to know
One must ask oneself: "do I will trolling to become a universal law?" And then when one realizes "yes, I do will it to be such," one feels completely justified.
-- from Groundwork for the Metaphysics of Trolling

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #14 on: November 06, 2007, 12:04:58 pm »
A lot of different things. But I know better than to get into a discussion about anything Microsoft-related with you, so I'm not going to bite.

I won't jump, promise. I genuinely want to know

Fine, since you promised. These are just the things that bug me most.

My least favorite thing so far is pointers, though. Having to declare variables as "fixed" indicates a fundamental problem: they're trying to add a low-level paradigm to a high-level language, and end up with ugly constructs like that. It doesn't have a good feeling to me.

I also hate operator overloading. To me, a + should always add and a << should always left-shift. C# provides operator overloading, which is something I can get over. However, when using, for example, delegates, you add all your events to your delegate with + and remove them with -. That kind of thing just isn't right, to me. Then when you want to find out if it's empty, you compare it to null. That's just confusing, it took me awhile to figure out how a non-reference variable could be null. In my opinion, it's exactly why operator overloading is bad.

Another thing I don't like is that they .. damnit, I got an email and left for 10 minutes, so I totally forget what I was writing. Ohwell. :)

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #15 on: November 06, 2007, 12:35:57 pm »
Fine, since you promised. These are just the things that bug me most.

My least favorite thing so far is pointers, though. Having to declare variables as "fixed" indicates a fundamental problem: they're trying to add a low-level paradigm to a high-level language, and end up with ugly constructs like that. It doesn't have a good feeling to me.

I also hate operator overloading. To me, a + should always add and a << should always left-shift. C# provides operator overloading, which is something I can get over. However, when using, for example, delegates, you add all your events to your delegate with + and remove them with -. That kind of thing just isn't right, to me. Then when you want to find out if it's empty, you compare it to null. That's just confusing, it took me awhile to figure out how a non-reference variable could be null. In my opinion, it's exactly why operator overloading is bad.

Another thing I don't like is that they .. damnit, I got an email and left for 10 minutes, so I totally forget what I was writing. Ohwell. :)
Muwahahahaha, I didn't promise!

For the record, C# pointers don't always work with the fixed keyword.  They only are used when you need to obtain a pointer to a heap-allocated, garbage-collected object.  Arrays are heap-allocated except when using the stackalloc keyword:
Code: [Select]
unsafe void PointMe()
{
    byte* ptr = stackalloc byte[80];
}
Stack-allocated memory is intrinsically cleaned up at the end of a function scope.  The fixed keyword exists to inform the garbage collector not to automatically relocate an object during a garbage collection pass.  As I've gone farther in my C# use, I do what I can to avoid using fixed in favor of other constructs (Marshal.AllocHGlobal, Marshal.AllocCoTaskMem, and stackalloc - as far as I'm concerned, Marshal.AllocHGlobal and AllocCoTaskMem are the same as using malloc).

For operator overloading, best practices indicate that the overloaded operators should be used only for the mathematical functions they represent.  For instance, MBNCSUtil's BigInteger has overloaded operators for all of its numeric functions.  Best practices further dicate that there should be named functions (such as Add()) for any overloaded operators.

As for delegates and events, I suppose it's a matter of preference:
Code: [Select]
this.btnOK.Click += new EventHandler(this.btnOK_Click);
// vs.
this.btnOK.addActionListener(new ButtonActionListener(this));
To me, += and .addXXX() pretty much equate to the same thing.  I think of += as syntactic sugar - I can say
Code: [Select]
Delegate.Join(btnOK.Click, new EventHandler(btnOK_Click));

And you're mistaken about delegates and events - they *are* reference types.  That's why you need to check for nullility.

I agree with you - I don't like e-mail.  Particularly work things are notorious for pulling me away from important things like posting on the forums.  I think we should make e-mail illegal immediately!
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #16 on: November 06, 2007, 01:07:13 pm »
I've got to agree with iago. In Java, the delegates issue is solved by storing a List of a particular type of interface. Additionally, you can declare anonymous classes, which means you can do cool things like this:

Code: [Select]
tray.addMouseListener(new MouseListener() {
public void mouseClicked(MouseEvent e) {
if(e.getButton() == MouseEvent.BUTTON1) {
setVisible(!isVisible());
if(isVisible())
toFront();
}
}
public void mouseEntered(MouseEvent e) {}
public void mouseExited(MouseEvent e) {}
public void mousePressed(MouseEvent e) {}
public void mouseReleased(MouseEvent e) {}
});

The implementation code is quite elegant:
Code: [Select]
public class SomethingWithEvents {
List<EventHandlingInterface> delegates = new ArrayList<EventHandlingInterface>();

public boolean addDelegate(EventHandlingInterface ehi) {
return delegates.add(ehi);
}

private void doEvent(...) {
for(EventHandlingInterface ehi : delegates)
ehi.eventName(...);
}
}

I think MyndFyre said something about this coming to .NET in 3.0?

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #17 on: November 06, 2007, 01:10:44 pm »
And you're mistaken about delegates and events - they *are* reference types.  That's why you need to check for nullility.

What? In Java, an empty list is not null, they are a reference to a List object that happens to have no contents. I think this is what iago was pointing out.

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #18 on: November 06, 2007, 01:13:08 pm »
Muwahahahaha, I didn't promise!
Luckily, it's mostly preference stuff, so I can't really argue any of your points. Plus, I don't like the idea of being on the same side as Camel. :)

But it's really hard to explain, things just feel hackish to me. *shrug*

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #19 on: November 06, 2007, 01:21:11 pm »
Plus, I don't like the idea of being on the same side as Camel. :)

That's a wise position to take.

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #20 on: November 06, 2007, 01:39:58 pm »
I've got to agree with iago. In Java, the delegates issue is solved by storing a List of a particular type of interface. Additionally, you can declare anonymous classes, which means you can do cool things like this:

Code: [Select]
tray.addMouseListener(new MouseListener() {
public void mouseClicked(MouseEvent e) {
if(e.getButton() == MouseEvent.BUTTON1) {
setVisible(!isVisible());
if(isVisible())
toFront();
}
}
public void mouseEntered(MouseEvent e) {}
public void mouseExited(MouseEvent e) {}
public void mousePressed(MouseEvent e) {}
public void mouseReleased(MouseEvent e) {}
});
See, the difficulty there is that you're still creating an entire type to handle a signal, when a function will do.

C# 2.0 (2005) introduced anonymous methods so that function definitions wouldn't need to be class members:
Code: [Select]
btnClickMe.Click += delegate { MessageBox.Show("*GASP!* You clicked me!"); };
Anonymous methods also support parameters:
Code: [Select]
btnClickMe.MouseDown += delegate(object sender, MouseEventArgs e) { MessageBox.Show(string.Format("({0}, {1})", e.X, e.Y)); };

The implementation code is quite elegant:
Code: [Select]
public class SomethingWithEvents {
List<EventHandlingInterface> delegates = new ArrayList<EventHandlingInterface>();

public boolean addDelegate(EventHandlingInterface ehi) {
return delegates.add(ehi);
}

private void doEvent(...) {
for(EventHandlingInterface ehi : delegates)
ehi.eventName(...);
}
}

I think MyndFyre said something about this coming to .NET in 3.0?
This has actually been part of .NET since the beginning.  A little-known (because it's really not used much) feature of C# (and actually, VB too) is that you can manually provide event backing fields for events:
Code: [Select]
private EventHandler handlers;
public event EventHandler Clicked
{
    add(EventHandler eh)
    {
        Delegate.Combine(this.handlers, eh);
    }
    remove(EventHandler eh)
    {
        Delegate.Remove(this.handlers, eh);
    }
}
Invocation is then done:
Code: [Select]
if (handlers != null)
  handlers(this, EventArgs.Empty);

Though, I still think that from an OO standpoint, the fact that an object posesses properties and events, and that other objects listen to those events by registering for them, is more clear than registration via a behavior (which is what a method is supposed to represent - a behavior).

Incidentally, this is (more or less) what the compiler does when you create:
Code: [Select]
public event EventHandler Clicked;
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #21 on: November 06, 2007, 09:45:47 pm »
See, the difficulty there is that you're still creating an entire type to handle a signal, when a function will do.

If your quarrel is with the bulky code, I agree with you. However, your concerns are mostly unwarranted because hotspot will optimize this down beyond an anonymous method if possible. I say mostly because hotspot does this optimization at runtime, not compile time. The bytecode in the class files still has the extra info.

There's no way to say that either Java or C# is inherently better than the other, however, the preference always seems to come back to the same thing: what OO means to you. In Java, it means everything is an instance of an <Object>. This makes the language intrinsically simpler to learn, and, in my opinion, more elegant.

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #22 on: November 06, 2007, 10:37:13 pm »
There's no way to say that either Java or C# is inherently better than the other, however, the preference always seems to come back to the same thing: what OO means to you. In Java, it means everything is an instance of an <Object>. This makes the language intrinsically simpler to learn, and, in my opinion, more elegant.
But see, in Java, everything *isn't* an instance of <Object>.
Code: [Select]
int i = 5;

i isn't an Object.  It is in C#, though! :P
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Joe

  • B&
  • Moderator
  • Hero Member
  • *****
  • Posts: 10319
  • In Soviet Russia, text read you!
    • View Profile
    • Github
Re: A C# Event Primer (for iago!)
« Reply #23 on: November 07, 2007, 12:13:32 am »
Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

You missed something: Java and C# syntax are 99.9% the same. I've copy/pasted hundreds of lines of my Java code into C#, fixed the API references, and then ran them with zero syntax conversion.
I'd personally do as Joe suggests

You might be right about that, Joe.


Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #24 on: November 07, 2007, 12:31:29 am »
There's no way to say that either Java or C# is inherently better than the other, however, the preference always seems to come back to the same thing: what OO means to you. In Java, it means everything is an instance of an <Object>. This makes the language intrinsically simpler to learn, and, in my opinion, more elegant.
But see, in Java, everything *isn't* an instance of <Object>.
Code: [Select]
int i = 5;

i isn't an Object.  It is in C#, though! :P

Java will automatically cast an int to an <Integer> if you try to use it as an object, and you're splitting hairs.

Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

You missed something: Java and C# syntax are 99.9% the same. I've copy/pasted hundreds of lines of my Java code into C#, fixed the API references, and then ran them with zero syntax conversion.

I was clearly talking about corner cases: enums, anonymous types, delegates, etc.
« Last Edit: November 07, 2007, 12:33:56 am by Camel »

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #25 on: November 07, 2007, 12:47:58 am »
Java will automatically cast an int to an <Integer> if you try to use it as an object, and you're splitting hairs.
You still need to allocate a heap object.  It's not so much a splitting-hairs thing so much as a "here's a big difference between the runtimes."
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Chavo

  • x86
  • Hero Member
  • *****
  • Posts: 2219
  • no u
    • View Profile
    • Chavoland
Re: A C# Event Primer (for iago!)
« Reply #26 on: November 07, 2007, 11:55:29 pm »
Speaking of split hairs, I'm thinking about trying a new shampoo.  What do you think?

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #27 on: November 08, 2007, 12:08:19 pm »
Java will automatically cast an int to an <Integer> if you try to use it as an object, and you're splitting hairs.
You still need to allocate a heap object.  It's not so much a splitting-hairs thing so much as a "here's a big difference between the runtimes."

I don't know how .NET handles this situation; could you enlighten me?

FWIW though, your point seems to be moot, since all objects in all languages exist in the heap. Maybe I missed your point?

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #28 on: November 08, 2007, 01:04:10 pm »
FWIW though, your point seems to be moot, since all objects in all languages exist in the heap. Maybe I missed your point?
Hmm, maybe you don't know how all languages work?

In .NET, value-types (everything declared with the struct keyword instead of the class keyword, as well as enums) live on the stack instead of on the heap.  The .NET stack, like the x86 stack, is a place for temporary variables.  So let's say I have a class that holds 12 bytes of information; we'll push the stack by 12 bytes and say that the memory space between that push is where the variable lives.  When a function is called referencing the variable, the variable is copied to the new stack.  So for example:
Code: [Select]
// C#
public struct Point
{
  public int X, Y;
}
public class CPoint
{
  public int X, Y;
}
void Test()
{
  Point p = new Point() { X = 10, Y = 20 };
  ModifyPoint(p);
  Console.WriteLine("({0}, {1})", p.X, p.Y);
  CPoint cp = new CPoint() { X = 15, Y = 30 };
  ModifyPoint(cp);
  Console.WriteLine("({0}, {1})", cp.X, cp.Y);
}
void ModifyPoint(Point p)
{
  p.X *= 2;
  p.Y *= 2;
}
void ModifyPoint(CPoint p)
{
  p.X *= 2;
  p.Y *= 2;
}

The output of this is:
Code: [Select]
(10, 20)
(30, 60)

This is similar to C and C++:
Code: [Select]
typedef struct tagPOINT
{
  int X;
  int Y;
} Point;
void ModifyPoint(Point p)
{
  p.X *= 2;
  p.Y *= 2;
}
void ModifyPPoint(Point *p)
{
  p->X *= 2;
  p->Y *= 2;
}
void ModifyRPoint(Point& p)
{
  p.X *= 2;
  p.Y *= 2;
}
Now, C++ gives you a little more flexibility:
Code: [Select]
Point p; // allocates 8 bytes on the stack
Point* p = new Point; // allocates 8 bytes on the heap and the machine pointer size on the stack
You can use all 3 modify-point functions on the first one (since you can get a pointer to a stack variable as well), but you can only use the ModifyPPoint function on the heap object.

Incidentally, this is the way Java treats primitive types too.  You just can't expect them to change when they get back to the original function.  If I have an int in Java, and I call toString() on it, the compiler implicitly creates a new Integer object on the heap and calls the function on that.  IMO that's a bit of a hack.  OTOH, .NET calls .ToString() directly on the int on the stack.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #29 on: November 08, 2007, 02:02:12 pm »
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.

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

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #30 on: November 08, 2007, 03:26:43 pm »
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.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #31 on: November 08, 2007, 03:34:51 pm »
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.
« Last Edit: November 08, 2007, 03:42:19 pm by Camel »

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #32 on: November 08, 2007, 04:08:48 pm »
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.

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline Joe

  • B&
  • Moderator
  • Hero Member
  • *****
  • Posts: 10319
  • In Soviet Russia, text read you!
    • View Profile
    • Github
Re: A C# Event Primer (for iago!)
« Reply #33 on: November 08, 2007, 04:21:46 pm »
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!
I'd personally do as Joe suggests

You might be right about that, Joe.


Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #34 on: November 08, 2007, 06:46:16 pm »
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.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #35 on: November 08, 2007, 07:46:19 pm »
Oh no you didn't!

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #36 on: November 09, 2007, 10:14:16 am »
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...

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #37 on: November 09, 2007, 10:22:54 am »
That's not even the worst part, iago. They had to overload the new operator to do it!

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #38 on: November 09, 2007, 11:26:04 am »
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?  :P

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.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #39 on: November 09, 2007, 11:31:18 am »
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.

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #40 on: November 09, 2007, 12:31:34 pm »
How often do you need to know how an object is allocated?  :P
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. :)

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #41 on: November 09, 2007, 02:01:24 pm »
structs in general feel like a hack. :)
Only because they do something useful that Java doesn't. :P
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #42 on: November 09, 2007, 02:13:11 pm »
structs in general feel like a hack. :)
Only because they do something useful that Java doesn't. :P
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!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #43 on: November 09, 2007, 03:10:03 pm »
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #44 on: November 09, 2007, 03:56:59 pm »
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. :P

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #45 on: November 09, 2007, 04:51:32 pm »
Either way, I think I make a good point. :P

So did Hitler.  :P
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #46 on: November 09, 2007, 05:00:58 pm »
Either way, I think I make a good point. :P

So did Hitler.  :P

If Hitler was alive, he'd probably like C#. So you must be wrong.

Offline Blaze

  • x86
  • Hero Member
  • *****
  • Posts: 7136
  • Canadian
    • View Profile
    • Maide
Re: A C# Event Primer (for iago!)
« Reply #47 on: November 09, 2007, 05:12:21 pm »
Either way, I think I make a good point. :P

So did Hitler.  :P

If Hitler was alive, he'd probably like C#. So you must be wrong.

Obviously!  Also, Stalin would still be boasting about how QBasic is the best.
And like a fool I believed myself, and thought I was somebody else...

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #48 on: November 09, 2007, 06:49:14 pm »
Incidentally, shame on Myndy for invoking Godin's Law! :)

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #49 on: November 09, 2007, 07:27:43 pm »
Incidentally, shame on Myndy for invoking Godin's Law! :)

Hahahahahahaha.  <3!
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #50 on: November 10, 2007, 11:24:53 am »
structs in general feel like a hack. :)
Only because they do something useful that Java doesn't. :P

The reason I structs seem hacky to me is that they are subclasses of Objects, but their behavior is completely different. You can't even do that in C#, which definitely makes it a framework hack.

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline Joe

  • B&
  • Moderator
  • Hero Member
  • *****
  • Posts: 10319
  • In Soviet Russia, text read you!
    • View Profile
    • Github
Re: A C# Event Primer (for iago!)
« Reply #51 on: November 10, 2007, 04:18:03 pm »
structs in general feel like a hack. :)
Only because they do something useful that Java doesn't. :P
You just said they're useless!

The difference between .. C# and .. Java: [C#] is faster. .. Big deal!
I'd personally do as Joe suggests

You might be right about that, Joe.


Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #52 on: November 10, 2007, 05:41:25 pm »
The reason I structs seem hacky to me is that they are subclasses of Objects, but their behavior is completely different. You can't even do that in C#, which definitely makes it a framework hack.
Wait, what?  I just described how you do it in C#....  You declare it as a "struct" instead of a "class."
Quote from: C# Language Reference section 1.3
C#’s type system is unified such that a value of any type can be treated as an object. Every type in C# directly or indirectly derives from the object class type, and object is the ultimate base class of all types.

.....

However, unlike classes, structs are value types and do not require heap allocation. Struct types do not support user-specified inheritance, and all struct types implicitly inherit from type object.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #53 on: November 11, 2007, 05:01:41 pm »
Structs are classes, but instances of structs do not behave the same as instances of classes. How is that not hacky? Behavior is supposed to be inherited, not arbitrarily redefined.

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #54 on: November 11, 2007, 08:03:48 pm »
Structs are classes, but instances of structs do not behave the same as instances of classes. How is that not hacky? Behavior is supposed to be inherited, not arbitrarily redefined.
It's not "arbitrarily" redefined - it's formally defined.  See: the C# language reference.

That's like saying that floats are numbers, and integers are numbers, but they do not behave the same.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #55 on: November 11, 2007, 08:48:41 pm »
Structs are classes, but instances of structs do not behave the same as instances of classes. How is that not hacky? Behavior is supposed to be inherited, not arbitrarily redefined.
It's not "arbitrarily" redefined - it's formally defined.  See: the C# language reference.

That's like saying that floats are numbers, and integers are numbers, but they do not behave the same.
It's formally defined, but, as much as it hurts to agree with Camel, I think it feels like a hack. floats and integers behave the same way (or, at least, consistently) when you perform the same operations on them, which isn't something that can be said for structs (in my opinion).

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #56 on: November 11, 2007, 08:57:34 pm »
So, int can behave both ways in Java too, right?  So it's a hack too?

Or how about the way that autoboxing was hacked into the Java compiler but doesn't have intrinsic support in the runtime?
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: A C# Event Primer (for iago!)
« Reply #57 on: November 11, 2007, 09:32:48 pm »
I don't believe that int can behave both ways. The base type (int) behaves like a base type, and the class (Integer) behaves another way. There are things in Java that feel hackish, but that's not one of them.

I have no idea what autoboxing is. I don't have a whole lot of formal training in languages except for C, so I don't know the terms for a lot of things.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #58 on: November 12, 2007, 01:02:32 am »
When did agreeing with me become inherently tabu?

In Java, ints do not behave both ways. Ints are base types, and are passed, as all base types are, by value. Integers are Objects, and are passed, as all Objects are, by pointer-value. There are no Java Objects that revert to being passed as the sum of their fields (with the exception of uboxed numbers, which doesn't count).

Autoboxing is the silent up-conversion of a base type to an Object. Ex:
Code: [Select]
Integer i = (int)2;
Java also has automatic unboxing:
Code: [Select]
int i = new Integer(2);
If you switch down to a Java 1.4 compiler, and try to compile the following:
Code: [Select]
Integer x = new Integer(1);
Integer y = new Integer(2);
Integer z = x + y;

You will get an error indicating that two Objects can not be added together. In Java 5, this was solved by adding autoboxing/unboxing; the third line will unbox the Integers to ints, add them, and autobox them back in to an Integer.

It isn't hacky because it's intuitive, and it isn't in the runtime for two reasons: one, for backwards compatibility. Two, you can't overload operators in Java. As we've already discussed, Java doesn't believe in operator overloading, with the exception of number objects (because they're being used to do math on numbers which is intuitive) and java.lang.Strings (because typing out .concat is tedious and is less intuitive than using +). There simply aren't any other conditions where the + operator, or any operator for that matter, can be used intuitively.

C# structs are hacky because they aren't intuitive, and because they don't inherit behavior from their parent class, System.Object.



If you really are going to insist that autoboxing is hacky, you should also complain about the automatic import of java.lang.*, because it's equally as hacky, and less intuitive.
« Last Edit: November 12, 2007, 01:06:57 am by Camel »

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #59 on: November 12, 2007, 04:50:26 am »
C# structs are hacky because they aren't intuitive, and because they don't inherit behavior from their parent class, System.Object.
Do you understand what "behavior" means in an object-orientation sense?

Behavior in OO land is the type of behaviors an object exhibits to the outside world - ways to change state.  Whether an object lives on the heap or the stack is not part of OO, nor is whether an object is copied by value or reference - it's entirely a semantic part of the language.  The fact that a language enables you to define it indicates that it's rather expressive, instead of hackish, don't you think?

I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #60 on: November 12, 2007, 11:10:33 am »
If you pass a struct to a method in C#, the instance passed to the method is not the originating instance, because it is copied on to the stack. That means if you modify its state, the original object does not reflect the changes. Since this isn't how objects work in C#, even though structs are objects, it's confusing, breaks OOD, and is a hack.

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: A C# Event Primer (for iago!)
« Reply #61 on: November 12, 2007, 01:35:58 pm »
If you pass a struct to a method in C#, the instance passed to the method is not the originating instance, because it is copied on to the stack. That means if you modify its state, the original object does not reflect the changes. Since this isn't how objects work in C#, even though structs are objects, it's confusing, breaks OOD, and is a hack.

But you're not invoking the behavior on the object.  You're invoking the behavior of another object using the state of the object in question.  And you're still confusing an object behavior with a semantic language behavior.  When you modify its state, you're modifying a new copy.

You say it breaks OOD.  Name six examples.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: A C# Event Primer (for iago!)
« Reply #62 on: November 13, 2007, 12:08:26 am »
If structs are going to outright violate the rules defined for a System.Object, but they are still defined as a subclass of System.Object, that's a clear violation of OOD. If you are seriously going to sit here and tell me that behavior is restricted to state transitions of the instance, you should consider giving some of those certifications back.

Here are the six examples you asked for:
Code: [Select]
int i = 1;
Code: [Select]
long l = 1234567890;
Code: [Select]
double d = 42.1;
Code: [Select]
float f = 0.5;
Code: [Select]
byte b = 127;
Code: [Select]
char c = 'X';

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!