It is very convenient. The fact that I make mistakes in this approach is due to my perfectionism (I scatter consts everywhere, necessary and not necessary). This does not mean that this technique itself is wrong.
Our goals are clear, tasks are defined! Let's work, comrades! -- Nikita Khrushchev
O_oIt is very convenient.
How? You save a couple or three characters?
The fact that you can't follow your aggressive `const' strategy, one which I too apply, without still further `typedef' pointers, a `const' flavor, should give you a good understanding of why the technique really is bad practice.This does not mean that this technique itself is wrong.
Soma
“Salem Was Wrong!” -- Pedant Necromancer
“Four isn't random!” -- Gibbering Mouther
O_oThis demonstrates yet again that the practice of having pointer typedefs for non-opaque pointer types is a poor practice.
The other valid case: pointers to functions when used as function parameters.
Soma
“Salem Was Wrong!” -- Pedant Necromancer
“Four isn't random!” -- Gibbering Mouther
This is not using assert correctlty.Originally Posted by zub
The idea of assert is to help you when developing the code - When you release the code, you are supposed to define NDEBUG before the <assert.h> and all of the asserts are ignored.
When your code uses asserts to check if malloc was successful, you loose the checks when NDEBUG is defined.
Also, exiting a program on a failed malloc is also very poor practice: Imagine that your user has spent hours making a document, all of the sudden they get a message saying, "Malloc Failed" and the program shuts down. The user is left confused and (rightfully) angry. What you should do is tell the user that the system is short on memory and ask them to close some other programs that they might be using.
Fact - Beethoven wrote his first symphony in C
And why are you casting your malloc in your macro?Originally Posted by zub
Also, laserlight has asked you not to spoonfeed answers out.
Fact - Beethoven wrote his first symphony in C