Y
Yevgen Muntyan
Consider the following macro:
#define ALLOCIT(Type) ((Type*) malloc (sizeof (Type)))
The intent is to wrap raw memory allocation of N bytes
into a macro which returns allocated chunk of memory
to be used as a Type structure.
The background: I was beaten many times (it surely
is not my exclusive experience) by functions which
return and accept void*. There are such functions,
and there are cases when you can't do much about it
(third-party libraries, containers, etc.). I make
a conclusion: void* is evil and must be avoided when
possible and easy. Therefore I believe it's better
to use above macro than raw malloc. And I think this
is a valid belief, not like believing in Santa or alive
Elvis.
In toy programs like posted here, when you do
int *func (void)
{
int *foo = malloc (10 * sizeof *foo);
...
}
it certainly doesn't matter how you use malloc since
it's small and easy. But in big programs, when you have
lot of other things to worry about, it's nice to know
that you reduced number of function calls which return
void*. At least it's nice to know for me. Type mismatch
here is quite a usual thing (unfortunately), since
I deal a lot with "classes", with nested structures
like
struct Parent {...};
struct Child {struct Parent parent; ...};
It's extremely easy to mess it up, and avoiding using
extra void* is actually a good thing. Note that this
Child-Parent thing has nothing to do with malloc. But
it does have a lot to do with using wrong types. And
I don't try to think like "this is malloc, has nothing
to do with that, void* is fine here". I just avoid using
void*.
Now not all people think that ALLOCIT() buys any type safety.
Some other people do think it does.
Anyway, it's hard to argue with more than one person
at once, so I decided to post what I think about this
particular "yes I want cast *here*" thing. You may
say I want C++, you may say "Wrong.", you may prove
using ten steps that it's wrong, whatever. I at least
know that I am not the only person who believes in
"cast is good in this single thing" so I am not a complete
idiot. (Of course you can say that people who believe this
are all idiots or wrong, but working software proves they
aren't).
Yevgen
#define ALLOCIT(Type) ((Type*) malloc (sizeof (Type)))
The intent is to wrap raw memory allocation of N bytes
into a macro which returns allocated chunk of memory
to be used as a Type structure.
The background: I was beaten many times (it surely
is not my exclusive experience) by functions which
return and accept void*. There are such functions,
and there are cases when you can't do much about it
(third-party libraries, containers, etc.). I make
a conclusion: void* is evil and must be avoided when
possible and easy. Therefore I believe it's better
to use above macro than raw malloc. And I think this
is a valid belief, not like believing in Santa or alive
Elvis.
In toy programs like posted here, when you do
int *func (void)
{
int *foo = malloc (10 * sizeof *foo);
...
}
it certainly doesn't matter how you use malloc since
it's small and easy. But in big programs, when you have
lot of other things to worry about, it's nice to know
that you reduced number of function calls which return
void*. At least it's nice to know for me. Type mismatch
here is quite a usual thing (unfortunately), since
I deal a lot with "classes", with nested structures
like
struct Parent {...};
struct Child {struct Parent parent; ...};
It's extremely easy to mess it up, and avoiding using
extra void* is actually a good thing. Note that this
Child-Parent thing has nothing to do with malloc. But
it does have a lot to do with using wrong types. And
I don't try to think like "this is malloc, has nothing
to do with that, void* is fine here". I just avoid using
void*.
Now not all people think that ALLOCIT() buys any type safety.
Some other people do think it does.
Anyway, it's hard to argue with more than one person
at once, so I decided to post what I think about this
particular "yes I want cast *here*" thing. You may
say I want C++, you may say "Wrong.", you may prove
using ten steps that it's wrong, whatever. I at least
know that I am not the only person who believes in
"cast is good in this single thing" so I am not a complete
idiot. (Of course you can say that people who believe this
are all idiots or wrong, but working software proves they
aren't).
Yevgen