Hi Attila, I wouldn't worry about not being able to see the assembly code while debugging. In practice, there is less need for debugging Java or C# code than with C++. For example, in C++, out-of-bounds array writes and incorrect type conversions can give rise to bugs that are hard to find, because the effect may be felt some time after the cause (e.g. the out-of-bounds array write corrupts some data). In Java or C#, the runtime system catches this sort of bug immediately.
My company uses a code generator that can generate either C++ or Java. Although the production version of the products we ship are built using C++ code, for development and initial testing we generally use the Java code because bugs are caught much earlier. The performance improvement you can get from using C++ rather than Java or C# is significant only if the program uses really huge amounts of CPU time, in which case you might be able to make a case that the hardware cost saving outweighs the higher cost and time to develop in C++ rather than Java or C#. Otherwise, for application-level programming, Java or C# would generally be a more productive choice. Regards David Crocker, Escher Technologies Ltd. Consultancy, contracting and tools for dependable software development www.eschertech.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of SZALAY Attila Sent: 09 November 2006 11:20 To: [EMAIL PROTECTED] Cc: Secure Coding Subject: Re: [SC-L] Could I use Java or c#? [was: Re: re-writingcollege books] Hi All, On Thu, 2006-11-09 at 10:20 +1100, mikeiscool wrote: > > You can definately get appropriate information via the stack trace > with java's exception handling. It's strange to see you say debugging > is _eaiser_ in c, typically people find it far easier in a managed > language :) People are different. :)) I personally want to know what happens and I don't believe anything waht I can't see. In C I can see the assembly code what (I hope) is a deterministic thing. An interpreter is to big (to me) to think about it as a deterministic thing. And yes, with ``normal'' bugs a managed language could give me more possibility to find the place of the problem. But I want to hope, that we don't commit normal bugs. :) And with mysterious bugs, when you cannot reproduce it in a test system, just the costumer some hundred miles away, I think that the stability of the compiled code (and the core file what may created) is give more more chance to find the right place. > That's a java applet; please don't judge Java the language based on > applets; they are a really bad representation. Serverside java will be > very effective and useful; what sort of client are you writing? Is it > a website or a desktop app? Even if it's a desktop app, perhaps look > to azureus to see a good, well running app written in java for the > desktop. There are others. This is a desktop application in a client-server model. I will look after azureus. _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
