I'm having a slight problem with CPPDepend's ability to detect virtual function usage. Consider the following scenario. Two classes, CParentClass and CChildClass, where CChildClass is derived from CParentClass. The CParentClass has a virtual function Test and CChildClass overrides the base class version of Test.
When it comes to usage, for various reasons I want to do something like the following:-
CChildClass * pMyChild = new CChildClass();
CParentClass * pParentClass = (CParentClass*)pMyChild;
int B = pParentClass->Test();
delete pParentClass;
This results in pMyChild's Test function being called, as desired, yet CPPDepend doesn't detect this and claims that the code is never reached. If I add the word "virtual" to the Test function header in CChildClass (in addition to the one already in CParentClass) then CPPDepend claims everything is ok.
Can anyone shed some light on this for me please as it feels wrong that I should have to put virtual in the derived class function as well as the base class function.
A similar issue can be seen with CDialog destructors in derived classes. Without the virtual in the derived class destructor declaration, CPPDepend complains.
Thanks for any help you can give.
Regards
Neil.
CppDepend do a static analysis not a dynamic one, and give the dependencies from a static point of view and it's more interesting. Indeed what's important is the dependency related to the design choices, for example in your case the object is declared as CParentClass, so the method is coupled with the contract of CParentClass, and in the runtime it could invoke a method from child classes.
Related
Seems std::get is just used on tuple class. Why not make it member class of tuple in standard library, any other usages?
The reason get is a non-member function is that if this functionality
had been provided as a member function, code where the type depended
on a template parameter would have required using the template
keyword.
source.
Snippet code when get is non-member function:
template<class T>
void foo ( tuple<T>& t ) {
get<0>(t) = 10; // get is non-member function
}
and another if get is member function of tuple:
template<class T>
void foo ( tuple<T>& t ) {
t. template get<0>() = 10; // ugly
}
Which version of get usage do you prefer ? For me, the first is better.
There is also a much older, less c++11 specific and generally more general version of an answer. (If you are only wondering about the specific case, you don't need to read on).
The general case for free functions is described in this classic DrDobb's article by an absolute C++ guru.
The short n sweet version: If you separate between public interface with access to private members and public interface with access to only the public interface you have a harder separation between a class and operations on that class.
It looks somewhat ugly, decreases helpfulness of most IDEs, but has some profound effects on your code modularity, especially when you embrace the template frenzy of the last std iterations. Matthias's answer depicts one clear example of this.
A more classic advantage is, that you can provide a set of free functions inside an extra header that a user can include on demand. Now think about interoperation between templated but otherwise completely separate classes A and B. You can now tie them together by providing a header like A_B_interop.h, full of free functions, without switching paradigms. You include that header, the classes become more powerful.
Here is a question related to the algorithm of constructing the call graph for Java bytecode using CHA.
As there is no concrete method implementation for methods in abstract classes, adding a call edge to such methods might be a bit misleading.
take junit-4.12.jar for instance. runFailed has been defined in junit.runner.BaseTestRunner which is an abstract class. Besides, there are calls to runFailed in method getTest which also defined in junit.runner.BaseTestRunner
While in "Assumption Hierarchy for a CHA Call Graph Construction Algorithm"(Jason&Atanas), it is said that
"given a call site x.m(), where the declared type of x is C, the
possible runtime type of x must be a non-abstract subtype of C."
As far as i'm considered, without add a call edge(Calledge1) from junit.runner.BaseTestRunner getTest to junit.runner.BaseTestRunner runFailed, it is more reasonable to add a call edge(Calledge2) from junit.runner.BaseTestRunner getTest to junit/textui/TestRunner runFailed as TestRunner extends BaseTestRunner.
While after running test code to get the result of CallGraph.calledByStatistics(), only Calledge1 has been found. Calledge2 is missing.
Is there anybody can do me a favor to confirm this?
Thank you in advance.
Regards,
Jiang
I found OPAL offers two views of call graph. The second one won't add a "library-call" edge into call edge.
In CallGraph.calledByStatistics()
The binding is between Callsite (PC) to caller.method
for example: between “INVOKEVIRTUAL(junit.runner.BaseTestRunner{ void runFailed(java.lang.String) })” and
junit/runner/BaseTestRunner.public junit.framework.Test getTest(java.lang.String)
In CallGraph.callsStatistics()
The binding is between subtype.method to caller.method
for example:
between "junit/textui/TestRunner.protected void runFailed(java.lang.String)” and “junit/runner/BaseTestRunner.public junit.framework.Test getTest(java.lang.String)”
Hi and thanks in advance,
I have a custom class being constructed from my main class. In the custom class it has another custom class that is passed in as a parameter. I would like to strictly type the parameter variable but when I do, 'the type is not a compile type constant etc'.
This, I understand, is because the custom class used as a parameter has not yet been constructed.
It all works when I use the variable type ( * ) to type the parameter.
I suspect this is a design flaw, in that I am using an incorrect design pattern. It is actually hand-me-down code, having received a large project from someone else who is not entirely familiar with oop concepts and design patterns.
I have considered using a dummy constructor for the parametered class in my main class but the passed in class also takes a custom class (itself with a parametered constructor). I am considering using ... (rest) so that the custom classes' parameters are optional.
Is there any other way to control the order of construction of classes? Would the rest variables work?
Thanks
(edit)
in main.as within the constructor or another function
var parameter1:customclass2;
customclass1(parameter1);
in customclass1 constructor:
public function customclass1(parameter1:customclass2)
{
....
Flash complains that the compiled type cannot be found when I use the data type customclass 2 in the paramater. It does not complain when I use the variable data type * or leave out the data type (which then defaults to * anyway). I reason that this is because customclass2 has not yet been constructed and is therefore not available to the compiler.
Alternatively, I have not added the path of customclass2 to the compiler but I am fairly certain I have ruled this out.
There are over 10,000 lines of code and the whole thing works very well. I am rewriting simply to optimise for the compiler - strict data typing, error handling, etc. If I find a situation where inheritance etc is available as an option then I'll use it but it is already divided into classes (at least in the main part). It is simply for my own peace of mind and to maintain a policy of strict data typing so that compiler optimization works more efficiently.
thnx
I have not added the path of customclass2 to the compiler but I am fairly certain I have ruled this out.
So if you don't have the class written anywhere what can the compiler do ? It is going to choke of course. You either have to write the CustomClass class file or just use "thing:Object" or "thing:Asteriks". It's not going to complain when you use the "*" class type because it could be anything an array, string, a previously declared class. But when you specify something that doesn't exists it will just choke, regardless of the order the parameters are declared in.
I have to decide whether to put a variable within a constructor or outside, but I keep getting the feeling that I am missing information, I have looked at other posts on stack overflow, but all mentioned it was a matter of preference, yet I found two difference that I feel might be important:
-If I decide to put the variables within a constructor, then I must have an object parameter for any function that wish to alter the variables, even if the code is internal to the class.
-Subclassing would cause the variables to not appear, something that causes problems when the class and any subclasses must have the variables in order to operate properly.
I may be wrong on all of these points, but at 4am, I would rather be told I am wrong than commit a mistake due to pride. If this has been answered somewhere else and I missed it, I am sorry, and if you could post the link, I would be grateful.
actions inside the constructor are interpreted, all others are precompiled so they work faster
Like www0z0k already said, the declarations outside the constructor are merly interpreted, so declaring them outside can be a performance bost under some circumstances.
-If I decide to put the variables within a constructor, then I must have an object parameter for any function that wish to alter the variables, even if the code is internal to the class.
This is correct.
-Subclassing would cause the variables to not appear, something that causes problems when the class and any subclasses must have the variables in order to operate properly.
You should think about what you want to archive. Most times you should rather choose a good software design then to think about performance. This subclassing problem that you mentioned can also protect some variables from being changed.
Greetings,
iuiz
-Subclassing would cause the variables to not appear, something that causes
problems when the class and any
subclasses must have the variables in
order to operate properly.
If I understood you correctly you're looking for protected fields (or properties).
-If I decide to put the variables within a constructor, then I must have
an object parameter for any function
that wish to alter the variables, even
if the code is internal to the class.
Sry, I don't get that...
#Performance: with all that said about interpreted constructors you could add a simple init(...) function within your constructor which does all you would do in the constructor - but without being interpreted.
public function ConstructorOfClass(arg1:int, arg2:*)
{
init(arg1, arg2);
}
private function init(arg1:int, arg2:*):void
{
// do whatever you want here
}
I have question regarding the use of function parameters.
In the past I have always written my code such that all information needed by a function is passed in as a parameter. I.e. global parameters are not used.
However through looking over other peoples code, functions without parameters seem to be the norm. I should note that these are for private functions of a class and that the values that would have been passed in as paramaters are in fact private member variables for that class.
This leads to neater looking code and im starting to lean towards this for private functions but would like other peoples views.
E.g.
Start();
Process();
Stop();
is neater and more readable than:
ParamD = Start(paramA, ParamB, ParamC);
Process(ParamA, ParamD);
Stop(ParamC);
It does break encapsulation from a method point of view but not from a class point of view.
There's nothing wrong in principle with having functions access object fields, but the particular example you give scares me, because the price of simplifying your function calls is that you're obfuscating the life cycle of your data.
To translate your args example into fields, you'd have something like:
void Start() {
// read FieldA, FieldB, and FieldC
// set the value of FieldD
}
void Process() {
// read FieldA and do something
// read FieldD and do something
}
void Stop() {
// read the value of FieldC
}
Start() sets FieldD by side effect. This means that it's probably not valid to call Process() until after you've called Start(). But the code doesn't tell you that. You only find out by searching to see where FieldD is initialized. This is asking for bugs.
My rule of thumb is that functions should only access an object field if it's always safe to access that field. Best if it's a field that's initialized at construction time, but a field that stores a reference to a collaborator object or something, which could change over time, is okay too.
But if it's not valid to call one function except after another function has produced some output, that output should be passed in, not stored in the state. If you treat each function as independent, and avoid side effects, your code will be more maintainable and easier to understand.
As you mentioned, there's a trade-off between them. There's no hard rule for always preferring one to another. Minimizing the scope of variables will keep their side effect local, the code more modular and reusable and debugging easier. However, it can be an overkill in some cases. If you keep your classes small (which you should do) then the shared variable would generally make sense. However, there can be other issues such as thread safety that might affect your choice.
Not passing the object's own member attributes as parameters to its methods is the normal practice: effectively when you call myobject.someMethod() you are implicitly passing the whole object (with all its attributes) as a parameter to the method code.
I generally agree with both of Mehrdad and Mufasa's comments. There's no hard and fast rule for what is best. You should use the approach that suits the specific scenarios you work on bearing in mind:
readability of code
cleanliness of code (can get messy if you pass a million and one parameters into a method - especially if they are class level variables. Alternative is to encapsulate parameters into groups, and create e.g. a struct to whole multiple values, in one object)
testability of code. This is important in my opinion. I have occassionally refactored code to add parameters to a method purely for the purpose of improving testability as it can allow for better unit testing
This is something you need to measure on a case by case basis.
For example ask yourself if you were to use parameter in a private method is it ever going to be reasonable to pass a value that is anything other than that of a specific property in the object? If not then you may as well access the property/field directly in the method.
OTH you may ask yourself does this method mutate the state of the object? If not then perhaps it may be better as a Static and have all its required values passed as parameters.
There are all sorts of considerations, the upper most has to be "What is most understandable to other developers".
In an object-oriented language it is common to pass in dependencies (classes that this class will communicate with) and configuration values in the constructor and only the values to actually be operated on in the function call.
This can actually be more readable. Consider code where you have a service that generates and publishes an invoice. There can be a variety of ways to do the publication - via a web-service that sends it to some sort of centralized server, or via an email sent to someone in the warehouse, or maybe just by sending it to the default printer. However, it is usually simpler for the method calling Publish() to not know the specifics of how the publication is happening - it just needs to know that the publication went off without a hitch. This allows you to think of less things at a time and concentrate on the problem better. Then you are simply making use of an interface to a service (in C#):
// Notice the consuming class needs only know what it does, not how it does it
public interface IInvoicePublisher {
pubic void Publish(Invoice anInvoice);
}
This could be implemented in a variety of ways, for example:
public class DefaultPrinterInvoicePublisher
DefaultPrinterInvoicePublisher _printer;
public DefaultPrinterInvoicePublisher(DefaultPrinterFacade printer) {
_printer = printer
}
public void Publish(Invoice anInvoice) {
printableObject = //Generate crystal report, or something else that can be printed
_printer.Print(printableObject);
}
The code that uses it would then take an IInvoicePublisher as a constructor parameter too so that functionality is available to be used throughout.
Generally, it's better to use parameters. Greatly increases the ability to use patterns like dependency injection and test-driven design.
If it is an internal only method though, that's not as important.
I don't pass the object's state to the private methods because the method can access the state just like that.
I pass parameters to a private method when the private method is invoked from a public method and the public method gets a parameter which it then sends to the private method.
Public DoTask( string jobid, object T)
{
DoTask1(jobid, t);
DoTask2(jobid, t);
}
private DoTask1( string jobid, object T)
{
}
private DoTask2( string jobid, object T)
{
}