Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Preprocessor automation to define/declare array of strings

Reply
Thread Tools

Re: Preprocessor automation to define/declare array of strings

 
 
Eric Sosman
Guest
Posts: n/a
 
      08-06-2012
On 8/6/2012 10:23 AM, pozz wrote:
> I have a lot of array of strings defined in strings.c and declared in
> strings.h.
>
> --- strings.c ---
> const char *strlist_month[] = { "Jan", "Feb", ... };
> const char *strlist_day[] = { "Mon", "Thu", ... };


Calendar reform?

> const char *strlist_onoff[] = { "ON", "OFF" };


It's too bad that strlist_onoff[false] is "ON" ...

>[...]
> As you can understand, maintain synchronized strings.c and strings.h can
> be tedious: when I add a list in strings.c, I have to remember to add it
> in strings.h also and I have to take care to use the same name.
>
> I was thinking to automate the declaration/definition of lists of strings
> through C preprocessor. For example:
>
> --- defstrings.def ---
> STRINGLIST(strlist_month, { "Jan", "Feb", ... } );
> STRINGLIST(strlist_day, { "Mon", "Thu", ... } );
> STRINGLIST(strlist_onoff, { "ON", "OFF", ... } );
> --- defstrings.c ---
> #define STRINGLIST(name, list) const char *name[] = list;
> #include "defstrings.def"
> --- defstrings.h ---
> #define STRINGLIST(name, list) extern const char *name[];
>
> Have you a better suggestion?


You're on the right track, but the execution is faulty. The
problem is the "list" piece, for which I think the best solution
is a C99-style variadic macro. The two versions would be

#define STRINGLIST(name,...) \
const char *name[] = { __VA_ARGS__ } // BTW, no ;
and
#define STRINGLIST(name,...) \
extern const char *name[] // no ;

You'd invoke them as

STRINGLIST(strlist_onoff, "ON", "OFF", "HEISENBERG");

See also Question 10.26 in the FAQ at <http://www.c-faq.com/>.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      08-06-2012
On 8/6/2012 10:51 AM, Eric Sosman wrote:
>[...]
> See also Question 10.26 in the FAQ at <http://www.c-faq.com/>.


Typo: "Question 10.25" -- sorry!

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      08-06-2012
On 8/6/2012 11:10 AM, pozz wrote:
> Eric Sosman ha scritto:
>> On 8/6/2012 10:23 AM, pozz wrote:
>>> I have a lot of array of strings defined in strings.c and declared in
>>> strings.h.
>>>
>>> --- strings.c ---
>>> const char *strlist_month[] = { "Jan", "Feb", ... };
>>> const char *strlist_day[] = { "Mon", "Thu", ... };

>>
>> Calendar reform?

>
> Ooops...
>
>
>>> const char *strlist_onoff[] = { "ON", "OFF" };

>>
>> It's too bad that strlist_onoff[false] is "ON" ...

>
> You are right.
>
>
>>> [...]
>>> As you can understand, maintain synchronized strings.c and strings.h can
>>> be tedious: when I add a list in strings.c, I have to remember to add it
>>> in strings.h also and I have to take care to use the same name.
>>>
>>> I was thinking to automate the declaration/definition of lists of strings
>>> through C preprocessor. For example:
>>>
>>> --- defstrings.def ---
>>> STRINGLIST(strlist_month, { "Jan", "Feb", ... } );
>>> STRINGLIST(strlist_day, { "Mon", "Thu", ... } );
>>> STRINGLIST(strlist_onoff, { "ON", "OFF", ... } );
>>> --- defstrings.c ---
>>> #define STRINGLIST(name, list) const char *name[] = list;
>>> #include "defstrings.def"
>>> --- defstrings.h ---
>>> #define STRINGLIST(name, list) extern const char *name[];
>>>
>>> Have you a better suggestion?

>>
>> You're on the right track, but the execution is faulty. The
>> problem is the "list" piece, for which I think the best solution
>> is a C99-style variadic macro. The two versions would be
>>
>> #define STRINGLIST(name,...)
>> const char *name[] = { __VA_ARGS__ } // BTW, no ;
>> and
>> #define STRINGLIST(name,...)
>> extern const char *name[] // no ;
>>
>> You'd invoke them as
>>
>> STRINGLIST(strlist_onoff, "ON", "OFF", "HEISENBERG");

>
> And what if my "very old microcontroller" compiler doesn't support
> variadic macros?


Then I think you're out of luck.

>> See also Question 10.26 in the FAQ at <http://www.c-faq.com/>.

>
> Ok, I read 10.25. Are you suggesting to migrate toward another
> preprocessor tool instead of insisting with C preprocessor? Is my request
> so far from C preprocessor features?


I'm suggesting that this may be about as far as you want
to try to take the preprocessor, even if it could (with effort)
be taken further. Even taking it this far requires[*] a feature
introduced in C99, so if you can't use C99 capabilities you may
already be beyond the pale.
[*] "Requires" may be too strong. Some people can make the
preprocessor whistle "Dixie" while riding a bicycle backwards
and juggling lit blowtorches (Hallvard Furuseth comes to mind).
Perhaps a wizard can figure out a way to do what you want using
only C90 features, which would mean that "requires" is wrong.

> How can I use m4 to solve this problem?


Dunno; I've only used m4 in "prepackaged" settings. If I
were in your situation, unable to use C99 macros, I'd probably
either bite the bullet and maintain the two files in parallel,
or write a little twenty-line program to parse a single input
file and write .c and .h files as output. Maybe with m4 you
can do it in fewer than twenty lines.

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      08-06-2012
(E-Mail Removed) (pozz) writes:
<snip>
> And what if my "very old microcontroller" compiler doesn't support
> variadic macros?


In the common include write this:

STRINGLIST(strlist_month) { "Jan", "Feb", "Mar" } EOL));

and so on for each list. To get the .c file use:

#define KILL(x)
#define STRINGLIST(name) const char *name[] =
#define EOL KILL((

and to get the .h file use:

#define KILL(x)
#define STRINGLIST(name) extern const char *name[] KILL((
#define EOL

The "KILL" macro is the same.

<snip>
--
Ben.
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      08-07-2012
On Aug 6, 4:10*pm, (E-Mail Removed) (pozz) wrote:
> Eric Sosman ha scritto:
>
> > On 8/6/2012 10:23 AM, pozz wrote:
> > > I have a lot of array of strings defined in strings.c and declared in
> > > strings.h.

>
> > > --- strings.c ---
> > > const char *strlist_month[] = { "Jan", "Feb", ... };
> > > const char *strlist_day[] = { "Mon", "Thu", ... };

>
> > * * *Calendar reform?

>
> Ooops...
>
> > > const char *strlist_onoff[] = { "ON", "OFF" };

>
> > * * *It's too bad that strlist_onoff[false] is "ON" ...

>
> You are right.
>
>
>
>
>
> > >[...]
> > > As you can understand, maintain synchronized strings.c and strings.h can
> > > be tedious: when I add a list in strings.c, I have to remember to addit
> > > in strings.h also and I have to take care to use the same name.

>
> > > I was thinking to automate the declaration/definition of lists of strings
> > > through C preprocessor. For example:

>
> > > --- defstrings.def ---
> > > STRINGLIST(strlist_month, { "Jan", "Feb", ... } );
> > > STRINGLIST(strlist_day, { "Mon", "Thu", ... } );
> > > STRINGLIST(strlist_onoff, { "ON", "OFF", ... } );
> > > --- defstrings.c ---
> > > #define STRINGLIST(name, list) const char *name[] = list;
> > > #include "defstrings.def"
> > > --- defstrings.h ---
> > > #define STRINGLIST(name, list) extern const char *name[];

>
> > > Have you a better suggestion?

>
> > * * *You're on the right track, but the execution is faulty. *The
> > problem is the "list" piece, for which I think the best solution
> > is a C99-style variadic macro. *The two versions would be

>
> > * *#define STRINGLIST(name,...)
> > * * * *const char *name[] = { __VA_ARGS__ } *// BTW, no ;
> > and
> > * *#define STRINGLIST(name,...)
> > * * * *extern const char *name[] *// no ;

>
> > You'd invoke them as

>
> > * *STRINGLIST(strlist_onoff, "ON", "OFF", "HEISENBERG");

>
> And what if my "very old microcontroller" compiler doesn't support
> variadic macros?
>
> > * * *See also Question 10.26 in the FAQ at <http://www.c-faq.com/>.

>
> Ok, I read 10.25. Are you suggesting to migrate toward another
> preprocessor tool instead of insisting with C preprocessor? Is my request
> so far from C preprocessor features?
> How can I use m4 to solve this problem?


another alternative is to generate both the .c and the .h
from a common definition file. Uing Perl maybe.
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      08-10-2012
Ben Bacarisse <(E-Mail Removed)> writes:
> (E-Mail Removed) (pozz) writes:
> <snip>
> > And what if my "very old microcontroller" compiler doesn't support
> > variadic macros?

>
> In the common include write this:
>
> STRINGLIST(strlist_month) { "Jan", "Feb", "Mar" } EOL));
>
> and so on for each list. To get the .c file use:
>
> #define KILL(x)
> #define STRINGLIST(name) const char *name[] =
> #define EOL KILL((
>
> and to get the .h file use:
>
> #define KILL(x)
> #define STRINGLIST(name) extern const char *name[] KILL((
> #define EOL
>
> The "KILL" macro is the same.


I find that a little perverse with the parentheses divorced from their partners,
but not actually wrong. Perhaps "clever" is the most appropriate way of expressing
my worries about it.


For variety, I'm sure I encountered something like this in the past:

In one location define:

#define INTRO(name) const char *name[] = {
#define ELEMENT(s) s,
#define OUTRO };

In a different location define:

#define INTRO(name) extern const char *name[];
#define ELEMENT(s)
#define OUTRO

Which permits you do have files such as

INTRO(strlist_month)
ELEMENT("Jan")
ELEMENT("Feb")
....
OUTRO


I think when I saw it, the first thing that went through my mind was

#define INTRO(name) extern const char *name[0
#define ELEMENT(s) +1
#define OUTRO ]

such that the clients can know the size of the array, which means you don't need a
sentinal at the end, or a redundantly-provided source for that information.
However, I've not ever really needed to use the technique. I offer it just as
a new way of approaching the problem.

Phil
--
> I'd argue that there is much evidence for the existence of a God.

Pics or it didn't happen.
-- Tom (/. uid 822)
 
Reply With Quote
 
Mark Bluemel
Guest
Posts: n/a
 
      08-10-2012
On 10/08/2012 09:35, Phil Carmody wrote:

>
> For variety, I'm sure I encountered something like this in the past:
>
> In one location define:
>
> #define INTRO(name) const char *name[] = {
> #define ELEMENT(s) s,
> #define OUTRO };


I suddenly heard the dulcet tones of Vivian Stanshall when I read this -
did anyone else?

--
Count Basie and his Orchestra, on triangle

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      08-10-2012
Phil Carmody <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>> (E-Mail Removed) (pozz) writes:
>> <snip>
>> > And what if my "very old microcontroller" compiler doesn't support
>> > variadic macros?

>>
>> In the common include write this:
>>
>> STRINGLIST(strlist_month) { "Jan", "Feb", "Mar" } EOL));
>>
>> and so on for each list. To get the .c file use:
>>
>> #define KILL(x)
>> #define STRINGLIST(name) const char *name[] =
>> #define EOL KILL((
>>
>> and to get the .h file use:
>>
>> #define KILL(x)
>> #define STRINGLIST(name) extern const char *name[] KILL((
>> #define EOL
>>
>> The "KILL" macro is the same.

>
> I find that a little perverse with the parentheses divorced from their
> partners, but not actually wrong. Perhaps "clever" is the most
> appropriate way of expressing my worries about it.


Yes, it's... odd looking.

> For variety, I'm sure I encountered something like this in the past:
>
> In one location define:
>
> #define INTRO(name) const char *name[] = {
> #define ELEMENT(s) s,
> #define OUTRO };
>
> In a different location define:
>
> #define INTRO(name) extern const char *name[];
> #define ELEMENT(s)
> #define OUTRO
>
> Which permits you do have files such as
>
> INTRO(strlist_month)
> ELEMENT("Jan")
> ELEMENT("Feb")
> ...
> OUTRO


I posted what I did because the OP had said:

| And what if my "very old microcontroller" compiler doesn't support
| variadic macros?

which made me think that the compiler probably did not accept trailing
commas in an initialiser list. That can be fixed, of course, by adding
a sentinel to OUTRO:

#define OUTRO 0 };

but it's never clear in these situations what's OK and what isn't, so I
searched for a solution that matched the __VA_ARGS__ one that had
already been posted.

> I think when I saw it, the first thing that went through my mind was
>
> #define INTRO(name) extern const char *name[0
> #define ELEMENT(s) +1
> #define OUTRO ]


(should be ]; to match the ones above)

> such that the clients can know the size of the array, which means you
> don't need a sentinal at the end, or a redundantly-provided source for
> that information.


Now that's definitely a plus point for doing it element by element. If
the OP's compiler does accept trailing commas, this might be
significant.

<snip>
--
Ben.
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      08-11-2012
Mark Bluemel <(E-Mail Removed)> writes:
> On 10/08/2012 09:35, Phil Carmody wrote:
> > For variety, I'm sure I encountered something like this in the past:
> >
> > In one location define:
> >
> > #define INTRO(name) const char *name[] = {
> > #define ELEMENT(s) s,
> > #define OUTRO };

>
> I suddenly heard the dulcet tones of Vivian Stanshall when I read this
> - did anyone else?


Nope, but if I had all the money I'd spent ond drink, I'd spend it on drink!

Phil
--
> I'd argue that there is much evidence for the existence of a God.

Pics or it didn't happen.
-- Tom (/. uid 822)
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      09-07-2012
Nick Keighley <(E-Mail Removed)> writes:

> On Aug 6, 4:10 pm, (E-Mail Removed) (pozz) wrote:
>> Eric Sosman ha scritto:
>>
>> > On 8/6/2012 10:23 AM, pozz wrote:
>> > > I have a lot of array of strings defined in strings.c and declared in
>> > > strings.h.

>>
>> > > --- strings.c ---
>> > > const char *strlist_month[] = { "Jan", "Feb", ... };
>> > > const char *strlist_day[] = { "Mon", "Thu", ... };

>>
>> > Calendar reform?

>>
>> Ooops...
>>
>> > > const char *strlist_onoff[] = { "ON", "OFF" };

>>
>> > It's too bad that strlist_onoff[false] is "ON" ...

>>
>> You are right.
>>
>>
>>
>>
>>
>> > >[...]
>> > > As you can understand, maintain synchronized strings.c and strings.h can
>> > > be tedious: when I add a list in strings.c, I have to remember to add it
>> > > in strings.h also and I have to take care to use the same name.

>>
>> > > I was thinking to automate the declaration/definition of lists of strings
>> > > through C preprocessor. For example:

>>
>> > > --- defstrings.def ---
>> > > STRINGLIST(strlist_month, { "Jan", "Feb", ... } );
>> > > STRINGLIST(strlist_day, { "Mon", "Thu", ... } );
>> > > STRINGLIST(strlist_onoff, { "ON", "OFF", ... } );
>> > > --- defstrings.c ---
>> > > #define STRINGLIST(name, list) const char *name[] = list;
>> > > #include "defstrings.def"
>> > > --- defstrings.h ---
>> > > #define STRINGLIST(name, list) extern const char *name[];

>>
>> > > Have you a better suggestion?

>>
>> > You're on the right track, but the execution is faulty. The
>> > problem is the "list" piece, for which I think the best solution
>> > is a C99-style variadic macro. The two versions would be

>>
>> > #define STRINGLIST(name,...)
>> > const char *name[] = { __VA_ARGS__ } // BTW, no ;
>> > and
>> > #define STRINGLIST(name,...)
>> > extern const char *name[] // no ;

>>
>> > You'd invoke them as

>>
>> > STRINGLIST(strlist_onoff, "ON", "OFF", "HEISENBERG");

>>
>> And what if my "very old microcontroller" compiler doesn't support
>> variadic macros?
>>
>> > See also Question 10.26 in the FAQ at <http://www.c-faq.com/>.

>>
>> Ok, I read 10.25. Are you suggesting to migrate toward another
>> preprocessor tool instead of insisting with C preprocessor? Is my request
>> so far from C preprocessor features?
>> How can I use m4 to solve this problem?

>
> another alternative is to generate both the .c and the .h
> from a common definition file. Uing Perl maybe.


I wrote a .c file in a perfectly ordinary way, then processed
the .c file to generate the corresponding .h file. A four
line awk script.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Preprocessor automation to define/declare array of strings Jorgen Grahn C Programming 1 08-11-2012 05:31 PM
Re: Preprocessor automation to define/declare array of strings Ike Naar C Programming 0 08-06-2012 02:55 PM
Supressing the ctrl-c and other keys during word automation in automation apondu ASP .Net 0 07-19-2007 09:10 PM
[netbeans] Changing preprocessor syntax automation (from old to new) marekdec Java 0 01-05-2007 08:41 AM
preprocessor, token concatenation, no valid preprocessor token Cronus C++ 1 07-14-2004 11:10 PM



Advertisments