I'm losing my marble.

Discussion in 'C Programming' started by Kevin D. Quitt, Dec 11, 2003.

  1. Today is not a good day, concentration-wise. I'm trying to do something
    that really ought to be simple, but I can't find a way.

    I have a bunch of bit-map images, of various sizes, each in its own static
    buffer. I want to have a static structure that lets me associate the name
    with the buffers, so I can access the "files" by name.

    I'm sure it's blindingly obvious, and that I'd see it were it not for the
    flu. In the meantime, though, can I buy a clue?


    --
    #include <standard.disclaimer>
    _
    Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
    Per the FCA, this address may not be added to any commercial mail list
     
    Kevin D. Quitt, Dec 11, 2003
    #1
    1. Advertising

  2. Kevin D Quitt wrote:
    > I have a bunch of bit-map images, of various sizes, each in its own static
    > buffer. I want to have a static structure that lets me associate the name
    > with the buffers, so I can access the "files" by name.


    static struct {
    const char *name;
    const char *bitmap;
    } bitmaps[] = {
    {"first", first_buffer},
    {"second", second_buffer},
    };
     
    Jeremy Yallop, Dec 11, 2003
    #2
    1. Advertising

  3. On Thu, 11 Dec 2003, Kevin D. Quitt wrote:
    >
    > Today is not a good day, concentration-wise. I'm trying to do something
    > that really ought to be simple, but I can't find a way.
    >
    > I have a bunch of bit-map images, of various sizes, each in its own static
    > buffer. I want to have a static structure that lets me associate the name
    > with the buffers, so I can access the "files" by name.


    Sounds like someone's been programming too much Perl again, or
    Lisp, or something. :) Anyway, I *think* what you're wanting is
    something along the lines of [UNTESTED CODE]:

    struct Bitmap;

    struct LookupEntry {
    char *name;
    struct Bitmap *file;
    };

    struct LookupTable {
    int ntable;
    struct LookupEntry table[100];
    };

    struct LookupEntry *add(struct LookupTable *tab, char *name,
    struct Bitmap *file)
    {
    char *tmp;
    if (tab->ntable >= 100) return NULL;
    tmp = malloc(strlen(name)+1);
    if (tmp == NULL) return NULL;
    strcpy(tmp, name);
    tab->table[tab->ntable].name = tmp;
    tab->table[tab->ntable].file = file;
    ++tab->ntable;
    return &tab->table[tab->ntable - 1];
    }

    struct LookupEntry *find(struct LookupTable *tab, char *name)
    {
    int i;
    for (i=0; i < tab->ntable; ++i) {
    char *tmp = tab->table[tab->ntable].name;
    if (tmp == NULL) continue;
    if (0 == strcmp(tmp, name))
    return &tab->table;
    }
    return NULL;
    }

    int delete(struct LookupTable *tab, struct LookupEntry *entry)
    {
    int idx = (entry - tab->table);
    free(entry->name);
    --tab->ntable;
    for (i=idx; i < tab->ntable; ++i) {
    tab->table = tab->table[i+1];
    }
    return 0; /* successful deletion */
    }


    int main()
    {
    struct LookupTable mytab = {0};
    struct LookupEntry *ent;
    add(&mytab, "foo.bmp", NULL);
    ent = find(&mytab, "bar.bmp");
    if (ent)
    delete(&mytab, ent);
    return 0;
    }


    Replace the linear table by a binary tree or a hash table or something,
    if you want better asymptotic performance. And check for bugs. ;-)

    HTH,
    -Arthur
     
    Arthur J. O'Dwyer, Dec 11, 2003
    #3
  4. On Thu, 11 Dec 2003 15:42:59 -0500 (EST), "Arthur J. O'Dwyer"
    <> wrote:

    > Sounds like someone's been programming too much Perl again, or
    >Lisp, or something. :)


    Been too long for either of them. Thanks to both (quick) responders.

    This is to be help screens for an embedded system. I want to define a
    hierarchical set of structures that define each screen, including buttons
    with multiple representations (being pressed, e.g.), and a function
    associated with each button.

    It wasn't the code for manipulating it, I just couldn't get everything
    declared. Fortunately, that part of my stupidity has cleared. Here's
    what I came up with in case anybody's interested.

    -------8<-------

    #ifndef _BUTTON_H_
    #define _BUTTON_H_

    typedef unsigned char uchar;

    typedef enum
    { SC_EXIT, SC_Main, SC_Wireless, SC_DotQuad, SC_ESSID } SCREEN;

    // Button defines size and which, of possibly 4, image to display

    typedef struct
    {
    size_t cols, rows; // Pixels
    int current; // If more than one set of images, which?
    int active; // Use active rather than idle
    uchar *idle[ 2 ]; // Primary & alternate idle view
    uchar *actv[ 2 ]; // Primary & alternate active view
    } Button;


    // ButtonOp defines the operation of a given button: where it is on
    // screen, its active touch values, the function to be called, and the
    // images to use for it.

    typedef struct _ButtonOp
    {
    int tp, lp; // Top left pixel
    int tt, lt, bt, rt; // Top left, bottom right touch
    SCREEN (*touchFunc)(struct _ButtonOp *, int, int, int);
    Button *button;
    } ButtonOp;


    // MenuScreen defines the entire screen.

    typedef struct
    {
    SCREEN theScreen;
    int bcolor;
    int tf, tb;
    void (*initFunc)(void);
    int buttons;
    ButtonOp *button[ 20 ];
    } MenuScreen;


    extern MenuScreen MainScreen;


    #endif
    ---->8----

    And here's a stripped-down version of a screen definition:

    ----8<----
    #include <stdio.h>
    #include <stdlib.h>
    #include "button.h"

    static void sc1_initFunc( void );
    static SCREEN sc1_bf1( ButtonOp *theBop, int ht, int vt, int up );
    extern uchar sc1_b1i[], sc1_b1a[];

    static Button sc1_b1 = { 100, 40, 0, 0, {sc1_b1i}, {sc1_b1a}};
    static ButtonOp SC1_BB1 = { 20, 20, 1, 1, 2, 5, sc1_bf1, &sc1_b1 };

    MenuScreen MainScreen =
    {
    SC_Main, 0, 0, 0, sc1_initFunc, 1, { &SC1_BB1 }
    };

    static void sc1_initFunc( void )
    {
    return;
    }

    static SCREEN sc1_bf1( ButtonOp *theBop, int ht, int vt, int up )
    {
    (void)theBop;(void)ht;(void)vt;(void)up;
    return SC_DotQuad;
    }


    // In the real world, these are not strings, but raw bitmaps.
    static uchar sc1_b1i[] = "sc1_b1i";
    static uchar sc1_b1a[] = "sc1_b1a";

    ---->8----

    --
    #include <standard.disclaimer>
    _
    Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
    Per the FCA, this address may not be added to any commercial mail list
     
    Kevin D. Quitt, Dec 12, 2003
    #4
  5. Kevin D. Quitt <> wrote in message news:<>...

    > #define _BUTTON_H_


    isn't _BUTTON_H_ in a reserved namespace?


    --
    Nick Keighley
     
    Nick Keighley, Dec 12, 2003
    #5
  6. Irrwahn Grausewitz, Dec 12, 2003
    #6
  7. Kevin D. Quitt

    Grumble Guest

    Irrwahn Grausewitz wrote:

    > Nick Keighley wrote:
    >
    >> isn't _BUTTON_H_ in a reserved namespace?

    >
    > It is.
    > Better: BUTTON_H
    > Even better (IMHO): H_BUTTON
    > My personal favorite: H_BUTTON_INCLUDED


    Why do you think H_BUTTON is better than BUTTON_H?
     
    Grumble, Dec 12, 2003
    #7
  8. Kevin D. Quitt

    Simon Biber Guest

    "Grumble" <> wrote:
    > Why do you think H_BUTTON is better than BUTTON_H?


    H_FILENAME is better than FILENAME_H in case your header
    file name starts with
    E
    PRI
    SCN
    LC_
    SIG
    or SIG_
    because those identifiers (among others) are reserved in
    certain contexts.

    --
    Simon.
     
    Simon Biber, Dec 12, 2003
    #8
  9. "Simon Biber" <> wrote:
    > "Grumble" <> wrote:
    > > Why do you think H_BUTTON is better than BUTTON_H?

    >
    > H_FILENAME is better than FILENAME_H in case your header
    > file name starts with
    > E
    > PRI
    > SCN
    > LC_
    > SIG
    > or SIG_
    > because those identifiers (among others) are reserved in
    > certain contexts.


    Correct, and I like to have a consistent naming scheme,
    therefore I always use H_<name>_INCLUDED.

    Regards
    --
    Irrwahn Grausewitz ()
    welcome to clc : http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
    clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
    acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~ajo/faqs/acllc-c .html
     
    Irrwahn Grausewitz, Dec 12, 2003
    #9
  10. Kevin D. Quitt

    CBFalconer Guest

    Grumble wrote:
    > Irrwahn Grausewitz wrote:
    > > Nick Keighley wrote:
    > >
    > >> isn't _BUTTON_H_ in a reserved namespace?

    > >
    > > It is.
    > > Better: BUTTON_H
    > > Even better (IMHO): H_BUTTON
    > > My personal favorite: H_BUTTON_INCLUDED

    >
    > Why do you think H_BUTTON is better than BUTTON_H?


    Because if you follow the same id creation process, what are you
    going to do with error.h? Or e<anything>.h.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Dec 12, 2003
    #10
  11. Kevin D. Quitt

    Dan Pop Guest

    In <> CBFalconer <> writes:

    >Grumble wrote:
    >> Irrwahn Grausewitz wrote:
    >> > Nick Keighley wrote:
    >> >
    >> >> isn't _BUTTON_H_ in a reserved namespace?
    >> >
    >> > It is.
    >> > Better: BUTTON_H
    >> > Even better (IMHO): H_BUTTON
    >> > My personal favorite: H_BUTTON_INCLUDED

    >>
    >> Why do you think H_BUTTON is better than BUTTON_H?

    >
    >Because if you follow the same id creation process, what are you
    >going to do with error.h? Or e<anything>.h.


    Frankly, I would use ERROR_H and E<ANYTHING>_H and assume the risks.
    I value simple conventions that improve code readability more than
    anal conformance to the C standard. YMMV.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Dec 12, 2003
    #11
  12. On 12 Dec 2003 16:28:13 GMT, (Dan Pop) wrote:
    >>> >> isn't _BUTTON_H_ in a reserved namespace?


    If that's the only objection, then I've truly surpassed myself. I may
    switch to the H_ form, then but I'd be perfect. 8o)

    --
    #include <standard.disclaimer>
    _
    Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
    Per the FCA, this address may not be added to any commercial mail list
     
    Kevin D. Quitt, Dec 15, 2003
    #12
  13. Kevin D. Quitt

    Ben Pfaff Guest

    Kevin Goodsell <> writes:

    > I'm not sure how many characters are required
    > to be significant in pre-processor symbols.


    From 5.2.4.1 in C99:

    - 63 significant initial characters in an internal
    identifier or a macro name (each universal character
    name or extended source character is considered a single
    character)

    --
    "In My Egotistical Opinion, most people's C programs should be indented six
    feet downward and covered with dirt." -- Blair P. Houghton
     
    Ben Pfaff, Dec 15, 2003
    #13
  14. Dan Pop wrote:

    >
    >
    > Frankly, I would use ERROR_H and E<ANYTHING>_H and assume the risks.
    > I value simple conventions that improve code readability more than
    > anal conformance to the C standard. YMMV.
    >


    The convention I use is this:

    #ifndef INCLUDED_SOMEFILE_H
    #define INCLUDED_SOMEFILE_H 1

    I think this is good for readability, and even a bit more logical than
    the other conventions. It means I can do something like this:

    #if INCLUDED_SOMEFILE_H

    /* ... */

    #endif

    Which I think reads a little better than the alternative that most
    conventions give. I've never actually had a reason to use this yet, though.

    The number of characters in the identifier could be an issue, though. 9
    non-unique characters at the start of the identifier might be asking for
    trouble. I'm not sure how many characters are required to be significant
    in pre-processor symbols.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Dec 15, 2003
    #14
  15. Kevin D. Quitt

    Simon Biber Guest

    "Ben Pfaff" <> wrote:
    > Kevin Goodsell <> writes:
    > > I'm not sure how many characters are required
    > > to be significant in pre-processor symbols.

    >
    > From 5.2.4.1 in C99:
    >
    > - 63 significant initial characters in an internal
    > identifier or a macro name (each universal character
    > name or extended source character is considered a single
    > character)


    If you don't have a C99 compiler, note that in C89 2.2.4.1 the limit
    is lower:
    * 31 significant initial characters in an internal identifier or
    a macro name

    --
    Simon.
     
    Simon Biber, Dec 16, 2003
    #15
  16. Kevin D. Quitt

    pete Guest

    Dan Pop wrote:
    >
    > In <> CBFalconer <> writes:
    >
    > >Grumble wrote:
    > >> Irrwahn Grausewitz wrote:
    > >> > Nick Keighley wrote:
    > >> >
    > >> >> isn't _BUTTON_H_ in a reserved namespace?
    > >> >
    > >> > It is.
    > >> > Better: BUTTON_H
    > >> > Even better (IMHO): H_BUTTON
    > >> > My personal favorite: H_BUTTON_INCLUDED
    > >>
    > >> Why do you think H_BUTTON is better than BUTTON_H?

    > >
    > >Because if you follow the same id creation process, what are you
    > >going to do with error.h? Or e<anything>.h.

    >
    > Frankly, I would use ERROR_H and E<ANYTHING>_H and assume the risks.
    > I value simple conventions that improve code readability more than
    > anal conformance to the C standard. YMMV.


    The standard reserves leading underscore
    followed by an upper case letter identifiers, such as _BUTTON_H_.
    That's a simple convention; newbies think it's easy to read
    and they frequently assume that it's the correct form
    for writing header guards.
    I never heard of anybody getting bit by it.

    But you're not saying that you would use _BUTTON_H_,
    are you?

    --
    pete
     
    pete, Dec 16, 2003
    #16
  17. Kevin Goodsell <> spoke thus:

    > #ifndef INCLUDED_SOMEFILE_H
    > #define INCLUDED_SOMEFILE_H 1

    ^

    Isn't the 1 unnecessary? Do you feel it improves readability?

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Dec 16, 2003
    #17
  18. Kevin D. Quitt

    Ben Pfaff Guest

    Christopher Benson-Manica <> writes:

    > Kevin Goodsell <> spoke thus:
    >
    > > #ifndef INCLUDED_SOMEFILE_H
    > > #define INCLUDED_SOMEFILE_H 1

    >
    > Isn't the 1 unnecessary? Do you feel it improves readability?


    I prefer to include a value on my `#define's, so that I can then
    use them in later conditionals without needing to write `defined
    (...)' around them; e.g.
    #if a || b || c || (d && e)
    instead of
    #if defined (a) || defined (b) || defined (c) || (defined (d) && defined (e))
    However, I don't think I've ever wanted to test a set of include
    guards that way.
    --
    Bite me! said C.
     
    Ben Pfaff, Dec 16, 2003
    #18
  19. Christopher Benson-Manica wrote:

    > Kevin Goodsell <> spoke thus:
    >
    >
    >>#ifndef INCLUDED_SOMEFILE_H
    >>#define INCLUDED_SOMEFILE_H 1

    >
    > ^
    >
    > Isn't the 1 unnecessary? Do you feel it improves readability?
    >


    I began adding the 1 solely because it seemed more logical. If
    "INCLUDED_SOMEFILE_H" is taken as a question, the answer should be
    affirmative. Take the example I mentioned:

    #if INCLUDED_SOMEFILE_H
    /* ... */
    #endif

    This seems very natural to me. It reads as "If I've #included somefile.h..."

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Dec 16, 2003
    #19
    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. jdl1291$pam
    Replies:
    7
    Views:
    639
  2. Victor Garcia Aprea [MVP]

    Re: Losing Form data

    Victor Garcia Aprea [MVP], Jun 25, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    923
    Victor Garcia Aprea [MVP]
    Jun 25, 2003
  3. Saravana

    Re: Losing scroll on postback

    Saravana, Jun 27, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    475
    Vu Dang
    Jun 27, 2003
  4. Veloso
    Replies:
    0
    Views:
    374
    Veloso
    Jul 27, 2007
  5. Jason C
    Replies:
    4
    Views:
    705
    Morty Abzug
    Jun 26, 2012
Loading...

Share This Page