I'm writing a physics simulation (Ising model) in C++ that operates on square lattices. The heart of my program is my Ising class with a constructor that calls for the row and column dimensions of the lattice. I have two other methods to set other parameters of the system (temperature & initial state) that must get called before evolving the system! So, for instance, a sample program might look like this
int main() {
Ising system(30, 30);
system.set_state(up);
system.set_temperature(2);
for(int t = 0; t < 1000; t++) {
system.step();
}
return 0;
}
If the system.set_*() methods aren't called prior to system.step(), system.step() throws an exception alerting the user to the problem. I implemented it this way to simplify my constructor; is this bad practice?
It is recommended to put all mandatory parameters in the constructor whenever possible (there are exceptions of course, but these should be rare - I have seen one real-world example so far). This way you make your class both easier and safer to use.
Note also that by simplifying your constructor you make the client code more complicated instead, which IMO is a bad tradeoff. The constructor is written only once, but caller code may potentially need to be written many times more (increasing both the sheer amount of code to be written and the chance of errors).
Not at all, IMO. I face the same thing when loading data from external files. When the objects are created (ie, their respective ctors are called), the data is still unavailable and can only be retrieved at a later stage. So I split the initialisation in different stages:
constructor
initialisation (called by the framework engine when an object is activated for the first time)
activation (called each time an object is activated).
This is very specific to the framework I'm developing, but there is no way to deal with everything using just the constructor.
However, if you know the variables at the moment the ctor is called, it's better not to complicate the code. It's a possible source of headaches for anyone using your code.
IMO this is poor form if all of these initialization steps must be invoked every time. One of the goals of well-designed software is to minimize the opportunities to screw up, and having multiple methods which must be invoked before an object is "usable" simply makes it harder to get right. If these calls were optional then having them as separate methods would be fine.
Share and enjoy.
The entire point in a class is to present some kind of abstraction. As a user of a class, I should be able to assume that it behaves like the abstraction it models.
And part of that is that the class must always be valid. Once the object has been created (by calling the constructor), the class must be in a meaningful, valid state. It should be ready to use. If it isn't, then it is no longer a good abstraction.
If the initialization methods must be called in a specific order then I would wrap the call to them in their own method as this indicates that the methods are not atomic on their own so the 'knowledge' of how they should be called should be held in one place.
Well that's my opinion, anyway!
I'd say that setting the initial conditions should be separate from the constructor if you plan to initialize and run more than one transient on the same lattice.
If you run a transient and stop, then it's possible to move setting the initial conditions inside the constructor, but it means that you have to pass in the parameter values in order to do this.
I fully agree with the idea that an object should be 100% ready to be used after its constructor is called, but I think that's separate from the physics of setting the initial temperature field. The object could be fully usable, yet have every node in the problem at the same temperature of absolute zero. A uniform temperature field in an insulated body isn't of much interest from a heat transfer point of view.
As another commentator pointed out, having to call a bunch of initialisation functions is poor form. I would wrap this up in a class:
class SimulationInfo
{
private:
int x;
int y;
int state;
int temperature;
public:
SimulationArgs() : x(30), y (30), state(up), temperature(2) { }; // default ctor
// custom constructors here!
// properties
int x() const { return x; };
int y() const { return y; };
int state() const { return state; };
int temperature() const { return temperature; };
}; // eo class SimulationInfo
class Simulation
{
private:
Ising m_system;
public:
Simulation(const SimulationInfo& _info) : m_system(_info.x(), _info.y())
{
m_system.set_state(_info.state());
m_system.set_temperature(_info.temperature());
} // eo ctor
void simulate(int _steps)
{
for(int step(0); step < _steps; ++steps)
m_system.step();
} // eo simulate
}; // eo class Simulation
There are otherways, but this makes things infinitely more usable from a default setup:
SimulationInfo si; // accept all defaults
Simulation sim(si);
sim.simulate(1000);
Related
During programming an embedded system without MMU, I should not use heap (because of memory fragmentation problem).
Part of the software is written in C (drivers) and the logic is written in C++ subset without dynamic allocation of memory.
Because of unit testing the default constructor is deleted. Instead - there is single parameter constructor with reference to structure of driver function pointers.
driver.h: (the pure C module)
#pragma once
bool Init();
uint32_t ReadMeasurement();
module.hpp: (the C++ part)
class Module {
public:
struct DriverApi {
void (*Init)();
uint32_t (*ReadData)();
};
Module() = delete;
explicit Module(DriverApi &aDriverApi);
private:
DriverApi& mDriverApi;
};
The module manager:
module_manager.hpp:
class ModuleManager {
// (...)
private:
Module::DriverApi module_1; // I can't declare this in this way
Module::DriverApi module_2; // because of lack of default constructor.
Module::DriverApi module_3;
etc.
};
How to initialize module_1, module_2 and module_3 without using heap? And n parameters constructor?
Options I'm aware:
It look's easy to use std::shared_ptr, but then std::make_shared use heap.
I can leave default constructor and then call sth. like Init(Module::DriverApi *aDriverApi) but this "violates" RAII.
Is there any other way to create "elegant" and embedded safe initialization?
Either use a default constructor or write one with named parameters. If you need to initialize members to non-zero values but don't have access to such values because the constructor has too few parameters, the constructor is incorrectly designed.
Because of unit testing the default constructor is deleted
Tests are supposed to make the product better - get rid of them if they do the opposite.
Normally any embedded system has a fixed set of drivers. So normally it would make little sense to have those as non-static members. Making a driver class per hardware peripheral present makes sense. Then a static instance for each instance of that hardware present on the target. You don't need to cover hardware which is never going to be present, nor will the hardware change dynamically in run-time. In fact a large part of it ought to be const and be stored in flash.
RAII has limited use on single core, single process embedded systems since your program needs to be deterministic and it owns all resources on the MCU. You usually never need to free up anything, all you need is to allocate as much memory as the product needs.
Keep it simple. Don't invent abstraction layers that fill no purpose.
I just put your code in IDE, and it compiles.
What I can identify in your program:
if you try to assign bool Init(); to the void (*Init)(), please change the return type.
When a user-defined constructor is defined, the default constructor is already deleted implicitly. What is missing is that you have to initialize the member.
Try explicit Module(DriverApi &aDriverApi):mDriverApi{aDriverApi}{}
class Module {
public:
struct DriverApi {
void (*Init)();
uint32_t (*ReadData)();
};
Module() = delete;
explicit Module(DriverApi &aDriverApi):mDriverApi{aDriverApi}{}
private:
DriverApi& mDriverApi;
};
void fun(){
std::cout<<"This is fun\n";
}
int main(){
Module::DriverApi module_1; // I can't declare this in this way because of lack of default constructor.
module_1.Init = fun;
module_1.Init();
Module m{module_1};
return 0;
}
I’ve been told to convert a procedural C++ program into an object-oriented one, using the principles of polymorphism, encapsulation and inheritance.
The standard C++ program accepts data values and filter values from the user. It then multiplies these values together using a simple algorithm and prints the output to the screen. The standard program is shown below.
I have made a start by deciding to use a class for 'TheFilter' and a class for 'TheData' each with their own 'enterdata()', 'displaydata()' and constructor member functions.
The problem I am having is with part of the criteria set, "main() should do no more than create the first object". I am having difficulty getting my head around this as all examples of OOP code I have ever seen generate objects within main().
The only current solution I could come up with to obey this is to create a 3rd class (FilteredData - see below) which would instantiate the other classes objects 'OriginalData', 'Filter' and 'FilteredData' upon being instantiated itself. However this is troubling me as would it not take away from the concept of encapsulation as it would result in having a class with members which are other classes objects?
If anyone has any suggestions at all into how this could be avoided and best obey the principles of encapsulation I would be very grateful!
I hate to admit defeat, but I’ve never programmed using an object-oriented approach and I’ve only been studying C++ for a couple of months. Please help!
#include <iostream>
using namespace std;
class TheData
{
public:
TheData(double* = 0, unsigned long = 0, bool = false); //constructor function
~TheData();
void EnterData(TheData& OriginalData);
void DisplayData(TheData OriginalData, TheData FilteredData) const;
private:
double* Values;
unsigned long Length;
bool Valid;
}
class TheFilter
{
public:
TheFilter(double* = 0, unsigned long = 0, bool = false); //constructor function
~TheFilter();
void EnterData(TheData& OriginalData);
void DisplayData(TheData OriginalData, TheData FilteredData) const;
int ApplyFilter();
private:
double* Values;
unsigned long Length;
bool Valid;
}
class
{
public:
FilteredData(); // constructor function that somehow instantiates an object for the filter and the data???
void DisplayData();
private:
TheData data
TheFilter filter
double * filteredData
}
int main()
{
FilteredData Object1;
}
The problem I am having is with part of the criteria set, "main() should do no more than create the first object", I am having difficulty getting my head around this as all examples of OOP code I have ever seen generate objects within main(). The only current solution I could come up with to obey this is to create a 3rd class (FilteredData - see below) which would instantiate the other classes objects 'OriginalData', 'Filter' and 'FilteredData' upon being instantiated itself. However this is troubling me as would it not take away from the concept of encapsulation as it would result in having a class with members which are other classes objects?
The criterion you cite is potentially problematic, but not necessarily for the reason you think. As a general rule, a constructor should not do work beyond initializing the object on which it is invoked. If main() cannot invoke at least one method on the object after initializing it then that requires the constructor to exhibit additional behavior (i.e. triggering the main work of the program), which is poor form. Even if all that is needed is for the object to be registered in some way with a GUI framework, that's still work that the constructor should not be responsible for performing.
On the other hand, there is nothing at all inherently wrong with class members that are objects, pointers or references to objects, or containers for objects. That's in fact extremely common, and good form often requires it. It does not inherently compromise encapsulation. In fact, it can do the opposite by affording even more encapsulation than otherwise there would be.
Overall, you have reached the correct conclusion that you require a class representing the overall program, with main() doing nothing but instantiating that class and setting it to work. That's a fairly common pattern. If the details you've come up with don't sit well with you, however, then there may be good reason for that. I'm inclined to agree that a class representing a composition of data and filter -- though entirely plausible in itself -- doesn't seem the correct representation for the overall program, or its main window, or whatever it is that you actually need.
How does the compiler treat a complete empty function to behave at runtime?
class Base
{
public:
virtual void execute(){ /* always empty */ }
};
example usage:
int main()
{
Base b;
b.execute();
return 0;
}
Am creating an entity system which should be able to have sub-classes which are only holding data. Those are called Properties. Some need to have a manipulation function to conclude the data. These classes are called Component.
The purpose is to be able to add functionality to a class at run-time and even later with additional shared libraries.
Due to the flexibility needed, and the wish to keep it as simple as possible, I came up with a shared Base class for the Properties and Component classes. See the code-block below.
However, the class Base contains the function execute() and is invoked in the final class Container for all the properties and components assigned to that class.
Maybe it is better to split the Property and Component entirely into two different identities, however they will rely on each other heavily, e.g. A property could be a transform (position, scale, quaternion, matrix) while a component can be an animation of that quaternion in the transform.
#include <vector>
class Base
{
public:
virtual void execute(){ /* always empty */ }
};
class Property // as manny will be
: public Base
{
public:
/* specifics */
};
class Component // as manny will be
: public Base
{
public:
/* specifics */
virtual void execute(){ /* do whatever */ }
};
class Container
{
public:
std::vector<Base*> list;
virtual void execute()
{
std::vector<Base>::iterator iterator = list.begin(), end = list.end();
while( iterator != end )
( *iterator )->execute();
}
}
Not knowing what the compiler actually does besides generating binaries, I don't think it would be an equivalent of a debug session going line by line.
How does the compiler treat such an empty function, would it be better to move the function execute(); to class Component as first declaration. Then add enum{ Property, Component }; to class Property so a if-statement can determine to call the execution function.
Virtual functions are very cheap to call, but depending on the number of different sub-classes a switch could be faster (the reason is that a switch will not create another execution context) but of course a lot less flexible. This is especially true if to implement the body of execute method most of them will share part of the processing and data access (like for example for different instructions of a virtual machine) because part of that could be cached out of the loop.
Keeping properties in the same container and leaving them with an empty execute method doesn't seem reasonable to me, but this could be just lack of context of the problem being solved.
The general rule is however to stop assuming and start measuring, with real data and real usage pattern. Performance forecasting is today very complex (almost impossibly complex) because CPUs are little monsters of complexity on their own and there are many of them. You need to test to find where the time is spent... guessing doesn't work that well.
My first approach would be using virtual functions and keeping things as simple as possible. Inlining those functions in a loop would only come later if I measure that the dispatch overhead is the problem and that there are no bigger wins to be searched in other areas.
Several questions about accessor methods in C++ have been asked on SO, but none was able satisfy my curiosity on the issue.
I try to avoid accessors whenever possible, because, like Stroustrup and other famous programmers, I consider a class with many of them a sign of bad OO. In C++, I can in most cases add more responsibility to a class or use the friend keyword to avoid them. Yet in some cases, you really need access to specific class members.
There are several possibilities:
1. Don't use accessors at all
We can just make the respective member variables public. This is a no-go in Java, but seems to be OK with the C++ community. However, I'm a bit worried about cases were an explicit copy or a read-only (const) reference to an object should be returned, is that exaggerated?
2. Use Java-style get/set methods
I'm not sure if it's from Java at all, but I mean this:
int getAmount(); // Returns the amount
void setAmount(int amount); // Sets the amount
3. Use objective C-style get/set methods
This is a bit weird, but apparently increasingly common:
int amount(); // Returns the amount
void amount(int amount); // Sets the amount
In order for that to work, you will have to find a different name for your member variable. Some people append an underscore, others prepend "m_". I don't like either.
Which style do you use and why?
From my perspective as sitting with 4 million lines of C++ code (and that's just one project) from a maintenance perspective I would say:
It's ok to not use getters/setters if members are immutable (i.e. const) or simple with no dependencies (like a point class with members X and Y).
If member is private only it's also ok to skip getters/setters. I also count members of internal pimpl-classes as private if the .cpp unit is smallish.
If member is public or protected (protected is just as bad as public) and non-const, non-simple or has dependencies then use getters/setters.
As a maintenance guy my main reason for wanting to have getters/setters is because then I have a place to put break points / logging / something else.
I prefer the style of alternative 2. as that's more searchable (a key component in writing maintainable code).
2) is the best IMO, because it makes your intentions clearest. set_amount(10) is more meaningful than amount(10), and as a nice side effect allows a member named amount.
Public variables is usually a bad idea, because there's no encapsulation. Suppose you need to update a cache or refresh a window when a variable is updated? Too bad if your variables are public. If you have a set method, you can add it there.
I never use this style. Because it can limit the future of your class design and explicit geters or setters are just as efficient with a good compilers.
Of course, in reality inline explicit getters or setters create just as much underlying dependency on the class implementation. THey just reduce semantic dependency. You still have to recompile everything if you change them.
This is my default style when I use accessor methods.
This style seems too 'clever' to me. I do use it on rare occasions, but only in cases where I really want the accessor to feel as much as possible like a variable.
I do think there is a case for simple bags of variables with possibly a constructor to make sure they're all initialized to something sane. When I do this, I simply make it a struct and leave it all public.
That is a good style if we just want to represent pure data.
I don't like it :) because get_/set_ is really unnecessary when we can overload them in C++.
STL uses this style, such as std::streamString::str and std::ios_base::flags, except when it should be avoided! when? When method's name conflicts with other type's name, then get_/set_ style is used, such as std::string::get_allocator because of std::allocator.
In general, I feel that it is not a good idea to have too many getters and setters being used by too many entities in the system. It is just an indication of a bad design or wrong encapsulation.
Having said that, if such a design needs to be refactored, and the source code is available, I would prefer to use the Visitor Design pattern. The reason is:
a. It gives a class an opportunity to
decide whom to allow access to its
private state
b. It gives a class an
opportunity to decide what access to
allow to each of the entities who are
interested in its private state
c. It
clearly documents such exteral access
via a clear class interface
Basic idea is:
a) Redesign if possible else,
b)
Refactor such that
All access to class state is via a well known individualistic
interface
It should be possible to configure some kind of do's and don'ts
to each such interface, e.g. all
access from external entity GOOD
should be allowed, all access from
external entity BAD should be
disallowed, and external entity OK
should be allowed to get but not set (for example)
I would not exclude accessors from use. May for some POD structures, but I consider them a good thing (some accessors might have additional logic, too).
It doesn't realy matters the naming convention, if you are consistent in your code. If you are using several third party libraries, they might use different naming conventions anyway. So it is a matter of taste.
I've seen the idealization of classes instead of integral types to refer to meaningful data.
Something like this below is generally not making good use of C++ properties:
struct particle {
float mass;
float acceleration;
float velocity;
} p;
Why? Because the result of p.mass*p.acceleration is a float and not force as expected.
The definition of classes to designate a purpose (even if it's a value, like amount mentioned earlier) makes more sense, and allow us to do something like:
struct amount
{
int value;
amount() : value( 0 ) {}
amount( int value0 ) : value( value0 ) {}
operator int()& { return value; }
operator int()const& { return value; }
amount& operator = ( int const newvalue )
{
value = newvalue;
return *this;
}
};
You can access the value in amount implicitly by the operator int. Furthermore:
struct wage
{
amount balance;
operator amount()& { return balance; }
operator amount()const& { return balance; }
wage& operator = ( amount const& newbalance )
{
balance = newbalance;
return *this;
}
};
Getter/Setter usage:
void wage_test()
{
wage worker;
(amount&)worker = 100; // if you like this, can remove = operator
worker = amount(105); // an alternative if the first one is too weird
int value = (amount)worker; // getting amount is more clear
}
This is a different approach, doesn't mean it's good or bad, but different.
An additional possibility could be :
int& amount();
I'm not sure I would recommend it, but it has the advantage that the unusual notation can refrain users to modify data.
str.length() = 5; // Ok string is a very bad example :)
Sometimes it is maybe just the good choice to make:
image(point) = 255;
Another possibility again, use functional notation to modify the object.
edit::change_amount(obj, val)
This way dangerous/editing function can be pulled away in a separate namespace with it's own documentation. This one seems to come naturally with generic programming.
Let me tell you about one additional possiblity, which seems the most conscise.
Need to read & modify
Simply declare that variable public:
class Worker {
public:
int wage = 5000;
}
worker.wage = 8000;
cout << worker.wage << endl;
Need just to read
class Worker {
int _wage = 5000;
public:
inline int wage() {
return _wage;
}
}
worker.wage = 8000; // error !!
cout << worker.wage() << endl;
The downside of this approach is that you need to change all the calling code (add parentheses, that is) when you want to change the access pattern.
variation on #3, i'm told this could be 'fluent' style
class foo {
private: int bar;
private: int narf;
public: foo & bar(int);
public: int bar();
public: foo & narf(int);
public: int narf();
};
//multi set (get is as expected)
foo f; f.bar(2).narf(3);
Suppose you have the following code:
int main(int argc, char** argv) {
Foo f;
while (true) {
f.doSomething();
}
}
Which of the following two implementations of Foo are preferred?
Solution 1:
class Foo {
private:
void doIt(Bar& data);
public:
void doSomething() {
Bar _data;
doIt(_data);
}
};
Solution 2:
class Foo {
private:
Bar _data;
void doIt(Bar& data);
public:
void doSomething() {
doIt(_data);
}
};
In plain english: if I have a class with a method that gets called very often, and this method defines a considerable amount of temporary data (either one object of a complex class, or a large number of simple objects), should I declare this data as private members of the class?
On the one hand, this would save the time spent on constructing, initializing and destructing the data on each call, improving performance. On the other hand, it tramples on the "private member = state of the object" principle, and may make the code harder to understand.
Does the answer depend on the size/complexity of class Bar? What about the number of objects declared? At what point would the benefits outweigh the drawbacks?
From a design point of view, using temporaries is cleaner if that data is not part of the object state, and should be preferred.
Never make design choices on performance grounds before actually profiling the application. You might just discover that you end up with a worse design that is actually not any better than the original design performance wise.
To all the answers that recommend to reuse objects if construction/destruction cost is high, it is important to remark that if you must reuse the object from one invocation to another, in many cases the object must be reset to a valid state between method invocations and that also has a cost. In many such cases, the cost of resetting can be comparable to construction/destruction.
If you do not reset the object state between invocations, the two solutions could yield different results, as in the first call, the argument would be initialized and the state would probably be different between method invocations.
Thread safety has a great impact on this decision also. Auto variables inside a function are created in the stack of each of the threads, and as such are inherently thread safe. Any optimization that pushes those local variable so that it can be reused between different invocations will complicate thread safety and could even end up with a performance penalty due to contention that can worsen the overall performance.
Finally, if you want to keep the object between method invocations I would still not make it a private member of the class (it is not part of the class) but rather an implementation detail (static function variable, global in an unnamed namespace in the compilation unit where doOperation is implemented, member of a PIMPL...[the first 2 sharing the data for all objects, while the latter only for all invocations in the same object]) users of your class do not care about how you solve things (as long as you do it safely, and document that the class is not thread safe).
// foo.h
class Foo {
public:
void doOperation();
private:
void doIt( Bar& data );
};
// foo.cpp
void Foo::doOperation()
{
static Bar reusable_data;
doIt( reusable_data );
}
// else foo.cpp
namespace {
Bar reusable_global_data;
}
void Foo::doOperation()
{
doIt( reusable_global_data );
}
// pimpl foo.h
class Foo {
public:
void doOperation();
private:
class impl_t;
boost::scoped_ptr<impl_t> impl;
};
// foo.cpp
class Foo::impl_t {
private:
Bar reusable;
public:
void doIt(); // uses this->reusable instead of argument
};
void Foo::doOperation() {
impl->doIt();
}
First of all it depends on the problem being solved. If you need to persist the values of temporary objects between calls you need a member variable. If you need to reinitialize them on each invokation - use local temporary variables. It a question of the task at hand, not of being right or wrong.
Temporary variables construction and destruction will take some extra time (compared to just persisting a member variable) depending on how complex the temporary variables classes are and what their constructors and destructors have to do. Deciding whether the cost is significant should only be done after profiling, don't try to optimize it "just in case".
I'd declare _data as temporary variable in most cases. The only drawback is performance, but you'll get way more benefits. You may want to try Prototype pattern if constructing and destructing are really performance killers.
If it is semantically correct to preserve a value of Bar inside Foo, then there is nothing wrong with making it a member - it is then that every Foo has-a bar.
There are multiple scenarios where it might not be correct, e.g.
if you have multiple threads performing doSomething, would they need all separate Bar instances, or could they accept a single one?
would it be bad if state from one computation carries over to the next computation.
Most of the time, issue 2 is the reason to create local variables: you want to be sure to start from a clean state.
Like a lot of coding answers it depends.
Solution 1 is a lot more thread-safe. So if doSomething were being called by many threads I'd go for Solution 1.
If you're working in a single threaded environment and the cost of creating the Bar object is high, then I'd go for Solution 2.
In a single threaded env and if the cost of creating Bar is low, then I think i'd go for Solution 1.
You have already considered "private member=state of the object" principle, so there is no point in repeating that, however, look at it in another way.
A bunch of methods, say a, b, and c take the data "d" and work on it again and again. No other methods of the class care about this data. In this case, are you sure a, b and c are in the right class?
Would it be better to create another smaller class and delegate, where d can be a member variable? Such abstractions are difficult to think of, but often lead to great code.
Just my 2 cents.
Is that an extremely simplified example? If not, what's wrong with doing it this
void doSomething(Bar data);
int main() {
while (true) {
doSomething();
}
}
way? If doSomething() is a pure algorithm that needs some data (Bar) to work with, why would you need to wrap it in a class? A class is for wrapping a state (data) and the ways (member functions) to change it.
If you just need a piece of data then use just that: a piece of data. If you just need an algorithm, then use a function. Only if you need to keep a state (data values) between invocations of several algorithms (functions) working on them, a class might be the right choice.
I admit that the borderlines between these are blurred, but IME they make a good rule of thumb.
If it's really that temporary that costs you the time, then i would say there is nothing wrong with including it into your class as a member. But note that this will possibly make your function thread-unsafe if used without proper synchronization - once again, this depends on the use of _data.
I would, however, mark such a variable as mutable. If you read a class definition with a member being mutable, you can immediately assume that it doesn't account for the value of its parent object.
class Foo {
private:
mutable Bar _data;
private:
void doIt(Bar& data);
public:
void doSomething() {
doIt(_data);
}
};
This will also make it possible to use _data as a mutable entity inside a const function - just like you could use it as a mutable entity if it was a local variable inside such a function.
If you want Bar to be initialised only once (due to cost in this case). Then I'd move it to a singleton pattern.