Re: Promoting unsigned long int to long int

[Keith Thompson]

pereges <Br*****@gmail. comwrites:
[...]

#define ulong unsigned long int
#define uchar unsigned char

[...]

These types already have perfectly good names already. Why give them
new ones?

If you must rename them for some reason, use typedefs, not macros.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

pereges <Br*****@gmail. comwrites:

btw, i see a lot of people saying that size_t must be used over
unsigned long. The question is are there any fix guidelines as to when
i should and when i shouldn't use size_t. It seems to me that size_t
is most commonly used in three situations :

1. Size of array or any object.
2. Array indices.
3. Count of something.

Although I don't see why using unsigned long for any of the above
could be wrong. It may not be a necessity to use size_t

size_t can represent the size in bytes of any object (since it's the
type of the result of the sizeof operator and of the argument to
malloc(). It can therefore represent the size in elements of any
array object, making it suitable for array indices.

The third is a bit more iffy; it depends on what you're counting.

But there are no such guarantees for unsigned long. Consider a
hypothetical system where unsigned long is 32 bits and size_t is 64
bits. You might have objects whose size cannnot be represented as an
unsigned long value.

The question is, why would you want to use unsigned long rather than
size_t?

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

pereges wrote:

btw, i see a lot of people saying that size_t must be used over
unsigned long. The question is are there any fix guidelines as to when
i should and when i shouldn't use size_t. It seems to me that size_t
is most commonly used in three situations :

1. Size of array or any object.
2. Array indices.
3. Count of something.

Although I don't see why using unsigned long for any of the above
could be wrong. It may not be a necessity to use size_t

size_t is for counting parts of an object.
That's cases 1 and 2 of your list.
In terms of efficiency, you can expect that size_t
will probably be the fastest type that is big enough
to do the job.

When I count nodes in linked list, I use long unsigned.
The number of nodes that malloc can generate,
isn't related to size_t.

--
pete

[santosh]

pereges wrote:

btw, i see a lot of people saying that size_t must be used over
unsigned long. The question is are there any fix guidelines as to when
i should and when i shouldn't use size_t. It seems to me that size_t
is most commonly used in three situations :

1. Size of array or any object.

This is the purpose of size_t.

2. Array indices.

IMHO, any unsigned type of suitable range will do. Sometimes signed
types are convenient too, for certain forms of loops, and rarely, to
index with a negative offset.

3. Count of something.

Again a suitable unsigned type, not necessarily size_t should be okay.

Although I don't see why using unsigned long for any of the above
could be wrong. It may not be a necessity to use size_t

You are correct. In C, size_t has the only purpose of being large enough
to hold the size in bytes of the largest possible single object. Also
the sizeof operator yields a size_t value for related reasons. It is
not necessarily a suitable type for counting things are holding
offsets, indexes and such.

Generally, a careful examination of the origin, purpose and types of use
a value may be subject to will give you a clue as to the most suitable
type of object to represent it.

[pereges]

On Jun 30, 11:19 pm, santosh <santosh....@gm ail.comwrote:

1. Size of array or any object.

This is the purpose of size_t.

2. Array indices.

IMHO, any unsigned type of suitable range will do. Sometimes signed
types are convenient too, for certain forms of loops, and rarely, to
index with a negative offset.

3. Count of something.

Again a suitable unsigned type, not necessarily size_t should be okay.

Although I don't see why using unsigned long for any of the above
could be wrong. It may not be a necessity to use size_t

You are correct. In C, size_t has the only purpose of being large enough
to hold the size in bytes of the largest possible single object. Also
the sizeof operator yields a size_t value for related reasons. It is
not necessarily a suitable type for counting things are holding
offsets, indexes and such.

Generally, a careful examination of the origin, purpose and types of use
a value may be subject to will give you a clue as to the most suitable
type of object to represent it.

Thanks for the clarification. After reading this, I guess I will
continue using unsigned long for all the 3 situations.

[pereges]

On Jun 30, 11:13 pm, Keith Thompson <[e-mail] rote:

size_t can represent the size in bytes of any object (since it's the
type of the result of the sizeof operator and of the argument to
malloc(). It can therefore represent the size in elements of any
array object, making it suitable for array indices.

The third is a bit more iffy; it depends on what you're counting.

But there are no such guarantees for unsigned long. Consider a
hypothetical system where unsigned long is 32 bits and size_t is 64
bits. You might have objects whose size cannnot be represented as an
unsigned long value.

The question is, why would you want to use unsigned long rather than
size_t?

Suppose I have a structure:

struct mesh
{
unsigned long nvert; /* number of vertices */
unsigned long ntri; /* number of triangles */
vector *vert; /* pointer to array of vertices */
triangle *tri; /* pointer to array of triangles */
};

Now, according to what you are saying nvert and ntri should have data
type size_t instead. In my program its possible for nvert and ntri to
be in millions. I have been adviced that size_t in many cases causes
loss of data, hence I'm skecptical about its use. Also, I would want
to keep things consistent.

[Keith Thompson]

pereges <Br*****@gmail. comwrites:

On Jun 30, 11:19 pm, santosh <santosh....@gm ail.comwrote:

1. Size of array or any object.

This is the purpose of size_t.

2. Array indices.

IMHO, any unsigned type of suitable range will do. Sometimes signed
types are convenient too, for certain forms of loops, and rarely, to
index with a negative offset.

3. Count of something.

Again a suitable unsigned type, not necessarily size_t should be okay.

Although I don't see why using unsigned long for any of the above
could be wrong. It may not be a necessity to use size_t

You are correct. In C, size_t has the only purpose of being large enough
to hold the size in bytes of the largest possible single object. Also
the sizeof operator yields a size_t value for related reasons. It is
not necessarily a suitable type for counting things are holding
offsets, indexes and such.

Generally, a careful examination of the origin, purpose and types of use
a value may be subject to will give you a clue as to the most suitable
type of object to represent it.

Thanks for the clarification. After reading this, I guess I will
continue using unsigned long for all the 3 situations.

Um, why? It will probably work, but for case 1 size_t is exactly the
right type, and for case 2 it's guaranteed to work, while unsigned
long isn't.

It sounds like you want to use unsigned long if at all possible, and
use size_t only if it's absolutely necessary. Why is that?

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pereges]

On Jul 1, 1:24 am, Keith Thompson <[e-mail] rote:

Um, why? It will probably work, but for case 1 size_t is exactly the
right type, and for case 2 it's guaranteed to work, while unsigned
long isn't.

It sounds like you want to use unsigned long if at all possible, and
use size_t only if it's absolutely necessary. Why is that?

Mainly because my project has grown beyond 1000 lines and now its
becoming more and more difficult to keep track of things. That's why I
wanted to keep things a little consistent.

[pereges]

btw can i sort an array of pointers with qsort function ?? I tried the
following but failed miserably as it reutrned the same unsorted list :
int cmp_coord_x(con st void *vpa, const void *vpb)
{
const vector *va = vpa;
const vector *vb = vpb;

return (va->coord[0] < va->coord[0] ? -1 : vb->coord[0] vb-

>coord[0]);

}

int cmp_coord_y(con st void *vpa, const void *vpb)
{
const vector *va = vpa;
const vector *vb = vpb;

return (va->coord[1] < va->coord[1] ? -1 : vb->coord[1] vb-

>coord[1]);

}

int cmp_coord_z(con st void *vpa, const void *vpb)
{
const vector *va = vpa;
const vector *vb = vpb;

return (va->coord[2] < va->coord[2] ? -1 : vb->coord[2] vb-

>coord[2]);

}

/* axis is used as criterion on how we sort the array */
if (axis == 0)
{
qsort(parent_vp a, sizeof parent_vpa/ sizeof *parent_vpa,
sizeof *parent_vpa, cmp_coord_x);
}
if (axis == 1)
{
qsort(parent_vp a, sizeof parent_vpa/ sizeof *parent_vpa,
sizeof *parent_vpa, cmp_coord_y);
}
if (axis == 2)
{
qsort(parent_vp a, sizeof parent_vpa/ sizeof *parent_vpa,
sizeof *parent_vpa, cmp_coord_z);
}

[Ben Bacarisse]

pereges <Br*****@gmail. comwrites:

btw can i sort an array of pointers with qsort function ??

Yes, you can.

I tried the
following but failed miserably as it reutrned the same unsorted list :
int cmp_coord_x(con st void *vpa, const void *vpb)
{
const vector *va = vpa;
const vector *vb = vpb;

The array is an array of vector *. The void * you get in the compare
points to an array element -- it is a void * but it points to a vector
**. This is in the FAQ. If you don't mind a cast:

const vector *va = *(const vector *const *)vpa;
const vector *vb = *(const vector *const *)vpb;

return (va->coord[0] < va->coord[0] ? -1 : vb->coord[0] vb->coord[0]);

You have your va's and vb's mixed up. I think you wanted:

return (va->coord[0] < vb->coord[0] ? -1 : va->coord[0] vb->coord[0]);

}

int cmp_coord_y(con st void *vpa, const void *vpb)
{
const vector *va = vpa;
const vector *vb = vpb;

return (va->coord[1] < va->coord[1] ? -1 : vb->coord[1] vb-

>>coord[1]);

}

int cmp_coord_z(con st void *vpa, const void *vpb)
{
const vector *va = vpa;
const vector *vb = vpb;

return (va->coord[2] < va->coord[2] ? -1 : vb->coord[2] vb-

>>coord[2]);

}

/* axis is used as criterion on how we sort the array */
if (axis == 0)
{
qsort(parent_vp a, sizeof parent_vpa/ sizeof *parent_vpa,
sizeof *parent_vpa, cmp_coord_x);
}
if (axis == 1)
{
qsort(parent_vp a, sizeof parent_vpa/ sizeof *parent_vpa,
sizeof *parent_vpa, cmp_coord_y);
}
if (axis == 2)
{
qsort(parent_vp a, sizeof parent_vpa/ sizeof *parent_vpa,
sizeof *parent_vpa, cmp_coord_z);
}

I'd use an array of function pointers and write:

qsort(parent_vp a, sizeof parent_vpa / sizeof *parent_vpa,
sizeof *parent_vpa, cmp_coord[axis]);

the array would be:

typedef int compare_functio n(const void *, const void *);
compare_functio n *cmp_coord[] = {
cmp_coord_x, cmp_coord_y, cmp_coord_z
};

(not compiled so beware syntax errors).

--
Ben.

[Barry Schwarz]

On Mon, 30 Jun 2008 12:04:04 -0700 (PDT), pereges <Br*****@gmail. com>
wrote:

>On Jun 30, 11:13 pm, Keith Thompson <[e-mail] rote:

>size_t can represent the size in bytes of any object (since it's the
type of the result of the sizeof operator and of the argument to
malloc(). It can therefore represent the size in elements of any
array object, making it suitable for array indices.

The third is a bit more iffy; it depends on what you're counting.

But there are no such guarantees for unsigned long. Consider a
hypothetical system where unsigned long is 32 bits and size_t is 64
bits. You might have objects whose size cannnot be represented as an
unsigned long value.

The question is, why would you want to use unsigned long rather than
size_t?

Suppose I have a structure:

struct mesh
{
unsigned long nvert; /* number of vertices */
unsigned long ntri; /* number of triangles */
vector *vert; /* pointer to array of vertices */
triangle *tri; /* pointer to array of triangles */
};

Now, according to what you are saying nvert and ntri should have data
type size_t instead. In my program its possible for nvert and ntri to
be in millions. I have been adviced that size_t in many cases causes
loss of data, hence I'm skecptical about its use. Also, I would want
to keep things consistent.

SIZE_MAX can be as small as 65K while ULONG_MAX must be at least 4G.
Check your system, or your portability goals, to determine if this a
concern.
Remove del for email