Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > MALLOC problem

Reply
Thread Tools

MALLOC problem

 
 
Felix Palmen
Guest
Posts: n/a
 
      10-16-2010
* sajjad <(E-Mail Removed)>:
> int loopcount; /* used as a loop counter */


Oh, really?

> float temporary; /* temporary variable */


You don't say

At least, state the /intention/ of the variable in the comment.

--
Felix Palmen (Zirias) + [PGP] Felix Palmen <(E-Mail Removed)>
web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      10-16-2010
On 16 Oct, 08:22, Nobody <(E-Mail Removed)> wrote:
> On Fri, 15 Oct 2010 23:19:45 -0700, luser- -droog wrote:


> > I mean really: loopcounter /* the loop counter */
> > REALLY?

>
> It's not that uncommon. Take a self-taught programmer who has never
> bothered to comment their code, and put them on a programming course.
> They'll be told how important it is to comment code, so they'll start
> adding (often meaningless) comments to every declaration and statement.


I saw this once (well nearly this, I forget the atcual header name)

#include "crtwxe.h" /* obvious use */
 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      10-16-2010
On 16 Oct, 08:52, sajjad <(E-Mail Removed)> wrote:
> Nobody writes:
> > On Fri, 15 Oct 2010 23:19:45 -0700, luser- -droog wrote:

>
> >> I mean really: loopcounter /* the loop counter */ REALLY?

>
> > It's not that uncommon. Take a self-taught programmer who has never
> > bothered to comment their code, and put them on a programming course.
> > They'll be told how important it is to comment code, so they'll start
> > adding (often meaningless) comments to every declaration and statement.

>
> Our course teaches good programming practise


perhaps you should follow them!



- EVERY variable must be
> commented, also EVERY functions purpose explained


why? If a function is well named and uses sensible types it may be
perfectly obvious what it does

> and EVERY argument
> commented,


no. Really no.

void add_block_to_queue (Queue *q, const Block *b);

how does a comment help? (well ok, error handling)

> and only use meaningful names for functions and variables.


"meaningful" doesn't mean loopcount is better than i
 
Reply With Quote
 
August Karlstrom
Guest
Posts: n/a
 
      10-16-2010
On 2010-10-16 09:52, sajjad wrote:
> Our course teaches good programming practise - EVERY variable must be
> commented, also EVERY functions purpose explained and EVERY argument
> commented, and only use meaningful names for functions and variables.


If you have to, you have to. However, as others have mentioned, there is
no sense in adding comments that say the same thing as the code, like
for instance

/* output the contents of the array */
prn_array(array, size);

Do you think the above comment makes the statement easier to understand?

Good luck with your C programming.


/August

--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra
 
Reply With Quote
 
Felix Palmen
Guest
Posts: n/a
 
      10-16-2010
* Nick Keighley <(E-Mail Removed)>:
> On 16 Oct, 08:52, sajjad <(E-Mail Removed)> wrote:
>> and EVERY argument
>> commented,

>
> no. Really no.


Depends. In my opinion, it's good practice to document every argument as
well as the return value of a function IFF this function is part of a
public API. Also add exceptions for languages that have them.

And, of course, it should be done in a standard format that allows for
automatic generation of API documentation (e.g. visual-studio XML
comments, javadoc or doxygen).

Regards,
Felix

--
Felix Palmen (Zirias) + [PGP] Felix Palmen <(E-Mail Removed)>
web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-16-2010
August Karlstrom <(E-Mail Removed)> writes:
> On 2010-10-16 09:52, sajjad wrote:
>> Our course teaches good programming practise - EVERY variable must be
>> commented, also EVERY functions purpose explained and EVERY argument
>> commented, and only use meaningful names for functions and variables.

>
> If you have to, you have to. However, as others have mentioned, there is
> no sense in adding comments that say the same thing as the code, like
> for instance
>
> /* output the contents of the array */
> prn_array(array, size);
>
> Do you think the above comment makes the statement easier to understand?


Without the comment, I wouldn't have been at all sure that "prn" is an
abbreviation for "print".

If the function has the more sensible name "print_array", the comment
would be unnecessary.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
August Karlstrom
Guest
Posts: n/a
 
      10-16-2010
On 2010-10-16 23:43, Keith Thompson wrote:
> August Karlstrom<(E-Mail Removed)> writes:
>> On 2010-10-16 09:52, sajjad wrote:
>>> Our course teaches good programming practise - EVERY variable must be
>>> commented, also EVERY functions purpose explained and EVERY argument
>>> commented, and only use meaningful names for functions and variables.

>>
>> If you have to, you have to. However, as others have mentioned, there is
>> no sense in adding comments that say the same thing as the code, like
>> for instance
>>
>> /* output the contents of the array */
>> prn_array(array, size);
>>
>> Do you think the above comment makes the statement easier to understand?

>
> Without the comment, I wouldn't have been at all sure that "prn" is an
> abbreviation for "print".
>
> If the function has the more sensible name "print_array", the comment
> would be unnecessary.
>


Agreed, "only use meaningful names" as Sajjad says above.


/August

--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra
 
Reply With Quote
 
Geoff
Guest
Posts: n/a
 
      10-17-2010
On Sat, 16 Oct 2010 07:52:03 +0000 (UTC), sajjad <(E-Mail Removed)>
wrote:

>Nobody writes:
>
>> On Fri, 15 Oct 2010 23:19:45 -0700, luser- -droog wrote:
>>
>>> I mean really: loopcounter /* the loop counter */ REALLY?

>>
>> It's not that uncommon. Take a self-taught programmer who has never
>> bothered to comment their code, and put them on a programming course.
>> They'll be told how important it is to comment code, so they'll start
>> adding (often meaningless) comments to every declaration and statement.

>
>Our course teaches good programming practise - EVERY variable must be
>commented, also EVERY functions purpose explained and EVERY argument
>commented, and only use meaningful names for functions and variables.


This is an attempt by your instructor to discern whether you
understand and can describe what you think you are doing in your code.
It's possible to write code that "works" but doesn't do what the
author thinks it does. To conform with the "house coding rules" in
your course work you must do this but you should write comments where
it is meaningful and in C you don't need to write that int i; is an
integer. It is more meaningful to state it is an outer loop counter or
some such.

When you are writing code to a specification the specification will
describe what the code is supposed to do. It's the coder's job to make
the code behave as described in the specification in a clear and
maintainable way. With "large" or complex functions this is essential.
With small functions like swap, it is often unnecessary and
distracting.

As for style, you should definitely use more white space in your code.
Your example is dense and hard to read. Conform to the known standards
style and stick with them. You should also work to make your functions
more generic. Your prn_array is not really generic. If you wrote:

/* prints the contents of the array to stdout.
array is the array to print, size is it's size */
void print_array(float *farray, int size)
{
int counter;

for (counter = 0; counter < size; counter++)
printf("%f ", farray[counter]);
printf("\n");
}

.... then you can write:

/* output the contents of the array */
printf("\nThe sorted array is:\n");
print_array(farray, size);
return 0;
}

in main and you can write

print_array(farray, size);

anywhere in your program to debug the state of the array at any time.

You should also try to write your array indexing as though you know
what you are doing and know how to maintain bounds. Don't write silly
things like this:

void sort_descending (float array[], int size) {

int i, j; /* integers */

for (i=0; i<size - 1; ++i)
for (j= size-1; i<j;--j)
if (array[j-1] < array[j])
swap(&array[j-1], &array[j]);

}

/* sorts array in ascending order. array is the array
to print, size is it's size */
void sort_ascending (float array[], int size) {

int i, j; /* integers */ /* no kidding? */

for (i=size; i>0 - 1; --i)
for (j= 0-1; i>j;++j) /* 0-1? what the heck??? */
if (array[j-1] > array[j])
swap(&array[j-1], &array[j]);

}

when you should be writing something like this:

/* sorts array in descending order. array is the array
to print, size is it's size */
void sort_descending (float farray[], int size)
{
int i; /* outer loop counter */
int j; /* inner loop counter */

for (i = size; i > 0; --i)
for (j = 1; i > j; ++j)
if (farray[j-1] < farray[j])
swap(&farray[j-1], &farray[j]);
}

/* sorts array in ascending order. array is the array
to print, size is it's size */
void sort_ascending (float farray[], int size)
{
int i;
int j;

for (i = size; i > 0; i--)
for (j = 0; i > j; j++)
if (farray[j-1] > farray[j])
swap(&farray[j-1], &farray[j]);
}

It is very clear your problem will malloc prevented you from debugging
these functions.
 
Reply With Quote
 
John Bode
Guest
Posts: n/a
 
      10-26-2010
On Oct 16, 2:52*am, sajjad <(E-Mail Removed)> wrote:
> Nobody writes:
> > On Fri, 15 Oct 2010 23:19:45 -0700, luser- -droog wrote:

>
> >> I mean really: loopcounter /* the loop counter */ REALLY?

>
> > It's not that uncommon. Take a self-taught programmer who has never
> > bothered to comment their code, and put them on a programming course.
> > They'll be told how important it is to comment code, so they'll start
> > adding (often meaningless) comments to every declaration and statement.

>
> Our course teaches good programming practise - EVERY variable must be
> commented, also EVERY functions purpose explained and EVERY argument
> commented, and only use meaningful names for functions and variables.


Comments on variable declarations are only useful if a) they are
correct, and b) they give information not already present in the
variable name. The excerpt cited by luser- -droog is an example of a
poor comment; it doesn't tell us anything we don't already know about
that variable. At best, it's redundant and adds visual clutter.

There's a point where commenting for the sake of commenting makes the
code *harder* to read and maintain. When writing a comment, ask
yourself if you're providing useful information that's not apparent in
the code itself. If the answer is "no", then don't add the comment.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-27-2010
John Bode <(E-Mail Removed)> writes:
> On Oct 16, 2:52*am, sajjad <(E-Mail Removed)> wrote:
>> Nobody writes:
>> > On Fri, 15 Oct 2010 23:19:45 -0700, luser- -droog wrote:

>>
>> >> I mean really: loopcounter /* the loop counter */ REALLY?

>>
>> > It's not that uncommon. Take a self-taught programmer who has never
>> > bothered to comment their code, and put them on a programming course.
>> > They'll be told how important it is to comment code, so they'll start
>> > adding (often meaningless) comments to every declaration and statement.

>>
>> Our course teaches good programming practise - EVERY variable must be
>> commented, also EVERY functions purpose explained and EVERY argument
>> commented, and only use meaningful names for functions and variables.

>
> Comments on variable declarations are only useful if a) they are
> correct, and b) they give information not already present in the
> variable name. The excerpt cited by luser- -droog is an example of a
> poor comment; it doesn't tell us anything we don't already know about
> that variable. At best, it's redundant and adds visual clutter.
>
> There's a point where commenting for the sake of commenting makes the
> code *harder* to read and maintain. When writing a comment, ask
> yourself if you're providing useful information that's not apparent in
> the code itself. If the answer is "no", then don't add the comment.


Agreed, mostly.

An exception might be in an assignment for a beginning programmer
(either learning the language or just learning to program), when
the purpose of a comment isn't so much to convey information to
the reader, but to demonstrate that the writer knows what he's doing.

The question is, how does the student break the habit of writing
elementary comments as he progresses? I don't have a good answer to
that.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
to malloc or not to malloc?? Johs32 C Programming 4 03-30-2006 10:03 AM
porting non-malloc code to malloc micromysore@gmail.com C Programming 3 02-19-2005 05:39 AM
Malloc/Free - freeing memory allocated by malloc Peter C Programming 34 10-22-2004 10:23 AM
free'ing malloc'd structure with malloc'd members John C Programming 13 08-02-2004 11:45 AM
Re: free'ing malloc'd structure with malloc'd members ravi C Programming 0 07-30-2004 12:42 PM



Advertisments