| T O P I C R E V I E W |
| cgough |
Posted - Aug 29 2006 : 10:51:48 AM
I was waiting for a build that corrects all of the (.) to (->) issues reported since build 1531. This core functionality is 100% required and is a HUGE SHOWSTOPPER for any C++ developer. I really like the find feature and the refactoring but your product without this basic functionality is not worth paying for. As a fellow developer I am not sure how a beta build can be produced without the core functionality working. That's not beta!
Sorry to gripe but this issue is really critical for us.
Case 2131
Case 2069
Case 2060
Case 2276
Thanks |
| 22 L A T E S T R E P L I E S (Newest First) |
| kurt |
Posted - Sep 19 2006 : 9:17:59 PM
Thanks, feline! |
| support |
Posted - Sep 19 2006 : 01:55:22 AM
Case 2069 is fixed in build 1535. |
| feline |
Posted - Sep 16 2006 : 4:54:52 PM
kurt that makes sense. i have spent a lot of time writing C myself, and casting a lot of things to and from (void *)
personally i always tried to cast into a pointer of the correct type, and then use that pointer, but this does not help when you have a lot of code written by different people.
i have bumped the priority of case 2276 for you, so hopefully it will appear fairly soon. |
| kurt |
Posted - Sep 15 2006 : 01:15:46 AM
feline, re 2276, eliminating C-style casts is not as easy as simply setting the "compile as C++" option. The C code is full of pointers declared as void* that have to be cast to various actual pointer types depending on some condition. To clean that up, I would have to change a few hundred function prototypes and structure definitions, provide polymorphic versions of all those functions, etc. You are so fortunate to be working with code that you have written yourself according to a modern style. One reason VA is so valuable is that it helps a lot in coping with this old legacy code that lots of us still have out here. |
| sean |
Posted - Sep 12 2006 : 2:02:51 PM
bug 2069 is fixed for the next build.
we have a fix for bug 2131 that needs further testing...
|
| cgough |
Posted - Sep 12 2006 : 1:05:02 PM
feline - 2131 is pretty much what I am seeing. I am going to upgrade to the release build and go from there. I am not typing too fast (believe me!)
Thanks for your attention, C++ parser being re-worked explains lots of things. |
| jpizzi |
Posted - Sep 08 2006 : 12:44:35 PM
Yea, I guess they figured that if you are using Scientific view, you don't need the operation, as you know what it really means.
That, or they just ran out of real-estate in the window.  |
| SvenC |
Posted - Sep 07 2006 : 02:52:07 AM
jpizzi: I always use calc in scientific view. I turned back to Standard and your are right: % is there. So the ops are user sensitive ;) |
| feline |
Posted - Sep 06 2006 : 6:17:10 PM
kurt, this is a long shot, but do you have the option to compile your C code as C++? if you are using the IDE then you certainly have a C++ compiler in hand. i am currently ignoring the nasty thought that most of the C code will fail to compile as C++.
SvenC we are grappling with the age old problem "which bugs first?" *sigh* |
| jpizzi |
Posted - Sep 06 2006 : 01:58:55 AM
SvenC, I agree with your point, but I wanted to point out that calc.exe does have the %. |
| SvenC |
Posted - Sep 06 2006 : 01:42:25 AM
I'd compare the ". to ->" feature more to a % operator which some calculators offer rather than the add operator. That function helps in calculating the percentage of a number, so you don't have to know how to calculate x% of y. To not have that function (calc.exe does not have it) would not be a show stopper for me to use that calculator.
However, I guess the VAX team will do its best to address the above cases. |
| kurt |
Posted - Sep 05 2006 : 8:10:29 PM
perhaps it is just me, but i manage to avoid C style casts in my code, and only use dynamic_cast very sparingly.
The project in which I encounter this is a rather large legacy C project, not C++. Sadly, C style casts are unavoidable. |
| feline |
Posted - Sep 05 2006 : 5:08:18 PM
let me try to address this one thing at a time. in C#, which is the main .NET feature that comes up on the forum, VA gets its intellisense information from the IDE, it does not parse the code its self.
the C++ parser was re-written, specifically around VA version 1418. there were a variety of reasons for this, but one of them was that it was becoming impossible to fix certain classes of parser bugs in the old code base. certain new bugs were introduced when this was done, but hopefully most of them have been fixed by now.
cgough you speak as if this is a constant problem for you. is this the case? is this going wrong all of the time, all over the place, everywhere? or is it limited to specific situations, as described in the cases?
i am trying to pin down what is going on here, so we can try to do something constructive about this.
case 2131 comes from this thread http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=5136
and this is not something that a lot of people seem to be experiencing. note this is only reported as happening on "chains", not on all dots, and even then only when typing fast.
case 2069 (Dot expanded to -> after insert of try/catch) i cannot even reproduce, as i have already said, and schoenherr is getting it occasionally. are you seeing this all of the time?
case 2060, do you use the #define LPNMDATETIMEFORMATQUERY much? is this happening on other #define types in your code?
case 2276 (dot not converted to -> on cast)
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=5222
perhaps it is just me, but i manage to avoid C style casts in my code, and only use dynamic_cast very sparingly.
the other big question from my perspective, are these new problems in a recent build? or are these problems you have been running into for a long time? in thread 5222 kurt reported that this was not a problem in VA 1446, but i saw exactly the same problem in 1446 when i tested it. |
| cgough |
Posted - Sep 05 2006 : 12:09:06 PM
Thruska - Beta software is just fine but if you look at the top of the page "Visual Assist - A higher form of intellisense" tells me that Beta still should offer a "A higher form of intellisense". Putting out a calulator that does not add or multiply, and calling it beta is not really fair.
SvenC - C++ programmers should understand when to use . or ->, shouldn't they? I am not talking about fringe cases, but basic expected functionality. Yes I realize the parsing bit can be hard, but that's what I am paying for!
Wrongway - Yes you got my point.
Jrynd - This functionality has been part of the product for years (VC6 timeframe, possibly earlier). Turning it off is no feature at all.
I only think it's a big or huge showstopper because changes have been made that have disabled core functionality. What if calc.exe stopped adding numbers correctly? Beta or Showstopper.
My concern is all these new .NET languages have hosed up C++ parsing to the point where it may never get fixed correctly.
Sorry to gripe.
|
| feline |
Posted - Sep 04 2006 : 6:40:48 PM
the good news is you do not need to convince me, since someone has already entered the case i always dislike problems like this, that only happen very occasionally for no obvious reason, since they are so hard to pin down. |
| schoenherr |
Posted - Sep 04 2006 : 01:36:15 AM
hello feline,
about case 2069: this happens to me occasionally (usaly when typing very fast). i often tried to reproduce this to make a bug report (you can see that i didn't know about case 2096). But every time i noticed the bug it was unreproducible. Deleting the "->.." and retyping the 3 dots as fast as i can didn't produce anything than 3 dots). So i decided not to bother anyone, but now reading about case 2069 i thougt it's worth to mention that it's not a single user problem.
with kind regards
m.schoenherr |
| feline |
Posted - Sep 02 2006 : 3:34:24 PM
i have just had a look at the 4 cases listed in the first post, and they all apply to fairly specific conditions. personally i have this option turned on all of the time, on all of my machines, and it works perfectly for me over 99% of the time.
as for something being a show stopper, speaking personally a "huge showstopper" would be: "the IDE crashed, corrupted all of the source code, and the hard drive needed to be re-formatted." thankfully i don't recall ever seeing one of those reported.
my personal definition of a show stopper would be "i pressed this button on the toolbar and the IDE crashed." we had one of those a couple of weeks ago in VC6 which took quite a bit of going back and forward between me and the user effected to pin down and reproduce.
if every time i typed a dot it was converted into ->, regardless of context or the nature of the variable then i would call this a fairly major bug, but still not quite in the same league as an IDE crash.
i DO know just how frustrating bugs in VA can be, but at the same time it is important to retain some form of perspective there are outstanding bugs that effect me personally that i would quite like to see fixed, but i do appreciate they are fairly minor, and only effect a small number of people.
as a final point on all of this, i cannot even reproduce case=2069, which is about a dot being converted to -> when typing a "catch(...)" block. |
| jrynd |
Posted - Sep 01 2006 : 09:57:37 AM
quote:
Originally posted by SvenC
Thats true - I was mainly wondering about the term "huge showstopper"
The bug is only a showstopper if you leave the feature turned on! |
| SvenC |
Posted - Aug 31 2006 : 01:02:37 AM
Thats true - I was mainly wondering about the term "huge showstopper" |
| Wrongway |
Posted - Aug 30 2006 : 11:07:53 AM
To me, the grip is that it WAS there and now it is broken. It does help productivity in using one key stroke versus 2. I can go back to using 2, but prefer 1. I read the release notes for 1533 and nothing in there indicated that this issue was corrected, so I have not even tried it.
Give them time and I'm sure it will be fixed. |
| SvenC |
Posted - Aug 29 2006 : 1:17:59 PM
Hi cgough,
C++ programmers should understand when to use . or ->, shouldn't they? If not give them C# or Java 
So defining this as a huge showstopper makes me wonder.
Whenever I rebuild my machine I make sure this option is turned off. Just like thruska said: with all the handy smart pointer stuff around how should VAX know when I want to access the smart pointer members or the pointer members. You can easily setup a scenario where smart pointer code will compile with . and ->. Just have a member on the pointed to class with the exact same signature as your smart pointer class. Would not want to check all the time while typing if VAX "corrected" my code correctly regarding that option.
Regards,
SvenC |
| thruska |
Posted - Aug 29 2006 : 11:47:52 AM
Definition of "beta" in my book: Not quite working as expected yet but you're free to give it a whirl if you don't mind running software that might not be 100% stable or ever 100% what you expect...but be sure to let us know if there are problems!
Betas are for the people who are willing to try software out to make sure nothing is busted and are willing to take the time to report bugs. Whole Tomato doesn't _HAVE_ to release betas but doing so makes it possible to get feedback before official releases. If they are "playing" with the core parser, lots of weird, unexpected problems can show up and it could be a while before they get fixed.
They are trying to get smart pointers to work properly in all contexts, which is probably where the majority of the '.' to '->' (and vice versa) issues are coming from. Patience. I threw them a doozy of a parser issue last week related to smart pointers and it (obviously) still exists in 1533, but a case was opened for it (case 2221). Both the '.' and '->' operators are valid for smart pointers. It is pretty easy for a human to figure out which one to use, but for a computer program, it is a lot harder.
1533 is a huge improvement over 1532, but it still needs some work. |
