| Author |
 Topic  |
|
|
TLHobbes
Junior Member
14 Posts |
 Posted - May 03 2007 : 4:28:01 PM
|
struct Foo
{
int x;
int y;
};
// ( 1 ) This moslty works fine.
typedef Foo * Bar;
Bar alpha; // 'Bar' is purple, it should be blue.
alpha->x = 0; // Good: typing "alpha->" brings up a menu showing 'x' and 'y'.
// ( 2 ) Oddly this works slightly better.
typedef Foo * Weird;
Weird beta; // Improvement: 'Weird' is blue instead of purple like 'Bar' above.
// ( 3 ) This does not work well.
#define NO_WORKY( type ) typedef Foo * type##Ptr
NO_WORKY( Hello ); // 'Hello' is black, it should be blue.
HelloPtr delta; // 'HelloPtr' is black, autocomplete couldn't help type it either.
delta->x = 0; // Typing 'delta->' does NOT bring up any help.
// ( 4 ) This also does not work well.
#define ALSO_BAD( type ) typedef Foo * type
ALSO_BAD( Hi ); // Oddly 'Hi' is gray where as 'Hello' above is black.
Hi epsilon; //'Hi' is blue whereas 'HelloPtr' above is black, they should both be blue.
epsilon->x = 0; // Again no help is given after typing "epsilon->".
|
|
|
TLHobbes
Junior Member
14 Posts |
Posted - May 03 2007 : 4:31:52 PM
|
| In color coding the above code, via Forum Code, I did not see any way to make GRAY text, so I made the variables BROWN instead. It would be nice if the available colors in Forum Code matched the default colors used by .NET and VA_X. Oh-well. |
Edited by - TLHobbes on May 03 2007 4:32:24 PM |
 |
|
|
TLHobbes
Junior Member
14 Posts |
Posted - May 03 2007 : 4:46:56 PM
|
So I'm using VS.NET 2005 SP1 with Visual Assist 10.3.1555.0 on Windows XP.
I just made up the above code to show the issue that I'm running into with some of my own code dealing with smart pointers that are declared using a macro:
#define PREDECLARE(type) \ class type; \ typedef Types::SmartPointer<type> type##Ptr; \ typedef Types::SmartPointer<const type> type##CPtr; \ typedef Types::SmartHandle<type> type##Handle; \ typedef Types::SmartHandle<const type> type##CHandle;
Initially i thought the problem was with smart pointers, but they actually work just fine with Visual Assist. What does not appear to work at all is having a typedef inside of a macro. So when I do the following I don't get visual assist/intellisense help.
class Foo
{
...
void Bar();
}
PREDECLARE( Foo );
FooPtr p = new Foo(); // FooPtr is not recognized.
p->Bar(); // typing "p->" gives nothing for help.
Thanks in advance for any help. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19247 Posts |
Posted - May 04 2007 : 10:27:24 AM
|
Forum colours, most people don't use them this heavily, so it is not to big a problem that they do not match the IDE defaults. Also people often change the IDE colour schemes 
Part of the problem you are seeing with colouring is due to the names you have used. Since VA is having problems with this code, and does not really know what these symbols are, it is matching them to existing symbols it has found in other files, and picking up the colouring from there.
Problem 3 is a known bug, VA is having problems with macro's using ##
case=3873
Problem 4, I have renamed the code slightly, to make sure the names are unique, and introduced a function for the variable, and it works correctly for me using VS2005 and VA 1555 using the following code:
struct structMacroTypedef
{
int x;
int y;
};
static void testMacroTypedefCode()
{
// ( 4 ) This also does not work well.
#define ALSO_BAD( type ) typedef structMacroTypedef * type
ALSO_BAD( test3 );
test3 epsilon;
epsilon->|;
}
Can you try this code and see if it works correctly for you? |
zen is the art of being at one with the two'ness |
|
|
|
TLHobbes
Junior Member
14 Posts |
Posted - May 04 2007 : 11:57:13 AM
|
I tried your test code and it worked just fine
Thank you for clarifying the matters.
What can I do with the case number? Better yet, any word on when the ## inside of macros may be fixed. Thanks!
and here's my info I forgot to put in:
VA_X.dll file version 10.3.1555.0 built 2007.04.26
Licensed to:
VA X: [email protected] (12-user license) Support ends 2007.09.29
VAOpsWin.dll version 1.3.2.0
VATE.dll version 1.0.5.4
DevEnv.exe version 8.0.50727.762
msenv.dll version 2.0.5401.0
Font: Courier New 13(Pixels)
Comctl32.dll version 6.0.2900.2982
Windows XP 5.1 Build 2600 Service Pack 2
4 processors
Platform: Win32
Stable Includes:
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\include;
Library Includes:
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\crt\\src;
Other Includes:
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19247 Posts |
Posted - May 04 2007 : 1:55:20 PM
|
FAQ answer to case:
http://docs.wholetomato.com?W318
Unfortunately I don't have an estimate on this case at the moment. Do you have a lot of code like this? I am wondering if it is possible to find a work around, but that will depend in part on how often this is done in your code.
If it is only done a few times then it may be possible to add some macro's to VA's stdafx.h file for these cases.
http://docs.wholetomato.com?W302 |
zen is the art of being at one with the two'ness |
|
|
|
TLHobbes
Junior Member
14 Posts |
Posted - May 04 2007 : 3:47:36 PM
|
Yes, I (or rather we: the whole studio) do have a lot of code like this. More precisely I have a lot of uses of the macro PREDECLARE which I pasted again below. The big problem is just this one macro for the most part. I'm not yet familiar with editing VA's stdafx.h. Can a work around fix for this one macro be created to fix the general case of using it? Thanks!
#define PREDECLARE(type) \ class type; \ typedef Types::SmartPointer<type> type##Ptr; \ typedef Types::SmartPointer<const type> type##CPtr; \ typedef Types::SmartHandle<type> type##Handle; \ typedef Types::SmartHandle<const type> type##CHandle;
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19247 Posts |
Posted - May 10 2007 : 6:18:39 PM
|
Apologies for the delay in getting back to you about this, I have been very busy.
So far I have not been able to think up a good solution to this. It really depends on how often, and how many types, you declare like this.
If it is only 3 or 4 types then adding the definitions manually to a single file, perhaps VA's stdafx.h file, is a reasonable approach. But if this is hundreds of different types then this is only an option for the main types you used all the time in your code. |
zen is the art of being at one with the two'ness |
|
|
|
TLHobbes
Junior Member
14 Posts |
Posted - May 15 2007 : 1:07:36 PM
|
We're closer to using hundreds of types rather than just a few types. In addition we have many new types being added.
A bandaid fix for the most commonly used types may help a bit, but it sounds like the best bet is to hope for a fix to case=3873.
Thanks for the help
|
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - May 15 2007 : 1:29:42 PM
|
+1 vote to case=3873 
I have rewrited about a hundred of defines to make VAX happy.  It taken a lot of time, but without it, VAX was TOTALLY confused. Most of the source was underlined for example due to complex define codes (not mine of course I think it is not normal to use too much defines )
I haven't posted bug reports about defines yet, because I can use a workaround, and bugs without workaround are more important I think 
But I agree, define parsing bugs are VERY important (as every parser bug) |
Edited by - accord on May 15 2007 1:35:03 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19247 Posts |
Posted - May 16 2007 : 08:15:43 AM
|
| I have increased the priority on this for you. |
zen is the art of being at one with the two'ness |
|
|
|
TLHobbes
Junior Member
14 Posts |
Posted - Dec 10 2007 : 12:43:40 PM
|
Any updates on case=3873 ?
It would be most awesome to have this fixed! Thanks :) |
|
|
|
feline
Whole Tomato Software
United Kingdom
19247 Posts |
Posted - Dec 11 2007 : 07:09:50 AM
|
| Unfortunately no progress yet, but this is on our list of things to fix. |
zen is the art of being at one with the two'ness |
|
|
|
tesshu
New Member
Canada
5 Posts |
Posted - Dec 14 2007 : 12:59:58 PM
|
I have also been waiting on this one for sometime. I use a macro to define all my STL containers, so it's all over. I have also noticed that STL in general doesn't work as well since 1293.
To be honest I am not sure if I am going to bother renewing in the next 7 days. I understand there have been many great new features, that I have enjoyed, but I would rather have outstanding bugs fixed first. Especially since they are features that used to work.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19247 Posts |
Posted - Dec 14 2007 : 3:28:38 PM
|
tesshu I am sorry you feel this way. I understand your perspective in this, for what that's worth.
The problem here seems to be based around the # operator inside macro's. I assume your own macro's use the # command.
If you check out the history of changes here:
http://www.wholetomato.com/support/history.asp
you will see that most of the changes are bug fixes of one form or another. Of course the bug fix you are specifically waiting for has not been done yet, which does not help much.
What problems are you seeing with STL in general? Off hand I am not aware of general problems with STL code. |
zen is the art of being at one with the two'ness |
|
|
|
tesshu
New Member
Canada
5 Posts |
Posted - Dec 14 2007 : 5:46:48 PM
|
I did some test cases for you again. I realize that there have been lots of bug fixes, more than features as a matter of fact. Thing is that this bug goes back to version 1293 and I purchased the upgrade to VC2005 expecting it to work as previous versions did. Now it's been a year waiting for a fix and there has been nothing.
That's all I am saying :)
#include <vector>
#include <list>
#define STL_Vector std::vector
#define STL_List std::list
#define STL_DefineVec( _type ) \ typedef std::vector<_type> _type##Vec; \ typedef _type##Vec::iterator _type##VecIter; \ typedef _type##Vec::reverse_iterator _type##VecRIter;
#define STL_DefineList( _type ) \ typedef STL_List<_type> _type##List; \ typedef _type##List::iterator _type##ListIter; \ typedef _type##List::const_iterator _type##ListConstIter;
#define STL_DefinePtrList( _type ) \ typedef STL_List<_type*> _type##PtrList; \ typedef _type##PtrList::iterator _type##PtrListIter; \ typedef _type##PtrList::const_iterator _type##PtrListConstIter;
int main( int argc, char** argv )
{
// 1) No macros at all. Everything works perfect.
std::vector<int> vecInts;
// typing 'v' auto completes 'vecInts'.
// typing '.p' gives me 'push_back()'.
vecInts.push_back( 1 );
// 2) Just a macro for the std::vector. Again perfect. Note this macro isn't all that important.
// I got in the habit of using it for custom allocators etc.. I can live with this going.
STL_Vector( int ) vecInts2;
// typing 'v' auto completes 'vecInts2'.
// typing '.p' gives me 'push_back()'.
vecInts2.push_back( 2 );
// 3) Macro defines everything except the base std::vector. This one is really broken. Even the
// 'vecFloats' below doesn't have the right color.
STL_DefineVec( float ) vecFloats;
// typing 'v' give me a list but 'vecFloats' isn't in it. Even with CTRL-SPACE no member functions
// are found either.
vecFloats.push_back( 2.0f );
// 4) Removed the macro for defining all the types but kept the base macro. This one is Half broken.
typedef STL_List<int> intList;
typedef intList::iterator intListIter;
typedef intList::const_iterator intListConstIter;
intList listInt;
// typing l gives me 'listInt'.
// typing '.pu' and then CTRL-SPACE gives me push_back().
listInt.push_back( 1 );
//5) Perfect. Everything works.
typedef std::list<float> floatList;
typedef floatList::iterator floatListIter;
typedef floatList::const_iterator floatListConstIter;
floatList listFloat;
listFloat.push_back( 3.0f );
}
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19247 Posts |
Posted - Dec 15 2007 : 11:27:18 AM
|
| All of these problems are centred around VA's problems with # inside macros. This is down as a high priority bug fix, but unfortunately I have no estimate on when this will be fixed. |
zen is the art of being at one with the two'ness |
|
|
|
valmenn
New Member
USA
5 Posts |
Posted - May 07 2008 : 4:17:49 PM
|
I hate to ressurect old topics, but this one describes my problem the best. It deals with type definitions that include macros. And I don't think it is limited to # in macros. Here is a snippet (doing my best to color it appropriately):
#ifdef GCC
#define PAL_PACKED_STRUCT(type) __attribute__((packed)) type
#else
#define PAL_PACKED_STRUCT(type) type
#endif
typedef struct _MY_STRUCT
{
#xa0;#xa0;short dataLen;
#xa0;#xa0;short flags;
} PAL_PACKED_STRUCT(MY_STRUCT);
int init (MY_STRUCT *buffer)
{
#xa0;#xa0;buffer->dataLen = 0;
}
The MY_STRUCT type is not picked up by VA. It is black and buffer-> does not show the structure members. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19247 Posts |
Posted - May 08 2008 : 08:17:31 AM
|
I suspect the "#xa0;" bits are supposed to be tabs, or some other form of white space.
Here I suspect I know what is happening. VA is seeing both parts of the #ifdef statement, which is by design. VA normally picks the fist #define definition it see's, and in this case it is probably confused by the "__attribute__((packed)) type" expansion.
The solution is to edit VA's "StdAfx.h" file as explained in this FAQ entry:
http://docs.wholetomato.com?W302
and add the entry:
#define PAL_PACKED_STRUCT(type) type
at the bottom. This file is used to help VA's parser with difficult code, and can be used to work around odd effects. 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
I have tested this here, and this fixes the problem with this sample code. |
zen is the art of being at one with the two'ness |
|
|
|
valmenn
New Member
USA
5 Posts |
Posted - May 08 2008 : 9:36:42 PM
|
| Thanks. This bothered me for a while. Your solution worked like a charm. |
|
|
| |
Topic |
|
typedefs inside of macros
