definition/explanation of an unboxed array in c is ...?

[ben]

i was reading this page "Optimizing Machine Learning Programs"
http://hunch.net/?p=290 where in the comments at the bottom regarding
the third point "Avoid Pointer-Based Representations" there is talk of
unboxed arrays.

having done a bit of searching i have now have a rough idea of what
unboxed variables are. generally they seem to be primative variable
types like int and float where the value in question is right there,
not referrenced by a pointer which points to the value in the heap. so
is an unboxed variable one which is local and on the stack? also in c,
so far as arrays go, would an unboxed array be one that is only on the
stack? do unboxed arrays never exist on the heap?

thanks.

 

[ben]

or is "unboxed" and "unboxed arrays" not really applicable to c ?

 

[Richard Tobin]

i was reading this page "Optimizing Machine Learning Programs"
http://hunch.net/?p=290 where in the comments at the bottom regarding
the third point "Avoid Pointer-Based Representations" there is talk of
unboxed arrays.

I think you may have misinterpreted this. As far as I can tell,
they're not contrasting "boxed arrays" and "unboxed arrays", but boxed
representations - typed objects, which point to each other - with
arrays.

I take the term "unboxed array-base implementations" to mean "unboxed
(i.e. array-based) implementations".

I haven't read the article in detail.

-- Richard

 

[Eric Sosman]

or is "unboxed" and "unboxed arrays" not really applicable to c ?

"Unboxed" and "boxed" aren't C terms. In some object-
oriented languages, they refer (usually informally) to
simple primitive variables and to full-fledged objects,
respectively. In Java, for example, a `float' variable is
a primitive and a `Float' is an object with a `float' hidden
("boxed") inside it. (Why bother? Because an object is an
instance of a "class," and the class provides "methods" that
code can use without necessarily being fully aware of exactly
what kind of object is at hand. This is said to promote code
reuse; IMHO "promote" is some distance short of "guarantee.")

C has "objects," but not in the way O-O languages use the
term. C's objects are passive receptacles for values; an O-O
language would probably call them primitives or aggregates of
primitives. In other words, all C variables of all kinds are
"unboxed," and there is no way to "box" them.

 

[ben]

ok, thanks v. much for the replies.

 

[Malcolm McLean]

"Unboxed" and "boxed" aren't C terms. In some object-
oriented languages, they refer (usually informally) to
simple primitive variables and to full-fledged objects,
respectively. In Java, for example, a `float' variable is
a primitive and a `Float' is an object with a `float' hidden
("boxed") inside it. (Why bother? Because an object is an
instance of a "class," and the class provides "methods" that
code can use without necessarily being fully aware of exactly
what kind of object is at hand. This is said to promote code
reuse; IMHO "promote" is some distance short of "guarantee.")

C has "objects," but not in the way O-O languages use the
term. C's objects are passive receptacles for values; an O-O
language would probably call them primitives or aggregates of
primitives. In other words, all C variables of all kinds are
"unboxed," and there is no way to "box" them.

Though the equivalent would be, for say a list of x, y, z co-ordinantes

float **coords;

as opposed to

float coords[100][3];

A more illuminating example might be a tree.

typedef struct node
{
struct node *left;
struct node *right;
double data;
}
is the obvious way to do it.

However

struct node
{
int right;
int left;
double data.
};

struct tree
{
struct node nodes[100];
/* left and right index into this array */
};

will tend to produce fewer pointer dereferences and execute faster.

 

[Ben Bacarisse]

Though the equivalent would be, for say a list of x, y, z co-ordinantes

A more illuminating example might be a tree.

typedef struct node
{
struct node *left;
struct node *right;
double data;
}
is the obvious way to do it.

However

struct node
{
int right;
int left;
double data.
};

struct tree
{
struct node nodes[100]; /* left and right index into this array */
};

will tend to produce fewer pointer dereferences and execute faster.

....but also represents a different structure. I suspect the OP will
stare at this and be baffled as to how these two represent boxed and
un-boxed versions of some type.

In a boxed type, it is usual to find the same data inside. You could
have illustrated it with a raw array:

float data[100];

vs. a "boxed" version with high-level access operations:

Array *make_array(size_t n);
void set(Array *a, size_t elem, float value);
float get(Array *a, size_t elem);
float sum(Array *a);

but even this is rather confusing because everything has to be "done
by hand" in C since there is no native language equivalence of boxing
a type.