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 1 year ago.
Improve this question
The use case is quite common: I have a few variables that should be accessible globally (by various classes) and initialized from a configuration file. I can't decide the best way to do this.
Options struct is owned by someone and passed around:
struct Opts {
int op1;
double op2;
};
int main() {
Opts o = {3, 0.5};
// Pass this around as const reference, or potentially copying
return 0;
}
Use static vars for some Options struct.
struct Opts {
inline static int op1;
inline static double op2;
};
int main() {
Opts::op1 = 3;
Opts::op2 = 0.5;
// No passing around, but use Opts::op1 instead
return 0;
}
Use static vars, but sorta differently (not really).
struct Opts {
static int op1;
static double op2;
};
int Opts::op1;
double Opts::op2;
int main() {
Opts::op1 = 3;
Opts::op2 = 0.5;
// No passing around, but use Opts::op1 instead
return 0;
}
What should I actually do here? I thought the best case would be static const vars to make sure no one changes these, but the values can only be obtained from some file (so seems like it has to be run time instead of compile time), even though they won't change at after initializing.
I could make it const refs if I don't make it static, but that just forces me to pass this around among many classes. I also wanted the class that owns these options to be different from the class that parses them. This would just be even uglier with either moving unique_ptr or copying.
Is there a way to get best of both worlds:
not having to pass things around excessively (hence the semantics of "static")
making sure that these can't be modified after initialization, at least indicating that is the case (hence the semantics of "const")?
I commonly use a singleton Class. A config object is instantiated at startup time, and it reads the content of the file. It contains "getters" which return the values to you, and it might also contain "setters" which allow those values to be changed – in which case it also rewrites the underlying file. The settings file is simply how this object "persists" itself from one run to the next.
The object is also responsible for checking the contents of the settings to ensure that they are proper. If someone edits the file incorrectly, the object is going to throw a meaningful exception. So, if it doesn't do that, you know the settings file is good. The "setters" are equally suspicious: if some other part of the program tries to store an incorrect value, the object will catch the attempt and throw an exception.
Related
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
What options are available to create an object with lots of parameters in the global namespace? I'm thinking of the tradeoff between temporary object/variable creation and readability.
Edit
This is for embedded programming on the Arduino. It will be the main object of a reusable library controlling a set of nested objects.
Background: I have a test PCB which can be populated differently depending on its final use and I need to cover all of these options in one easy to use library. I am trying to avoid the user accidently missing required initialisation parameters before using the object.
Feel free to constructively criticise my code!
The two options that I can think of are:
A constructor with lots of parameters.
A constructor with a single struct parameter.
Option 1 looks messy and hard to follow with lots of parameters.
Option 2 requires a temporary struct variable for readability.
Example below (normally I would separate into headers etc.):
#include <Arduino.h>
class NestedClass {
public:
// Empty constructor for creation of unitialised object. Bad practice?
NestedClass() {
}
// Main constructor.
NestedClass(float voltageReference) :
voltageReference_(voltageReference) { // Use initialisation list.
}
float measureVoltage(uint_fast8_t channel) {
// Convert ADC value to absolute voltage.
return analogRead(channel) * (voltageReference_ / 1023);
}
private:
float voltageReference_;
};
class ComplexClass {
public:
enum class Mode
: uint_fast8_t {
MODE1,
MODE2,
MODE3
};
struct Parameters {
uint_fast8_t parameter1;
uint8_t parameter2;
float parameter3;
float parameter4;
Mode mode;
float voltageReference;
};
// Empty constructor for creation of unitialised object. Bad practice?
ComplexClass(void) {
}
// Big constructor. Messy when used.
ComplexClass(uint_fast8_t parameter1, uint8_t parameter2, float parameter3,
float parameter4, Mode mode, float voltageReference) {
// Could have used initialisation list instead.
this->parameter1_ = parameter1;
this->parameter2_ = parameter2;
this->parameter3_ = parameter3;
this->parameter4_ = parameter4;
this->mode_ = mode;
this->nestedClass_ = NestedClass(voltageReference); // Wasted temporary object with reassignment?
}
// Alternative constructor. Looks neater/more legible when used.
ComplexClass(Parameters parameters) {
this->parameter1_ = parameters.parameter1;
this->parameter2_ = parameters.parameter2;
this->parameter3_ = parameters.parameter3;
this->parameter4_ = parameters.parameter4;
this->mode_ = parameters.mode;
this->nestedClass_ = NestedClass(parameters.voltageReference); // Wasted temporary object with reassignment?
}
void megaMeasurements() {
// Do something involving nestedClass.measureVoltage().
}
private:
// Maybe put all of these in another struct for neatness?
uint_fast8_t parameter1_;
uint8_t parameter2_;
float parameter3_;
float parameter4_;
Mode mode_;
NestedClass nestedClass_;
};
//####################
// Start main code.
//####################
// Option 1:
// Not immediately obvious which value is for which parameter.
ComplexClass complexClass(1, 2, 3.30, 2.7, ComplexClass::Mode::MODE2, 5.00);
// Option 2:
// Unitialised object (sort-of).
ComplexClass complexClass2;
// Arduino standard function. Called once from main.cpp
void setup() {
// Option 2 continued:
ComplexClass::Parameters parameters;
parameters.mode = ComplexClass::Mode::MODE2;
parameters.parameter1 = 1;
parameters.parameter2 = 2;
parameters.parameter3 = 3.30;
parameters.parameter4 = 2.7;
parameters.voltageReference = 5.00;
complexClass2 = ComplexClass(parameters); // Reassignment. Wasteful?
}
// Arduino standard function. Called in a continuous loop after setup().
void loop() {
complexClass.megaMeasurements();
complexClass2.megaMeasurements();
}
My opinion (based on my practice):
constructor with many parameters look messy and should better be avoided. More, if some parameters are bad, you can't return "false" and the only way to complain is to throw an exception. If you want to go this way, it's better to define some init() function with several parameters, optionally returning false (or some error code) to complain if parameters are bad. In this case it's better to avoid literal numeric values using #define or static const declarations.
The other way is to assign values one by one, either directly (public) or with set() methods. In this case you can put literals in the code.
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
I have a question that is sort of a follow up to this:
Initializing default values in a struct
I've got a struct that's already got 17 bools, and a clear() method that sets them all to false. It's a long term project; the code could still be in use years from now and get added to. Is there a way to initialize all members that will extend automatically, so that someone adding new members to the struct doesn't need to remember to add them to the clear() method (other than a comment saying "please don't forget")?
This code base is not C++11 at this time, so I don't think I can initialize in the declaration.
The code is like this:
typedef struct {
bool doThingA;
bool doThingB;
bool doThingC;
bool doThingD;
// etc for several more bools
void clear() {
doThingA = false;
doThingB = false;
doThingC = false;
doThingD = false;
// etc...
}
} EnableFlags;
struct EnableFlags {
bool doThingA;
bool doThingB;
bool doThingC;
bool doThingD;
// etc for several more bools
void clear() {
*this = EnableFlags();
}
};
This will create a temporary with all members set to zero and then make *this a copy of it. So it sets all the members to zero, no matter how many there are.
This assumes that you haven't defined a default constructor that does something other than set all the flags to false. If you have no user-defined constructors then that assumption holds.
Since C++11 it's even simpler:
void clear() {
*this = {};
}
One option is to use a static assertion about the size of the structure inside the clear function.
First determine the current size of the struct. Let's say it's 68. Then, add this:
void clear()
{
BOOST_STATIC_ASSERT(sizeof(EnableFlags) == 68 && "You seem to have added a data member. Clear it before changing the number 68 to match current struct size!!");
// the rest as before ...
}
I've used Boost's static assertion macro, but you can use any other one you want, or roll out your own.
With such an assertion, the code will fail to compile when the size of the structure changes. It's not a catch-all solution, but does provide a safeguard.
Just use objetcs.
So you can use a 'for' loop to check in a std::vector if their values are false or true.
So you don't have your futurs co-workers put the "false" value each time they create a new boolean variable.
Structures are inapropriates here.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
First of all, I have been looking on stackoverflow for more than 1 hour, but I really don't know, how to find the specific question I'm looking for (I guess there is already some answer).
I am trying to call an object via variable (string)
example of my code:
//class itself
using namespace std
class locations {
public:
locations(int id, string name){ // constructor
this->id= id;
this->name=name;
}
int id= 0;
string name = "";
};
and new object:
locations home(1,"home");
what I want now is something like:
string obj = "home";
obj.id = 3;
or
string meth = "id";
home.meth = 3;
If you have any good links to other questions it would be helpful.
Maybe it can be accessed somehow through vectors but I don't know about it a lot
C++ is designed with strong typing and compile time checking and optimization in mind. There's no build in facilities for the kind of access that you desire.
1) Find dynamically an object:
C++ doesn't support the semantic that you expect:
string obj = "home"; // create an object of type string.
obj.id = 3; // access to member id of your object.
If it would be dynamic, the generated code would need to maintain the scope of variables (because the home object can have different meansings in different scope.
But fortunately you can easily implement an object store, in wich you register your objects and their name, with the help of a map :
map<string, locations> mystore; // store of all my location variables
mystore["home"] = locations(1,"home"); // copy a new object into the store
string obj = "home";
mystore[obj].id = 3; // access object via its name.
By the way, if locations::name is only there to give access by name, you'd no longer need it in locations, as the map links the string to the object value anyway.
2) Find dynamically a member:
C++ doesn't support your semantic at all:
string meth = "id"; // name of a member
home.meth = 3; // invalid: because meth is not a member of home
C++ doesn't support reflection that you find in java and other semi-compiled or interpreted languages. If you need something like that, you'd need to design carefully your classes to implement this by yourself. It'll be rather difficult as every member can have its own type, and C++ needs to know the type at compile time.
One way would be to combine the use of a map (to store your dynamic members) with the use of boost::variant (to store in the map objects that can have different type of values).
But it's not easy, and most of all, you'd have to manage by yourself any inheritance logic betwwen diferent classes.
This isn't how thing are done in C++, C++ is a object oriented, statically typed, value semantics language. All of these affect design, and the design you seem want just don't fit with a statically typed language. Whether this lead you to change design, or change language is up to you. That said, if you really want to map objects and methods runtime, it could be emulated something like this:
#include <iostream>
#include <string>
#include <map>
using namespace std;
struct Object;
typedef int (*funcptr)(Object*,int);
struct Object
{
map<string,funcptr> funcs;
map<string,int> data;
int call(string name,int param) { return funcs[name](this,param); }
};
map<string,Object> allObjects;
Object& get(string name) { return allObjects[name]; }
//----------------------------------------------------------------------------------
int main()
{
get("obj1").funcs["run"] = [](Object* self,int param) -> int { self->data["somename"] = param; return 0; };
get("obj1").call("run",5);
cout << get("obj1").data["somename"] << endl;
}
That said, please don't do that, change your design to something that actually is a good fit for C++'s strengths, i.e. object oriented, statically typed, value semantics.
So I am new to c++ and I'm writing for a scientific application.
Data needs to be read in from a few input text files.
At the moment I am storing these input variables in an object. (lets call it inputObj).
Is it right that I have to pass this "inputObj" around all my objects now. It seems like it has just become a complicated version of global variables. So I think I may be missing the point of OOP.
I have created a g++ compilable small example of my program:
#include<iostream>
class InputObj{
// this is the class that gets all the data
public:
void getInputs() {
a = 1;
b = 2;
};
int a;
int b;
};
class ExtraSolver{
//some of the work may be done in here
public:
void doSomething(InputObj* io) {
eA = io->a;
eB = io->b;
int something2 = eA+eB;
std::cout<<something2<<std::endl;
};
private:
int eA;
int eB;
};
class MainSolver{
// I have most things happening from here
public:
void start() {
//get inputs;
inputObj_ = new InputObj();
inputObj_ -> getInputs();
myA = inputObj_->a;
myB = inputObj_->b;
//do some solve:
int something = myA*myB;
//do some extrasolve
extraSolver_ = new ExtraSolver();
extraSolver_ -> doSomething(inputObj_);
};
private:
InputObj* inputObj_;
ExtraSolver* extraSolver_;
int myA;
int myB;
};
int main() {
MainSolver mainSolver;
mainSolver.start();
}
Summary of question: A lot of my objects need to use the same variables. Is my implementation the correct way of achieving this.
Don't use classes when functions will do fine.
Don't use dynamic allocation using new when automatic storage will work fine.
Here's how you could write it:
#include<iostream>
struct inputs {
int a;
int b;
};
inputs getInputs() {
return { 1, 2 };
}
void doSomething(inputs i) {
int something2 = i.a + i.b;
std::cout << something2 << std::endl;
}
int main() {
//get inputs;
inputs my_inputs = getInputs();
//do some solve:
int something = my_inputs.a * my_inputs.b;
//do some extrasolve
doSomething(my_inputs);
}
I'll recommend reading a good book: The Definitive C++ Book Guide and List
my answer would be based off your comment
"Yea I still haven't got the feel for passing objects around to each other, when it is essentially global variables im looking for "
so this 'feel for passing object' will come with practice ^^, but i think it's important to remember some of the reasons why we have OO,
the goal (in it simplified version) is to modularise your code so as increase the reuse segment of code.
you can create several InputObj without redefining or reassignig them each time
another goal is data hiding by encapsulation,
sometimes we don't want a variable to get changed by another function, and we don't want to expose those variable globally to protect their internal state.
for instance, if a and b in your InputObj where global variable declared and initialized at the beginning of your code, can you be certain that there value doesn't get changed at any given time unless you want to ? for simple program yes.. but as your program scale so does the chances of your variable to get inadvertently changed (hence some random unexpected behavior)
also there if you want the initial state of a and b to be preserved , you will have to do it yourself ( more temp global variables? )
you get more control over the flow of your code by adding level abstractions with classes/inheritances/operation overriding/polymorphisms/Abtract and interface and a bunch of other concepts that makes our life easier to build complex architectures.
now while many consider global variable to be evil, i think they are good and useful when used properly... otherwise is the best way to shoot yourself in the foot.
I hope this helped a bit to clear out that uneasy feeling for passing out objects :)
Is using your approach good or not strongly depends on situation.
If you need some high speed calculation you can't provide incapsulation methods for your InputObj class, though they are recommended, because it will strongly reduce speed of calculation.
However there are two rules that your can follow to reduce bugs:
1) Carefully using 'const' keyword every time you really don't want your object to modify:
void doSomething(InputObj * io) -> void doSomething(const InputObj * io)
2) Moving every action related with initial state of the object(in your case, as far as I can guess, your InputObj is loaded from file and thus without this file loading is useless) to constructor:
Instead of:
InputObj() { }
void getInputs(String filename) {
//reading a,b from file
};
use:
InputObj(String filename) {
//reading a,b from file
};
You are right that this way you have implemented global variables, but I would call your approach structured, and not complicated, as you encapsulate your global values in an object. This will make your program more maintainable, as global values are not spread all over the place.
You can make this even nicer by implementing the global object as a singleton (http://en.wikipedia.org/wiki/Singleton_pattern) thus ensuring there is only one global object.
Further, access the object through a static member or function. That way you don't need to pass it around as a variable, but any part of your program can easily access it.
You should be aware that a global object like this will e.g. not work well in a multithreaded application, but I understand that this not the case.
You should also be aware that there is a lot of discussions if you should use a singleton for this kind of stuff or not. Search SO or the net for "C++ singleton vs. global static object"
Typically, the way I'd define a true global constant (lets say, pi) would be to place an extern const in a header file, and define the constant in a .cpp file:
constants.h:
extern const pi;
constants.cpp:
#include "constants.h"
#include <cmath>
const pi=std::acos(-1.0);
This works great for true constants such as pi. However, I am looking for a best practice when it comes to defining a "constant" in that it will remain constant from program run to program run, but may change, depending on an input file. An example of this would be the gravitational constant, which is dependent on the units used. g is defined in the input file, and I would like it to be a global value that any object can use. I've always heard it is bad practice to have non-constant globals, so currently I have g stored in a system object, which is then passed on to all of the objects it generates. However this seems a bit clunky and hard to maintain as the number of objects grow.
Thoughts?
It all depends on your application size. If you are truly absolutely sure that a particular constant will have a single value shared by all threads and branches in your code for a single run, and that is unlikely to change in the future, then a global variable matches the intended semantics most closely, so it's best to just use that. It's also something that's trivial to refactor later on if needed, especially if you use distinctive prefixes for globals (such as g_) so that they never clash with locals - which is a good idea in general.
In general, I prefer to stick to YAGNI, and don't try to blindly placate various coding style guides. Instead, I first look if their rationale applies to a particular case (if a coding style guide doesn't have a rationale, it is a bad one), and if it clearly doesn't, then there is no reason to apply that guide to that case.
I can understand the predicament you're in, but I am afraid that you are unfortunately not doing this right.
The units should not affect the program, if you try to handle multiple different units in the heart of your program, you're going to get hurt badly.
Conceptually, you should do something like this:
Parse Input
|
Convert into SI metric
|
Run Program
|
Convert into original metric
|
Produce Output
This ensure that your program is nicely isolated from the various metrics that exist. Thus if one day you somehow add support to the French metric system of the 16th century, you'll just add to configure the Convert steps (Adapters) correctly, and perhaps a bit of the input/output (to recognize them and print them correctly), but the heart of the program, ie the computation unit, would remain unaffected by the new functionality.
Now, if you are to use a constant that is not so constant (for example the acceleration of gravity on earth which depends on the latitude, longitude and altitude), then you can simply pass it as arguments, grouped with the other constants.
class Constants
{
public:
Constants(double g, ....);
double g() const;
/// ...
private:
double mG;
/// ...
};
This could be made a Singleton, but that goes against the (controversed) Dependency Injection idiom. Personally I stray away from Singleton as much as I can, I usually use some Context class that I pass in each method, makes it much easier to test the methods independently from one another.
A legitimate use of singletons!
A singleton class constants() with a method to set the units?
You can use a variant of your latter approach, make a "GlobalState" class that holds all those variables and pass that around to all objects:
struct GlobalState {
float get_x() const;
float get_y() const;
...
};
struct MyClass {
MyClass(GlobalState &s)
{
// get data from s here
... = s.get_x();
}
};
It avoids globals, if you don't like them, and it grows gracefully as more variables are needed.
It's bad to have globals which change value during the lifetime of the run.
A value that is set once upon startup (and remains "constant" thereafter) is a perfectly acceptable use for a global.
Why is your current solution going to be hard to maintain? You can split the object up into multiple classes as it grows (one object for simulation parameters such as your gravitational constant, one object for general configuration, and so on)
My typical idiom for programs with configurable items is to create a singleton class named "configuration". Inside configuration go things that might be read from parsed configuration files, the registry, environment variables, etc.
Generally I'm against making get() methods, but this is my major exception. You can't typically make your configuration items consts if they have to be read from somewhere at startup, but you can make them private and use const get() methods to make the client view of them const.
This actually brings to mind the C++ Template Metaprogramming book by Abrahams & Gurtovoy - Is there a better way to manage your data so that you don't get poor conversions from yards to meters or from volume to length, and maybe that class knows about gravity being a form acceleration.
Also you already have a nice example here, pi = the result of some function...
const pi=std::acos(-1.0);
So why not make gravity the result of some function, which just happens to read that from file?
const gravity=configGravity();
configGravity() {
// open some file
// read the data
// return result
}
The problem is that because the global is managed prior to main being called you cannot provide input into the function - what config file, what if the file is missing or doesn't have g in it.
So if you want error handling you need to go for a later initialization, singletons fit that better.
Let's spell out some specs. So, you want:
(1) the file holding the global info (gravity, etc.) to outlive your runs of the executable using them;
(2) the global info to be visible in all your units (source files);
(3) your program to not be allowed to change the global info, once read from the file;
Well,
(1) Suggests a wrapper around the global info whose constructor takes an ifstream or file name string reference (hence, the file must exist before the constructor is called and it will still be there after the destructor is invoked);
(2) Suggests a global variable of the wrapper. You may, additionally, make sure that that is the only instance of this wrapper, in which case you need to make it a singleton as was suggested. Then again, you may not need this (you may be okay with having multiple copies of the same info, as long as it is read-only info!).
(3) Suggests a const getter from the wrapper. So, a sample may look like this:
#include <iostream>
#include <string>
#include <fstream>
#include <cstdlib>//for EXIT_FAILURE
using namespace std;
class GlobalsFromFiles
{
public:
GlobalsFromFiles(const string& file_name)
{
//...process file:
std::ifstream ginfo_file(file_name.c_str());
if( !ginfo_file )
{
//throw SomeException(some_message);//not recommended to throw from constructors
//(definitely *NOT* from destructors)
//but you can... the problem would be: where do you place the catcher?
//so better just display an error message and exit
cerr<<"Uh-oh...file "<<file_name<<" not found"<<endl;
exit(EXIT_FAILURE);
}
//...read data...
ginfo_file>>gravity_;
//...
}
double g_(void) const
{
return gravity_;
}
private:
double gravity_;
};
GlobalsFromFiles Gs("globals.dat");
int main(void)
{
cout<<Gs.g_()<<endl;
return 0;
}
Globals aren't evil
Had to get that off my chest first :)
I'd stick the constants into a struct, and make a global instance of that:
struct Constants
{
double g;
// ...
};
extern Constants C = { ... };
double Grav(double m1, double m2, double r) { return C.g * m1 * m2 / (r*r); }
(Short names are ok, too, all scientists and engineers do that.....)
I've used the fact that local variables (i.e. members, parameters, function-locals, ..) take precedence over the global in a few cases as "apects for the poor":
You could easily change the method to
double Grav(double m1, double m2, double r, Constants const & C = ::C)
{ return C.g * m1 * m2 / (r*r); } // same code!
You could create an
struct AlternateUniverse
{
Constants C;
AlternateUniverse()
{
PostulateWildly(C); // initialize C to better values
double Grav(double m1, double m2, double r) { /* same code! */ }
}
}
The idea is to write code with least overhead in the default case, and preserving the implementation even if the universal constants should change.
Call Scope vs. Source Scope
Alternatively, if you/your devs are more into procedural rather thsn OO style, you could use call scope instead of source scope, with a global stack of values, roughly:
std::deque<Constants> g_constants;
void InAnAlternateUniverse()
{
PostulateWildly(C); //
g_constants.push_front(C);
CalculateCoreTemp();
g_constants.pop_front();
}
void CalculateCoreTemp()
{
Constants const & C= g_constants.front();
// ...
}
Everything in the call tree gets to use the "most current" constants. OYu can call the same tree of coutines - no matter how deeply nested - with an alternate set of constants. Of course it should be encapsulated better, made exception safe, and for multithreading you need thread local storage (so each thread gets it's own "stack")
Calculation vs. User Interface
We approach your original problem differently: All internal representation, all persistent data uses SI base units. Conversion takes place at input and output (e.g. even though the typical size is millimeter, it's always stored as meter).
I can't really compare, but worksd very well for us.
Dimensional Analysis
Other replies have at least hinted at Dimensional Analysis, such as the respective Boost Library. It can enforce dimensional correctness, and can automate the input / output conversions.