What do you prefer and why?
char *p;
p = malloc(SIZE);
…
memset( p,0, sizeof (char) * SIZE )
or
memset( p, 0, sizeof( *p ) * SIZE );
======================
char x[SIZE];
memset( x, 0, sizeof x );
or
memset ( x, 0, sizeof x * SIZE )
or
memset ( x, 0, sizeof char * SIZE );
Mario Charest wrote:
What do you prefer and why?
char *p;p = malloc(SIZE);
…
memset( p,0, sizeof (char) * SIZE )
This is okay but I’d just use calloc() since it initializes the memory
to zero anyway. (I realize that’s not the point 
or
memset( p, 0, sizeof( *p ) * SIZE );
This is probably better in case you make ‘p’ something else later.
======================
char x[SIZE];
memset( x, 0, sizeof x );
I usually do this for immediates just because it’s easy and
accurate…could bite you if you decided to allocate later though.
cheers,
Kris
Kris Warkentin <kewarken@qnx.com> wrote:
KW > Mario Charest wrote:
What do you prefer and why?
char *p;p = malloc(SIZE);
…
memset( p,0, sizeof (char) * SIZE )
KW > This is okay but I’d just use calloc() since it initializes the memory
KW > to zero anyway. (I realize that’s not the point
I try to write code that is self documenting. Therefore I prefer this method.
or
memset( p, 0, sizeof( *p ) * SIZE );
KW > This is probably better in case you make ‘p’ something else later.
Here, I don’t know what p is pointing to.
======================
char x[SIZE];
memset( x, 0, sizeof x );
KW > I usually do this for immediates just because it’s easy and
KW > accurate…could bite you if you decided to allocate later though.
I didn’t know it was even valid to use sizeof without (). I always use them.
Then again I know people who always put () around values being returned
in a return statement. And I never do that.
I guess it’s mostly a matter of personal choice.
HOWEVER ! ! !
In the example that Kris did not copy here that looked like:
sizeof char * SIZE
I found that line to be very misleading. It looked like it was taking
the sizeof( char *) ! ! ! and SIZE was just hanging.
Bill Caroselli wrote:
memset( p,0, sizeof (char) * SIZE )
KW > This is okay but I’d just use calloc() since it initializes the memory
KW > to zero anyway. (I realize that’s not the point >I try to write code that is self documenting. Therefore I prefer this method.
ormemset( p, 0, sizeof( *p ) * SIZE );
KW > This is probably better in case you make ‘p’ something else later.Here, I don’t know what p is pointing to.
Hmmmm, if you are trying to write self-documenting code then isn’t “p”
an identifier name that you just wouldn’t use?
Do you use the (hungarian?) naming method which contains some of the
type info, eg
Mario Charest wrote:
What do you prefer and why?
char *p;p = malloc(SIZE);
…
memset( p,0, sizeof (char) * SIZE )
Since sizeof(char) is guaranteed to be one, it’s redundant here. I
think it’s a good habit to pass exactly the same expression to memset()
that you passed to malloc() – it makes it more obvious that you’re
memsetting exactly the correct amount of memory.
or
memset( p, 0, sizeof( *p ) * SIZE );
I prefer this one, especially when p is not a char pointer. It makes it
obvious that no matter what type of objects p points to, you’re
memsetting SIZE such objects. With an explicit type in the sizeof,
there’s a chance that some day you may change the type of p but forget
to change the type in the sizeof.
======================
char x[SIZE];
memset( x, 0, sizeof x );
This one guarantees that you’re memsetting all the bytes of x, provided
that x is an array. If you later change x to be a pointer, this will
happily memset the first four bytes of whatever it points to, which is
not a good thing.
Personally, I prefer
memset( &x, 0, sizeof(x) );
because it works no matter whether x is an array, a structure, or a
simple scalar. If you change the array into a pointer some day but
forget to allocate memory, this will set the pointer to NULL, and
hopefully, a crash will tell you what you’re missing.
or
memset ( x, 0, sizeof x * SIZE )
This one is wrong… Did you mean sizeof(x[0]) * SIZE, or something
like that?
or
memset ( x, 0, sizeof char * SIZE );
Kris Warkentin <kewarken@qnx.com> wrote:
KW > Colin Burgess wrote:
Do you use the (hungarian?) naming method which contains some of the
type info, egchar *pzTempString;
KW > Hungarian? Hssss… BAD!!! I don’t care if Microsoft does
KW > it…putting type information in variable names is just plain evil and
KW > there’s no way around it. I could see it if you used it to indicate
KW > scope rather than type perhaps.
KW > A) Refactoring is a pain.
KW > B) It’s a type of documentation that only works if EVERYONE follows the
KW > same convention
KW > C) Doesn’t promote encapsulation/abstraction…in some cases I should
KW > neither know nor care what the type is.
KW > D) It’s the compilers job to track the types, not the function names.
KW > E) Migrating to greater bits? Change all your ‘w’ prefixes to ‘dw’
KW > prefixes? ick?
I’m glad you said it. I’ve always hated this hungarian crap. But it
is so common these days that I keep my mouth shut. However, I
absolutely don’t ever trust it.
Colin Burgess wrote:
Bill Caroselli wrote:
memset( p,0, sizeof (char) * SIZE )
KW > This is okay but I’d just use calloc() since it initializes the
memory KW > to zero anyway. (I realize that’s not the point >I try to write code that is self documenting. Therefore I prefer this
method.
ormemset( p, 0, sizeof( *p ) * SIZE );
KW > This is probably better in case you make ‘p’ something else later.Here, I don’t know what p is pointing to.
Hmmmm, if you are trying to write self-documenting code then isn’t “p”
an identifier name that you just wouldn’t use?Do you use the (hungarian?) naming method which contains some of the
type info, egchar *pzTempString;
Hungarian? Hssss… BAD!!! I don’t care if Microsoft does
it…putting type information in variable names is just plain evil and
there’s no way around it. I could see it if you used it to indicate
scope rather than type perhaps.
A) Refactoring is a pain.
B) It’s a type of documentation that only works if EVERYONE follows the
same convention
C) Doesn’t promote encapsulation/abstraction…in some cases I should
neither know nor care what the type is.
D) It’s the compilers job to track the types, not the function names.
E) Migrating to greater bits? Change all your ‘w’ prefixes to ‘dw’
prefixes? ick?
Mario Charest wrote:
What do you prefer and why?
char *p;p = malloc(SIZE);
#include
string p;
John Nagle
Team Overbot
John Nagle wrote:
Mario Charest wrote:
What do you prefer and why?
char *p;p = malloc(SIZE);
#include <string
string p;
John Nagle
Team Overbot#!/usr/bin/env python
mystring = “Some string”
Kris
Previously, Kris Warkentin wrote in qnx.cafe:
John Nagle wrote:
Mario Charest wrote:What do you prefer and why?
char *p;p = malloc(SIZE);
#include <string
string p;
John Nagle
Team Overbot#!/usr/bin/env python
mystring = “Some string”
Kris
my $p = “Perl string”; # Must yank Pythoner’s chain…
10 LET P$ = “BASIC STRING?” : REM It’s been a while…
(setq p “Lisp string?”) ; Can barely remember…
COBOL, Fortran, Pascal, Tcl/Tk, REXX, Standard ML, APL, Prolog,
and all those darn Unix shells left as exercises for the reader.
–
±---- Pete DiMarco ------±--------------------------------------+
| Staff Software Engineer | Web: www.ifspurity.com |
| Integrated Flow Systems | Email: peted [At] ifspurity [Dot] com |
±------------------------±--------------------------------------+
<< Opinions expressed here are my own, not those of my employer. >>
John Nagle wrote:
Mario Charest wrote:
What do you prefer and why?
char *p;p = malloc(SIZE);
#include <string
string p;
John Nagle
Team Overbot
Great - you just bloated your program… :v)
/home/cburgess >qcc -o mcc malloc.cc
/home/cburgess >qcc -o mc malloc.c
/home/cburgess >size mc mcc
text data bss dec hex filename
872 228 4 1104 450 mc
4912 1092 28 6032 1790 mcc
Colin Burgess <cburgess@qnx.com> wrote:
CB > John Nagle wrote:
Mario Charest wrote:
What do you prefer and why?
char *p;p = malloc(SIZE);
#include <string
string p;
John Nagle
Team Overbot
CB > Great - you just bloated your program… :v)
CB > /home/cburgess >qcc -o mcc malloc.cc
CB > /home/cburgess >qcc -o mc malloc.c
CB > /home/cburgess >size mc mcc
CB > text data bss dec hex filename
CB > 872 228 4 1104 450 mc
CB > 4912 1092 28 6032 1790 mcc
Isn’t it great that you can soup-up an ordinary C program to C++ and it
costs you less than 5K bytes ! ! !
Bill Caroselli wrote:
Colin Burgess <> cburgess@qnx.com> > wrote:
CB > John Nagle wrote:Mario Charest wrote:
What do you prefer and why?
char *p;p = malloc(SIZE);
#include <string
string p;
John Nagle
Team Overbot
CB > Great - you just bloated your program… :v)CB > /home/cburgess >qcc -o mcc malloc.cc
CB > /home/cburgess >qcc -o mc malloc.c
CB > /home/cburgess >size mc mcc
CB > text data bss dec hex filename
CB > 872 228 4 1104 450 mc
CB > 4912 1092 28 6032 1790 mccIsn’t it great that you can soup-up an ordinary C program to C++ and it
costs you less than 5K bytes ! ! !
Well, assuming that it’s a one time cost. On the other hand, if it
scales then you could say the c++ is 5 times the size of the c. In
practice, the answer is somewhat between the two although if you start
using templates you’ll be crying about the size of the binary in a
pretty big hurry.
cheers,
Kris
Hi Mario,
char x[SIZE];
This allocates the memory on the stack. If SIZE is too big, you get stack
overflow errors.
Markus
memset( x, 0, sizeof x );
or
memset ( x, 0, sizeof x * SIZE )
or
memset ( x, 0, sizeof char * SIZE );
- Mario
\
In article <c2a23f$qhv$1@inn.qnx.com>, markus@qrts.com says…
Hi Mario,
char x[SIZE];
This allocates the memory on the stack. If SIZE is too big, you get stack
overflow errors.
Hi Markus,
Even if x is a global variable(array)?
Eduard.
Markus