| Author |
 Topic  |
|
|
wstanley
Junior Member
20 Posts |
 Posted - Jan 30 2007 : 8:01:40 PM
|
In the following example, the first enum typedef works fine, the second one however does not seem to be recognised (but it compiles fine).
typedef enum { a, b } AB;
typedef enum : char { a, b } ABint;
AB ab;
ABint abInt;
|
|
|
feline
Whole Tomato Software
United Kingdom
18749 Posts |
Posted - Jan 31 2007 : 12:15:17 PM
|
I am seeing the same effect here. Thank you for the clear description.
case=4839
What does ": char" do in this situation? I am not familiar with this syntax, but as you say it does compile quite happily in VS2005.
I am guessing it tells the compiler to use a char rather than an int for storage of this enum, but that is just a guess 
Out of interest why are you doing this? |
zen is the art of being at one with the two'ness |
 |
|
|
wstanley
Junior Member
20 Posts |
Posted - Jan 31 2007 : 5:24:06 PM
|
Your guess is very well educated...
I have a bunch of enumerations (from a library written in C, and they are all stored into unsigned char's (which is the actual storage class I am using). A set of these enumeration values that I want to encapsulate need to be combined in a union (mapping from the original structure semantics), so I have something like the following:
typedef enum {a, b} AB;
typedef enum {c, d} CD;
typedef union {
AB ab;
CD cd;
} ABuCD;
struct {
unsigned char c1;
unsigned char c2;
unsigned char c3;
} origValue;
origValue.c1 = 0xBB;
origValue.c2 = 1;
origValue.c3 = 0xBB;
ABuCD unionValue = *(ABuCD*)&(origValue.c2)
//unionValue.aa != 1 unless the storage class has a 1 byte size
As an aside, is there any priority on solutions for the other two problems you have raised for me (3105, 3220)? I find VA very useful, but while I am working with lots of volatile's, it is almost useless...
|
Edited by - wstanley on Jan 31 2007 5:26:09 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18749 Posts |
Posted - Jan 31 2007 : 5:34:58 PM
|
Interesting. I learn something new every day. I probably would have just used #define'd values instead of an enum, but the enum is definitely the better, and safer, choice.
I have upped the priority on 3105 for you.
For 3220 a recent workaround I came up with might help you. Change the code to read:
#define VOLATILE volatile
class test
{
void volatileTest2(const int i1) VOLATILE;
int volatileTest1() VOLATILE {return 1;}
void nvTest2(const int i1);
void nvTest3(const int i1);
int m_i1;
};
and then edit the file:
"C:\\Program Files\\Visual Assist X\\Misc\\StdAfx.h"
and add the entry:
#define VOLATILE
at the bottom. This file is used to help VA's parser with difficult code, and can be used to work around odd effects. There are a couple of things to watch out for though. After modifying this file you need to rebuild the VA symbol database for the changes to take effect:
VA Options -> Performance -> General -> Rebuild symbol databases
Secondly when you install a new build of VA it will install the latest version of VA's StdAfx.h file, which will overwrite your changes. So long as you reapply your changes before loading the IDE then the rebuild that the installer triggers will also pick up your changes.
Here the idea is to simply hide the "volatile" keyword from VA's parser, giving you an instant solution.
With a bit of care it should be possible to use the same technique to hide the ": char" part of the enum statement from VA as well. |
zen is the art of being at one with the two'ness |
|
|
|
wstanley
Junior Member
20 Posts |
Posted - Jan 31 2007 : 6:40:48 PM
|
Hiding ": char" from VA works perfectly.
The VOLATILE workaround make the situation much better, but it is still not perfect. If you open up the scope dropdown (the dropdown on the left), the volatile methods are all only identified as VOLATILE (the method name is nowhere to be seen... I don't know what else this would affect.
Thanks for the tips, they should make things a lot more usable. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18749 Posts |
Posted - Jan 31 2007 : 7:08:07 PM
|
I had forgotten that. There is a known bug with putting a macro after a function with the alt-m list, which you have just encountered.
case=4589
At least it helps some of the time. |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Feb 23 2007 : 10:50:32 PM
|
| Case 3105 is fixed in build 1548. |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Oct 29 2007 : 02:36:04 AM
|
| case=4589 is fixed in Build 1614 |
|
|
| |
Topic |
|
VA b1544: enum : type {...} causes parsing problem
