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

Skybuck Flying wrote:
Rob Kennedy wrote:

Skybuck Flying wrote:
No the point is:

If the variable version is banned then you can't make that
programming mistake.
The mistake being that of passing a static-array variable to the
SizeOf function. There's of course no problem with doing that since
the size of the variable really is the size of the type.

If you do try to make that mistake the compiler will give you a
compile error.

And then a good programmer like you will automatically know what
the problem is, must use SetLength for dynamic arrays.
OK, so when I try to pass the variable to SizeOf, the compiler will
complain and I'll know to fix something. The fix will not be to call
SetLength, though, since that doesn't tell me anything about the size
of the variable.

Instead, I'll need to go look up the declared type of the variable
and enter that type as the argument to SizeOf instead of the variable
itself. The program compiles and all is well.

But now I decide I should have a dynamic array instead of a static
array. So I go change the type declaration of the array type. I
remove the array bounds from the declaration, press Ctrl+F9, and
everything continues to compile.

Oops. The compiler didn't catch the mistake. The mistake that you
were hoping to eliminate by forbidding asking for the size of a
variable. Being required to ask for the size of a type doesn't gain
you anything in this scenario.

Ok, when changing from static array type to dynamic array type, sizeof
would be legal and return 4 bytes for the dynamic array type.

That doesn't fix anything. Delphi already behaves that way.

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.

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.

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.

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.

Static arrays on the stack are a bad idea anyway, think "buffer
overrun".

Who said anything about the stack?

--
Rob
.

Relevant Pages

  • Re: A couple of things from H&S
    ... "If VLA type name appears in a sizeof expression and the value of the ... array size affects the value of sizeof expression, ... Whats analyze? ... compiler determines the type of the expression. ...
    (comp.lang.c)
  • 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 couple of things from H&S
    ... expression of array type decays to a pointer to the array's first ... element *unless* it's in one of three contexts: the operand of sizeof, ... is quite obvious, p is the pointer. ...
    (comp.lang.c)
  • Re: TCHAR and buffer overflows
    ... >> I never use sizeof when I mean countof! ... It can't possibly return the size of the array at compile time ... Maybe sizeofwould be a compiler error, since, as you say, the size can ... than being an unsized array (where countof always returns 1). ...
    (comp.security.misc)
  • Re: TCHAR and buffer overflows
    ... >> I never use sizeof when I mean countof! ... It can't possibly return the size of the array at compile time ... Maybe sizeofwould be a compiler error, since, as you say, the size can ... than being an unsized array (where countof always returns 1). ...
    (comp.os.ms-windows.nt.admin.security)