| Re: Naive pointer question ? [message #28993 is a reply to message #28944] |
Thu, 24 January 2002 15:17   |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
"David Burridge" <dave@clogic.f9.co.uk> writes:
> Hi Paul et al.
>
>> <BIG snip>
>> p.s. Common blocks are not evil. They are unfairly maligned (and
> misaligned) but should be used
>> judiciously.... just like GOTOs.
>
>
> Sorry, I couldn't resist this!!! The problem with common blocks two-fold,
> both relating to their global scope (ie: the reason for using them in the
> first place). First, if you have two programs running in an IDL session
> (e.g. a pair of widget programs) which both use the same common block, each
> will corrupt the others data. In fact, you might even just be using two
> routines that don't realise another is accessing the common block. Secondly,
> you cannot trace the changes in a common block, so debugging becomes a
> nightmare. This is even worse in IDL when variables can change TYPE as well
> as value.
>
> That's it. Rant over:-) Let's just say, I gave them up a LONG time ago!-)
I think I've weighed in on this before, but I won't let that stop my
yapping. I think there are at least two cases where common blocks are
pretty nice.
The first one is where you need a persistent store of information.
For example, CMPS_FORM() keeps a list of printer configurations in a
common block. I also keep large tables in a common block, so they are
initialized only once to save CPU cycles. Any time you need a
procedure to "remember" something from one call to the next, common
blocks are actually a pretty good idea.
Another case is for argument passing between tightly coupled
procedures, typically ones in the same file. I use this in MPFITFUN
to pass the user's arguments. Since the underlying driver, MPFIT(),
doesn't understand about the user function, there must be some way to
pass the data along. I tried pointers (handles) for awhile, but a few
heap leaks later I was hatin' that. I also use a common so that the
user function can (optionally!) return an error code.
The key is access control. In the first case the access to the common
block is through a single function, so no other functions should
interfere. Part of that solution is giving a name to your common
block which is unique so there is virtually no chance of conflict with
some other common.
In the second case there is still access control. Generally speaking,
I think there should only be one assigned writer to a common block,
and any other functions should be readers. Mixed writing and reading
can get hairy. Furthermore, in the "use-commons-to-pass-arguments"
approach, I always guarantee that when control returns to the user
there is nothing vitally important in the common block, so that it can
be wiped clean with impunity on the next call.
Common-ly yours,
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
