17
It's not quite zero-overhead, but you can use the GLFWwindow User Pointer Property to make a relatively clean solution, I think (caveat: my C++ is a little rusty, and I am not familiar with the GLFW library).
In your Window constructor,
Window(...) {
// ...
glfwSetWindowUserPointer(mHandle, static_cast<void *>(this));
...
15
You misunderstood the “zero overhead” principles. It means that features of the C++ language should have zero overhead if you don’t use the feature. For example, exceptions have overhead if you use them, and that’s fine, but the fact alone that the language supports exceptions causes no runtime overhead if you don’t use them.
7
Two things occur to me that look ugly to my eye.
IMHO the things you mentioned look quite less ugly to me than they were before.
in the constructor to my Matrix class -- at the point when I know what the fixed size of the matrix will be -- I won't be calling the vector's constructor, but rather the function elem.resize()
It depends on the point where you ...
4
Sure, virtual calls have some runtime overhead. But when you use virtual functions, it's usually not a choice but a consequence of the problem you are solving. If you need to call a function on a type-erased value there isn't a real alternative, unless we count some C-style void* approaches.
This runtime overhead is typically just a memory load to retrieve ...
3
It seems like using the same variable 'i' to iterate through the two for-loops would overlap and cause errors.
Indeed, it would. Well, not "errors", so much as unexpected behavior. The code you have is syntactically fine; no C or C++ compiler that I know of would raise any warnings, much less errors. However, if you run it, you'll see that it ...
3
You can install BERT as an add-in in Excel. Then in Excel you can enter the R console for basic coding and debugging. And for the clients, you wrap your R function into a new file saved to the startup folder, so BERT can load all the functions from there, and clients can choose whatever they want in Excel directly.
customized_function <- function(data){
...
3
You suggest to stop using virtual functions at some point, but don't suggest an alternative, so that makes the question of "at what point to stop" hard to answer.
Virtual functions are not simply optional or "nice/fun to use but easily avoidable" — they solve a certain set of design problems, and so should be compared with alternatives ...
2
"you shouldn't test Implementation Details (such as functions in an anonymous namespace or private functions)" - this philosophy is controversial, or at least debated, or, at a minimum, I disagree with it. It is totally possible and usable and frequently desirable to test implementation "details". In fact, once you've tested them, ...
1
You should stop using virtual calls if:
This leads to a measurable speed improvement.
For in-house software: Cost savings due to the speed improvement demonstrably outweigh the development cost.
For software that you are selling: Speed improvements lead to increased sales so the profits demonstrably outweigh the development cost.
There are no other ...
1
@Bart Van Ingen Schenau is basically correct.
In most jurisdictions, you have two choices for protecting your algorithm. What he's described is essentially trade secret protection. To get actual trade secret protection (rather than just a normal contract) you normally have to identify fairly specifically that you're revealing trade secrets to them, and ...
1
The concern is a client can share that library with anyone and get it running without our involvement, how to prevent that?
You cannot prevent this by technical means.
The typical way this is prevented in the real world is through legal means: You have the legal department draw up a good, enforceable contract and then you drag those customers that break it ...
answered Dec 26 '20 at 18:48
Bart van Ingen Schenau
61.5k11 gold badges94 silver badges152 bronze badges
1
This is part of why most of the standard library deals in iterators rather than dealing directly with containers themselves. Iterators were designed from the beginning to support iteration over the data in the container, without your having to worry about the container itself.
So in your case, you're passing an std::vector<T>, where T is a std::array&...
1
Expressiveness is in the eye of the beholder.
(Many famous programmers have used the word "expressiveness" to mean different things, sometimes in contradictory ways.)
To appreciate Bjarne Stroustrup's approach for C++, one has to be armed with intimate knowledge with the lower level working of C++, such as memory allocations, the standard library, ...
1
How far down the rabbit hole do you want to go?
The C++ virtual function table based dynamic dispatch is just one OO model. You can implement others, and your code is still C++.
Suppose you want to have a polymorphic method without vtable overhead.
template<class T> using ptr_to = T*;
template<auto F, class T>
struct Operation {
constexpr ...
1
Proposed solution
I propose a bunch of static "dispatcher" functions, which would lookup the right Window instance and then forward the received GLFWwindow* to that instance, so it could do the real work:
class Window {
// // // Part 1: object-oriented UI stuff // // //
float _coolnessFactor; /* your data members */
Window (/*params?*/) ...
Only top voted, non community-wiki answers of a minimum length are eligible
