Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am learning about Abstraction, and as I have understood so far, Abstraction is basically providing an interface of how to use an object while hiding the implementation details. But does the concept of Abstraction only applies to OOP, I mean if we think of a standalone function (without being a part of a class), using a function is indeed only using its interface without actually caring of how the function is implemented.
Of course a function provides abstraction.
Why would a bunch of functions and a this pointer provide abstractions while a single function without a this pointer would not?
If, for example you have a function sort() which sorts some data, it abstracts from the concrete sorting algorithm. If you have a function which is the entry point to a huge piece of code consisting of thousands of sub-functions called in the context of that function, it can even be very abstract. Example: GetRouteFromCurrentLocationTo(...). A router, a position sensor, some geographical database... all that abstracted to a single function name.
Why would it be more of an abstraction if you wrote instead: NavigationSystem navSys; navSys.GetRouteFromCurrentLocationTo(...); ?
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
In unversity, my tutor told me always use private variables in class and have a setter and getter function, because it provides better encapsulation. But what is encapsulation? Is there any resons to do so if I know my code is only going to be developed by myself? It's just simpler to use my_obj.var instead of my_obj.set_var(var)!
Encapsulation in the classroom means making an over-engineered 2D point struct. Completely contrived and useless. It does a disservice to the entire concept by teaching it with poor examples.
Encapsulation in the real world is e.g. std::vector which works how you expect and is safe due to not allowing you to tamper with its internals.
In short: no, it's not necessary. It really depends on what you're doing.
In particular, you want encapsulation if your object is handling dynamically-allocated resources directly. So all properly-implemented container types should use encapsulation to prevent you from accidentally breaking it.
But if your type is just a pair of ints or some other raw data, there's really no need.
Specifically, getters and setters should be used if the details of the implementation could potentially change at some later point in the future. E.g. a struct representing a timespan could be represented as seconds:minutes:hours, but could also just be (a lot of) milliseconds. The getters and setters would allow you to turn that into seconds/minutes/etc. without it actually having to be stored that way internally. The operating word here is internal representation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm developing a MCU (MicroController Unit) development system (which means limited space and low speed, and no operating system in my project). It is composed of 2 kinds of MCUs which play different roles in the system, and their programs are different.
They use the same underlying (static) library written in C. The library needs a callback function when it receives data from bus. The callback functions should be in the clients (C for one the C++ for another), and are also different for two programs.
What should the structure be like? Here are two solutions.
Declare a function in the underlying library and define it in the client. The library just calls this function.
Define a function which take an function pointer as a parameter and then assign to a static variable. The library calls the function by the function pointer.
Currently I'm using the second solution just because it seems to be more elegant. However, the first has higher performance, and is safer (linker will give an error if the definition doesn't exist), while the first involves an indirection and is not that safe (if I forget to register the function).
Which one should I choose? Or are there any better solutions?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have never tried Swift but my research suggests that callling pure C code is simpler than calling C++ code.
Does this mean that there are associated performance impediments and, if so, how significant are they?
Swift has no C++ interop at present. That means you either have to create a C or Objective-C++ wrapper around your C++ classes in order to bridge them to Swift.
In practice this is very unlikely to have a performance impact - it'll add another method call using VTABLE dispatch that in turn calls the C++ method. It does, however, create a lot more manual work that needs to be done in order to use your C++ code-base in Swift.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Let's suppose I'm writing a compiler for some programming language. It is common to use abstract syntax tree (AST) as an internal representation. I can see two possible ways to design it:
using boost::variant
using inheritance
As hierarchy of nodes is fixed - boost::variant will suffice.
My question is what are the advantages and disadvantages of each approach from points of maintability and runtime efficiency?
Using boost::variants will work, but will require you to use visitor pattern extensively to exploit the content of a variant object. If later you extend the number of types used in your variant, you'll have to maintain all the visitors that you've implemented.
With inheritance, you have the advantage of being able to use polymorphism. Later extension will be straightforward : simply derive one of the existing base and override the polymorphic functions, without touching the rest of the code.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
sorry to bother but I'm a newbie programmer and has just been starting on c++ course. The reason I asked this question is because I've been hearing on OOP and its relation to class.
So my question is:
Does class actually simplify the programming code just because it groups up all related functions into one single "object" thats called "class" ?
One more thing is that...
Why do we create class inheritance when we could use one class and derive all functions from that one class alone?
Sorry to bother.
Newbie programmer.
"Does class actually simplify the programming code just because it groups up all related functions into one single "object" thats called "class" ?"
The main idea is to encapsulate state (== data) with operations that can be applied to it into a single class type.
Yes, that simplifies programming code, because there are certain interfaces/operations that can be used with this type.
"Why do we create class inheritance when we could use one class and derive all functions from that one class alone?"
Derived classes may introduce different behavior as inherited from their base class. There are many uses when you want to change that behavior, without inventing new function names all the time (or just add numbers to them).