wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Dec 13, 2019 2:54 am Post subject: |
|
|
John, I typically do not allocate memory for a TYPE with more allocations inside. I said typically on purpose, as it does not bother me to do so. That being said, using a derived TYPE inside another TYPE (and perhaps in another TYPE) is actually a good practice. But, it does take some care when designing the nested TYPE's as well as the code that operates on it/them. I have numerous examples of this in my code.
My most complex is a combination of three %ls, one %rd, and one %rs. A selection in the lead %ls rebuilds the next %ls control, which rebuilds the next %ls control. The %rd is only enabled for input when the last %ls is one specific selection, and the %rs is totally optional. Each of the %ls controls has a separate TYPE (because string lengths are different in each one) that maintains itself. Over this structure is a set of data specific routines that allow the controls to interact. These are then coupled (depending on the function desired) to one of 4 additional sets of control to additional data specification.
I also have a TYPE that allows me to handle the same basic data inside a %lv, but display the data in a specific format. So, I came up with a way of passing the address of a processing routine in the TYPE, and make a dynamic call. The handler for the %lv contents is unique for the specific process, while the generic pieces allow me to select items, remove them from the display (and optionally from the raw data), or sort by a column of the %lv. All generically. Saves a LOT of coding time!
I look at a set of controls that performs one specific function to be a great user of TYPE's. When I then couple that set of controls inside another bunch of controls that use their own TYPE's, I can have two or three separate types, sometimes 3 levels deep.
It is regrettable that Fortran chose the % sign as a data separator, versus using a decimal point like in "C". It makes reading the code a bit more complex to have a %.
Bill |
|