i want to be able to write 2 sets of rules:
Ruleset which ignores errors like
Uninitialized variable
variableScope
Ruleset which includes ALL , but i can manually ignore one or more rule sets
Keeping in view that :
cppcheck will check for memory leaks.
For classes the checking is only made if "--all" is given. The reason is that there will be false positives if an instance is deallocated automatically.
In Cppcheck terminology.. a rule is a user-defined pattern that Cppcheck should look out for in the code and report about.
1.Ruleset which ignores errors like
Use suppressions. See --suppression-list and --suppress. You can use -i to skip entire files.
2.Ruleset which includes ALL , but i can manually ignore one or more rule sets
Use --enable.
Related
AWS docs state that this property is "A list of Java properties that are set when the job flow step runs. You can use these properties to pass key-value pairs to your main function in the JAR file."
But there is no explanation (at least, I failed to find any) how exactly they are passed, and how to properly access said collection of key-value pairs on a main function side.
Quick check proved that they aren't passed via environment nor command line arguments. Could be some other way?
Okay, seems that this map goes to Java system properties and is accessible from main function side via System.getProperties() call, but there are some non-obvious implications.
First thing to keep in the mind, that internally they are set via environment variable HADOOP_CLIENT_OPTS as -Dkey=value switches. But EMR does not bother itself to properly escape keys nor values by shell rules.
Also, it does not report any syntax errors if there are properties with non-printable characters, just omits setting them altogether. And it plays even worse with special shell characters like * ? ( ) \ and such — it'll fail the task execution without a proper explanation, and the log records will vaguely point only to obscure syntax errors in some eval() call deeply inside of EMR internal shell script wrappers.
Please be aware about that behaviour.
Properties must be shell-escaped, and in some cases even doubly shell-escaped.
struct Foo{
Bar get(){
}
}
auto f = Foo();
f.get();
For example you decide that get was a very poor choice for a name but you have already used it in many different files and manually changing ever occurrence is very annoying.
You also can't really make a global substitution because other types may also have a method called get.
Is there anything for D to help refactor names for types, functions, variables etc?
Here's how I do it:
Change the name in the definition
Recompile
Go to the first error line reported and replace old with new
Goto 2
That's semi-manual, but I find it to be pretty easy and it goes quickly because the compiler error message will bring you right to where you need to be, and most editors can read those error messages well enough to dump you on the correct line, then it is a simple matter of telling it to repeat the last replacement again. (In my vim setup with my hotkeys, I hit F4 for next error message, then dot for repeat last change until it is done. Even a function with a hundred uses can be changed reliably* in a couple minutes.)
You could probably write a script that handles 90% of cases automatically too by just looking for ": Error: " in the compiler's output, extracting the file/line number, and running a plain text replace there. If the word shows up only once and outside a string literal, you can automatically replace it, and if not, ask the user to handle the remaining 10% of cases manually.
But I think it is easy enough to do with my editor hotkeys that I've never bothered trying to script it.
The one case this doesn't catch is if there's another function with the same name that might still compile. That should never happen if you do this change in isolation, because an ambiguous name wouldn't compile without it.
In that case, you could probably do a three-step compiler-assisted change:
Make sure your code compiles before. Then add #disable to the thing you want to rename.
Compile. Every place it complains about it being unusable for being disabled, do the find/replace.
Remove #disable and rename the definition. Recompile again to make sure there's nothing you missed like child classes (the compiler will then complain "method foo does not override any function" so they stand right out too.
So yeah, it isn't fully automated, but just changing it and having the compiler errors help find what's left is good enough for me.
Some limited refactoring support can be found in major IDE plugins like Mono-D or VisualD. I remember that Brian Schott had plans to add similar functionality to his dfix tool by adding dependency on dsymbol but it doesn't seem implemented yet.
Not, however, that all such options are indeed of a very limited robustness right now. This is because figuring out the fully qualified name of any given symbol is very complex task in D, one that requires full semantics analysis to be done 100% correctly. Think about local imports, templates, function overloading, mixins and how it all affects identifying the symbol.
In the long run it is quite certain that we need to wait before reference D compiler frontend becomes available as a library to implement such refactoring tool in clean and truly reliable way.
A good find all feature can be better than a bad refactoring which, as mentioned previously, requires semantic.
Personally I have a find all feature in Coedit which displays the context of a match and works on all the project sources.
It's fast to process the results.
I have quite a few source files in nested subfolders for a project. I have 4 different classes that I am attempting to replace, and want to locate every place in the source they are allocated (heap + stack).
Unfortunately, due to a poor include structure, Visual Studio's "search entire solution" feature cannot be trusted, so I have resorted to a manual search within the source files.
What I believe is sufficient:
"new CLASS1(" with any combination of spaces between the three tokens there for heap and
"^CLASS2" where I'm trying to say the Class name starts at the beginning of the line (excluding spaces) for stack allocation.
For stack allocation, [^a-zA-Z] CLASS3 [a-zA-Z]+ was attempted, but I'm not fluent in regex so wanted to run this by SO. For heap, just that string above was tried, but I know that a simple extra spacing would break that pattern so I know it is incorrect.
Can anyone come up with a better matcher or even an entirely better way to go about the problem?
Thank you,
AK
Make the constructors private and you'll get an error message for every attempt to create the object.
Make a private new() operator to do the same trick with heap allocations.
Edit: watch out for the code INSIDE the class implementation (including static methods) creating instances of itself. Calling a private constructor from such context is valid and won't trigger an error. Also watch out for friend classes/functions.
One guaranteed way to ensure you eliminate all usage of a class is to simply remove the definition of a class or make some key part of it invalid. Then when you compile the project you will get an error for each and every situation that class is used in. When everything is successfully compiled you will know everything has been replaced.
You can of course speed things up a little bit by using find/replace for the simple cases and then manually fix up any remaining cases.
I currently use some old C library for getting program options and would like to replace that with some proper C++ (mainly to become independent of that library, which is a real burden). I was looking into using boost.program_options, but am not sure it can support all I want. Some things I want is:
allow the following command-line syntax: myprogram option=value (in particular, I don't really want the --option value syntax)
use a default value if no value is provided (obviously this can be done in my program, but support in the options library would be nice)
allow default options (which are always present even if I don't give them) and an automatic help output consisting of all the options and their descriptions
allow mathematical parsing, i.e. (command line) myprogram option1=Pi option2=3/5 option3=sqrt(2) to give 3.1415..., 0.6, and 1.415... in my program
allow single values to be expanded. Let option_3Dpoint correspond to an std::array<double,3>, I want both myprogram option_3Dpoint=0,0,0 and myprogram option_3Dpoint=0 (expanding to 0,0,0) to work
Which of these can be supported by boost.program_options? Are there any alternatives?
boost.program_options is very good library. You can use to parse config files aswell. Answers:
Dont know but seems no builtin support.
Yes.
Yes.
No unless you make your own expression evaluation handler or use some other boost libs to do this.
Yes, you will need to write your own handler which creates 3DPoint object from string like 0,0,0
I'm using a tool chain that is more like a web. There are lotys of alternate start points, all resulting in a single final output.
I typically use make or scons - actually, I prefer scons, but my team highly prefers make. I'm open to other build tools.
E.g. final_result depends on penultimate
final_result: penultimate
penultimate may be made in any of several different ways:
If starting from file1, then
penultimate: file1 ; rule1
If starting from file2, then
penultimate: file2 ; rule2
Q: how do I specify to start with file2, not file1?
I suppose that I could use a command line switch and ifdeffing. But I would prefer to have make or scons figure out "Hey, there's a file2 around, so I should use rule2, not fil1/rule1". In part because the web is much more complex than this...
Worse, sometimes an intermediate on one path may be a start on another. Let's see:
A .s produces a .diag
foo.diag: foo.s
But sometimes there is no .s, and I just have a .diag that somebody else gave me already built.
A .diag produces a .heximg, and a .hwresult
foo.hwresult: hwsim foo.heximg
foo.heximg: foo.diag
But sometimes I am given a .img directly
Etc.
I just want to write the overall dependency graph, and say "OK, now here's what I have been given - now how do you get to the final result?"
With what I have now, when I am given, say, a foo.img, I get told (by make in this case) "foo.s not dfound". Because make wants to go all the way back in the dependency graph to tell if foo.img is out of date, whereas I want to say "assume foo.img is up to date, and work forwrads for stuff that depends on foo.img, instead of going back for stuff that foo.img depends on."
You have to do it all with pattern rules (implicit rules). If you specify an explicit rule then make considers that a hard dependency and if some portion of the dependency is not met, make will fail.
If you use an implicit rule then make will consider that a POSSIBLE way to build the target. If that way doesn't work (because some prerequisite does not exist and make doesn't know how to build it) make will try another way. If no way works, and the target already exists, make will just use that target without having to update it.
Also you say "a .diag produces a .heximg and a .hwresult" then gave a strange example makefile syntax that I didn't recognize, but FYI with pattern rules you can specify that a single command generates multiple outputs (you can't do this with explicit rules):
%.heximg %.hwresult: %.diag
Here's the bad news: the only way to define an implicit rule in GNU make is if there is a common "stem" in the filename. That is, you can write an implicit rule that converts foo.diag to foo.heximg by writing a pattern rule "%.heximg: %.diag", because they have a common stem "foo", but there's no way to create a pattern rule for a compilation from "foo1" to "penultimate", because they don't share a common stem.
I'm not sure, but probably you're looking for Double-Colon Rules:
Double-colon rules are explicit rules written with :: instead of : after the target names. They are handled differently from ordinary rules when the same target appears in more than one rule.
Double-colon rules are somewhat obscure and not often very useful; they provide a mechanism for cases in which the method used to update a target differs depending on which prerequisite files caused the update, and such cases are rare.