Re: Poll: SizeOf(variable) vs SizeOf(type), should SizeOf(variable)bebanned?

Skybuck Flying wrote:
Rob Kennedy wrote:
That doesn't fix anything. Delphi already behaves that way.

I know that's what I ment.

Your claim is that by forbidding SizeOf on variables, and forcing
SizeOf on types only, the compiler will catch errors. That's simply
not true.

The opposite is also not true, as shown above.

Right. So you've taken a situation where mistakes are possible, introduced an arbitrary rule, and we're left with a situation where all the same mistakes are possible. Thanks.

In other words:

Using SizeOf on variables does not prevent programming mistakes.

I never said it did.

The common case:

SizeOf( on pointer variables )

How will you solve the problem for pointer variables ?

You can't use SizeOf on pointer variable because that will return the
size of the pointer, that is not what you want, you want the size of
the array.

No, when I call SizeOf on a pointer variable, it's because I want to know how big the variable is. If I wanted to know the size of the thing the pointer variable is declared to point to, I would have called SizeOf on something else, or perhaps refered to some other variable that holds the size of the thing the pointer really points to (as opposed to its declared value).

I don't use pointers to point to arrays. For that, I use dynamic arrays, which case I use Length in conjunction with SizeOf to determine the amount of memory occupied by the array data (on the rare occasions when I actually need that information).

What if the pointer is untyped in that case you have no choice but to
use SizeOf on a type.

Why in the world would I be using an untyped pointer? And what could I possibly expect to get when calling SizeOf on the dereferenced pointer?

Alternatively you would need to make the pointer a typed pointer by
adding a Ptype so no matter how you look at it, you still need to
create an additional type, might as well have done that in the first
place.

Yes. Introducing types is very good. It helps you tell the compiler what you're doing.

Conclusion:

Using SizeOf on types is the only way to get it working in all cases.

Just because you had to introduce a typed pointer doesn't mean you have to call SizeOf on that type. You can call it on the dereferenced pointer just as easily. Perhaps even _more_ easily as I explained in my first reply to this topic, since calling SizeOf on a dereferenced pointer variable means you don't need to go find what the declared type of the variable is. The compiler already knows, so let the compiler do the work.

I want to see an example where calling SizeOf on a variable leads to
a mistake that would have been fixed by calling SizeOf on a type
instead.

Mostly besides the point.

The point is:

There are now two ways to do the same thing, one method probably less
universal, why add this potential confusion.

Probably? So you're not even sure this new rule would always work.

By the way, there is one situation in Delphi where calling SizeOf on
a variable is the only thing you can do -- it's impossible to call
SizeOf on that variable's type.

And what would that be ?

I'll give you a hint. It has to do with a certain kind of array.

I have already shown opposite cases:

Calling SizeOf on untyped pointer variables to determine array length
<- flawed.

Calling Abs to get the square root of a number is also flawed. So what?

Calling SizeOf on dynamic array variables to determine array length <-
flawed.

Calling StrToInt to get the capital of Russia is also flawed. So what?

However why would somebody dynamically allocate a static array
instead of using a dynamic array in the first place. Doesn't make
too much sense.
When did I say the static array was being allocated dynamically? If
it were, the same code wouldn't have compiled when the array type was
changed to dynamic.

What reason could you possible have then for calling SizeOf ?

I've called SizeOf to get the size of an *element* of an array. But rarely to get the size of an array itself.

If I had a static array of characters and was passing it to an API function, I would pass the length of the array, not the size. Unicode API functions expect their buffer lengths measured in characters, not bytes.

Static arrays on the stack are a bad idea anyway, think "buffer
overrun".
Who said anything about the stack?

Well that leaves few possiblities:

static arrays in record.
static arrays in objects/classess.

OK. There are also static arrays in the EXE's data section. That is, global and local typed constants.

--
Rob
.

Relevant Pages

  • Re: [C or C++] Is this legal? sizeof *p
    ... where the size of an automatic array is defined at run time. ... > that case if sizeof is applied to a VLA, ... But applying sizeof to a VLA is applying ... > sizeof to an array, not a pointer, and using the name of an array as ...
    (alt.comp.lang.learn.c-cpp)
  • Re: How can I get the size of this?
    ... > I am now having a problem at using sizeof() function ... the pointer. ... Operating on something declared as an array returns the size of the ... LPCSTR is already typedef'd as "const char *", ...
    (microsoft.public.vc.language)
  • Re: De-referencing pointer to function-pointer
    ... >> Either your compiler is broken or you are not invoking it as a C ... >> is a constraint violation to apply the sizeof operator to a function ... >> pointer to the element type of the array. ... >> bytes, of the function, not of a pointer to the function. ...
    (comp.lang.c)
  • Re: A question on string literals
    ... and is why I said "or maybe even `sizeof context'". ... "pointer to T"; ... to first element of array". ... Chris Torek, Wind River Systems ...
    (comp.lang.c)
  • Re: Null terminated strings: bad or good?
    ... specified type, it must not be possible to use callocto allocate such ... allocate such an array, that still doesn't make it possible for ... For any object that you can actually define in your program, with either static or automatic storage duration, "sizeof object" is supposed to give the size of that object; the standard provide no exceptions to this requirement. ...
    (comp.lang.c)