Preprocessor issue?

[Tim Kemp]

I have a preprocessor conditional selecting what type of enum to create.  The members of the enum don't get tagged.  I didn't write this code so I can't explain why it's done this way.  I just noticed that it's not working.

- Tim

-------------------

SlickEdit Version 15.0.0.5

Licensed number of users: Single user
License file: C:\Documents and Settings\All Users\Application Data\slickedit\15\slickedit.lic

Build Date: April 26, 2010
Emulation: CUA

OS: Windows XP
OS Version: 5.01.2600  Service Pack 3
Memory: 33% Load, 0MB/2097MB Physical, 209MB/2097MB Virtual
Shell Info: C:\WINDOWS\system32\cmd.exe /q

Project Type: cpp
Language: .h (C/C++)

[Tim Kemp]

By the way, it doesn't matter if PC_SIMULATION is defined or not, the enumerations don't get tagged.

[Tim Kemp]

I'm curious if this affects anyone else.  The code I'm working with uses this construct extensively, so I have a lot of "Symbol Color: Symbol not found".

- Tim

[ScottW, VP of Dev]

Refer to the User Guide. Look in Language-Specific Editing > C and C++ > C/C++  Preprocessing. The section begins as follows:

C/C++ Preprocessing
Typically your source code base will include preprocessor macros that you use in your code for portability or convenience. For performance considerations, Context Tagging® does not do full preprocessing, so macros that interfere with normal C++ syntax can cause the parser to miss symbols.

The section goes on to describe how to define your macros to SlickEdit. Please let us know if that doesn't resolve this for you.

[Tim Kemp]

Unless I'm misunderstanding (which is quite possible) I already tried this:

By the way, it doesn't matter if PC_SIMULATION is defined or not, the enumerations don't get tagged.

I've included a capture of the options dialog.  Is there more I have to do?

- Tim

[chrisant]

I typed in the text from the screenshot in the original post.
I commented out various combinations of lines.

The root issue appears to be that the tag parser does not recognize the syntax "typedef enum : unsigned char".
The preprocessor stuff appears to be a red herring.

[ScottW, VP of Dev]

Tim,

When you said:

By the way, it doesn't matter if PC_SIMULATION is defined or not, the enumerations don't get tagged.

I couldn't tell if you were referring to defined in the code or defined to SlickEdit. Most folks don't know about the C/C++ Preprocessing dialog in SlickEdit, so that's where we typically start.

I'll pass along this bit of code and see if we can update the parser to handle it. 

[Dennis]

typedef enum : unsigned char { ... } is a non-standard syntax.  I had not seen it before in C/C++.  We can extend the parser to handle that for a future version of SlickEdit.  I will file a feature request just for that.

You do need to configure the preprocessing correctly.  If SlickEdit can not prove whether a preprocessing condition is true or false, it will parse both paths, which will leave you with "typedef enum : unsigned char typedef enum { ... };  which is still nonsense code as far as the parser is concerned.

As for the preprocessing issue, what you need to do is create PC_SIMULATION as a #undef (see the "undef" checkbox on the preprocessing dialog), because you want the parser to take the other code path through the standard code which we will be able to parse.

One final warning.  15.0.1 is a little picky about the preprocessing configuration options applying, so you may have to close the editor and restart it for them to take effect.  This will be fixed in the next release.

[Tim Kemp]

Dennis,

Thanks! undef makes things much nicer.

- Tim

[sigmund]

The ": unsigned char" part looks like an underlying type specification which is part of strongly typed enums in C++0x:
http://en.wikipedia.org/wiki/C%2B%2B0x#Strongly_typed_enumerations
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf

(I'm not sure if the C-style typedef syntax is valid C++0x.)

Cheers,
Siggy

[Dennis]

Version 16 has support for the new syntax: "typedef enum : unsigned { one, two, three }".
Give the beta a try.

However, this doesn't work around the need for setting up preprocessing as in Tim's original test case, because otherwise, you have something that looks like "typedef enum : unsigned char { typedef enum {" when the parser doesn't recognize the #define and winds up taking both paths.