Hi, I am using calloc in a function to allocate memory to my array. This function writes to the array different number of elements each time the function is called. Here is my problem. Say for the first time function writes to all the 3 locations and next time it writes to only first 2 locations. After the second call, the 3rd memory locations still contains the value written by the first function call. I understand that is the way it works.But I want to know if there is a way to erase all the locations before calling the function again? Is there any built-in function available? Also when I print the values of array initially it doesn't print zeroes. I have read that calloc initializes the memory fields to 0's. Following is the function code.
function write_to_array(int value) { int xdata *ascii_value,i; ascii_value = calloc(3, sizeof (int)); for(i=0;value!=0;i++) { mod = value%10; c = mod+'0'; ascii_value[i] = toascii(c); value/=10; } }
what we are discussing is not 'C' but design philosophy.
I have yet to find two persons that can agree fully in that area.
My philiosophy is 'efficiency' (whatever the cost) and I gather that your philiosophy is 'purity' (whatever the cost).
so you take the high road and I take the low road but I'll be in Scotland before ye (i.e. faster code)
Erik
"... I gather that your philiosophy is 'purity' (whatever the cost)."
Pure efficiency with the lowest cost possible.
How can you maintain 'pure' C and go for efficiency?. No, i am not talking about going to assembler (which I do when needed) but things like 'taking advantage' of the library functions.
lowest cost possible is that development cost or unit cost?
"How can you maintain 'pure' C and go for efficiency?."
They are not mutually exclusive.
"is that development cost or unit cost?
We try to minimize both, but optimizing one typically has the opposite effect on the other.
They are not mutually exclusive. Oh, well, 'pure' may have been the wrong word, I am still, after 10+ years, remembering the "real C" idiot I fired.
"is that development cost or unit cost? We try to minimize both, but optimizing one typically has the opposite effect that seems to be the case in my world too. In a place where I once worked the formula was if [cost of optimizing development calculated at 5 times anticipated time] / ([unit savings] * [anticipated unit count]) came out in favor, then optimize.
"In a place where I once worked the formula was ..."
Or like when they want it "small" and "soon" and "cheap". They can pick only two.
agreed
what we are discussing is not 'C' but design philosophy
Not so. The discussion is most definitely about 'C', a subject on which you have much to say despite a fundamental lack of knowledge.
you keep babbeling about my "lack of knowledge" about C, what makes you a judge of that. That I apply C is a sensible way, instead of harping on what is C and what is not C does not indicate "lack of knowledge' but rather "intelligent application in an environment the language was not originally intended for"
"... instead of harping ..."
"Harping"? Now that's pretty offensive. I would prefer that folks take my posts as "educating".
sorry, Dan, addressed to Jack.
Dan, you and I may differ, but I have yet to see you post derogatives about me, whereas Jack seems to enjoy doing so.
you keep babbeling about my "lack of knowledge" about C, what makes you a judge of that
You persist in posting statements about 'C' that are incorrect. What other reason could there be to explain that than your lack of knowledge?
"Harping"? Now that's pretty offensive.
As usual.
I would prefer that folks take my posts as "educating".
There would appear to be no possibility of educating some people. Disagreement is probably the best you can hope for.
You . What other reason could there be to explain that than your lack of knowledge?
well then the fact that you "persist in posting statements about 'C' in small embdeed that makes it ineffective" show your immense lack of practical knowledge.
You just are so moribund in your 'adherence' that you can not possibly have any idea how to make a working product.
I do not give a hoot whether what I feed the C compiler is "real C" or whatever as long as what comes out is effective code. You however seem to be more concerned with what you feed the compiler than with what comes out.
well then the fact that you "persist in posting statements about 'C' in small embdeed that makes it ineffective"
Please provide a quotation to back up this statement.
My pleasure
I posted: "There are features in Keil C51 that should not be there simply because they have to be "wresteled into the architecture" but Keil need to be able to state "ANSI compatible" so they are there."
you replied: "If you'd like to give us all a laugh by inventing some examples to back up your statement please go ahead."
That reply from you do state "there are no C features wrestled in to fit the '51 architecture"
If you in any way state that e.g. malloc() has a place in effective C for the '51 my point is proven. naah, not even 'effective' leave it at C for the '51.