sizeof([ALLOCATED MEMORY])

[ballpointpenthief]

If I have malloc()'ed a pointer and want to read from it as if it were
an array, I need to know that I won't be reading past the last index.

If this is a pointer to a pointer, a common technique seems to be
setting a NULL pointer to the end of the list, and here we know that
the allocated memory has been exhausted. All good.

When this is a pointer to another type, say int, I could have a
variable that records how much memory is being allocated and use that
to track the size of the 'array'.
Alternatively, we could set the end of the 'array' to some kind of
error-code, such as 99 or MAX_INT.
I don't like either of these techniques.

So, what is a good way to stop a loop reading or writing past the
memory allocated to a pointer?
Or if possible, what is a good way of determining the size of memory
allocated to a pointer?

Cheers,
Matt

[Howard Hinnant]

In article <44************ ***@yahoo.com>,
CBFalconer <cb********@yah oo.com> wrote:

Howard Hinnant wrote:

Keith Thompson <ks***@mib.or g> wrote:

... snip ...

You're assuming the information is there. I can imagine that it
might be either nonexistent or meaningless in some implementations .
(I don't know enough about actual implementations to know how
common this is.)

I know. I've written commercial malloc systems for both desktop and
embedded (even bareboard) systems. If you're going to implement the C
realloc interface, you have to know the size of a pointer passed to you.

Not necessarily. Consider the hypothetical "one time use"
allocater. realloc need only allocate a new chunk of the
appropriate size and copy the old over. It doesn't need to know
the size of the old, even for the copying if it can detect 'the
end' by some other means, analogous to encountering EOF.

I never said that sizeof_alloc(p) should have O(1) complexity. That
indeed would be over constraining. The "one time use" allocator still
must know the sizeof_alloc(p) in order to realloc; in the same way that
strlen(s) knows the size of the string s. One way or another, it must
know the size of the old memory to copy.

The smart interface would combine an allocation (e.g. malloc), with the
size query, so that an efficient implementation is more likely:

I'm requesting N bytes. Please give me the pointer (if able) and the
actual number of bytes it is pointing to.

-Howard

[CBFalconer]

Howard Hinnant wrote:

In article <44************ ***@yahoo.com>,
CBFalconer <cb********@yah oo.com> wrote:

Howard Hinnant wrote:

Keith Thompson <ks***@mib.or g> wrote:

... snip ...

>
> You're assuming the information is there. I can imagine that it
> might be either nonexistent or meaningless in some implementations .
> (I don't know enough about actual implementations to know how
> common this is.)

I know. I've written commercial malloc systems for both desktop and
embedded (even bareboard) systems. If you're going to implement the C
realloc interface, you have to know the size of a pointer passed to you.

Not necessarily. Consider the hypothetical "one time use"
allocater. realloc need only allocate a new chunk of the
appropriate size and copy the old over. It doesn't need to know
the size of the old, even for the copying if it can detect 'the
end' by some other means, analogous to encountering EOF.

I never said that sizeof_alloc(p) should have O(1) complexity. That
indeed would be over constraining. The "one time use" allocator still
must know the sizeof_alloc(p) in order to realloc; in the same way that
strlen(s) knows the size of the string s. One way or another, it must
know the size of the old memory to copy.

Read again please. I postulated a copy mechanism that detected the
equivalent of EOF. Much like:

while (*dest++ = *source++) continue;

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell. org/google/>
Also see <http://www.safalra.com/special/googlegroupsrep ly/>

[Tomás]

CBFalconer posted:

while (*dest++ = *source++) continue;

Redundant, yet nonetheless depictive, use of "continue".

I wonder, however, if it would hinder the compiler's optimization?
-Tomás

[pete]

Tomás wrote:

CBFalconer posted:

while (*dest++ = *source++) continue;

Redundant, yet nonetheless depictive, use of "continue".

There are some style guidlines against writing code like this:
while (*dest++ = *source++);
because it looks like an accident.

Myself, I would write that this way:
do {
*dest = *source++;
} while (*dest++ != 0);

I'm not into cramming vertical space.

--
pete

[Tomás]

pete posted:

There are some style guidlines against writing code like this:
while (*dest++ = *source++);
because it looks like an accident.

while (*dest++ = *source++); /* Not an accident */

;)

Myself, I would write that this way:
do {
*dest = *source++;
} while (*dest++ != 0);

More than one way to skin a cat. If I were looking for the most efficient
way, I'd use the "register" keyword for "dest" and "source", and I'd
probably do the following:

while ( *dest = *source ) ++dest, ++source;

This would remove the redundant last incrementation.

-Tomás

[pete]

Tomás wrote:

More than one way to skin a cat.
If I were looking for the most efficient way,
I'd use the "register" keyword for "dest" and "source",
I don't use the register keyword.

"Smaller, faster programs can be expected if register
declarations are used appropriately, but future improvements
in code generation may render them unnecessary."
-- K&R, A 8.1, 1978
and I'd probably do the following:

while ( *dest = *source ) ++dest, ++source;

This would remove the redundant last incrementation.

http://www.prism.uvsq.fr/~cedb/local_copies/lee.html
Optimization is simply waste of programmer time if any of these
statements are true:
parts of the program haven't been written yet
the program is not fully tested and debugged
it seems to run fast enough already

Jackson's Rules of Optimisation:
Rule 1: Don't do it.
Rule 2: (for experts only) Don't do it yet - that is, not until you
have a perfectly clear and unoptimized solution.
- Michael Jackson

--
pete

[Tomás]

pete posted:

Jackson's Rules of Optimisation:
Rule 1: Don't do it.
Rule 2: (for experts only) Don't do it yet - that is, not until you
have a perfectly clear and unoptimized solution.
- Michael Jackson

I prefer to think for myself -- I tend to be more open-minded, more
creative, more inventive, more intuitive, and more intelligent than the
person who's trying to spoon-feed me guidelines.

The following code is A-OK by me:

void Strcpy( register char* dest, register const char* source )
{
while ( *dest = *source ) ++dest, ++source;
}
You have your way of doing things, and I have mine. I'm sure we both get
the job done... but I get that extra sprinkle of satisfaction from knowing
I perfected the code to the best of my ability.

-Tomás

[Al Balmer]

On Tue, 16 May 2006 04:21:29 GMT, "Tomás" <NU**@NULL.NULL > wrote:

pete posted:

Jackson's Rules of Optimisation:
Rule 1: Don't do it.
Rule 2: (for experts only) Don't do it yet - that is, not until you
have a perfectly clear and unoptimized solution.
- Michael Jackson

Rule 2.5: It's much easier to make correct code fast than to make fast
code correct.

I prefer to think for myself -- I tend to be more open-minded, more
creative, more inventive, more intuitive, and more intelligent than the
person who's trying to spoon-feed me guidelines.

The following code is A-OK by me:

void Strcpy( register char* dest, register const char* source )
{
while ( *dest = *source ) ++dest, ++source;
}
You have your way of doing things, and I have mine. I'm sure we both get
the job done... but I get that extra sprinkle of satisfaction from knowing
I perfected the code to the best of my ability.

It's even possible that the compiler can optimize this code in spite
of your attempt to interfere ;-)

--
Al Balmer
Sun City, AZ

[Zara]

On Tue, 16 May 2006 04:21:29 GMT, "Tomás" <NU**@NULL.NULL > wrote:

pete posted:

Jackson's Rules of Optimisation:
Rule 1: Don't do it.
Rule 2: (for experts only) Don't do it yet - that is, not until you
have a perfectly clear and unoptimized solution.
- Michael Jackson

I prefer to think for myself -- I tend to be more open-minded, more
creative, more inventive, more intuitive, and more intelligent than the
person who's trying to spoon-feed me guidelines.

The following code is A-OK by me:

void Strcpy( register char* dest, register const char* source )
{
while ( *dest = *source ) ++dest, ++source;
}
You have your way of doing things, and I have mine. I'm sure we both get
the job done... but I get that extra sprinkle of satisfaction from knowing
I perfected the code to the best of my ability.

-Tomás

Well, you could be surprised to see the assembler code geenrated by
the compiler. Many timed, the followin lines give all of them the same
final code:

while ( *dest = *source ) ++dest, ++source;

for(;*dest = *source;++dest, ++source);

while ( *dest++ = *source++ );

for(;*dest++ = *source++;);

None of them is the most optimal until proven woth some profiler. You
may choose your preferred style, but don't take for grnated it is the
more optimized solution. Optimum solutions may be optimum in code size
but not in speed, or the contrary, or optimum in local stack size but
not in code size, or whatever.

Profile the results of your compiler. This is not a guideline, this is
the only recognized way to find where to optimize your code.

Best regards,

Zara

[Tomás]

while ( *dest = *source ) ++dest, ++source;
This one doesn't do a redundant final incrementation.

for(;*dest = *source;++dest, ++source);

Nor does this one.

while ( *dest++ = *source++ );

This one does however.

for(;*dest++ = *source++;);

As does this one.
-Tomás