By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,388 Members | 1,823 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,388 IT Pros & Developers. It's quick & easy.

I'm losing my marble.

P: n/a
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
Nov 14 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
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},
};
Nov 14 '05 #2

P: n/a

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[i];
}
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[i] = 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
Nov 14 '05 #3

P: n/a
On Thu, 11 Dec 2003 15:42:59 -0500 (EST), "Arthur J. O'Dwyer"
<aj*@nospam.andrew.cmu.edu> 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
Nov 14 '05 #4

P: n/a
Kevin D. Quitt <KQ**********@IEEIncUNMUNG.com> wrote in message news:<q7********************************@4ax.com>. ..
#define _BUTTON_H_


isn't _BUTTON_H_ in a reserved namespace?
--
Nick Keighley
Nov 14 '05 #5

P: n/a
ni***********@marconi.com (Nick Keighley) wrote:
Kevin D. Quitt <KQ**********@IEEIncUNMUNG.com> wrote:
#define _BUTTON_H_


isn't _BUTTON_H_ in a reserved namespace?


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

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.angelfire.com/ms3/bchambl...me_to_clc.html
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...acllc-c++.html
Nov 14 '05 #6

P: n/a
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?

Nov 14 '05 #7

P: n/a
"Grumble" <in*****@kma.eu.org> 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.
Nov 14 '05 #8

P: n/a
"Simon Biber" <ne**@ralminNOSPAM.cc> wrote:
"Grumble" <in*****@kma.eu.org> 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 (ir*******@freenet.de)
welcome to clc : http://www.angelfire.com/ms3/bchambl...me_to_clc.html
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...acllc-c++.html
Nov 14 '05 #9

P: n/a
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 (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #10

P: n/a
In <3F***************@yahoo.com> CBFalconer <cb********@yahoo.com> 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: Da*****@ifh.de
Nov 14 '05 #11

P: n/a
On 12 Dec 2003 16:28:13 GMT, Da*****@cern.ch (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
Nov 14 '05 #12

P: n/a
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.
Nov 14 '05 #13

P: n/a
Kevin Goodsell <us*********************@neverbox.com> 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
Nov 14 '05 #14

P: n/a
"Ben Pfaff" <bl*@cs.stanford.edu> wrote:
Kevin Goodsell <us*********************@neverbox.com> 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.
Nov 14 '05 #15

P: n/a
Dan Pop wrote:

In <3F***************@yahoo.com> CBFalconer <cb********@yahoo.com> 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
Nov 14 '05 #16

P: n/a
Kevin Goodsell <us*********************@neverbox.com> 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.
Nov 14 '05 #17

P: n/a
Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:
Kevin Goodsell <us*********************@neverbox.com> 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.
Nov 14 '05 #18

P: n/a
Christopher Benson-Manica wrote:
Kevin Goodsell <us*********************@neverbox.com> 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.
Nov 14 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.