# An unallocated variable passed as an argument is not PRESENT **URL:** https://fortran-lang.discourse.group/t/an-unallocated-variable-passed-as-an-argument-is-not-present/1724 **Category:** Uncategorized **Created:** [August 19, 2021, 8:45pm UTC](https://fortran-lang.discourse.group/t/an-unallocated-variable-passed-as-an-argument-is-not-present/1724 "2021-08-19T20:45:21Z") **Posts on this page:** 1 **Showing post:** 11
### Author: ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan) #### Post date: [August 22, 2021, 4:56am UTC](https://fortran-lang.discourse.group/t/an-unallocated-variable-passed-as-an-argument-is-not-present/1724/11 "2021-08-22T04:56:25Z")
On this, see comments by @jacobwilliams [**here**](https://fortran-lang.discourse.group/t/best-practices-should-pre-allocated-work-be-passed-to-subroutines/1649/3) (“Make it a class and put the work arrays in the class”) and [**here**](https://fortran-lang.discourse.group/t/what-goes-in-stdlib-and-what-is-separate/1722/6) ("… the object-oriented interface is the real one…"). Should one pay heed to the deprecation by the authors of MFE of the feature mentioned in the original post, an OO approach would make sense. And indeed it’s a pattern preferred in some domains, particularly in industry whereby consumers never directly allocate and use `work areas` such as `worka`, `workb1`, `workb2` or deal with pivots, to state the obvious they navigate at a high level using helper procedures for the same (usually type-bound) that do the needful in terms of setting up the components of the derived type (the class) suitably and the method invocation to do some work is always with the same i.e., with a consistent API, say ```auto call process%work( x ) ! or call work( process, x ) ``` Thus making the feature in question inoperative. --- _[View the full topic](https://fortran-lang.discourse.group/t/an-unallocated-variable-passed-as-an-argument-is-not-present/1724)._