You mean a modern network server doesn't have to read data from it's incoming connections? News to me, every one I've worked on has that as one of it's primary tasks. And it can't process the data until it's read it (or at least a sufficient portion of it to be able to figure out what to do next). Now, you can get fancy by trying to multiplex multiple connections in a single thread, but it's much simpler to spawn one thread of execution for each connection. You've got enough complexity already that you don't need to go creating any more for yourself.
Duh. The typicaly modern network server *or* end user application doesn't just sit there, read data and have NOTHING ELSE TO DO whilst its waiting for data.
Modern GUI applications are message-driven. It's the message-processing loop that needs to never block. If you look, you'll find that 90% of the code in that GUI application is plain old traditional synchronous code to handle each type of message. Only a small portion in the message loop actually deals with controlling multiple threads.
Duh. That doesn't mean it can't be rewritten to do tasks asynchronously. Many applications in the past have been written poorly but most applications now days will take advantage of multiple threads to make the GUI more responsive.
As an example, if a GUI event triggers a time-consuming compute process, I can do two things. One, I can spawn off a thread to do the compute job and signal me when it's done. Two, I can write the data block down a pipe and let another thread or process deal with it, after having set a monitor on the pipe so I'll get a message when data's available on it. When the data-available message comes in, I snarf the results back from the pipe and do what needs done with them
Oh that's smart. Calling something in another thread is no harder than calling a function and the alternative is to serialize your data and mutable global state, create a RPC protocol and send the task to another process and then read the response back. Yeah, that sounds heaps easier.
And on a Unix system where fork/exec is relatively cheap, why waste development time on a complex multi-threaded compute program when I can design a simple single-threaded one that reads it's input from standard input (connected to the incoming pipe) and writes it's output to standard output (connected to the outgoing pipe) and is pretty much immune to memory leaks, memory corruption and a host of other problems caused by other threads of execution in the same address space
ROFL. Threading (basically calling a function) more complex than writing client/server processes? We're back to asking you why you believe that somehow, different threads of execution have no need to be associated with the address space of another thread of execution even though different functions do.
I'm pretty tired of talking to someone who clearly has no experience with end user apps or modern concurrent and async application design.
You're misreading. It's not 90% of the problems out there, it's 90% of the code in a given program that's synchronous.
I really doubt that.
Take, for example, the process of reading data from a single input source and processing it. With no other input sources to look at, and no processing that doesn't require the data you're trying to read, exactly what can the code do while the read's completing?
That's not a typical modern server or end user application.
You incur the overhead of creating a thread, and then the parent simply blocks until the child thread completes. Less overhead to simply do the read in the same thread as a simple function call
Who was suggesting that we should call functions in a seperate thread when the operation is synchronous? My example was an example of how silly it was for you to state that a shared address space between async operations weren't needed.
You incur the overhead of creating a thread, and then the parent simply blocks until the child thread completes.
I would think someone with your experience would know about something as basic as thread-pooling.
Most of a program is like that: the caller can't proceed until the function it's called returns it's results, so running the called function in a seperate thread doesn't actually result in any parallelization
That most programs today aren't GUI applications where the UI should not be *blocked* whilst some request is processed? Even something as basic as IO can easily be made asynchronous as there is almost always some post processing to be done after a file or part of a file is loaded into memory that can be done whilst the next block is read.
Most of a program is like that: the caller can't proceed until the function it's called returns it's results, so running the called function in a seperate thread doesn't actually result in any parallelization
Sounds like you need to be more creative in how you design your applications. Most modern applications aren't top-down flow chart style processes.
As for the first part, as I noted a lot of "shared" memory is read-only as far as the child's concerned. The only real issue with seperate processes is the potential for a massive memory split if one process suddenly updates the majority of that "read-only" memory (eg. reloading of configuration data). Where you have lots of memory shared that doesn't involve pointer-based data structures, shared memory will get you what you need without the need for fully-shared address space (which means your various processes are protected from heap corruption by their siblings, among other things). There are times you need the entire address space shared, but IMHO they aren't nearly as common as they're made out to be and the problems of fully-shared address space are well-known and not insignificant.
Again, I totally disagree. I find your idea that 90% of the time, different threads of executation don't need to execute in the context of a shared address space to be rather bizarre. Perhaps it's because you've spent so many years programming with processes rather than threads.
As far as why you don't make every function a process, for the same reason you don't make every function a thread: the vast majority of a program is not parallelizable. Parallel threads of execution, be they threads or processes, are applicable when the parent can fire off the child and go do something else while the child executes. If the only thing the parent can do at that point is wait for the child to finish, it's more efficient to simply do a call within the same thread of execution.
You missed my point which is that functions share the exact same address space because it is useful and there multiple threads of execution have the exact same address space for exactly the same reasons.
I find it astounding that someone can think that 90% of the time, a single address space only needs one thread of execution.
What kind of applications have you been writing the last 25 years?
Forked processes do share memory (at least until it's modified).
That's not what I meant by shared. That's just copy-on-write memory copied memory and only 'shared' for the purposes of saving memory.
Maybe you're writing a different class of applications, but I find threading extremely important. There are many classes of problems where you want to go off and perform a task asynchronously whilst you continue doing something else. I don't think an animation or maybe some blocking IO should require spawning a another process.
It's not about using memory for data communication, it's about using memory for sharing or resources. Like I said, if using seperate processes were so great, why not just write every *function* in your program as a forked process and use IPC and shared memory?
Hence NT needed threads to provide a faster alternative to processes, while Unix (whose processes were almost as cheap to create as NT threads) didn't really need threads
You make it sound like they added threads cause they couldn't get processes fast enough which is absolutely false. Threading and asynchronous IO were a design *feature* not an after thought.
while Unix (whose processes were almost as cheap to create as NT threads) didn't really need threads for anything other than a marketing checklist (about the only thing Unix threads get you that processes don't is fully-shared address space, and I'd argue that's often more a problem than an advantage).
Threads are suprior to forked processes in many ways. If you don't think having all the process memory shared between threads is important, why bother having memory shared between different functions? The fact is that the need for multiple asynchronous operations to occur within the context of a single memory space is not only useful, but very important in modern day applications. There are cases where isolating memory is good (for security) but there are just as many cases where having isolated memory is a pain because suddenly you've lost the usefulness of the native language (C in this case) and have to resort to using mmap and other system calls just to share and pass data.
Ofcourse, they only condemned "blind" attacks which makes it pretty useless a fatwa since the youths certainly don't think what they're doing is blind (and the 'official islamic body' knows that). The wording works to their advantage and people like you coo when they say it.
Um no. Static in Java merely means the class doesn't have an implicit reference (and binding) to the outer instance that created it.
Microsoft muddied the whole issue by not having inner classes (only nested classes) and then by introducing "static" classes which have a totally different meaning from Java static inner classes.
Re:disappointed -- try the java cert exam
on
Java Puzzlers
·
· Score: 1
Interestingly, Microsoft did fix that when they designed C#.
Re:master of the obvious
on
Java Puzzlers
·
· Score: 1
It *might* be interesting from the perspective of loading a file (e.g. buffer.append((char)in.read());), except that the IO streams provide Integers to get around the sign problem.
I think you mean readers provider integers to get around the problem. Streams only read bytes whereas readers read chars (which may consist of one or more bytes depending on the encoding).
I think the point we're clashing on is that you don't realize your original post insinuated that the Chinese are multiplying like horny rabbits, and that they shouldn't pollute any more than the US, even though they have way more people.
The US has a large population because it has historically had very open immigration and a huge number of willing immigrants.
I never said that China shouldn't pollute more than the US. I'm saying that Kyoto quotas, if anything, should be based on land mass (or maybe productivity) *NOT* on population size.
However, my personally belief is that Kyoto is flawed. China can pollute as much as it wants to. I don't really care and don't believe they should be allowed to pollute without consequence *at the expense* of countries like the US simply because they're "developing" and have more people. Most countries that are smart have developed their own measures for environmental preservation (the modern environmental movement was born in the US).
I guess reading comprehension and the ability to write goes hand in hand. If you learn to write, I will consider replying to the rest of your diatribe.
Re:per capita, per shmapita
on
Chinese Eco-Cities
·
· Score: 0, Redundant
1) China is developing at a rapid pace -- if things continue on the present course they'll be the worlds biggest eco-disaster no matter what scale you measure by... probably in as little as a generation or two.
Well duh.
2) If everyone in the States multiplied until there were more than a billion citizens, and if the lifestyles remained as they are now, then the States would be an even bigger eco-disaster than China might ever hope to be.
or at the very least that 1.3 billion people aren't allowed to pollute more than the us, which is more than 4x smaller?
That's so stupid I didn't even think it needed a reply.
Who is saying that they're "not allowed to polute more than 'us'". If you recall, the US didn't ratify Kyoto -- the treaty that dictates who can pollute and who can't.
You're the kind of person who thinks that the couple who live confortably because they choose to only have one child should have to pay for irresponsible couple with 7 children living in a trailer park.
Agreeing with the other two posts about China's birth rates even being BELOW sustainable growth. They are actively enforcing a one child limit policy, and yet you're touting that the Chinese are having babies like fucking crazy, or at the very least that 1.3 billion people aren't allowed to pollute more than the us, which is more than 4x smaller? And still get modded insightful for it? You're an ignorant fucktwit.
Everyone knows about China'a one child limit (which has recently been changed BTW). It has nothing to do with that you "ignorant fuckwit".
It has to do with population size. America has a smaller population and they would need to "breed like there's no tomorrow" in order to get a high population size (like China).
China's population "growth"-- their birth rates are below sustainable and therefore also below ours
Their birthrate is irrelevant. It's about their population size. Other people got it, why didn't you?
I am a nation of one. That is, I am the nation of Bert. I pretty much rule, because I'm the only fellow around. I thoroughly enjoy both dumping oil into the ocean AND eating dolphin steak. I enjoy these activities so much that I indeed match the absolute pollution levels of the US. Clearly, I am a much worse polluter than the average american (who shares his or her polluting mischief with about a quarter billion other people). It is way more reasonable for a nation of a billion people to throw a billion styrofoam containers away, than it is for one person.
If the goal is to reduce polution on the planet, it should be based on land area. We are talking about a treaty between *countries* and not individuals. A nation of one million people with the land mass of America, under Kyoto, *should* be allowed to pollute just as much as nation with the same land mass and one billion people. Perhaps it'll encourage the country with one billion people to consider sustainable growth....I guess that nation has....
How the HELL do you get modified insightful for making such a blatently false statement?
Perhaps because the point flew over your head?
It's not about the birth rate, it's about "per capita" quotas. The chinese clearly see the light so have restricted (by law) population growth (and did it long ago).
Re:We can all breathe a bit easier
on
Chinese Eco-Cities
·
· Score: 1, Insightful
Let's talk per capita. Because that's really what matters
Why?
Perhaps the Americans should have babies like there is no tomorrow so that they can "legally" pollute more, have higher levels of poverty and then complain that the rest of the world won't support them.
No. The internet is based on the foundations of the American ideal. Freedom & liberty. The internet works because individuals and companies formed by coalitions of individuals freely *choose* to be part of it.
Notice that on the internet, everyone is *NOT* equal because in real life no two people are equal. Everyone/webiste/whatever has value based on how society (not a central authority) judges it. The only way to have a communist society is to treat everyone differently so that it all evens out. That is unfair, immoral and corrupt and why communist systems always fail.
Microsofts methodics are plain stupid, because for everything you want to do you have to specify it so explicitly my fingers still hurt last time I tried it.
Java:
obj.SetValue(obj.GetValue() + 1);
C#:
obj.Value++;
Java:
public class C {
private List listeners = new List();
public void addOnSomeEvent(ActionEventListener l)
{
listeners.add(l);
}
public void removeOnSomeEvent(ActionEventListener l)
{
listeners.remove(l);
}
public void fireEvent(ActionEvent e)
{
for (Iterator = listeners.iterator(); iterator.hasNext();)
{
((ActionEventListener)iterator.next()).handleActio nEvent(e);
}
} }
someobj.addOnSomeEvent(new ActionEventListener {
public void handlActionEvent(ActionEvent)
{
doStuff();
} });
C#
public class C {
public virtual event EventHandler SomeEvent;
You attribute those deaths to halliburton so do you consider the deaths of millions due to corrupt government and dictators who implement sociliast economic policies accountable too?
...you can find hand written notes within a file without converting them to text? If so, that is pretty cool. I will have to look into that. Thanks.
Yep, that was IMHO, one of the biggest breakthoughs with the tablet pc platform. Searching handwritten notes is more accurate than searching notes converted to text because "close looking matches" can also be returned.
I pretty much get 100% accuracy with my search results with the occasional negative (wrong result cause of similar looking words).
Slashdot Mirror
I just love these "microsoft's big mistake" posts.
Why would people buy a NEW XBOX to play OLD GAMES that their OLD XBOX can already play?
You mean a modern network server doesn't have to read data from it's incoming connections? News to me, every one I've worked on has that as one of it's primary tasks. And it can't process the data until it's read it (or at least a sufficient portion of it to be able to figure out what to do next). Now, you can get fancy by trying to multiplex multiple connections in a single thread, but it's much simpler to spawn one thread of execution for each connection. You've got enough complexity already that you don't need to go creating any more for yourself.
Duh. The typicaly modern network server *or* end user application doesn't just sit there, read data and have NOTHING ELSE TO DO whilst its waiting for data.
Modern GUI applications are message-driven. It's the message-processing loop that needs to never block. If you look, you'll find that 90% of the code in that GUI application is plain old traditional synchronous code to handle each type of message. Only a small portion in the message loop actually deals with controlling multiple threads.
Duh. That doesn't mean it can't be rewritten to do tasks asynchronously. Many applications in the past have been written poorly but most applications now days will take advantage of multiple threads to make the GUI more responsive.
As an example, if a GUI event triggers a time-consuming compute process, I can do two things. One, I can spawn off a thread to do the compute job and signal me when it's done. Two, I can write the data block down a pipe and let another thread or process deal with it, after having set a monitor on the pipe so I'll get a message when data's available on it. When the data-available message comes in, I snarf the results back from the pipe and do what needs done with them
Oh that's smart. Calling something in another thread is no harder than calling a function and the alternative is to serialize your data and mutable global state, create a RPC protocol and send the task to another process and then read the response back. Yeah, that sounds heaps easier.
And on a Unix system where fork/exec is relatively cheap, why waste development time on a complex multi-threaded compute program when I can design a simple single-threaded one that reads it's input from standard input (connected to the incoming pipe) and writes it's output to standard output (connected to the outgoing pipe) and is pretty much immune to memory leaks, memory corruption and a host of other problems caused by other threads of execution in the same address space
ROFL. Threading (basically calling a function) more complex than writing client/server processes? We're back to asking you why you believe that somehow, different threads of execution have no need to be associated with the address space of another thread of execution even though different functions do.
I'm pretty tired of talking to someone who clearly has no experience with end user apps or modern concurrent and async application design.
You're misreading. It's not 90% of the problems out there, it's 90% of the code in a given program that's synchronous.
I really doubt that.
Take, for example, the process of reading data from a single input source and processing it. With no other input sources to look at, and no processing that doesn't require the data you're trying to read, exactly what can the code do while the read's completing?
That's not a typical modern server or end user application.
You incur the overhead of creating a thread, and then the parent simply blocks until the child thread completes. Less overhead to simply do the read in the same thread as a simple function call
Who was suggesting that we should call functions in a seperate thread when the operation is synchronous? My example was an example of how silly it was for you to state that a shared address space between async operations weren't needed.
You incur the overhead of creating a thread, and then the parent simply blocks until the child thread completes.
I would think someone with your experience would know about something as basic as thread-pooling.
Most of a program is like that: the caller can't proceed until the function it's called returns it's results, so running the called function in a seperate thread doesn't actually result in any parallelization
That most programs today aren't GUI applications where the UI should not be *blocked* whilst some request is processed? Even something as basic as IO can easily be made asynchronous as there is almost always some post processing to be done after a file or part of a file is loaded into memory that can be done whilst the next block is read.
Most of a program is like that: the caller can't proceed until the function it's called returns it's results, so running the called function in a seperate thread doesn't actually result in any parallelization
Sounds like you need to be more creative in how you design your applications. Most modern applications aren't top-down flow chart style processes.
As for the first part, as I noted a lot of "shared" memory is read-only as far as the child's concerned. The only real issue with seperate processes is the potential for a massive memory split if one process suddenly updates the majority of that "read-only" memory (eg. reloading of configuration data). Where you have lots of memory shared that doesn't involve pointer-based data structures, shared memory will get you what you need without the need for fully-shared address space (which means your various processes are protected from heap corruption by their siblings, among other things). There are times you need the entire address space shared, but IMHO they aren't nearly as common as they're made out to be and the problems of fully-shared address space are well-known and not insignificant.
Again, I totally disagree. I find your idea that 90% of the time, different threads of executation don't need to execute in the context of a shared address space to be rather bizarre. Perhaps it's because you've spent so many years programming with processes rather than threads.
As far as why you don't make every function a process, for the same reason you don't make every function a thread: the vast majority of a program is not parallelizable. Parallel threads of execution, be they threads or processes, are applicable when the parent can fire off the child and go do something else while the child executes. If the only thing the parent can do at that point is wait for the child to finish, it's more efficient to simply do a call within the same thread of execution.
You missed my point which is that functions share the exact same address space because it is useful and there multiple threads of execution have the exact same address space for exactly the same reasons.
I find it astounding that someone can think that 90% of the time, a single address space only needs one thread of execution.
What kind of applications have you been writing the last 25 years?
Forked processes do share memory (at least until it's modified).
That's not what I meant by shared. That's just copy-on-write memory copied memory and only 'shared' for the purposes of saving memory.
Maybe you're writing a different class of applications, but I find threading extremely important. There are many classes of problems where you want to go off and perform a task asynchronously whilst you continue doing something else. I don't think an animation or maybe some blocking IO should require spawning a another process.
It's not about using memory for data communication, it's about using memory for sharing or resources. Like I said, if using seperate processes were so great, why not just write every *function* in your program as a forked process and use IPC and shared memory?
Hence NT needed threads to provide a faster alternative to processes, while Unix (whose processes were almost as cheap to create as NT threads) didn't really need threads
You make it sound like they added threads cause they couldn't get processes fast enough which is absolutely false. Threading and asynchronous IO were a design *feature* not an after thought.
while Unix (whose processes were almost as cheap to create as NT threads) didn't really need threads for anything other than a marketing checklist (about the only thing Unix threads get you that processes don't is fully-shared address space, and I'd argue that's often more a problem than an advantage).
Threads are suprior to forked processes in many ways. If you don't think having all the process memory shared between threads is important, why bother having memory shared between different functions? The fact is that the need for multiple asynchronous operations to occur within the context of a single memory space is not only useful, but very important in modern day applications. There are cases where isolating memory is good (for security) but there are just as many cases where having isolated memory is a pain because suddenly you've lost the usefulness of the native language (C in this case) and have to resort to using mmap and other system calls just to share and pass data.
Islam has nothing to do with these rioters. If they were white, would we say it's because of christianity? These criminals are not muslim.
No cause there are hardly any white christians in France anymore.
Would you care to explain why these rioters are running around yellow "Allah Ackbar"?
Ofcourse, they only condemned "blind" attacks which makes it pretty useless a fatwa since the youths certainly don't think what they're doing is blind (and the 'official islamic body' knows that). The wording works to their advantage and people like you coo when they say it.
I don't know about this particular vulnerability, but MS's
Actually, it's mostly interop over existing windows apis (not com). System.Drawing is based on GDI+ which is a C library.
Um no. Static in Java merely means the class doesn't have an implicit reference (and binding) to the outer instance that created it.
Microsoft muddied the whole issue by not having inner classes (only nested classes) and then by introducing "static" classes which have a totally different meaning from Java static inner classes.
Interestingly, Microsoft did fix that when they designed C#.
It *might* be interesting from the perspective of loading a file (e.g. buffer.append((char)in.read());), except that the IO streams provide Integers to get around the sign problem.
I think you mean readers provider integers to get around the problem. Streams only read bytes whereas readers read chars (which may consist of one or more bytes depending on the encoding).
I think the point we're clashing on is that you don't realize your original post insinuated that the Chinese are multiplying like horny rabbits, and that they shouldn't pollute any more than the US, even though they have way more people.
That's all in your head, not mine.
The US has a large population because it has historically had very open immigration and a huge number of willing immigrants.
I never said that China shouldn't pollute more than the US. I'm saying that Kyoto quotas, if anything, should be based on land mass (or maybe productivity) *NOT* on population size.
However, my personally belief is that Kyoto is flawed. China can pollute as much as it wants to. I don't really care and don't believe they should be allowed to pollute without consequence *at the expense* of countries like the US simply because they're "developing" and have more people. Most countries that are smart have developed their own measures for environmental preservation (the modern environmental movement was born in the US).
I guess reading comprehension and the ability to write goes hand in hand. If you learn to write, I will consider replying to the rest of your diatribe.
1) China is developing at a rapid pace -- if things continue on the present course they'll be the worlds biggest eco-disaster no matter what scale you measure by... probably in as little as a generation or two.
Well duh.
2) If everyone in the States multiplied until there were more than a billion citizens, and if the lifestyles remained as they are now, then the States would be an even bigger eco-disaster than China might ever hope to be.
Well duh.
or at the very least that 1.3 billion people aren't allowed to pollute more than the us, which is more than 4x smaller?
That's so stupid I didn't even think it needed a reply.
Who is saying that they're "not allowed to polute more than 'us'". If you recall, the US didn't ratify Kyoto -- the treaty that dictates who can pollute and who can't.
You're the kind of person who thinks that the couple who live confortably because they choose to only have one child should have to pay for irresponsible couple with 7 children living in a trailer park.
Agreeing with the other two posts about China's birth rates even being BELOW sustainable growth. They are actively enforcing a one child limit policy, and yet you're touting that the Chinese are having babies like fucking crazy, or at the very least that 1.3 billion people aren't allowed to pollute more than the us, which is more than 4x smaller? And still get modded insightful for it? You're an ignorant fucktwit.
Everyone knows about China'a one child limit (which has recently been changed BTW). It has nothing to do with that you "ignorant fuckwit".
It has to do with population size. America has a smaller population and they would need to "breed like there's no tomorrow" in order to get a high population size (like China).
Use your brain next time.
China's population "growth"-- their birth rates are below sustainable and therefore also below ours
Their birthrate is irrelevant. It's about their population size. Other people got it, why didn't you?
I am a nation of one. That is, I am the nation of Bert. I pretty much rule, because I'm the only fellow around. I thoroughly enjoy both dumping oil into the ocean AND eating dolphin steak. I enjoy these activities so much that I indeed match the absolute pollution levels of the US. Clearly, I am a much worse polluter than the average american (who shares his or her polluting mischief with about a quarter billion other people). It is way more reasonable for a nation of a billion people to throw a billion styrofoam containers away, than it is for one person.
If the goal is to reduce polution on the planet, it should be based on land area. We are talking about a treaty between *countries* and not individuals. A nation of one million people with the land mass of America, under Kyoto, *should* be allowed to pollute just as much as nation with the same land mass and one billion people. Perhaps it'll encourage the country with one billion people to consider sustainable growth....I guess that nation has....
How the HELL do you get modified insightful for making such a blatently false statement?
Perhaps because the point flew over your head?
It's not about the birth rate, it's about "per capita" quotas. The chinese clearly see the light so have restricted (by law) population growth (and did it long ago).
Let's talk per capita. Because that's really what matters
Why?
Perhaps the Americans should have babies like there is no tomorrow so that they can "legally" pollute more, have higher levels of poverty and then complain that the rest of the world won't support them.
The internet is an extreme communist network
No. The internet is based on the foundations of the American ideal. Freedom & liberty. The internet works because individuals and companies formed by coalitions of individuals freely *choose* to be part of it.
Notice that on the internet, everyone is *NOT* equal because in real life no two people are equal. Everyone/webiste/whatever has value based on how society (not a central authority) judges it. The only way to have a communist society is to treat everyone differently so that it all evens out. That is unfair, immoral and corrupt and why communist systems always fail.
Simple common-sense tells you that Islam is not about to sweep across Europe
Ha. Famous last words.
Microsofts methodics are plain stupid, because for everything you want to do you have to specify it so explicitly my fingers still hurt last time I tried it.
Java:
obj.SetValue(obj.GetValue() + 1);
C#:
obj.Value++;
Java:
public class C
{
private List listeners = new List();
public void addOnSomeEvent(ActionEventListener l)
{
listeners.add(l);
}
public void removeOnSomeEvent(ActionEventListener l)
{
listeners.remove(l);
}
public void fireEvent(ActionEvent e)
{
for (Iterator = listeners.iterator(); iterator.hasNext();)
{
((ActionEventListener)iterator.next()).handleActi
}
}
}
someobj.addOnSomeEvent(new ActionEventListener
{
public void handlActionEvent(ActionEvent)
{
doStuff();
}
});
C#
public class C
{
public virtual event EventHandler SomeEvent;
protected virtual void OnSomeEvent(EventArgs e)
{
if (SomeEvent != null) SomeEvent(e);
}
}
new C().SomeEvent += delegate { doStuff(); };
Yeah...I see what you mean
You attribute those deaths to halliburton so do you consider the deaths of millions due to corrupt government and dictators who implement sociliast economic policies accountable too?
Yep, that was IMHO, one of the biggest breakthoughs with the tablet pc platform. Searching handwritten notes is more accurate than searching notes converted to text because "close looking matches" can also be returned.
I pretty much get 100% accuracy with my search results with the occasional negative (wrong result cause of similar looking words).