Re: Preprocessor automation to define/declare array of strings

Discussion in 'C Programming' started by Eric Sosman, Aug 6, 2012.

  1. Eric Sosman

    Eric Sosman Guest

    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
    d
    Eric Sosman, Aug 6, 2012
    #1
    1. Advertising

  2. Eric Sosman

    Eric Sosman Guest

    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
    d
    Eric Sosman, Aug 6, 2012
    #2
    1. Advertising

  3. Eric Sosman

    Eric Sosman Guest

    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
    d
    Eric Sosman, Aug 6, 2012
    #3
  4. (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.
    Ben Bacarisse, Aug 6, 2012
    #4
  5. On Aug 6, 4:10 pm, (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.
    Nick Keighley, Aug 7, 2012
    #5
  6. Eric Sosman

    Phil Carmody Guest

    Ben Bacarisse <> writes:
    > (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)
    Phil Carmody, Aug 10, 2012
    #6
  7. Eric Sosman

    Mark Bluemel Guest

    OT (Re: Preprocessor automation to define/declare array of strings)

    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
    Mark Bluemel, Aug 10, 2012
    #7
  8. Phil Carmody <> writes:

    > Ben Bacarisse <> writes:
    >> (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.
    Ben Bacarisse, Aug 10, 2012
    #8
  9. Eric Sosman

    Phil Carmody Guest

    Re: OT (Re: Preprocessor automation to define/declare array of strings)

    Mark Bluemel <> 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)
    Phil Carmody, Aug 12, 2012
    #9
  10. Eric Sosman

    Tim Rentsch Guest

    Nick Keighley <> writes:

    > On Aug 6, 4:10 pm, (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.
    Tim Rentsch, Sep 7, 2012
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Cronus
    Replies:
    1
    Views:
    648
    Paul Mensonides
    Jul 15, 2004
  2. marekdec
    Replies:
    0
    Views:
    349
    marekdec
    Jan 5, 2007
  3. apondu
    Replies:
    0
    Views:
    583
    apondu
    Jul 19, 2007
  4. Ike Naar
    Replies:
    0
    Views:
    332
    Ike Naar
    Aug 6, 2012
  5. Jorgen Grahn
    Replies:
    1
    Views:
    342
    Stefan Ram
    Aug 11, 2012
Loading...

Share This Page