Re: Embedding Text Data in Source (Was Re: String to Integer)

["Samuel T. Harris" <s_harris@hso.link.com>]

John M. Mills wrote:
> 
> I have a question which diverges slightly from the original topic, but is
> somewhat related.  Please redirect me to "Read The Fine Manual" if that
> is appropriate, but be specific if you can.
> 
> I now provide object parameters for a program in the form of a number of small
> files whose names are passed to the <ObjectType1>.Create(ParamFileName1, ...)
> procedures for each of the objects in my model.  This works fine.  I would
> also like to have a set of default parameters compiled into the code.  Hard-
> coding this would be simple, but I want instead to include as the default
> a specified file from my source tree, verbatim, then use the same parsing
> routines to process either the file image embedded in the code or one read
> under a file name, as transparently as possible using approaches similar to
> the earlier suggestions in this thread: String'Value( ParamStr ) ... etc.
> 
> The present form of my parameter files is similar to this:
> 
> ! comment description
> VersionIDString    ! string to match for error checking
> ! comment lines as desired
> RealValueString    ! parameter value
> ! descriptive comment(s)
> IntegerValueString ! parameter value
> EnumValueString    ! and so forth, with '*ValueString's in fixed order
> ...
> 
> There is no guarantee that a line will have a specific length, but the
> sequence and grouping of parameters by [non-comment] line is well-defined.
> 
> THE QUESTION:
> How can I embed those files' contents in my code automatically at compilation
> so they can be parsed as strings?
> 
> Hope I managed to explain that .. &:^P   I am using GNAT on a variety of
> UNIX platforms.
> 
> Thanks -- john mills --
> 
> --
> John M. Mills, Senior Research Engineer   --   john.m.mills@gtri.gatech.edu
>    Georgia Tech Research Institute, Georgia Tech, Atlanta, GA 30332-0834
>         Phone contacts: 404.894.0151 (voice), 404.894.6258 (FAX)
>  "The 'Quick and Dirty' approach can generally be relied on to be dirty."-RlF

My personal coding standard has long included producing an image and
value
function for any interesting aggregate (record or array) type and these
functions work with strings which appear as Ada aggregates. This way
I can initialize such objects with aggregates in the code, or copy
the aggregate source itself to a data file which I read at runtime.
I find the interoperability of the format to be a great time saver.

I use functions parse and format when I need a syntax which differs
from Ada aggregate syntax and I also sometimes provide a function debug
which produces a string with any extra intrernal debugging info I might
wish to include.

When using image/value, I can use the original source code aggregates
for my data file, and vice versa. No problem there. What is in a
particular
data file just becomes the source for an assignment statement. Cut and
Paste.

When using parse/format (as John would need since his syntax differs
from Ada aggregates) I need filtering utilities to convert the strings.
Since the syntax differs, I cannot use the data file in a direct
assignment
statement. I have to state the text of the data file in a string
and parse that string. The filtering involved is not very complicated.

1. Replace existing double quotes (") with two double quotes ("").
2. Prefix each line with a double quote (").
3. Suffix each line with a double quote (").
4. Add the following to each line except the last line ...

   & ascii.lf &

... if you wish to perserve the newlines implied in the file,
which is usually the case since the end of a line is often
an important delimiter.

5. You are done. The processed text can be inserted into your Ada code
as an source for a initialization of a string object (or constant string
object if you are using Ada83). Note that such a string should be hidden
inside a initialization procedure and not made global to a package.
If global, it will consume memory long after your program has no further
need for it. By staging it inside a procedure, it will (usually) be
placed on the stack as the procedure starts, and then clean away when
the procedure exits (and after you have processed it).

Filtering from such processed text in you Ada source back into a
data file involves performing the inverse steps in reverse order.

Processing John's example gives ...

init_string : constant string :=
"! comment description" & ascii.lf &
"VersionIDString    ! string to match for error checking" & ascii.lf &
"! comment lines as desired" & ascii.lf &
"RealValueString    ! parameter value" & ascii.lf &
"! descriptive comment(s)" & ascii.lf &
"IntegerValueString ! parameter value" & ascii.lf &
"EnumValueString    ! and so forth, with '*ValueString's in fixed order"
;

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"