Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Nokia (NOK) -- Ignore unavailable to you. Want to Upgrade?

To: Quincy who wrote (21120)	7/10/2002 7:48:31 PM
From: 49thMIMOMander	Read Replies (1) \| Respond to of 34857

Did you ever look beyond the C-code at the assembly, figure out why the pointers you manipulate were not allowed in Fortran, and not even in a pure C++ program?? Why not just write hubbadubby = malloc(5Byte) abbadubby=hubbadubby + 4 ; (pointers, whatever way you define it) wait for all memory to get defragmennted, moved around, and try to access abbaduddy - 2, instead of hubbadaddy + 3?? (ouch, plus minus one, or something similar) Compared to Fortran "descriptors" of Hubbadaddy[5] and Addabubby[3-5}, ouch, that already told you not to do it. (Fortran descriptors defined starting point and lenght, and the programmer only the where to access, C++ supports that too, but not only that) Much like Hubbydaddy.abbaduddy.get(oldguy-4), giving some chance for the compiler to catch whatever you are trying to do, and even for the operating system to move it all to another place in memory, to keep the footprint defragmented. More important, and in general, there is little need for the hupper-level programmer to know at what absolute adress his hubbadaddies are, just like in Fortran and Basic, who knows where the operating system moves them when every now and then packing up the memory?? Anyway, huppyduppy that MSFT has introduced both fortran descriptors and basic string handling, but not yet really handling the memory holes, the taks fo the operating system. Ilmarinen The magic of crash-and-bloath to mishandle java is another story, much more on the destructive side. I still remember the 3 days it took me to rewrite one of my old C program to make in totally indifferent to any stupid mallocs I had made. Assembly is obviously in another universe, they should never meet, except through a decent operating system. That is - compiler catccing the worst bugs (in debug and not-debug mode) - operating system able to move around, defragment memory, and the stuff still works after that, add the capabilty to do some real-time stuff, predicatabilty and priorities

To: Quincy who wrote (21120)	7/10/2002 8:12:55 PM
From: 49thMIMOMander	Respond to of 34857

That it, it should be left to the assembly guys to write the really tough stuff, handle where the stuff really is in memory. The upper-virtual-floor guys should not have a clue about all of that, or at least not have a chance to cut any corners nor remember where they dropped their underwear half a year ago. This makes it possible for the mom-operated housekeeping system to clean up the footprint without divorcing both husband and boys. Ever wondered why Win-Doze gets slower and slower, worse and worse, the longer you use it without a reboot, the more underwear there are dropped all over the memory, which nobody should move in case they are needed, and no way of telling the original wearer where they have been moved. (Fortran did not have that problem, a[5] is/was always they same, fifth element where-ever it was moved, cleaned or dirty) Funny stuff, like MyRidiculosBloathingClass::FinDtheElementSpecifiedWithinParenthesis(5) { return = (private pointer) base + 5 ; } Skipping the deadly * and &, which 99% of C-programmers still do not understand, and especially how the compiler is told to interpreste them (preprocessor and compiler directives) Ilmarinen Funny stuff, this BREW runtimebunnaries...