Author |
Message |
Samuel Lobo Poy #1 / 14
|
 Memory size check
I would like to know if someone knows (or has) a C function that returns the size of the memory allocated to a pointer variable. The function would have the pointer as an input. I will be very gratefull if someone can help with the above. Thanks in advance. -- Samuel Lobo Poyo Ingeniero Tec. de Informatica Universidad Carlos III de Madrid Departamento de Ingenieria Electrica, Electronica y Automatica Area de Ingenieria de Sistemas y Automatica C\Butarque 15 Leganes MADRID 28911 Tfn: 34 91 624 99 70
|
Mon, 13 Nov 2000 03:00:00 GMT |
|
 |
Lawrence Kir #2 / 14
|
 Memory size check
Quote: > I would like to know if someone knows (or has) a C function that >returns the size of the memory allocated to a pointer variable. The >function would have the pointer as an input.
There is no portable way to implement such a thing. The normal and correct approach is to make a note of the size when you allocate the object. -- -----------------------------------------
-----------------------------------------
|
Mon, 13 Nov 2000 03:00:00 GMT |
|
 |
Martin Ambuh #3 / 14
|
 Memory size check
: I would like to know if someone knows (or has) a C function that :returns the size of the memory allocated to a pointer variable. The :function would have the pointer as an input. ========== No. There is no standard way of retrieving this information from the pointer. ========== : : I will be very gratefull if someone can help with the above. : : Thanks in advance. : : : :-- :Samuel Lobo Poyo :Ingeniero Tec. de Informatica :Universidad Carlos III de Madrid :Departamento de Ingenieria Electrica, Electronica y Automatica :Area de Ingenieria de Sistemas y Automatica :C\Butarque 15 :Leganes MADRID 28911 :Tfn: 34 91 624 99 70
: : :
|
Mon, 13 Nov 2000 03:00:00 GMT |
|
 |
firewin #4 / 14
|
 Memory size check
Quote:
> : I would like to know if someone knows (or has) a C function that > :returns the size of the memory allocated to a pointer variable. > No. There is no standard way of retrieving this information from the pointer.
And, again, this is an aspect of pointers that unmasks a flaw, not in the programming language, but in the structure and design (or lack thereof) of the program being created. -- (initiator of the campaign for grumpiness where grumpiness is due in c.l.c) Attempting to write in a hybrid which can be compiled by either a C compiler or a C++ compiler produces a compromise language which combines the drawbacks of both with the advantages of neither.
|
Mon, 13 Nov 2000 03:00:00 GMT |
|
 |
John Kugelma #5 / 14
|
 Memory size check
Quote:
> > : I would like to know if someone knows (or has) a C function that > > :returns the size of the memory allocated to a pointer variable. > > No. There is no standard way of retrieving this information from the pointer. > And, again, this is an aspect of pointers that unmasks a flaw, not in the > programming language, but in the structure and design (or lack thereof) of > the program being created.
What flaw would that be? There are numerous standard functions that don't know the size of the data you pass to it, so it would be nice (and a whole lot safer) if there were a way to determine how much storage were actually pointed at by a pointer, which is what I assume the original poster was asking about. The answer is, of course, that the size must be stored along with the pointer if necessary, since an implementation is not required to do so itself, since this space would usually just be wasted. --
I believe we can change anything. I believe in my dream. - Joe Satriani
|
Mon, 13 Nov 2000 03:00:00 GMT |
|
 |
firewin #6 / 14
|
 Memory size check
Quote:
> What flaw would that be?
The flaw of losing a vital piece of information that the programmer should be keeping track of, maybe? -- (initiator of the campaign for grumpiness where grumpiness is due in c.l.c) Attempting to write in a hybrid which can be compiled by either a C compiler or a C++ compiler produces a compromise language which combines the drawbacks of both with the advantages of neither.
|
Mon, 13 Nov 2000 03:00:00 GMT |
|
 |
John Kugelma #7 / 14
|
 Memory size check
Quote:
> > What flaw would that be? > The flaw of losing a vital piece of information that the programmer should be > keeping track of, maybe?
Would you care to have to tell free() exactly how much memory to delete? I'm glad it just "knows", since it means I don't have to keep track of it, the same way that I don't have to tell realloc() how much is already allocated. It's convenient, and much safer. Not every function that is written is program-specific, you know. --
I believe we can change anything. I believe in my dream. - Joe Satriani
|
Tue, 14 Nov 2000 03:00:00 GMT |
|
 |
Lawrence Kir #8 / 14
|
 Memory size check
Quote:
>> > : I would like to know if someone knows (or has) a C function that >> > :returns the size of the memory allocated to a pointer variable. >> > No. There is no standard way of retrieving this information from the > pointer. >> And, again, this is an aspect of pointers that unmasks a flaw, not in the >> programming language, but in the structure and design (or lack thereof) of >> the program being created. >What flaw would that be? There are numerous standard functions that >don't know the size of the data you pass to it, so it would be nice (and >a whole lot safer) if there were a way to determine how much storage >were actually pointed at by a pointer, which is what I assume the >original poster was asking about.
However pointers don't have to point to the start of an array and you don't have to use the rest of an array right up to its end. Therefore even if such a facility were available it would be mostly useless. Defining standard library functions to use such a mechanism would make them far less flexible. Quote: >The answer is, of course, that the size must be stored along with the >pointer if necessary, since an implementation is not required to do so >itself, since this space would usually just be wasted.
If you want it you can create a form of ``fat pointer'' yourself from a structure consisting of a pointer and an integer size field. -- -----------------------------------------
-----------------------------------------
|
Tue, 14 Nov 2000 03:00:00 GMT |
|
 |
Dan P #9 / 14
|
 Memory size check
Quote: >Would you care to have to tell free() exactly how much memory to >delete? I'm glad it just "knows", since it means I don't have to keep >track of it, the same way that I don't have to tell realloc() how much >is already allocated. It's convenient, and much safer.
And it has a major limitation: you MUST pass exactly the same pointer value that was returned by malloc(). This is not a problem for free() and realloc() but it might be a problem for other functions, which can receive a pointer to the middle of a buffer (either dynamically or statically allocated). Functions that *need* to know the size of the buffer passed to them take an additional argument, like the Unix gethostname() or the Win32 GetUserName(). Dan -- Dan Pop CERN, IT Division
Mail: CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
|
Tue, 14 Nov 2000 03:00:00 GMT |
|
 |
firewin #10 / 14
|
 Memory size check
Quote:
> > The flaw of losing a vital piece of information that the programmer should > > be keeping track of, maybe? > Would you care to have to tell free() exactly how much memory to > delete?
No; likewise, I am glad that I do not have to specify alignment requirements to 'malloc(),' or how to obtain this memory. 'malloc()' and 'free()' are both allowed to employ tricks of implimentation; indeed, they need not be written in C at all! Thus, their behaviour does not provide creedence for the 'ptrsize()' beast. Quote: > I'm glad it just "knows", since it means I don't have to keep > track of it, the same way that I don't have to tell realloc() how much > is already allocated.
'free()' and 'realloc()' know how much memory is allocated? Are you sure about that? (Check comp.std.c archives to learn the gruesome truth.) Quote: > Not every function that is written is program-specific, you know.
I am well-aware of that, thank you. -- (initiator of the campaign for grumpiness where grumpiness is due in c.l.c) Attempting to write in a hybrid which can be compiled by either a C compiler or a C++ compiler produces a compromise language which combines the drawbacks of both with the advantages of neither.
|
Tue, 14 Nov 2000 03:00:00 GMT |
|
 |
John Kugelma #11 / 14
|
 Memory size check
Quote:
> > > The flaw of losing a vital piece of information that the programmer should > > > be keeping track of, maybe? > > Would you care to have to tell free() exactly how much memory to > > delete? > No; likewise, I am glad that I do not have to specify alignment requirements > to 'malloc(),' or how to obtain this memory. 'malloc()' and 'free()' are both > allowed to employ tricks of implimentation; indeed, they need not be written > in C at all! Thus, their behaviour does not provide creedence for the > 'ptrsize()' beast.
Yes, that's true. I didn't say there was or should be a way to determine the size of the storage area pointed to by a pointer, but I was responding to your assertion that the program should just "know". General purpose functions can't "know", so you must either tell them the size, or they must work like malloc()/free() and have some magical way of keeping track of the size, if they need to know it. I'm glad there's no ptrsize() type operator/function, since that would needlessly bloat the memory requirements of a program. Quote: > > I'm glad it just "knows", since it means I don't have to keep > > track of it, the same way that I don't have to tell realloc() how much > > is already allocated. > 'free()' and 'realloc()' know how much memory is allocated? Are you sure > about that? (Check comp.std.c archives to learn the gruesome truth.)
If they need to know, they do. That is, they can know this about malloc()/calloc()/realloc()'ed memory. Quote: > > Not every function that is written is program-specific, you know. > I am well-aware of that, thank you.
Methinks I was a bit insulting. I think I type faster than I should. --
I believe we can change anything. I believe in my dream. - Joe Satriani
|
Tue, 14 Nov 2000 03:00:00 GMT |
|
 |
John Kugelma #12 / 14
|
 Memory size check
Quote:
> > > > I would like to know if someone knows (or has) a C function that > > > > returns the size of the memory allocated to a pointer variable. > > What flaw would that be? There are numerous standard functions that > > don't know the size of the data you pass to it, so it would be nice (and > > a whole lot safer) if there were a way to determine how much storage > > were actually pointed at by a pointer, which is what I assume the > > original poster was asking about. > However pointers don't have to point to the start of an array and you > don't have to use the rest of an array right up to its end. Therefore > even if such a facility were available it would be mostly useless. > Defining standard library functions to use such a mechanism would make > them far less flexible.
If there were some way of getting the correct size, whatever that may be, it would be convenient. It can usually only be done for special case functions like malloc()/free(), though. I wasn't saying it could or should, I was just expanding on the original poster's question/idea. Quote: > >The answer is, of course, that the size must be stored along with the > >pointer if necessary, since an implementation is not required to do so > >itself, since this space would usually just be wasted. > If you want it you can create a form of ``fat pointer'' yourself from > a structure consisting of a pointer and an integer size field.
--
I believe we can change anything. I believe in my dream. - Joe Satriani
|
Tue, 14 Nov 2000 03:00:00 GMT |
|
 |
Lawrence Kir #13 / 14
|
 Memory size check
... Quote: >> However pointers don't have to point to the start of an array and you >> don't have to use the rest of an array right up to its end. Therefore >> even if such a facility were available it would be mostly useless. >> Defining standard library functions to use such a mechanism would make >> them far less flexible. >If there were some way of getting the correct size, whatever that may >be, it would be convenient.
The problem is that the ``correct size'' is only something that the program can know, it isn't something that the implementation can guess. That means that it will always come down to the program specifying it at one point or another. Doing that as an extra funcion argument is a natural and clean solution. Another solution would be to create a more complex datastructure that can hold size information. However the program would still have to set up the size information in one way or another. For specific datastructures that would be handy but it would be a nuisance in a lot of other cases. Quote: > It can usually only be done for special >case functions like malloc()/free(), though.
The property of those is that they always work on whole objects. Functions that work on arrays don't have to do that. Quote: > I wasn't saying it could >or should, I was just expanding on the original poster's question/idea.
And I was just pointing out the related problems. :-) -- -----------------------------------------
-----------------------------------------
|
Thu, 16 Nov 2000 03:00:00 GMT |
|
|
|