Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Feature Requests
 Don't insert matching parens unless at EOL
 New Topic  Topic Locked
 Printer Friendly
Author Previous Topic Topic Next Topic  

LarryLeonard
Tomato Guru

USA
1041 Posts

Posted - Jul 30 2004 :  12:26:51 PM  Show Profile
I just turned on the "Insert closing" switch to see if I like it. The main problem I see is when I try to fix this line of code:

int nHippo = 77;

to be:

int nHippo(77);

... as all right-thinking programmers do. The problem is, when I insert the open paren, VAX gives me this:

int nHippo() = 77;

... which is annying. What would it break if VAX only inserted the closing paren if the caret is at the End of Line?

WannabeeDeveloper
Tomato Guru

Germany
775 Posts

Posted - Jul 30 2004 :  3:53:50 PM  Show Profile
Just enable "Surround selection", select the 77 and press (

You still need to delete the = but that won't be such a pain in the butt (compared to what you get with your method)

Go to Top of Page

LarryLeonard
Tomato Guru

USA
1041 Posts

Posted - Jul 30 2004 :  8:12:17 PM  Show Profile
Aha! Excellent idea. Thanks!
Go to Top of Page

support
Whole Tomato Software

5566 Posts

Posted - Jul 30 2004 :  11:39:32 PM  Show Profile
As we have mentioned previously, we are not particularly fond of the "Insert closing" option. It's impossible to get right. Often more trouble than it's worth.
Go to Top of Page

Old as dirt
Tomato Guru

USA
246 Posts

Posted - Aug 02 2004 :  6:46:50 PM  Show Profile
Larry,
Not to get off topic except I haven't seen this anywhere else, how is
int nHippo = 77;
different from
int nHippo(77);
that makes it worth changing?
If there is a better place to discuss this, lets go there.
Thanks,

Ken
Go to Top of Page

jpizzi
Tomato Guru

USA
642 Posts

Posted - Aug 02 2004 :  8:55:03 PM  Show Profile
Both should be functionally equivalent. Conceptually, the first is creating a default int, then assigning 77 to it, but AFAIK all compilers will substitute calling the appropriate constructor.

My guess is that it is a coding standard issue, not a functional issue.

Joe Pizzi
Go to Top of Page

Stephen
Tomato Guru

United Kingdom
781 Posts

Posted - Aug 03 2004 :  05:08:18 AM  Show Profile
Ken and Joe are actually both correct, but I think they have proved Larry's point by seeming confused!

Of course, it makes no difference for ints, but for classes you need to know what functions are called when you write:
//case 1
CMy my1(myOld);

// case 2
CMy my2 = myOld;

// case 3
CMy my3;
my3 = myOld;
I guess it's obvious that case 1 calls the copy constructor CMy::CMy(const CMy&), and that case 3 calls the default constructor CMy::CMy(void) followed by the assignment operator CMy& CMy::operator=(const CMy&). But what does case 2 call (not "conceptually" or "AFAIK all compilers" but according to the language)?

Well, the answer is that case 2 also calls the copy constructor. It's identical to case 1. But this isn't obvious from the coding style. It looks like the assignment operator should be called, which doesn't happen. This is why Larry prefers case 1, to make it explicit what's going on. Of course, ints are a bit different because they're a built-in type, but he wants to be consistent. I don't actually do that, but I see his point.

</didacticism>

Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
Go to Top of Page

LarryLeonard
Tomato Guru

USA
1041 Posts

Posted - Aug 03 2004 :  05:43:48 AM  Show Profile
Couldn't have said it better myself!
Go to Top of Page

Old as dirt
Tomato Guru

USA
246 Posts

Posted - Aug 03 2004 :  12:56:08 PM  Show Profile
Thanks for the answers. So I wrote a line like this:
int ccc(34);
and WT colors ccc like it is a function.
Do you see the same thing?

Ken
Go to Top of Page

LarryLeonard
Tomato Guru

USA
1041 Posts

Posted - Aug 03 2004 :  1:06:52 PM  Show Profile
Yup, that's the only problem... there's a thread by me somewhere where support says that they are aware of the problem, but it's not high on the list of things to fix...
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Aug 03 2004 :  6:21:54 PM  Show Profile
quote:
Originally posted by Stephen

Ken and Joe are actually both correct, but I think they have proved Larry's point by seeming confused!


i could have done with this post a week ago, before i spent most of a day banging my head against a copy constructor "bug" in one of my classes.

you dont get these sort of problems in C

zen is the art of being at one with the two'ness
Go to Top of Page

support
Whole Tomato Software

5566 Posts

Posted - Aug 04 2004 :  3:11:38 PM  Show Profile
Coloring algorithms in VA X are not that smart -- they are build for speed. Hence, VA X occasionally gets a color incorrect. You have one such example. Without much parsing, ie without looking in more than just immediate code, VA X thinks ccc is a method.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Topic Locked
 Printer Friendly
Jump To:
© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000