On Mon, 28 Nov 2011, Debdatta wrote: > >>1. Your variables are thread local. This guarantees some nice > >>properties, like code that was intended to run in a single-threaded > >>environment when it was written will behave nicely in a multi-threaded > >>environment too, because every thread gets a copy of all global data. > >>This is a sane default. > > Now I understand your reasoning a lot better. :D this is one case where D's > defaults will come very handy. Its very different from what I have seen > so far, so maybe its a culture shock. > > >>There is one to one feature correspondence. > > Of course. That is obvious.:D It just seemed counter intuitive to have every > variable I declare to be thread local. Will experiment with it some > more and see if I can get used to the concept. You seem to have very good > reasons to prefer it, and I hope I can see them too. :D > > -Debdatta
If _most_ of your variables are thread local, then I think you might well be doing something wrong. Since that means that you're using a lot of what would be global variables in C/C++. In my experience, MOST variables are function scoped, and thus stack variables. My 2 cents, Brad
