Hi,
Sorry for this question, but why isn't sc_vec a good old pointer ?
t_gobj sc_gobj; /* header for graphical object */
t_symbol *sc_template; /* template name (LATER replace with pointer) */
t_word sc_vec[1]; /* indeterminate-length array of words */
} t_scalar;
Because this way you can reference data points with sc_vec+n as opposed to
dealing with single or double linked lists (since sc_vec can be an array).
On Feb 21, 2014 7:26 AM, Charles Goyard c...@fsck.fr wrote:
Hi,
Sorry for this question, but why isn't sc_vec a good old pointer ?
t_gobj
On 02/21/2014 09:00 AM, Ivica Bukvic wrote:
Because this way you can reference data points with sc_vec+n as
opposed to dealing with single or double linked lists (since sc_vec
can be an array).
If sc_vec is a pointer then you can access data points using the same
technique, which is
It's more efficient (especially in terms of memory) to keep the two
things contiguously in memory than to have to chase an additional pointer
to the array. In C it looks almost the same (arrays and their pointers are
both specified by naming the arraym but sizeof will act differently for
Can anyone explain what's going on with this in m_pd.h:
typedef struct _scalar /* a graphical object holding data */
{
t_gobj sc_gobj; /* header for graphical object */
t_symbol *sc_template; /* template name (LATER replace with pointer) */
t_word sc_vec[1]; /*
Hi all -
I don't know if this is a reasonable thing to do in 2014 - it's a coding trope
I learned around 1981. As far as I know C has no clean way to describe a
packed data structure with a header and then a variable number of identical
elements (like a soundfile with a header followed by
