Re: Differences in data description in programming languages

From: Robert Wagner (spamblocker-robert_at_wagner.net)
Date: 11/30/04 

Date: Tue, 30 Nov 2004 03:04:33 GMT

On 29 Nov 2004 10:56:46 -0800, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <spamblocker-robert@wagner.net> wrote
>
>> >What was misleading, or in fact misinformation was 'C did it
>> >statically, same as Cobol'.
>>
>> The context of the discussion was a comparison between variable
>> creation at execution-time vs. compile-time. Normal C variables are
>> created at compile time. When memory is allocated is a technical
>> detail.
>
>You seem to be attempting to side step your misinformation by claiming
>that automatics are the same as statics except for a 'technical
>detail'.

I was thinking of old C programs, where most variables were global. In
any case, the compiler carves out memory. They are not malloc-ed by
the programmer nor execution-time action such as dynamic OO
constructors.

>> Conceptually, the variable exists when the program or function
>> begins execution.
>
>That certainly is true of statics _and_ automatics. But there is a
>significant difference in that automatics cannot be returned to the
>caller by, for example, providing a reference to it.

References are normally passed IN, not OUT. There's an idea --
CALL 'foo' USING NOTHING RETURNING a, b, c.

>But you also failed to notice that it is a similar 'technical detail'
>with OO that an object 'exists when the program or function begins
>execution' when the 'program' is the class contructor.

Is that true? I thought the C++ object was a pointer to the real
object. In either case, you are correct when you say the object exists
when the program starts.

>> >> Index out of bounds, stack overflow, buffer overrun, heap full
>> >
>> >Those can happen in Cobol too, and have nothing to do with pointers.
>> >Index out of bounds is arrays, not pointers. Stack overflow and Heap
>> >full are not related to pointers directly.
>>
>> Those are SOME of the ways object pointers are overwritten, which
>> causes errors that are difficult to find.
>
>Heap full and stack overflow are terminal conditions which are
>generally not avoidable by the programmer. In most OO system that I
>know about the run-time detects these and 'abends' unless the
>programmer deals with it. They were an issue with non-OO system when
>the pointer created by malloc() was not checked by the programmer, in
>OO systems an exception will be passed up the process until it is
>checked or results in the run-time bailing out.
>
>In other words OO _does_ protect against those, or abends.

 I stand corrected. But that applies only to 100% OO programs. Any use
of C in a C++ program (or pointer in OO Cobol) voids the warranty.

>Index out of bounds on an array must be manually checked in non-OO
>unless the run-time does it such as in Cobol. In OO using an Array
>class (using an OCCURS nn is _NOT_ using OO) an ArrayIndexOutOfBounds
>exception is generated _without_ memory being scribbled on.
>
>In other words OO _does_ protect against this.

Same as above. Remember that strings in C are arrays.

>Buffer overrun can happen in C because the weak typing of strings has
>no length limit. With OO the strong typing and encapsulation prevents
>objects being overwritten.
>
>In other words OO _does_ protect against this.

Well said. You're right.

>> Every time a C++ program dynamically constructs an object using NEW,
>> the return is a pointer or a null. If the program fails to check for
>> null, it will abend when it tries to touch the object.
>
>You need to learn what an exception is and how the exception system
>works.
>
>A constructor will _NOT_ return NULL, it will throw an exception. If
>the caller does not catch that exception then it will be passed back
>to that procedure's caller until a catcher of that exception type is
>found. If it percolates up to the run-time then this will stop the
>program.
>
>In other words OO _does_ protect against this with exceptions.

Not true for VC++ 6.0, which returns a null pointer. I suspect it was
done deliberately (overloaded?) to give the application an opportunity
to free memory.

Relevant Pages

  • Re: how to prevent ACCESS_VIOLATION (C0000005) without SetUnhandledExceptionFilter
    ... > cause the access exception for a stack guard page to be eaten if you ... > try validating a bad pointer that happens to point to a guard page. ... Exception are for memory allocated outside the mm. ...
    (alt.lang.asm)
  • Re: how to prevent ACCESS_VIOLATION (C0000005) without SetUnhandledExceptionFilter
    ... cause the access exception for a stack guard page to be eaten if you ... try validating a bad pointer that happens to point to a guard page. ... Exception are for memory allocated outside the mm. ...
    (alt.lang.asm)
  • Re: Alignment issue on MIPS platform
    ... Well, you need to make sure that your TOS value is appropriate for a double, ... If the pointer you use has to be divisible by 8 ... the dissasembly and found the place the where the exception happens. ... memory on the heap with a given size. ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: size of object
    ... consume ANY memory. ... a perverted implementation may choose to do ... ie. the size of a pointer. ... figure out at compile time what function you want to call, ...
    (comp.lang.cpp)
  • Re: Thread crashing on return instruction...
    ... Does the returning thread free some ... memory used by the other thread and NULL out the pointer? ... > giving a First Chance Exception. ...
    (microsoft.public.windowsce.embedded)
Loading