Whole Tomato Software Forums

Whole Tomato Software Forums

All Forums

Visual Assist

Technical Support

Bad suggestion on default constructor

You must be registered to post a reply.
Click here to register.

Screensize:

UserName:

Password:

Format:

Message:

Forum code is on.
Html is off.

[quote][i]Originally posted by DaveSwedensky[/i]
[br]I've found what looks like a bug in the "VA Code Inspection" suggestions, but would be happy to be proved wrong :)

Unfortunately I can't seem to find a good minimal example of my problem - I think it only arises in complexity. But it goes roughly like this:
[code]
struct A
{
    A(Arg1 arg1, Arg2 arg2) {}
};

struct B : public A
{
    B() : A(thing1, thing2) {}
};
[/code]
All well and good. But if for some reason the inspector thinks the call to A's constructor is wrong, for example:
[code]
B() : A(thing1) {}
[/code]
then the "Code Inspection" window will tell me that the "Default constructor body can be replaced with '= default'", and the fix becomes:
[code]
B() : A(thing1) = default;
[/code]
which doesn't compile. Ok, for this example it wouldn't compile because we've got a bad constructor for A.

In my Real Life example, the constructor for A has a more complex form and the constructor for B does compile properly but for some reason the code inspector has the same problem so it suggests I change to:
[code]
B() : A(...args...) = default;
[/code]
which is definitely wrong.

Apologies for not being able to give a self-contained example of this - I tried but when I simplified as soon as the parser understood the constructor line the problem went away.

There doesn't seem to be any way to tell the code inspector that a particular instance that it thinks is wrong can't be changed for some (hopefully good) reason. Some IDEs do this by allowing a special comment on the line before and allow this to be added instead of applying the quick fix - could such a feature be incorporated for VisualAssist?

Thanks,
-Dave
[/quote]

Check to include your profile signature.
Check to subscribe to this topic.

T O P I C R E V I E W
DaveSwedensky	Posted - Sep 13 2017 : 04:32:51 AM I've found what looks like a bug in the "VA Code Inspection" suggestions, but would be happy to be proved wrong :) Unfortunately I can't seem to find a good minimal example of my problem - I think it only arises in complexity. But it goes roughly like this: struct A { A(Arg1 arg1, Arg2 arg2) {} }; struct B : public A { B() : A(thing1, thing2) {} }; All well and good. But if for some reason the inspector thinks the call to A's constructor is wrong, for example: B() : A(thing1) {} then the "Code Inspection" window will tell me that the "Default constructor body can be replaced with '= default'", and the fix becomes: B() : A(thing1) = default; which doesn't compile. Ok, for this example it wouldn't compile because we've got a bad constructor for A. In my Real Life example, the constructor for A has a more complex form and the constructor for B does compile properly but for some reason the code inspector has the same problem so it suggests I change to: B() : A(...args...) = default; which is definitely wrong. Apologies for not being able to give a self-contained example of this - I tried but when I simplified as soon as the parser understood the constructor line the problem went away. There doesn't seem to be any way to tell the code inspector that a particular instance that it thinks is wrong can't be changed for some (hopefully good) reason. Some IDEs do this by allowing a special comment on the line before and allow this to be added instead of applying the quick fix - could such a feature be incorporated for VisualAssist? Thanks, -Dave
5 L A T E S T R E P L I E S (Newest First)
sean	Posted - Nov 07 2019 : 5:45:28 PM case=111068 is implemented in build 2353 https://support.wholetomato.com/default.asp?W404#2353 Starting in 2353, directives in source comments can prevent issues from being flagged in particular instances without disabling a Code Inspection checker globally. Directives that are processed before parsing: // vaCI:skipall skip Code Inspection entirely Directives that are processed after parsing: // vaCI:skip skip fix(es) from the current line // vaCI:skip+10 skip 10 lines, starting with current line // vaCI:skip-10 skip 10 previous lines, starting with current line // vaCI:skip+* skip until the end // vaCI:skip-* skip from the beginning // vaCI:<any skip>:checker,checker,... // skip only specified checker(s); // checker names are matched by given substring; // code issue names/descriptions are not matched; An example that skips all modernize-make-unique and modernize-make-shared issues: // vaCI:skipall:unique,shared
accord	Posted - Sep 26 2017 : 08:57:59 AM You can also subscribe to this topic at the top of this page.
feline	Posted - Sep 19 2017 : 09:09:34 AM When we have a new release that fixes either of these cases, this thread will be updated. The easiest method may simply be to turn On: VA Options -> Startup -> Automatically check for new version and review the release notes to see what has been fixed. You can also always ask here for an update on this.
DaveSwedensky	Posted - Sep 14 2017 : 03:44:25 AM Yes, it has an initializer list so is likely covered by the same bug. Interestingly I found some examples of use of initializer lists where the bug does not manifest. So long as the issue is logged, I'm happy. Also, thanks for the feature request. I think it will be useful for many people. Apologies for a very basic question, but how do I subscribe to updates for these issues?
accord	Posted - Sep 13 2017 : 3:00:36 PM We have a bug report for Code Inspections to not suggest constructor with initialiser list be replaced with = default case=109725 Is it possible that your "real" world example has an initializer list? Regarding a special comment to disable code inspections: I have put in a feature request for that. case=111068

Snitz Forums 2000