It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
When reading the documentation of one or another boost library, I encountered some statements giving a hint that the virtual keyword is kind of evil. See http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/ch03s05.html, for example:
It will not be said that MSM forces the virtual keyword down your throat!
According to http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.4, the virtual keyword is really not that bad, and my feeling about it is the same.
Why do some of the boost people regard virtual function calls as the worst thing ever? I have the impression that the boost guys are really the experts on C++, so there must be something about it.
there is case where static polymorphism is preferred to dynamic one. That's what Christophe states here. Nothing more.
Runtime polymorphism has an extra cost, namely the vtable. Once the vtable is added in a type, it can't be removed. One of the core strengths of C++ is that "you only pay for what you use". Therefore, to keep objects as lean as possible, several libraries avoid virtual functions when possible. Not because it is evil, but because you may not want it.
I think the inference is that MSM does not, through its inner workings or structure, force you to declare members of your own code as virtual, or to override theirs. There are libraries that require this, for instance libraries that dynamically create "proxies" of your classes such as mocks or lazy-loaders.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I am from JAVA so please please guide me if i am wrong.
In Java we mostly use a singleton class and create all the class objects thought the singleton class.
What about in c++?
I know we can use singleton but mostly while going through most of the stack overflow questions. Most of them says it's not good to use singleton in c++
Can you recommend some book or some project which will be easy to understand?
Whether you're writing in C++ or Java singletons have many, bad implications.
They make it very difficult to test as their static nature preculdes late binding to, say, sway a real database with a stub that's quicker and has fewer depencies.
They also provide a fig leaf for global variables, trying to make them masquerade as a good design decision. Take a look at the alternatives, it'll pay off in a better design. You may want to look into dependency injection for ways to design a more testable system without singletons.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
In C and C++, what is the advantage of making a local const variable static? Assuming the initialization does not use other variables, is there any difference between preserving the value between calls, and setting the same constant value each call?
Could a valid C compiler ignore the static?
In C++, it avoids the construction/destruction between calls, but could there be any other benefit?
It doesn't take up stack-space may be a benefit if you have something like:
static const double table[fairly_large_number] = { .... };
Obviously, cost of construction can also be substantial enough that if the function is called a lot, there's good value in only constructing the object once.
Yes, and it is huge: a semantic benefit.
When you put const, you don't just mean the compiler shouldn't let you modify the variable. You make a bolder statement to whoever reads the code later: this won't ever change. Not even by a side effect where you give this variable as a pointer to another function.
Also, the compiler can take advantage of that new information and optimize it away in some situations, depending on the specific type you are dealing with.
(to be clear, I'm speaking here about const vs. non-const, not static vs. non-static.)
Edit: This SO answer is very informative too.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Taking this as an example:
I have 20 structs. I access all of the struct's fields directly, getting values off them, pointers to other sub-structs they might have, etc.
Now, I restructure the program:
Instead of acessing structs's fields DIRECTLY, I've encapsuled all of the struct into their own respective classes, and have functions for all the possible get(), and set(x).
The Question: Is there a performance impact for using methods/functions, instead of acessing structs directly?
Some sort of estimated % would be great, or some explanation.
In general, there shouldn't be a performance difference if the getters and setters are defined inline within the class. For virtually any contemporary compiler, the function call will be expanded inline, leaving no overhead. This will often be true for various small inline functions. (See, for example, http://www.gotw.ca/publications/mill18.htm, where Herb Sutter discusses why making most/all virtual functions nonpublic adds no overhead to the resulting code.)
Note that if you do define the function inline in the class, any client code will need to be recompiled if the definition ever changes. But that applies to most/all changes in header files.
I haven't heard of performance as a considerable difference between structs and classes, so it is your call.
I googled these pages below, and they say there shouldn't be a difference when it comes to performance.
http://www.gamedev.net/topic/115725-is-a-struct-faster-than-a-class/
http://forums.codeguru.com/showthread.php?332571-Struct-vs-Class
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
What does it mean "register a class", if we are talking about C++ and OOP, not about register, COM or some other libraries?
In the context of pure C++, without respect to any specific platoform or library, "register a class" has no meaning. This is not a language concept, nor is it any design pattern I am aware of.
It does however have at least two meanings the Windows world. For posterity and future readers:
You can register a Window class. A Window class contains some basic functionality and other parameters that effect how specific windows behave on-screen.
You can register a COM class so that specific instances of that COM class can be instantiated by clients.
"context was in articles about OOD, and it was said something like it is good practice to plan your classes in the way that for changing some aspect of program it will be enough to write new class, register it and you get new staff"
Now it seems to me you are talking about the publisher/subscriber pattern. It allows loose coupling between caller and callee.
You can find a C++ implementation everywhere, in the GoF book, or here:
http://rtmatheson.com/2010/03/working-on-the-subject-observer-pattern/
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Here's the problem: I'm developing a framework (CLCuda, not the most creative name out there) where the programmer instantiates one object, and depending on what the system supports (CUDA or AMD OpenCL), will use the corresponding methods, without having to change any line of code to that.
I have a abstract class named CLCuda (pure virtual methods, but could be just virtual), and the two classes that implement its methods are CLCudaCUDA and CLCudaOPENCL.
I wanted to have something like this: instantiate one object that will iniciatlizate CUDA or OpenCL, depending on what graphics card the user have, that can access the methods of the available platform (through the class CLCudaCUDA or CLCudaOPENCL).
I already coded the methods of CLCudaOpenCL and CLCudaCUDA (hard times doing that), so my problem is with OOP.
How could I structure my classes?
If anyone can help... thanks very much!
Your problem seems to suggest a "Factory" design pattern. Presumably you have a method to determine which is supported on the current host, so you should leverage that in the implementation of your factory.