Shamil Salakhetdinov
shamil at users.mns.ru
Fri Aug 19 15:28:29 CDT 2005
> the crash I described can > even happen when you just begin to type on a line while the program is > at a breakpoint. They probably reuse some MS Access 97 interpretator code - just kidding :) Seriously they had similar problem in MS Access 97, in MS Access 2000 it was better, in MS Access XP/2003 it's even better but they disallowed to save modules in MS Acces while debugging in "Edit & Continue" mode. MS Acces 2003 is still crashing in complicated cases of "Edit & Continue" and you never know when... (And in MS Access 97 it was exactly like you describe - as soon as you start typing it crashes. Another famous problem when the last edited line of "Edit and Continue" mode in MS Access 97 was lost etc - never believe them! In fact eXtreme Programming is an answer here too - XP doesn't need Edit and continue development mode... > Granted, this was a little bit > ago and they may have made improvements to the obfuscators now. I did use/try several obfuscators this spring (April) - the best of them make code absolutely unreproducable I think. After tests my customer decided that Xenocode in standard mode ($99) is good enough. >If you search the MSDN docs you should >be able to find easy ways to build this implementation in. OK, thanks, I will read about that... > restricting you from a common easy error, but at > the cost of speed and efficiency. But if the code doesn't have custom memory allocation/deallocation calls i.e. it uses garbage collector like .NET then by definition it should be more efficient - right? Or do you mean that .NET garbage collector is slow? > In the example of the garbage collector: It is unnecessary to use the > collector if you manage your resources of your classes and code > properly so that you do not leak any resources. Well, the cost to manage resources properly is high - I did do that in MS Access 97/2000/XP/2003 and VB6 and in C/C++/Delphi. Automaic intelligent garbage collector is a real "life saver". Of course in complicated cases one has to force resources deallocation - .NET has IDisposable interface for that as it's well known.... > I wasn't trying to promote the .NET as a restrictive language. I was > trying to state that MS and others can make framework seem more > flexible and easier to maintain, but that the same effect can also be > achieved by good coding practices and software design policy. We probably talk about different subjects here - when I asked "how do you will restrict the quantity of attributes and methods of a class using good coding pratices and software design policy?" (this is what happening "automagically" when one uses XP and classical behavioral OO design and development) I meant that there is no probably any other good coding practice and software design policy except XP, which allows to do that so flexibly and almost seamlessly - of course this work needs really "high pilotage design & development experience" - I'm not there yet, rather far from there I think.... Whatever else good coding design practice and software design policy one invents they inevitably go XP way - that's what I meant.... As for .NET Framework vs. something "home made" - I'm not MS advocate but I'd say that programming in VS.NET is like a "dream come true" - finally, after 20+ years of my programming experience... Shamil ----- Original Message ----- From: "Josh McFarlane" <darsant at gmail.com> To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com> Sent: Friday, August 19, 2005 10:40 PM Subject: Re: [AccessD] OT: Why did Mac switch to Intel revisted > On 8/19/05, Shamil Salakhetdinov <shamil at users.mns.ru> wrote: > > Josh, > > > > Do you mean VS.NET 2005 Beta 2 when you talk about Edit & Continue feature? > > You guess they will never be able to make it stable? (they managed to do > > that with VB6 and even in MS Access 2003 (although both VB6 and MS Access > > 2003 still may crash unexpectedly in complicated cases) - they will probably > > make it working stable somewhere in not that far future? No any hopes you > > think? > > Well, I'm using it mainly in reference to VC++, and having tried it on > VS.NET 2002, 2003, and now 2005, they all have inherient crash issues > even when doing simple things (for example, the crash I described can > even happen when you just begin to type on a line while the program is > at a breakpoint. > > > By using reflection I mean injecting specific attributes BEFORE Just-in-time > > compilation, just as one of thr possible ways to do that, in fact it will > > not be needed probably because attributes will be inline with the source > > code... > > Ah, I misunderstood you there. > > > Did you try any of obfuscators or other methods to protect compiled code > > from reverse engineering? - I did - and I found they are good enough even > > the cheap ones, and expensive ones are very good. > > I've tried a few different ones, and while some parts of the code > would be obfuscatied, core components such as algorithms were still > semi-reproducable in some test cases. Granted, this was a little bit > ago and they may have made improvements to the obfuscators now. > > > I have heard they made good progress with ATL in VS.NET 2005. But I can't > > judge here because I do use ATL a few. > > I didn't know that much about prioritizing threads to logical processors and > > HyperThreading. > > Basically the way the multicore processors work at this moment (at > least to the current library of MS code) is that they are just treated > as hyper-threading processors. If you search the MSDN docs you should > be able to find easy ways to build this implementation in. > > > > "Good software design policies" if I got that correctly is a very broad term > > Do you mean they can restrict also the quantity of attributes and methods of > > a class? If yes - could you please post an example of such software design > > ploicy here or give a reference to it, which also shows that it worked in a > > real life project? > > Well, the classic example I like to use is the garbage collector. > Normally in C++ you handle allocation / deallocation of objects on the > heap yourself. In managed C++ with .NET you can use the garbage > collector so you don't have to worry about memory leaks from heap > allocated objects, restricting you from a common easy error, but at > the cost of speed and efficiency. > > I wasn't trying to promote the .NET as a restrictive language. I was > trying to state that MS and others can make framework seem more > flexible and easier to maintain, but that the same effect can also be > achieved by good coding practices and software design policy. > > In the example of the garbage collector: It is unnecessary to use the > collector if you manage your resources of your classes and code > properly so that you do not leak any resources. > > Microsoft seems to be taking the approach towards creating an > easier-to-use interface (.NET) and it seems that the more default > customizable interfaces are being left in the dust because of it. > > -- > Josh McFarlane > "Peace cannot be kept by force. It can only be achieved by understanding." > -Albert Einstein > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com