handling Java properties

[Time Waster]

Java property files are dead simple:
key1=val1
some.key2=val2

For simplicity on the Java side, I'd like to use these files from C
as well (the C program and Java program must cooperate). Anyone have
any bright ideas on handling this sort of thing from C? Is there
any preexisting libraries or calls that would help?

One idea I had was to have a big enumerated type of the key names (which are
known ahead of time):
enum { key1 = 0, key2, key3 , MAXKEY}
char *keys[MAXKEY];

Then as I read the keys from the file, I could somehow fill in
the array:
<read key1=val1>
keys[key1] = val1;

But that led me to the dead end because even if I have stringvar == "key1"
that doesn't get me to the bareword needed to have an enumerated reference.
Of course, I could have another stupid array of structs defined mapping the
key1 enumeration thingy to "key1" as a string, but that seems kind of
ugly. Is there a way to get the enumerated constant key1 from the
string value "key1"?

TIA

[Chris Dollin]

Time Waster wrote:

Java property files are dead simple:
key1=val1
some.key2=val2

For simplicity on the Java side, I'd like to use these files from C
as well (the C program and Java program must cooperate). Anyone have
any bright ideas on handling this sort of thing from C? Is there
any preexisting libraries or calls that would help?

`fgets` to read lines, `strchr` to find characters, `malloc` to allocate
space -- that sort of thing?

One idea I had was to have a big enumerated type of the key names (which are
known ahead of time):
enum { key1 = 0, key2, key3 , MAXKEY}
char *keys[MAXKEY];

Mmmm.

Then as I read the keys from the file, I could somehow fill in
the array:
<read key1=val1>
keys[key1] = val1;

All the values had better have the same type, then.

But that led me to the dead end because even if I have stringvar == "key1"
that doesn't get me to the bareword needed to have an enumerated reference.

No. You'll have to map from the name to the value. Or you could just
look the things up on demand.

Of course, I could have another stupid array of structs defined mapping the
key1 enumeration thingy to "key1" as a string, but that seems kind of
ugly.

/Someone/ has to have that mapping. This is "Mr Bare Bones" C, so it's
the programmers job to define the mapping.

I'd just have a hash table mapping the keys (eg "some.key2") to their
values ("val2") and load that from the property file. I'm likely to
have hash-table code around anyway, so I'd use that. I wouldn't
bother with the `keys` array: for rarely-accessed elements I don't
think it's worth it, for frequently-accessed elements I'd probably
end up stuffing them into some context object with a more useful
access path than `keys[ENUM]`.

Is there a way to get the enumerated constant key1 from the
string value "key1"?

Not built-in, no.

--
"It's just the beginning we've seen." - Colosseum, /Tomorrow's Blues/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Eric Sosman]

Time Waster wrote:

Java property files are dead simple:
key1=val1
some.key2=val2

<off-topicSimple, but not quite *that* simple ... </off-topic>

For simplicity on the Java side, I'd like to use these files from C
as well (the C program and Java program must cooperate). Anyone have
any bright ideas on handling this sort of thing from C? Is there
any preexisting libraries or calls that would help?

Much depends on what you mean by "handling." Do you need to read
properties? Write them? Both? With what kind of reliability and/or
promptness must updated properties make it into the file?

One idea I had was to have a big enumerated type of the key names (which are
known ahead of time):
enum { key1 = 0, key2, key3 , MAXKEY}
char *keys[MAXKEY];

Then as I read the keys from the file, I could somehow fill in
the array:
<read key1=val1>
keys[key1] = val1;

But that led me to the dead end because even if I have stringvar == "key1"
that doesn't get me to the bareword needed to have an enumerated reference.
Of course, I could have another stupid array of structs defined mapping the
key1 enumeration thingy to "key1" as a string, but that seems kind of
ugly. Is there a way to get the enumerated constant key1 from the
string value "key1"?

If performance is not a big issue (few keys, infrequent processing),
you could build a table that associates key strings with enum values
and just look 'em up:

static struct {
const char *keyString;
const int keyIndex;
} table[] = {
{ "key1", key1 },
{ "key2", key2 },
...
};

Or eliminate the middle-man by getting rid of the enum and just
associating key strings with value strings:

static struct {
const char *keyString;
/* const? */ char *keyValue;
} table[] = {
{ "key1", NULL },
{ "key2", NULL },
...
};

If there are a lot of keys or if you consult the table a lot,
consider using a hash table that maps key strings to enums or to
value strings.

--
Er*********@sun.com

[Kenny McCormack]

In article <VB*****************@nwrddc02.gnilink.net>,
Time Waster <no***@nowhere.comwrote:

>Java property files are dead simple:
key1=val1
some.key2=val2

For simplicity on the Java side, I'd like to use these files from C
as well (the C program and Java program must cooperate). Anyone have
any bright ideas on handling this sort of thing from C? Is there
any preexisting libraries or calls that would help?

You're just going to get the usual fgets,index, etc re-invent the wheel
stuff here. This being CLC and all. Anything else (external libraries)
are:

Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

Unfortunately, I don't have a good suggestion for you, but I know that
some years back, I was looking for something similar - that is,
something in the Linux world that was similar to Windows INI files.
Naturally, mentioning anything Windows-y in any of the Unix-y groups (a
category into which, protestations to the contrary notwithstanding, CLC
falls), raises flags in front of bulls...

But a little newsgrouping and a little surfing did lead me to a
"registry" package for Linux that, although I never ended up actually
using it seriously, did look quite interesting. All the Unix-y types
did, of course, crap all over it for being inspired by the Evil Empire.

[Time Waster]

Eric Sosman <Er*********@sun.comwrote:

<off-topicSimple, but not quite *that* simple ... </off-topic>

I don't see this as off-topic! The only wrinkle i noticed
in property files was that you must escape equal signs in the
data value (to be expected). Are there other gotchas?
(I know about the comment character behavior as well.)

If there are a lot of keys or if you consult the table a lot,
consider using a hash table that maps key strings to enums or to
value strings.

I think I like this thought the best. To fill out the answers a bit,
I'll be writing the property files only from C. They are only occasionally
used, mostly at startup time. Various C programs and one Java program
will be the consumers, and just one C program, a configuration program,
will be the only writer.

It feels a bit wrong to cater to the 1 Java program, but I just wanted
a simple unified configuration representation instead of the mish-mash
of section headers and quasi-property-file stuff that is there currently.

Thanks!

[Eric Sosman]

Time Waster wrote:

Eric Sosman <Er*********@sun.comwrote:

> <off-topicSimple, but not quite *that* simple ... </off-topic>

I don't see this as off-topic! The only wrinkle i noticed
in property files was that you must escape equal signs in the
data value (to be expected). Are there other gotchas?
(I know about the comment character behavior as well.)

<off-topic>

http://java.sun.com/javase/6/docs/ap...java.io.Reader)

</off-topic>

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Keith Thompson]

Time Waster <bf*@fenway.our.netwrites:

Eric Sosman <Er*********@sun.comwrote:

> <off-topicSimple, but not quite *that* simple ... </off-topic>

I don't see this as off-topic! The only wrinkle i noticed
in property files was that you must escape equal signs in the
data value (to be expected). Are there other gotchas?
(I know about the comment character behavior as well.)

[...]

It's not obvious that an equals sign in the data value has to be
escaped. For example, given:

foo=bar=42

the format could easily treat the first '=' on the line as the
delimiter between the key and the value, and all other '=' characters
as part of the value; so the key is "foo" and the value is "bar=42".

Of course whatever standard defines the layout can require anything it
likes.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"