Hi all,

I have the following defined in exactly one file named MachineDefs.h:

// Action flags
#define ACTION_LOAD (1<<0)
#define ACTION_UNLOAD (1<<1)
#define ACTION_SET (1<<2)
#define ACTION_GET (1<<3)
#define ACTION_INIT (1<<4)
#define ACTION_EXEC (1<<5)
#define ACTION_UPDATE (1<<6) //new flag
#define ACTION_CHECK (1<<7) //new flag
#define ACTION_RENDER (1<<8) //new flag
//#define START_RE_ACTION (1<<9)

//Re-Action flags
#define RE_ACTION_CALLREQ (1<<9) //(START_RE_ACTION<<0)
#define RE_ACTION_CALLBACK (1<<10) //(START_RE_ACTION<<1)
#define RE_ACTION_CALLERDEF (1<<11) //(START_RE_ACTION<<2)
#define RE_ACTION_LOAD (1<<12) //(START_RE_ACTION<<3)
#define RE_ACTION_UNLOAD (1<<13) //(START_RE_ACTION<<4)

These are bit flags that are used in multiple modules and in multiple
projects. I made a change to the #define's and added UPDATE, CHECK, and
RENDER flags. Of course, I did a rebuild on everything. In one project,
all of my sub-projects seem to have done fine. But in a separate project (a
..dll), it appears to still be using the old bit flags (before I made the 3
additions). Where it ought to return:

(RE_ACTION_CALLREQ | RE_ACTION_CALLERDEF | RE_ACTION_LOAD)
//6656 or bits 10, 12, and 13

it instead returns:

(ACTION_UPDATE | ACTION_RENDER | RE_ACTION_CALLREQ)
//832 or bits 7, 9, and 10

Bits 7, 9, and 10 are what the flags I'm expecting USED to be (before I
made the 3 additions). I checked the file dependencies and it's using the
correct file (there's only one anyway). I even deleted the intermediate
files and did a rebuild--nothing.

I know some out there will say this is exactly why you shouldn't use
#define, but I'm pretty dead set on making this method work. It would take
a lot of re-designing to not use the bit flag system that I have in place.

Been stuck here for a while now. Any help would be GREATLY
appreciated!!
--

Best wishes,
Allen

Hi Thad,

Yeah, I checked for multiple copies (even though I only wrote one) and
there aren't any.

As to the complier listing, I don't understand what that is. You mean
look at the disassembly?

Best wishes,
Allen

"Thad Smith" <ThadSmith@acm.org> wrote in message
news:3F64D0E5.9B368428@acm.org...

There are ways to tell a compiler "preprocess-only", so it will convert each
translation unit into a huge sea of raw, ugly C++ code. I suspect Thad
suggested you use a system that expands each #include, at least, to see the
results.

Given...

// Action flags
#define ACTION_LOAD (1<<0)
#define ACTION_UNLOAD (1<<1)
#define ACTION_SET (1<<2)
....

....I would add a parallel system looking like this:

enum Action_Flags {
ACTION_LOAD_ = (1<<0),
ACTION_UNLOAD_ = (1<<1),
ACTION_SET_ = (1<<2),
...

Then, temporarily, code would have the option of using identifiers such as
"ACTION_LOAD" or "ACTION_LOAD_" to mean the same thing.

But because the 'enum's are less likely to be redefined, attempting to use
the enum version at the bug location might illuminate the actual problem.

The problem with saying "It would take a lot of re-designing to not use the
bit flag system that I have in place" is that such refactors are usually
very easy if you take them one edit at a time, and return the system to a
working state between each edit.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

Allen wrote:

Perhaps you have copies of the header file in multiple directories and only one got
updated.

If that doesn't help, generate a compiler listing, with include files listed, on the
modules which don't update properly. You should find the problem.

Thad

Hi all,

Well, I'm tempted to make up some extravagant story to cover up my
extreme stupidity, but I'll tell you what I did. <sigh>

At some point that I only remember now in hindsight, I changed the
target file name to a different extension than ".dll" because my system uses
a different extension scheme, ".ngc" specifically. "Hey, that'll be easier
because I won't have to rename the file with every re-build!" Except that I
forgot that I did that and kept copying/renaming the old ".dll" version that
was still in the output directory to use in my debug sessions!!! And you
can probably guess the rest...<slaps forehead repeatedly>

Thanks for the help though,
Mr. No-Short-Term-Memory

"Allen" <allen-terri-ng$uP3R@3n1u5att.net> wrote in message
news:PE29b.141674$3o3.10148924@bgtnsc05-news.ops.worldnet.att.net...

Allen wrote:

No. Some compilers allow you, as an option, to generate a listing file which lists the
source file being compiled, usually with line numbers added and usually some summary at
the end of error/warning count, possibly size of generated code, etc. If so, another
option is to show the included files in the listing (making a long listing file if you
have lots of included files). Your compiler might not have those options. If it does, it
lets you see exactly what the compiler looked at the generate the code.

My guesses for your problem are that there are multiple copies of the file (although you
haven't found it), that the defines are also located elsewhere, you are not remaking the
file that you think you are,
or that you are remaking it, but it is named differently than the one that you are
testing.

The steps to generating the code can be broken down, including, as someone else suggested,
a preprocessed source file and a disassembly listing. Verify the correct values being
generated at these steps. Verify that the correct object file is being linked. Verify
that the newly linked file is being tested.

Thad

Allen wrote:

Well, look on the bright side. I have been abusing these newsgroups with
bullshit about "refactoring" for years now. And someone has finally reported
a problem that it wouldn't have fixed. Incremental changes that preserve
behavior would, in this case, have left the bug symptom >exactly< the same.

Been there done that ;-)

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces