SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 15 Feb 2004 11:40:31 PST8
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: PL/I most important statement (was: call(TZ) ? - PL/I)

Content Type: text/plain

Lynn H. Maxson wrote:
>
> Automatic storage is dynamically allocated
> at runtime. It doesn't exist in C. Neither
> does 'controlled' or 'based'.

Well, just code the required setup. *You're* the one who likes to
explicitly allocate.

> If you believe that it is somehow cleaner or less
> messy in storage management or memory fragmentation
> with begin-end than allocate-free, then you are wrong.
> You actually use more storage. If you use multiple
> begin-ends, your memory fragmentation increases along
> with storage increases.

There's no memory fragmentation. All arrays are completely gone at the
end of each BEGIN block. The next BEGIN block allocates at the same
starting point.

That's another nice thing about BEGIN blocks. You can't accidentally
allocate your next array before you deallocate your last one.

Perhaps you've confused memory fragmentation with your expectation that
virtual memory would solve the problem?

> Whoever showed you the cute trick in your PL/I
> class didn't do you any favors. I will guarantee
> you that none of the PL/I authors did.

It wasn't a class, Lynn. It was one of the IBM books. Since IBM was
heavily pushing PL/I at the time, they used their best people as
writers.

> "...Lynn is asking why not just allocate all the arrays
> at the same time, which uses up more linear address space.
> I previously gavean example where each BEGIN block
> automatically deallocated a processed array before
> allocating the next one, thus minimizing the use of linear
> address space. ..."
>
> Do me two favors here, don't mislead about what I said
> and mislead about what you said.

??? See your Saturday morning message. And see my Saturday morning
response.

> I said use allocate and free for a
> given matrix instead of begin and end.

No, I'm sorry but that's not what you said. You said:

"You could have achieved both with an
allocate statement, letting the system
deallocate on procedure end."

There's a _big_ difference between specifically deallocating (either by
statement or by ENDing a BEGIN block) and allowing all allocations to
build up until you leave the PROCEDURE which forces deallocation.

> I never said to allocate all
> your matrices at the same time

??? See your Saturday evening message. That's the one where you
claimed my BEGIN block method wasn't capable of more than one matrix at
a time.

> You imply that if you have multiple dynamically
> allocated matrices within a begin-block, that one
> gets allocated and deallocated before the next.

I never implied any such thing. See my example, Lynn. It specifically
shows separate BEGIN blocks.

> If you don't understand why entering a begin-block within
> a procedure can increase linear storage usage and most
> definitely does in your particular use, I will attempt to
> explain why to you. It increases linear storage for the
> code space as well as the data space.

That's not much of an explanation. Can you be more specific? If you're
trying to compare a handful of setup instructions to ten's of megabytes
of wasted array space and you are deciding these things are equal in
magnitude, then say so.

> If you don't want to use 'allocate' and 'free'
> and the broader freedom they allow than possible
> with 'begin-end', that's your business.

I don't need that freedom for what I'm doing. I'm not processing linked
records. I'm processing matrices.

I'll even mention *another* good reason to use BEGIN blocks instead of
explicit allocation. The compiler will tell _me_ if I forget to
deallocate because of a missing END statement. The compiler won't tell
_you_ nothin' if you forget an explicit deallocate. Ha!

- Peter

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 15 | February | 2004 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.