So, the only way you judge an applications security is that it has a
history of being secured? Or do you call an application secure when you
don't update it? I fully trust a lot of applications i use, or i
wouldn't have em installed, but i still wouldn't put it past them to
have an easily exploitable security hole.
GetPixel() and SetPixel() have to be used for some
purposes, but so far
I have never had to use them in performance critical code.
Unsafe code is another thing to stay away from however if end users are
to enforce in-house restrictions based on security claims made for .Net.
By "natively" (in the .Net sense), you mean the
code runs in an
environment which relates to the native system. IL *does not* compile
into native calls of the OS.
No, what i mean is that the IL is compiled to native code and that
native code is then executed. Therefore the application is "native"
when it is executed. You are not interpreting IL on the fly.
.Net implementations on Windows are far slower
than their
native-compiled counterparts. Some claims are made that .Net math
operations are something like 80% as fast as native operations, but
these claimed cases are only possible if no boxing or unboxing are
involved. Still, that's a substantial performance disadvantage. But if
of course any boxing or unboxing are required, then of course the
disparities are going to be huge.
I think i've managed to avoid unwanted boxing in pretty much every
program i've written in C# except in cases where i didn't care enough
to write the code needed to avoid boxing, for example methods which are
called two or three times in the lifespan of the program.
There are net
BrowseForFolder dialogs in Visual Studio which, on my brand new Vista
system, take 9 seconds to display file content. This is a huge delay,
and something I certainly would never care to suffer in my own
applications. The early days of Delphi 1 had dialogs which were
instantaneous on Win95. So many years and orders of hardware efficiency
later, to suffer these delays is to me, incredible.
Generally speaking, i get a BrowseForFolder dialog to appear within
milliseconds of clicking on the required button. Your system may need
to be checked up. It's no flaw in .NET or mono that your system is
slow. It may be worthwhile checking for malware.
Well thanks for the tip, but imho, "managed" is
quite an overstated
virtue or advantage. Few C# developers probably truly know for instance
what the best way is to implement dispose patterns. There is
conflicting information on it. Visual Studio doesn't agree with
Richter. Richter doesn't agree with another source I rely on. Then
again, how many can expertly reply when and how to implement finalize?
Once again, that's not an isse with the .NET framework. I can argue
much more usefully that there are a huge number of developers in C/C++
who can't write code that doesn't leak. It's much much easier to do
that in C#. All you do is override the finalizer in any class that
holds unmanaged resources. Thats when and where.
What was the ostensible technical challenge
implementing Free or
FreeAndNil in C++Builder or Delphi? There was no challenge or mystery
when and how to use them. When you freed an object the memory was
instantly available to other processes. FreeAndNil obviously freed the
memory and wrote null/nil to it. When you wrote an aggregate
component/class, you routinely moved to your destructor and freed
subcomponents in the reverse order you created them. These things were
routine.
Now you don't need to do that. Funnily enough quite a lot of
programmers can't get this write. The reason is that objects can have
quite complex life cycles. Quite a lot of time is wasted getting this
right whereas with a managed language you can forget completely about
this kind of issue. There is always a challenge in making sure that
your objects are free'd correctly under all circumstances.
What is the ostensible advantage of ForEach?
Underneath your call to
ForEach is an iterative process which has to make the well known,
routine call to iterate count minus 1. The same thing has to be done.
Yes, but it's *nicer*. It's syntactic sugar. There's no point to it as
such. You could just as well argue that we don't need a "for" loop and
a "while" loop because they both do the same thing. One of them could
easily replace the other.
There's nothing managed for you at this level. If
the count changes
before iteration is complete, the only thing you can hope to account
for that is the compiler
No, you'll get an exception as it's illegal to modify a collection
while iterating over it. You will find out very quickly if your
collection is modified when enumerating over it.
Now, if you're trying to tell me MONO runs as fast
as Cocoa on OS X, I
can be made a believer of that part of your assertion. "Managed" code
little convenience -- but in many cases it certainly is one. In the
case of dispose or finalize patterns, ambiguities can lead to further
problems, and incomplete familiarity with these ambiguities can lead to
inferior design and poor performance.
Cocoa is a programming environment, not a language. I believe you mean
"Objective C". I never said that managed languages ran faster than
unmanaged ones. Once again, you can't blame Mono or .NET for the
programmer mis-understanding the Dispose or Finalize pattern. It's not
ambiguous, It's a fairly simple concept, much simpler than pointers. Of
course, if the programmer was equally unfamiliar with C or C++ i'm sure
they'd write even worse code than they would in C# ...
If we have to breech the barriers of ostensibly
"safe" code to *hope*
to achieve ostensibly comparable speed, hardly is it the case then that
.Net delivers what I consider to be acceptable performance. Your
remarks about GetPixel() and SetPixel(), I take to be agreement.
Nope, i never once mentioned unsafe code. GetPixel and SetPixel are
slow as there are several layers of indirection involved in getting the
actual data. The lockbits method provides a way to get at the actual
data, copy it into a managed byte[] and then in managed code, access
that array as you wish. Of course you *could* use unsafe code and
pointers if you wanted to, which would be slightly faster.
As to your final remarks, you do not understand
me. Assemblies call
into .Net libraries. What I am proposing is to map those calls into
libraries supporting the .Net calls, but compile the output into native
calls into the operating system -- using native OS dialogs, whatever.
C# compiles into native code when run. What you're talking about is
writing an implementation of .NET which is just a thin wrapper around
native OS calls, which is what i was asking earlier.
I won't have my users waiting 9 seconds for a
BrowseForFolder
or BrowseForFile dialog to display content. I would even anticipate
getting support calls for that.
And i'd laugh if you did. My system can manage to display a
FolderBrowserDialog in about 250ms (give or take). I think that's
perfectly acceptable.
Using managed languages removes the need to worry about memory
management. You can never have leaks. If you need to access unmanaged
resources then you have several good patterns for safely disposing
them. If someone can't apply those simple patterns, then they haven't a
hope in hell of managing their own resources in C/C++. You also gain
type safety, array bounds checking and misc other things.
What it also gives you is slightly higher memeory usage and slightly
slower code. If anyone tried to write a commercial video encoder using
pure managed C# i'd have to laugh at them. It'd never work. If anyone
said they were writing a new enterprise GUI application in C, i'd laugh
at them because i could write the same GUI in half the time with half
the bugs in C# simply because i don't have to worry about memory
management issues and i have a rich API at my disposal. This gives me
more time for bug quashing and feature extending.
So, if you can stand the performance reduction as compared to C when
balanced against the productivity gain moving to C#, then use C#.
Otherwise use your native language with the benefits and pitfalls it
entails.
Alan.
