flat assembler
Message board for the users of flat assembler.

Index > Heap > Interesting reading about C++

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Perhaps I am in error, but, in my opinion, most applications requiring some kind of sort algorithm work on a FINITE list of objects to be sorted. How can one sort an infinite sample? If the quantity is finite, by definition, it is possible to QUANTIFY the list. Quantification in turn, renders pointers redundant. If one does not know the size of the data to be sorted, one guesses, and OVERESTIMATES, if necessary, by a factor of ten. OOH! Horrors, wasteful of all that memory!!! Ah, help, there's a mouse in the house. What will I do??? Tom is wasting memory---eeek!
Pointers make sense in an architecture designed to MAXIMIZE the capabilities of a MODEST amount of random access memory. It is the solution to a problem which no longer exists, not too different from the situation 130 years ago, when electric lights began replacing the traditional, kerosene lanterns. Imagine someone who had developed a really nifty method of remotely igniting a kerosene lamp 4 meters off the ground, without depending on a scaffold, chair, or ladder. What's the poor fellow to do, when some guy comes along and proclaims kerosene lamps useless? Many programmers are accustomed to writing CODE with pointers. They find the "opportunity" to use arrays instead, to be a nuisance, not an advantage. But, for a STRUCTURED design, based on a blueprint, not an impromptou spiel an der klavier, nothing beats a READABLE data structure. Pointers to pointers to pointers guarantees longevity and financial support for the "systems" programmer, as the original, very realistic submission to this thread suggested. While it may have been entirely tongue in cheek, and falsely attributed to the author of C++, I thought it was an accurate portrayal of both C++ and the nonsensical "object oriented" debacle. The best program is the one that anyone can read and understand. Pointers guarantee inability to follow what someone is trying to accomplish. Pointers may well have been a necessary evil forty years ago, when one megabyte of RAM was beyond anyone's wildest imagination, (my first RAM purchase, in 1976, in Deutschland, was 128, not 128K, just plain 128) but today, one can sort a whole encyclopedia from a conventional desktop computer equipped with the customary gigabyte of ram. The pointer today has the same utility as the remotely operated kerosene lantern ignition controller.
Smile
Post 14 Feb 2006, 22:32
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2145
Location: Estonia
Madis731
I do agree with you. And the fact that we had an assignment in school that involved pointers proves, that there IS NEED to LEARN pointer and they are NOT easy to grasp. I did it and lot of my classmates did it, but it wasn't easy.
I think nobody grades a pupil for an assignment where you have to Dim your way through the code. "Dim x(10)" Very Happy Yeah! I did it!. Pointers are tricky and this is why they grade you Smile

Perhaps too tricky if you ask me Sad because of the abstraction. I had to insert INT3s into the C-code and debug before I knew what was going on. Oh, and what horror the C-code brings. Stack is its friend Wink
Post 15 Feb 2006, 08:16
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
vid
tom tobias wrote:
Perhaps I am in error, but, in my opinion, most applications requiring some kind of sort algorithm work on a FINITE list of objects to be sorted. How can one sort an infinite sample?

You need to differentiate between INFINITE and UNKNOWN size of input.

Without pointers (unless you use some REALLY high-level language) you need to specify some maximal size of input so it can fit into statically declared buffer. Then it won't be able to handle bigger inputs, even if computer has enough memory to handle such input, and it won't run on system with less memory, even for inputs which don't require such big amounts of memory?

Really, how would you sort lines of std input and print them on std output, without using pointers? Show me some (pseudo) algorithm please.
Post 15 Feb 2006, 09:07
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
This thread began with a wonderful satire suggesting that the oft-praised "object oriented" programming was largely a hoax, a scheme designed to funnel money into the pockets of "system programmers". From this bit of comedy, we diverged somewhat, to weigh the merits of FASM and Pascal, compared with C or C++. In proposing some potential liabilities associated with Pascal, (obscure pointer useage), Vid clarified his opinion that Pascal lacked several features, of utility to contemporary assembly language programmers. Vid's honest portrayal of a programming language, Pascal, offending his modus operandi, represented the silvery salmon swimming in front of a hungry bear, and I took the bait. For me, Pascal is nearly sacrosanct, not the language per se, but rather, Wirth's ideas embedded within it: in particular his ABSOLUTE requirement to DEFINE data prior to using it, and the RELATIVE goal of compelling authors to follow certain conventions in order to promote readability, at the cost of speed of implementation (and perhaps execution speed as well.) The logic behind this sacrifice of programmer time is the realization that ULTIMATELY, it is the ability of a program to withstand MODIFICATION by someone other than the original author, that demonstrates the true skill of the original architect. Most software is flawed in some respect, often because of an inadequate original design. Modifiability thus becomes crucial, in assessing the potential success of any program.
To answer the question raised in Vid's most recent post: How does one treat an array of data, whether for sorting, or any other manipulation, when the length of the array is unknown? Estimating space needed, (or time required!!) is a bit of an art, i.e. one improves at this task with experience. It is not black and white. However, since Vid is dissatisfied with this suggestion to waste memory by overestimating the maximum size needed for an array of unknown dimension, then I suggest writing a small program to capture all the data in a huge memory, a thousand times larger than the largest possible size imagined, and then, having captured all the data within this huge memory, it is possible to determine with absolute precision, the exact size of the hithertoo unknown array size, and then the original task can be completed, using now the precise, much smaller amount of memory required. Of course, compared with using pointers, this approach wastes time, and memory. That's a lot of sacrifice for what gain? Readability. Yup. Worth reiterating: READABILITY trumps every excuse offered for generation of CODE.
Pointers are FASTER, perhaps in execution, but probably in implementation by the programmer,
Pointers lead to a quicker completion date, because there is less typing, and MUCH less thinking about data structures required. Pointers permit programmers to generate code FIRST, and then, reflect, if at all, on the data structures which their pointers access. Pascal disallows such sloppiness. Pascal, instead, demands that the programmer, like an engineer designing a tall building, FIRST contemplate the nature of the data structures required for the program to attain success, THEN type the code to fulfill the requirements of the task at hand.
Pointers are far more efficient, saving LOTS of memory.
So, if one works with a variety of 1970's era computers when a 4 megabyte upgrade, doubling system RAM, represented a machine of such lofty attributes that it was available to only the most senior staff members at the most prestigious research institutes, then pointers may have some value.
Smile
Post 15 Feb 2006, 14:36
View user's profile Send private message Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2468
Location: Bucharest, Romania
Borsuc
tom tobias wrote:
Hmm, I have rarely encountered a more concise explanation of the elegance, beauty, and POWER of Pascal--unquestionably the best programming language (invention of Niklaus Wirth) to date, vastly superior to C or FASM, or anything else, PRECISELY for the reasons you have provided::
no need for pointers, a relic of days when memory was too precious to waste on fixed assignment for only some PARTICULAR array, at a FIXED location.
Declaration of LABELS, wow. What an advantage for debugging!!!
LONG KEYWORDS, GOSH, something READABLE, can it get any better than that????
I love Pascal. It is precisely that collection of attributes, cited above by VID, ostensibly as NEGATIVE attributes, which clearly differentiates PROGRAMMERS from "CODERS", who need not be concerned about READABILITY, or subsequent MODIFIABILITY, and who, virtue of their enormous prowress, NEED NOT BE CONCERNED about such trivia as debugging---CODERS don't make mistakes.
Smile

I think what you call READABILITY means more easier to understand, doesn't it? Well, it depends on the guy who's reading it, and his experience! I, for example, prefer short symbols, pointers, etc.. For that reason I use C for my 'test' programs (sure, release is usually in asm). And I find Pascal less readable than C or asm (I know it well enough).. why?? because of my experience with C or asm, or because of my styles. I prefer functionality over the look of a language.

This is the same thing as one saying ASM is hard.. well, just because he doesn't code in asm (thus, no experience) doesn't mean it is hard (true, it's a bit harder for 'human' logic, which is kinda flawed, btw). If I, for example, didn't know Pascal, I might as well say 'it sucks', even though it's a great language. Seriously, I don't like Pascal, but I don't say it's a 'sucking' language either, 'cause I know many of us still learn from or are using it, and I let them make their own path, I'm not someone who forces them to hate the language by expressing my opinions, just because I don't like it.. it's a matter of personal style, anyway.

And about pointers -- they are necessary, it's how computers really work or how their flawless logic works (it's not really flawless, since they are designed by flawed humans). If you're being abstracted, that doesn't mean it works without pointers. I don't like these kind of languages who abstract me, since I want to appreciate how the computer works.

Saying that a 20 year old 'design' is useless, is disgusting (at least for me).. I don't say you have to use it (woow, imagine 128 bytes RAM), but it's not like you throw a stick to trash, you know. It's complex, and I just say it should be appreciated, for all it has done. And 'new' doesn't always mean 'better' either.


Back to READABILITY: well, I assume you say more readable to you. Well, from the computer's point of view, they use pointers and they see Pascal or abstracted languages less readable than more low-level languages (i.e C, or even asm). It's a matter of 'designing' your code, not necessary algorithm 'optimization' (i.e it's different if you design something with OOP and then with procedural, NO MATTER what kind of compiler you're using).

And I don't know how many people think in 'my' way, but I PREFER TO THINK IN LOW-LEVEL TERMS, even the high-level code I browse from different sources, I translate it with my mind into low-level code. Thus, I see low-level code more READABLE than high-level (abstracted) code. It may seem than I am farther from human-logic (aka OOP, abstractions, flaws like lazyness or easyness, etc), and closer to computer-logic (aka bits). Computer-logic is not flawless either, since it was designed by creatures with flaws (guess what--humans).

At least I try my best to appreciate the computer (and free it from my mistakes, 'cause I'm a human too, so that's inevitable), but at least I hope when the machines begin to take over (Terminator anyone??), they will show some mercy for me, since I appreciate and 'understand' how they work, not just coding 'easier' for me, but also 'easier' for them (faster). Laughing (just jokin' of course)

The conclusion might be: what you consider more readable is less readable by another (for example, me), and what I consider more readable is less readable by another (for example, you). It depends on the styles/experience/skills after all of every one of us, so what I am trying to say is that it's false to consider something more readable than another, simply because it depends on the one who's coding/reading. hope to clarify it up a bit


ps: no offense intended, of course. just i'm not native english speaker, so I don't know if I wrote something I didn't want there. pls say if something 'doesn't make sense'


Last edited by Borsuc on 15 Feb 2006, 21:09; edited 2 times in total
Post 15 Feb 2006, 19:34
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
vid
tom tobias: i want exact way how you implement it, not some theoretical thoughts. Saying "something is like something" is not an argument.

You mean you would allocate (estimated) space for data and keep it stored there? That is pointer too. And you still need to know maximal size of string? Or you would "estimate" that user wants to use at most N - sized input and disallow bigger?
Post 15 Feb 2006, 19:48
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Data input: commercial retinal scanner:
http://www.hitl.washington.edu/publications/p-95-5/
image: 1024 x 768, each pixel has two components: (color range) 24 bits, + 8 bits for magnitude (intensity) of signal. Scan frequency is 72 hz, therefore total data in = 1024 * 768 * 72 * 5 pixels per second over the five second window comprising the retinal scan.
So, one needs to set aside 300,000,000 32 bit memory locations.
Ok, so what if we weren't sure about this calculation? Suppose, for sake of discussion, that we have 4 gbytes of memory on the motherboard. Then suppose we allocate the entire space to a large buffer, which we first clear, then assign an arbitrary value to, for example FFFF FFFF.
Now the data comes pouring in, at the end of the five seconds, all of the data has been received. The buffer is not full. But, the section beyond the last bit of buffer input will contain a lot of F's. Now we can determine precisely where the end of the real data is located, and then assign that length to the space needed for this input buffer, saving, for some other purpose, the unused memory. For many on this forum, such labor will be ridiculed, as it is much easier to simply use a pointer. With pointers, who cares how large the buffer is? No one. It is an unimportant, trivial, silly waste of time, right? But not to me. I like to know what is going on. I want to know exactly what is going where, why and when. I dislike pointers precisely because they not only PERMIT, they ENCOURAGE programmer ignorance of details--details which are admittedly USELESS when CREATING the program, but not so useless when, now, 11 years later (the retinal scan doc was published in 1995) someone wants to MODIFY this program, perhaps adding fluoroscein dye angiography: http://www.vrmny.com/angiography.htm
Where is the original programmer? gone. Where are his notes? none ever existed. Where is his documentation? He wasn't a native speaker, and didn't like English too much.....
START OVER.
How often has this happened? Countless times. The number of stars multiplied by the number of grains of sand, divided by the current population. In essence that was the thrust of the article that introduced this discussion---methods whereby programmers could create deliberately incomprehensible CODE, rather than writing PROGRAMS, that anyone could read and understand.
CODE: pointers--single integer to represent the starting address of an array of location specified not by the programmer but by the operating system or compiler.
Programs: ARRAYS--ACTUAL physical assignment of a specific, fixed locus for a finite, measurable amount of data.
Smile
Post 15 Feb 2006, 22:32
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2145
Location: Estonia
Madis731
I think that the cause of our problem is here:
Code:
mov eax,[ebx]
    

ebx is a pointer here and you can't read from a memory source without a pointer to it. This is why pointers are neccessary in any language. If this is not the problem....let the debate continue Very Happy
Post 16 Feb 2006, 07:56
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
vid
tom: you can't be serious. OK, i will try to formulate my question once again and clearly:

HOW DO YOU SAVE INPUT OF UNKNOWN SIZE WITHOUT USING POINTERS?

Note that i am not saying about infinite or unmeasurable input size. You just don't know how big it will be at compile-time.

Method you described (take all memory and use only required part of it) may have worked on DOS, but not on multitasking operating system.
Post 16 Feb 2006, 11:17
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
1. The size is NOT UNKNOWN to me. It may well be ERRONEOUS, but it has a size. I don't work with UNDEFINED DATA STRUCTURES. If I don't know the size, I make one up, thereby SQUANDERING precious memory, by having a data structure LARGER than it really needs to be.
2. Real time tasks, like the retinal scan example I gave, do not work well with DOS, or any other desktop operating system. Some folks have succeeded (I have not) to MODIFY desktop operating systems so that they become less ponderous, and more amenable to data gathering: I think Barry Kauler has worked with Linux, to pare it down to a more useable interface:
http://www.goosee.com/linux/intro/index.html
3. "multitasking" operating systems, at least traditionally, prior to the advent of multicore cpu's, or multiple cpu's on the same motherboard, really ran SINGLE tasks sequentially, with interrupts tricking the human nervous system, so that the operator imagines that several different activities operate concurrently. ANY SINGLE TASK then, has the same opportunity to employ or disregard pointers, as the architect wishes. I choose to disregard pointers, and the indirection addressing modes offered by the Intel cpu. When accessing a data element from an array, I do not employ pointers. I do not write programs with arrays of unspecified length, leaving it to FASM or some C compiler to determine where the data rests in memory. In my programs, I decide, not Bill Gates, where my data structures are located.
Smile
Post 16 Feb 2006, 12:18
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7493
Location: Kraków, Poland
Tomasz Grysztar
The problem lies here also in finding the difference between the array index and the pointer. When you've got the address of some array in EBX and access its fifth byte this way:
Code:
mov al,[ebx+5]    

you're definitely employing the pointer, since EBX is pointer to the array.
But when you've got an array at address 5, and in EBX you've got the index into this array (like when making a "for" loop to go through the whole array), this:
Code:
mov al,[5+ebx]    

is the instruction that uses the direct addressing, and EBX serves only the role of index.
The machine code in both cases is the same, it's their interpretation that differes.
Actually a pointer from the assembly point of view can be treated to be just an index into the array of bytes that compose the whole memory. And the assembly language syntax suggests it. The original Intel syntax was designed to imitate the array_name[index] syntax of some languages. Thus array_name[ebx] in Intel syntax is just the element of array, indexed by EBX. And simple [ebx] is the element of the "all memory array". (Is it what did you mean, Madis731?)
Post 16 Feb 2006, 12:45
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
vid
okay, we're getting somewhere.

To the first point: and what does your program do, when real input size shows to be larger than place you reserved?

Quote:
In my programs, I decide, not Bill Gates, where my data structures are located.

No you don't. Operating system loads your program wherever it wants it.
Post 16 Feb 2006, 12:46
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
JMGK



Joined: 26 Aug 2005
Posts: 27
JMGK
hmm,

i think... if pascal is so good, why we dont see the hot stuff (OSes, large database stuffs, etc) coded in pascal, but almost all in c/c++? why peoples end choosing c/c++ over pascal?

and the argument of the power of computers today made pointers obsolete is like saying that, with the power of the engines todays, the round wheels are obsolete, and with a squared wheel the cars will go forward anyway

jmgk

ps: sorry for my terrible english
Post 16 Feb 2006, 19:35
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
"Operating system loads your program wherever it wants it"
Ooops!
Sorry, Vid, no, not with my programs!!!
I tell the cpu exactly where to put all data (fixed addresses!!)
Hmm. Not very modern. Yes, and I like Thoreau too:
http://eserver.org/thoreau/walden00.html
JMGK:
(by the way, your English is EXCELLENT!)
your question was very good:
"why peoples end choosing c/c++ over pascal"
Wow, what a neat way to REJOIN the original post to this thread, which tried to explain, somewhat sarcastically, HOW C++ came to be so predominant.
Two comments regarding your very astute inquiry:
Old timers (ok, fuddy duddies like me) but not most of the FASM community, will remember the "good ole days", of CPM: a really nifty operating system for the first generation of affordable desktop computers, released back in the late 1970's. Microsoft with IBM put that puppy to rest permanently!!! Even to this day, if you peruse the internet where old foggies hang out, and raise a question about CPM, there will be archives of vituperative exclamations directed towards you. For, there is little that so arouses the ire of us old folks, like the memory of how that clever bit of software was DESTROYED, not because of some kind of superiority of DOS, compared with CP/M, but because of MONEY--i.e. the point of the humorous article that started this thread. So, in other words, JMGK, a particular implementation of some project, which can probably be accomplished with any language really, appears to the public, including the commercial sector, industry, universities, governments, bookstores, etc, NOT BECAUSE OF ITS intrinsic superiority, but because of financial considerations.
Wirth is European. C was developed at Bell Labs in New Jersey, in the late 1960's, during the war in Viet Nam. Wirth's work was TRANSPARENT, and based on computer science, unlike the hodge podge from the Bell Labs, which would ALWAYS receive praise for opacity and obtuseness. C, and UNIX based upon it, were 100% USA products, not European, like Wirth. Pascal supporters were few and far between in USA, most of them either university faculty, fellow mathematicians, or communists, or all of the above. In those days, (war in Viet Nam) politics played a LARGE role in software development. Given the importance of gaining USA military dollars, folks tended to drift towards the choice of C/UNIX, rather than Pascal, by a ratio of about 1000:1, due to the proverbial expression: BECAUSE THAT's WHERE THE MONEY IS -- the answer to the question posed to a famous bank robber in the 1940's, inquiring about his motivation to rob banks.
So, I would not conclude that Pascal is inferior to C, or C++ based on the existance of commercial projects (which require secrecy, hence INABILITY to READ and comprehend) favoring CODE over PROGRAMS.
However, there was one operating system developed using Pascal, I used it so long ago, I have forgotten what little I once knew about it, but, the point is: there is nothing intrinsically superior about C or C++ compared with Pascal. All of them are much better than the horrible languages I had to learn back in the 1960's: Fortran, Lisp, Cobol and BASIC. None of them are as good as Assembly, in my opinion.
Smile
Post 16 Feb 2006, 23:19
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
vid
nice, lot of text, but again you omited most important part:

and what does your program do, when real input size shows to be larger than place you reserved?
Post 17 Feb 2006, 12:48
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Heh. As if pascal code was magically easier to read than C/C++ code... you still haven't come with one single objective reason why pascal is better than anything, it's all a bunch of subjective vapor.

And what's with the aversion against pointers / dynamic memory? How are you going to handle, say, a customer system? Set aside memory for 1000 customers and hope that'll be enough? Which would use 10x more memory than needed for 100 customers, and fail for 10.000, or even 1001 customers?
Post 02 Mar 2006, 14:38
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Welcome back Fudder! Smile
Addressing your second point first:
memory useage in a customer tracking system, for example, some small enterprise, somewhere, wishes to keep a mailing list of customers with names, addresses, telephone numbers, and products of interest, including dates when contact was made, and the nature of the inquiry.
suppose 10 kilobytes of data, (about 5 pages of text)
with a list of 100 million customers, or potential customers, gosh, that's ONE GIGABYTE of memory.
Not many companies in the world have a list of customers larger than 100 million.
In 1970 or 1980, or even 1990, in fact, right up to 1999, that would be an UNIMAGINABLY LARGE data base for a desktop computer.
In 2006, a person would be unwise to purchase a desktop computer with LESS than a gigabyte of memory, and MOST motherboards sold today support 4 gigabytes of RAM.
So, I see no justification for writing CODE using pointers, instead of writing PROGRAMS with named ARRAYS, defined in the data section, PRIOR to writing any "code", (i.e. JUST THE EXACT opposite of what is "normally" done, at least on this forum). First define the data structures, then develop the algorithm = PROGRAM.
Mishmash a bunch of pointers here and there, add a dash of arithmetic to the pointers, omit any pattern to the resultant "code"--with data intermixed with instructions, and one cooks up an UNINTERPRETABLE mess, impossible to decipher or digest.
Post 02 Mar 2006, 16:15
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
vid
tom tobias: what is more important for you? Better program, or easier process of creating program? And what do you think is more important to people who use that program (majority)?
Post 02 Mar 2006, 16:29
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Vid, your questions, as usual, are very appropriate, and worthy of a more profound answer than I am capable of providing.
I mentioned in a recent post, on another thread, the tragic, and unexpected death of a great assembly language programmer, scholar, and teacher, Dr. S. Dandamudi. Here is a powerpoint presentation from one of his recent books:

http://www.scs.carleton.ca/~sivarama/asm_book/asm2ed_slides/slides/al2ed_chapter1.ppt

I am not citing Dr. Dandamudi's famous publications as some sort of vindication of my arguments, on the contrary, I suppose one could examine his writing and find criticism of, rather than support for, some of my wilder notions. No, I am not including this reference to suggest that my thinking is "mainstream", or something of that sort. No, I simply think that Dr. Dandamudi's writings, following the traditions elaborated by many scholars and teachers before him, some of whom, like Knuth and Wirth, are well known to participants of this forum, deserve a broader audience than exists at present. I have uploaded a jpeg copy of page 262 from his book on Assembly language programming from 2005, dealing with a variant of insertion sort algorithm. The whole module is not there, just an extract, to ensure that there are no copyright violations. The point is, I think glancing at this extract, one understands immediately, the distinction between writing CODE, and writing PROGRAMS.
Hope this helps address your questions.
Post 02 Mar 2006, 17:11
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
vid
how about shrinking image so it will become readable?
Post 02 Mar 2006, 17:31
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2019, Tomasz Grysztar.

Powered by rwasa.