SCOUG-Programming Mailing List Archives
Return to [ 15 |
February |
2004 ]
>> Next Message >>
Content Type: text/plain
"...Sure enough, I don't mess up my memory with stuff I won't
need until later! Egad, I'd hate to see all the leftovers in your
refrigerator. ..."
Interesting that you use a begin-end sequence to allocate and
free storage. You know where to begin and where to end,
but somehow it's a bother to know where to allocate and
where to free. At issue here is a storage type not available
elsewhere except in ALGOL: the automatic storage attribute.
If you used the 'static' storage attribute in your begin-block, it
would not work. Automatic storage is dynamically allocated
at runtime. It doesn't exist in C. Neither does 'controlled' or
'based'. You know that you can't allocate the storage at
procedure entry, because you must first calculate the
dimension values. You know then what you need to allocate.
As you are already in the procedure, it's too late. So you
enter a begin-block which allocates its internal automatic
storage variables on entry. That begin functions the same as
an 'allocate'. The end functions as a 'free'.
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.
You want to go running all over the place, be my guest.
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.
If your reader doesn't understand the different storage
attributes of PL/I, which he certainly would not experience in
any other programming language, then he would not see and
probably not understand the different allocation instances of
an automatic storage variable in the procedure and one in the
begin-block. Nor would he understand the "no" differences
between the static storage instances in both.
PL/I has another unique storage object known as an area
variable. You can declare a fixed area of any size. You can
then allocate and free storage within it. You can even write
it to a file, reread it later on into the same program in a
different location or in a later program. The only storage limit
here is that associated with a file. You can have an unlimited
number of files. So you may have some bookkeeping to take
care of in terms of remembering what is where, but you
certainly don't have any real concerns about running out of
virtual storage.
I won't accept your challenge about the classroom exercise
with respect to the peg solitaire solution using your method. I
won't because it won't work. That's one of the beauties of
'allocate' and 'free': they work regardless.
"...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. I said use allocate and free for
a given matrix instead of begin and end. It minimizes the use
of linear address space. I never said to allocate all your
matrices at the same time, but if you did so, PL/I would
deallocate them correctly on exiting the procedure. You imply
that if you have multiple dynamically allocated matrices
within a begin-block, that one gets allocated and deallocated
before the next. That's definitely not true. It's only true
when you have multiple begin blocks with one matrix each.
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.
In the end I simply want to leave this with my tail between my
legs, not understanding how we could have gotten off on
such a tangent based on explaining the two technical reasons
for inclusion of the 'begin' statement in PL/I. 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.
However, for anyone to claim that less programming or
programming knowledge is required or that an engineer would
naturally prefer one to the other without having the same
insight in both stretches credibility in my opinion.
Peter, I think you ought to use GCC or Watcom C. At least in
either one of them you can't do it in your favorite way. I
think we can find a buyer for your PL/I compiler.
=====================================================
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".
=====================================================
>> Next Message >>
Return to [ 15 |
February |
2004 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
| 
