 |
 |
>>> Phillip Helbig <[log in to unmask]> writes: > a TARGET has to be an address in memory. With PARAMETERs, they > might be stored in normal memory, or in read-only memory, or > whatever, but I think that they don't have to actually be > stored in memory at all. Thus, TARGET wouldn't make much > sense: what does it point to? The TARGET tells the compiler to reserve storage, while the PARAMETER tells it that it can assume that it will never change. Conceptually, the two are orthogonal. The compiler can still perform constant folding, it just has to keep one copy in memory. > precomputed tables are PARAMETER arrays. Just put them all in one > big table with an extra dimension, and switch between them by > deciding what the index of that extra dimension will be. They are not necessarily of the same shape. (The objects in question are two-dimensiona arrays and only the size along the first dimension is fixed.) >>> Richard Maine <[log in to unmask]> writes: > You are thinking about a parameter as just a variable whose value > can't be changed. Exactly. > A parameter is fundamentally a compile-time construct, which may or > may not happen to have a particular run-time manifestation. TARGET would instruct the compiler to provide a run-time manifestation. I can see where you are both coming from philosophically and the arguments make sense from an implementor's point of view. However, I'm not so sure about the user's POV. Thanks anyway! -- Thorsten Ohl, Physics Department, TU Darmstadt -- [log in to unmask] http://heplix.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%