T O P I C R E V I E W |
Uniwares |
Posted - Jul 15 2008 : 10:55:15 AM First the good ones: this build seems so far be much more to the point, needs less corrections than previous builds in C#. The member list filters are just great too.
Bad ones: does not parse C++ macros as previous versions did. example macro:
#define DEFINE_INT_VAL(x) \ private: int m_n##x; \ public: int x () const { return m_n##x; } void x(int n) { m_n##x = n; }
class xy { DEFINE_INT_VAL(SomeValue); }
This was in previous versions correctly resolved into member variable and funcions, now it shows in the member list as "xy::DEFINE_INT_VAL(SomeValue)", not good. Really not good.
|
8 L A T E S T R E P L I E S (Newest First) |
feline |
Posted - Jul 18 2008 : 09:14:19 AM lexxmt turning on deep macro parsing can cause problems, which is one reason we are not making this option to obvious.
Can you post details of any macro handling that has gotten worse in VA 1645? |
lexxmt |
Posted - Jul 18 2008 : 06:03:57 AM quote: Originally posted by feline
Did you used to have deep macro parsing turned on?
http://docs.wholetomato.com?W363
If this got turned off somehow this might explain the difference you are seeing.
Agree that 1645 work more badly with macros also comparing with build 1640. Can you add this stuff to VAX settings? |
Uniwares |
Posted - Jul 16 2008 : 7:00:23 PM I was mainly talking about the Alt+M member list; as far as I can see in most other places it shows up correctly parsed (definition bar, VA view, tooltips, etc), Alt+G brings me to the right place too.
Have to install an old version to see what exactly is different to 1645 now. May take a while to do so. |
accord |
Posted - Jul 16 2008 : 6:35:43 PM I may misunderstood the problem. I wrote about alt+m instead of member listboxes. This is because I am seeing "xy::DEFINE_INT_VAL(SomeValue)" like syntax only in alt+m list. I tested member listboxes and I'm seeing DEFINE_INT_VAL, m_nSomeValue, SomeValue with 1645. I have deep macro parsing turned off.
Can you try your example in a new default test project to see what happens? My test code was: #define DEFINE_INT_VAL(x) \ private: int m_n##x; \ public: int x () { return m_n##x; } void x(int n) { m_n##x = n; }
class xy { DEFINE_INT_VAL(SomeValue); }
void p() { xy i; i.| }
| is the caret. Or are we talking about different things? |
feline |
Posted - Jul 16 2008 : 09:22:18 AM When you say:
>> This was in previous versions correctly resolved into member variable and funcions
where did this work? In listboxes, or else where?
VA has problems with ## in macros to generate names:
case=729
this is a long standing problem. I would hope VA could work out the functions generated by this macro, but I would not expect VA to work out the member variables.
I am wondering if changes to VA now mean you are seeing a member listbox from VA instead of a member listbox from the IDE. If so does turning on:
VA Options -> Advanced -> Listboxes -> Get content from default Intellisense
make any difference? |
Uniwares |
Posted - Jul 15 2008 : 3:33:18 PM Deep macro parsing was not on as far as I remember. Never had a problem with these defines before. As for the single/multiline question, the real code consists of dozens of these (and other, similar) entries in multiple lines, spread over the whole class definition. |
feline |
Posted - Jul 15 2008 : 1:47:39 PM Did you used to have deep macro parsing turned on?
http://docs.wholetomato.com?W363
If this got turned off somehow this might explain the difference you are seeing. |
accord |
Posted - Jul 15 2008 : 1:30:07 PM I seeing the same effect here, but unfortunately I see this with 1626 and 1640 also. Which version did you use before 1645?
The only difference is, I'm seeing "::" after the class name in 1645, and "." in previous versions.
Also note that I do not see "SomeValue" if I use one line syntax:
class xy { DEFINE_INT_VAL(SomeValue); };
but It appears if I use multi-line syntax:
class xy {
DEFINE_INT_VAL(SomeValue);
};
How it differs from you experience? |