This message was edited by 684867 at 2004-11-19 10:16:22
This message was edited by 684867 at 2004-11-19 10:2:22
*********************************************************************
Reply to Point four:
: : Point taken. Memory management is a serious source of bugs.
That is true. However, there are times when I have problems
giving up control. Perhaps the compiler should allow garbage
collection to be turned on or off depending on the programmer's
desire (possibly using a directive?). This would allow smaller
projects to avoid the overhead, yet permit larger projects to
benefit from the safety of GC.
R: I believe that C# allows for both managed and unmanaged code. When
you are executing managed code, you get GC, no free pointer
arithmetic and so on. When you are executing unmanaged code, memory
management is your responsibility. I'm not sure on the details of
how it implements this - I guess you'd have to suspend garbage
collection while unmanaged code was being executed. Then you get
into the fun of doing calls from unmanaged code into managed code.
If you want to go down the allow both track (which to me seems a
good idea - I'd prefer it to things like JAVAs JNI) then looking at
the semantics that C# has may be worth doing.
*******************************************************************
Rebuttal on Point Four:
C# and Microsoft manage code through an interpreter. They limit the power of the C language (which means nothing is really a native binary anymore, and only MS software runs as fast as the op/sys can--everyone else is slower).
That is bad business. I want to write a language and compiler that allows the low level access C intends and the high-level stability application programmers require. That stability is not in the managed versus unmanaged code thinking of Microsoft. It is in the development of compilers that can be configured to produce code to the developer's specifications and a loader/executor that can safely launch a binary within specified parameters.
Eventually I would like to see coding minimized to the low-level and special needs moments, while most development is conducted through CASE tools. Graphical development environments which allow components to be assembled as lego blocks rather than klocs of code will reduce the probablility of error. ...as will IDE's that are capable of analyzing the code produced low-level and by CASE to identify problems.
Besides C# does not implement its solution with elegance. MS is in this for the money...not quality. That is why I break windows and love penguins, my friend.
*******************************************************************
Reply to Point Five:
I think there may be a subtle difference between finalizers and destructors, in that calling of destructors is a certainty, whereas a finalizer may or may not get called. This certainly matches my experience - Perl's destructors are always called, but in JAVA whether your finalizer gets called is down to the JVM and there are no promises that it will be. See here:-
:
http://portal.acm.org/citation.cfm?id=604153
*******************************************************************
Rebuttal on Point Five:
What is the point of writing a destructor or finalizer if there is no guarantee it will execute as you expect (hope?). That is bad programming. Whoever creates such an abortion should be dragged across the countryside by their entrials--or just mocked as an idiot.
I make enough faux pas in my life. This will not be one of them.
A destructor will execute as the object is released.
********************************************************************
Reply to Point Six(1):
R: I was arguing against free pointer math. I think if you:-
(a) Force all memory access to be done in an array style
notation
(b) Do bounds checking
You'll be enabling people to write much safer code than it's
possible to write in C/C++ today.
: I disagree. array notation can limit the control and power of the
: programmer within his code. How can I create objects that alter then
: call what first appears to be data, but is really code, without a
: pointer and the abilities of pointers "C" gives us.
: : How often do you really need to do this? You need to be
: :doing something fairly low level to need this, like writing a
: :JIT compiler. Also, memory that you want to do things like this
: :with these days needs to be marked as executable, or if it doesn't
: :now will in the near future.
:
: :I think one thing that it'd be nice to find a way to do is to be
: :able to acccess an array of a certain native type (e.g. ints) as if
: :they were another native type (e.g. chars). With C you just cast
: :the pointer. That's desirable and useful, but I'm not convinced
: :something safer can't be developed to do the same thing.
: :
***********************************************************************
Rebuttal to Point Six(1):
I am against the concept of marking memory as executable/non-executable. Memory should be allocated then left tabula rasa for the developer. Remember what I am looking at here is complete system level work. I am creating the paradigm.
To hell with MS standards.
What I do sometimes is create an algorithm that mutates during execution to serve multiple purposes in less memory. This requires some processor cycles but saves the amount of time that the CPU must take to access virtual memory because my code maximizes its memory. I would love to see components under CBOOP do more of this.
***********************************************************************
Reply to Point Six(2):
I think one thing that it'd be nice to find a way to do is to be able to acccess an array of a certain native type (e.g. ints) as if they were another native type (e.g. chars). With C you just cast the pointer. That's desirable and useful, but I'm not convinced something safer can't be developed to do the same thing.
***********************************************************************
Rebuttal to Point Six(2):
Good Point. But doesn't this negate the idea of strong typing. Usually programmers who perform casting are comfortable with pointers. Those who use arrays are doing so to avoid these issues. what about memory sizes. A char is now arbitrary. I still think of a char as 8 bits. Some now use DBCS, where a char is 16 bits. Translation of an integer (8 or 16 bits?) into a char (8 or 16 bits) may cause more problems than it is worth. But is a new type of power for the coder, thus it is an idea to consider.
Programming should be free and open for creativity.
***********************************************************************
Reply to Point Six(3):
As for function pointers, nice idea, but again they can be made safe - e.g. delegates. Mutlicast delegates are also a pretty cool idea.
Maybe just allow raw pointers in unsafe/unmanaged mode and force delegates/references in managed code?
***********************************************************************
Rebuttal to Point Six(3):
How would you implement this in C syntax? Remember the language must remain consistent unto itself.
***********************************************************************
Reply to Point Six(4):
: Safer code comes from good style and patient, methodical planning.
:
True, but even good programmers do make mistakes and it's nice if there is something there to catch their buffer overrun error that would otherwise overwrite stuff on the stack and cause all kinds of "fun".
It occurs to me that we'd have avoided this problem greatly if we'd put the stack near the bottom of the virtual memory space and had it growing up, then grown the heap downwards. Not sure if that brings up other problems I haven't thought of, though, which is probably the case.
***********************************************************************
Rebuttal to point six (4):
Slammer is the greatest reason your concern is not new to me. I do not want to continue to open these type of doors. If an object is issued memory, then it must have its own address range. An object must not be allowed to rape its neighbor. Nor must a component be allowed to do so. If an array is declared and pointer access is allowed then there is the potential for problems. But a good compiler should analyze the code to estimate its probability.
No matter the case, additional overhead must be avoided at all costs. We want better graphics and power, not useless overhead.
Memory checking (as you point out) will do nicely here.
