In a previous program that I have written in C I needed a single object with several "core" data in it that can be accessed by all the functions in my program, I end up picking a struct and i have used a pointer to this struct for reading or writing data; it was fast and good for the job, also it was cheap because accessing a pointer is probably one of the cheapest thing that you can do in C and I have never found something better so I'm happy with this solution.
Now in C++ I have the same problem, I need to share a state composed of some primitive types, I'm tempted to use one of the so called POD, which basically mean, struct, again, but this time with references for safety.
Supposing that I need this "Blob" of data to be carried around my program, a struct accessed by reference is the fastest thing in C++? How much a getter methods can cost?
If your getter code is inline (in the header file), then the compiler can eliminate the need to call a function in the machine code it outputs.
eg:
class Data
{
private:
int number_;
public:
int GetNumber() { return number_; }
};
The compiler will see GetNumber's definition, will know what it does is simple and and where you've called GetNumber(), it will simply replace it with number_. So, using a getter versus accessing the member directly will result in the equivalent code, and both will perform the same.
Related
I have often encountered classes with the following structure:
class FooAlgorithm {
public:
FooAlgorithm(A a, B b);
void run();
private:
A _a;
B _b;
};
So classes with only one public member function that are also only run once.
Is there any advantage in any case over a single free function foo(A a, B b)?
The latter option is easier to call, potentially has less header dependencies and also has much less boilerplate in the header.
An object has state that can be set up at object construction time. Then the single member function can be called at a later time, without knowing anything about how the object was set up, and the function can refer to the state that was set up earlier. A standalone function cannot do that. Any state must be passed to it as arguments, or be global/static (global/static data is best avoided for a variety of reasons).
An hands-on example is worth a thousand abstract explanations, so here is an exercise. Consider a simple object:
struct Obj {
std::array<std::string, 42> attributes;
};
How would you sort a vector of such objects, comparing only the attribute number K (K being a run-time parameter in the range 0..41)? Use std::sort and do not use any global or static data. Note how std::sort compares two objects: it calls a user-provided comparator, and passes it two objects to be compared, but it knows nothing about the parameter K and cannot pass it along to the comparator.
For bigger projects it may be easier to structure your programm using OOP.
For a simple program like yours it is easier to use a single function.
Classes introduce a new dynamic to your program -> Better readability, security, moudularity, re-usability....
functions are used to organize code into blocks.
I was trying to write down some implementations for a couple of data structures that I'm interested in for a multithreaded / concurrent scenario.
A lot of functional languages, pretty much all that I know of, design their own data structures in such a way that they are immutable, so this means that if you are going to add value to an instance t1 of T, you really get a new instance of T that packs t1 + value.
container t;
container s = t; //t and s refer to the same container.
t.add(value); //this makes a copy of t, and t is the copy
I can't find the appropriate keywords to do this in C++11; there are keywords, semantics and functions from the standard library that are clearly oriented to the functional approach, in particular I found that:
mutable it's not for runtime, it's more likely to be an hint for the compiler, but this keyword doesn't really help you in designing a new data structure or use a data structure in an immutable way
swap doesn't works on temporaries, and this is a big downside in my case
I also don't know how much the other keywords / functions can help with such design, swap was one of them really close to something good, so I could at least start to write something, but apparently it's limited to lvalues .
So I'm asking: it's possible to design immutable data structure in C++11 with a functional approach ?
You simply declare a class with private member variables and you don't provide any methods to change the value of these private members. That's it. You initialize the members only from the constructors of the class. Noone will be able to change the data of the class this way. The tool of C++ to create immutable objects is the private visibility of the members.
mutable: This is one of the biggest hacks in C++. I've seen at most 2 places in my whole life where its usage was reasonable and this keyword is pretty much the opposite of what you are searching for. If you would search for a keyword in C++ that helps you at compile time to mark data members then you are searching for the const keyword. If you mark a class member as const then you can initialize it only from the INITIALIZER LIST of constructors and you can no longer modify them throughout the lifetime of the instance. And this is not C++11, it is pure C++. There are no magic language features to provide immutability, you can do that only by programming smartly.
In c++ "immutability" is granted by the const keyword. Sure - you still can change a const variable, but you have to do it on purpose (like here). In normal cases, the compiler won't let you do that. Since your biggest concern seems to be doing it in a functional style, and you want a structure, you can define it yourself like this:
class Immutable{
Immutable& operator=(const Immutable& b){} // This is private, so it can't be called from outside
const int myHiddenValue;
public:
operator const int(){return myHiddenValue;}
Immutable(int valueGivenUponCreation): myHiddenValue(valueGivenUponCreation){}
};
If you define a class like that, even if you try to change myHiddenValue with const_cast, it won't actually do anything, since the value will be copied during the call to operator const int.
Note: there's no real reason to do this, but hey - it's your wish.
Also note: since pointers exist in C++, you still can change the value with some kind of pointer magic (get the address of the object, calc the offset, etc), but you can't really help that. You wouldn't be able to prevent that even when using an functional language, if it had pointers.
And on a side note - why are you trying to force yourself in using C++ in a functional manner? I can understand it's simpler for you, and you're used to it, but functional programming isn't often used because of its downfalls. Note that whenever you create a new object, you have to allocate space. It's slower for the end-user.
Bartoz Milewski has implemented Okasaki's functional data structures in C++. He gives a very thorough treatise on why functional data structures are important for concurrency. In that treatise, he explains the need in concurrency to construct an object and then afterwards make it immutable:
Here’s what needs to happen: A thread has to somehow construct the
data that it destined to be immutable. Depending on the structure of
that data, this could be a very simple or a very complex process. Then
the state of that data has to be frozen — no more changes are
allowed.
As others have said, when you want to expose data in C++ and have it not be available for changing, you make your function signature look like this:
class MutableButExposesImmutably
{
private:
std::string member;
public:
void complicatedProcess() { member = "something else"; } // mutates
const std::string & immutableAccessToMember() const {
return member;
}
};
This is an example of a data structure that is mutable, but you can't mutate it directly.
I think what you are looking for is something like java's final keyword: This keyword allows you to construct an object, but thereafter the object remains immutable.
You can do this in C++. The following code sample compiles. Note that in the class Immutable, the object member is literally immutable, (unlike what it was in the previous example): You can construct it, but once constructed, it is immutable.
#include <iostream>
#include <string>
using namespace std;
class Immutable
{
private:
const std::string member;
public:
Immutable(std::string a) : member(a) {}
const std::string & immutable_member_view() const { return member; }
};
int main() {
Immutable foo("bar");
// your code goes here
return 0;
}
Re. your code example with s and t. You can do this in C++, but "immutability" has nothing to do with that question, if I understand your requirements correctly!
I have used containers in vendor libraries that do operate the way you describe; i.e. when they are copied they share their internal data, and they don't make a copy of the internal data until it's time to change one of them.
Note that in your code example, there is a requirement that if s changes then t must not change. So s has to contain some sort of flag or reference count to indicate that t is currently sharing its data, so when s has its data changed, it needs to split off a copy instead of just updating its data.
So, as a very broad outline of what your container will look like: it will consist of a handle (e.g. a pointer) to some data, plus a reference count; and your functions that update the data all need to check the refcount to decide whether to reallocate the data or not; and your copy-constructor and copy-assignment operator need to increment the refcount.
I am a bit new to C++ having come from a very moderate C background so please excuse me if this question seems very elementary.
I have currently been given some C++ source code to read and modify.
However the code seems to me to be very ugly for a newbie but I am not sure whether the code is considered good C++ practice.
Basically there is only one class called STORAGE and all the information is public.
class STORAGE
{
public:
STORAGE();
virtual ~STORAGE();
//DATA
int np,nn;
int istep;
int print_step;
//...and many more variables.
//METHODS
void eos(double rho, double e, double &p, double &cs);
void ThermalEnergy(double rho,double &e,double p);
void allocation();
void initialization();
void var_dt();
// and many more methods which return void,
};
Now when I am reading the algorithm which calls these methods, I see each of them modifying many member variables of STORAGE, with many methods modifying the same set of variables, in a long list of method calls. Many of the methods are quite irritatingly of the type void A ()
With such a style , it seems to be very hard to keep track mentally of the changes to the large number member-variables.
My question: Is this style of programming common to C++ when using classes? Giving a method access to all members of the class seems a bit dangerous, and it seems that a lot of buggy code could arise.
Psychologically for me it looks much more simpler to write code, if I know that the only variables being modified in a function call are the input variables to a function.
"..all the information is public"
Yes, it it bad practice and contradicts the basic notion of encapsulation. Everybody outside the class, would be able see and modify all the members. Ideal is: to make the data members private, and provide public get/set methods (depending on need).
"Is this style of programming common to C++ when using classes?" -- Common but not good.
"Giving a method access to all members of the class seems a bit dangerous"
I think this is common, member functions should have access to member variables. Otherwise, who else will :) ? However, if you still want to prevent them to modify member variables, you can use the declare the function as const. (This approach is already described by Connor above).
I have about 15~20 member variables which needs to be accessed, I was wondering
if it would be good just to let them be public instead of giving every one of them
get/set functions.
The code would be something like
class A { // a singleton class
public:
static A* get();
B x, y, z;
// ... a lot of other object that should only have one copy
// and doesn't change often
private:
A();
virtual ~A();
static A* a;
};
I have also thought about putting the variables into an array, but I don't
know the best way to do a lookup table, would it be better to put them in an array?
EDIT:
Is there a better way than Singleton class to put them in a collection
The C++ world isn't quite as hung up on "everything must be hidden behind accessors/mutators/whatever-they-decide-to-call-them-todays" as some OO-supporting languages.
With that said, it's a bit hard to say what the best approach is, given your limited description.
If your class is simply a 'bag of data' for some other process, than using a struct instead of a class (the only difference is that all members default to public) can be appropriate.
If the class actually does something, however, you might find it more appropriate to group your get/set routines together by function/aspect or interface.
As I mentioned, it's a bit hard to tell without more information.
EDIT: Singleton classes are not smelly code in and of themselves, but you do need to be a bit careful with them. If a singleton is taking care of preference data or something similar, it only makes sense to make individual accessors for each data element.
If, on the other hand, you're storing generic input data in a singleton, it might be time to rethink the design.
You could place them in a POD structure and provide access to an object of that type :
struct VariablesHolder
{
int a;
float b;
char c[20];
};
class A
{
public:
A() : vh()
{
}
VariablesHolder& Access()
{
return vh;
}
const VariablesHolder& Get() const
{
return vh;
}
private:
VariablesHolder vh;
};
No that wouldn't be good. Image you want to change the way they are accessed in the future. For example remove one member variable and let the get/set functions compute its value.
It really depends on why you want to give access to them, how likely they are to change, how much code uses them, how problematic having to rewrite or recompile that code is, how fast access needs to be, whether you need/want virtual access, what's more convenient and intuitive in the using code etc.. Wanting to give access to so many things may be a sign of poor design, or it may be 100% appropriate. Using get/set functions has much more potential benefit for volatile (unstable / possibly subject to frequent tweaks) low-level code that could be used by a large number of client apps.
Given your edit, an array makes sense if your client is likely to want to access the values in a loop, or a numeric index is inherently meaningful. For example, if they're chronologically ordered data samples, an index sounds good. Summarily, arrays make it easier to provide algorithms to work with any or all of the indices - you have to consider whether that's useful to your clients; if not, try to avoid it as it may make it easier to mistakenly access the wrong values, particularly if say two people branch some code, add an extra value at the end, then try to merge their changes. Sometimes it makes sense to provide arrays and named access, or an enum with meaningful names for indices.
This is a horrible design choice, as it allows any component to modify any of these variables. Furthermore, since access to these variables is done directly, you have no way to impose any invariant on the values, and if suddenly you decide to multithread your program, you won't have a single set of functions that need to be mutex-protected, but rather you will have to go off and find every single use of every single data member and individually lock those usages. In general, one should:
Not use singletons or global variables; they introduce subtle, implicit dependencies between components that allow seemingly independent components to interfere with each other.
Make variables const wherever possible and provide setters only where absolutely required.
Never make variables public (unless you are creating a POD struct, and even then, it is best to create POD structs only as an internal implementation detail and not expose them in the API).
Also, you mentioned that you need to use an array. You can use vector<B> or vector<B*> to create a dynamically-sized array of objects of type B or type B*. Rather than using A::getA() to access your singleton instance; it would be better to have functions that need type A to take a parameter of type const A&. This will make the dependency explicit, and it will also limit which functions can modify the members of that class (pass A* or A& to functions that need to mutate it).
As a convention, if you want a data structure to hold several public fields (plain old data), I would suggest using a struct (and use in tandem with other classes -- builder, flyweight, memento, and other design patterns).
Classes generally mean that you're defining an encapsulated data type, so the OOP rule is to hide data members.
In terms of efficiency, modern compilers optimize away calls to accessors/mutators, so the impact on performance would be non-existent.
In terms of extensibility, methods are definitely a win because derived classes would be able to override these (if virtual). Another benefit is that logic to check/observe/notify data can be added if data is accessed via member functions.
Public members in a base class is generally a difficult to keep track of.
Let say I have a basic 2D vector class something like
class vector2
{
int x, y;
}
these two values could be used to represent a position as well as a width and height. does C++ provide a away for me to impliment a function such as vector2::getXpos() and then also define vector2::getWidth() and have it use the same implementation.
I know that I could just make both of these function inline, but the compiler might decide to not inline these functions. so if getWidth just called getXpos you would end up with two function calls.
A more relistic example of what I would want to use this for is getLength() and erm... getSpan() (thinking of like a screen here for when you say 40" tv)
I would assume that this would be a simple case of something like a special function definition... I did find this page but this sounds like it is a C feature... and a bit of a hack to get working.
EDIT
I am not asking about the mechanics of inline functions... I basicaly want to do something functionally like
class MyClass
{
void ActaullyDoStuff();
public:
void foo(){ActaullyDoStuff();}
void bar(){ActuallyDoStuff();}
}
but where I can just write something like
class MyBetterClass
{
public:
void foo(){ /* BLOCK OF CODE */ }
void bar(){ /* DO WHAT EVER foo() DOES */ }
}
I want bar() to be another way of just doing foo() so that the same functional code can have different, more appropriate names depending on the situation.
but the compiler might decide to not
inline these functions
Then the compiler probably has a good reason to do so.
I think this is a non problem, just have the function with the alternative name call the "real" function, and the compiler will most likely inline it.
EDIT:
If that didn't convince you, it is possible to use __forceinline in visual studio.
Here is the way to force inline in GCC.
EDIT2:
class MyBetterClass
{
public:
void foo(){ /* BLOCK OF CODE */ }
__forceinline void bar(){ foo(); /* DO WHAT EVER foo() DOES */ }
}
Using C++11 you could do:
//works for non-template non-overloaded functions:
const auto& new_fn_name = old_fn_name;
Other solutions:
How do I assign an alias to a function name in C++?
It appears you're not thinking about this in an object oriented way. I have to second mjfgates advice that you really don't want to do this.
What you want to do is abstract the idea of a vector into a class and implement the common methods you might want to use with a vector. In fact, you may want to consider implementing your class example above as a "Point" class and then have a "Vector" class aggregate two point classes.
Using your example, your class would not be well defined if it was used for two different purposes. Let's say you want to make a method on some class to draw vector2. You would have to know which instances of vector2 are representing a starting point and which ones are representing a width/height. You'd probably also need a third representation to represent direction. The easier way is to implement the vector in terms of getStartPoint, getEndPoint, and any other methods that will do calculations appropriate for the vector. Then the consumer doesn't need to know about the internal working of the vector2 class, they just call the methods to get the information they need.
Your referenced link is AFAIK not a C feature either, but something specific to that particular compiler.
C++ provides such a mechanism: it happens to be inlined functions! Worrying about the compiler not optimizing away the redundant call in an inlineable function is definitely premature optimization. Inline, then measure if you're worried about performance.
If you're absolutely insisting on eliminating the merest chance of a redundant call, you might do something with preprocessor #defines... but beware: macros do not respect class boundaries, and your header files will sooner or later stomp on some other, unrelated code. Better not go there.
you could use preprocessor #defines.... if you're into the world's worst bugs. You'll get the equivalent of guaranteed inline if you want, or just aliases if you want that too.
So, you want to have two functions, on the same object, that return exactly the same data, as the same data type.
Don't DO that.
Providing more than one path to the same data is one of those things that sounds like it might be convenient for whoever's going to be using your object-- until you think about it. What happens is that six months down the road, somebody turns up a bug in one of the two functions, and you fix that function but not the other one, so the bug's still there. Or the programmer who's writing clients for your object is driven half-insane wondering what the difference is between getLength() and getSpan().
The one time I'd do this would be when implementing an interface that requires a duplicate of an existing member function. In that case, the interface's function is going to be virtual, so the notion of inlining goes out the window.