Functions under difference name spaces are needed, the name space reflects different data version, but the all the functions has the same signature. Please see example
For version v_1_0 this function is needed v_1_0::decoder::decoding( ... )
For version v_1_1 then this shall be called v_1_1::decoder::decoding( ... )
I receives the version string from somewhere else. The version format is exactly as the namespace, I wonder if I could generated the function call from the namespace string variable.
The reason I'm asking for this question is, there are so many versions already and will be more added soon. I have to create a long if else or switch loop to call the function which is very annoying
switch (version) {
case v_1_0:
v_1_0::decoder::decoding( ... )
break;
case v_1_1:
v_1_1::decoder::decoding( ... )
break;
....
default:
break;
}
Would be nice to have something like
auto name_space = get_namespace( version );
name_space::decoding( ... )
This cannot be done. Namespace names are discarded when you compile the program.
You also cannot have a variable of type namespace. If each version was a class, or an instance of a class, you could create a function that returns the appropriate instance - but that is not the case for namespaces.
Related
Currently I am having a function which has two arguments of type enums, the function requires to compare both and do particular task
example:
void set_Test_Status(Tests TestName, Status TestStatus)
{
switch(TestName)
{
case Tests::Test1:
{
switch(TestStatus)
{
case TestStatus::St1:
//Rest of Code
}
}
//Rest of Code
}
}
is it a good programming practice? or is there any alternative method or style of coding that i should be aware of? Thank you!
Edit:
Finally after trial and error, I did this. First i saw the maximum and minimum items in each enums, In my case TestName were 6 and TestStatus had 3. I created 3 functions setStatusRunning(Tests TestName), setStatusSelected(Tests TestName) and setStatusFinished(Tests TestName) and in set_Test_status, using switch(TestName) i check which function should be called and then called the appropriate functions. The reason i had to make set_Test_Status in the first place was to make easy for other classes, since i made set_Test_Status public and the other 3 as private.
It is truly a matter of opinion as having nested switch statements is valid c++ code. Some may not have problems with it while others may argue that it can be confusing.
My advice would be on the lines of this; if the code blocks within the case statements are short such as 1-2 lines and they are fairly easy to read and follow, then there should be nothing wrong with it. However, if the code is quite cumbersome and the nested switch statements spans well over 50 to 100+ lines then I would suggest refining your code and make functions out of them.
Examples:
// should be okay
unsigned int outerSwitch = someValue();
unsigned int innerSwitch = someOtherValue();
switch ( outerSwitch ) {
case 1: {
switch ( innerSwitch ) {
case 1 : {
// 1 or 2 lines okay;
}
case 2 : {
// 1 or 2 lines okay;
}
case 3 : {
// 1 or 2 lines okay;
}
default : {
}
} // inner switch when outer switch case = 1
}
case 2: {
// Same as case 1
}
case 3: {
// Same as case 1
}
default: {
}
} // outer switch
But as you have seen above with just 3 cases to the outer and inner; it gets very long very quickly and I haven't even expanded them all. So this can be frowned upon.
You can have a single switch as others have suggested that calls a specific function to that switch then within that function it has its own switch statement like this:
unsigned int someFuncA( unsigned int someVal ) {
switch ( someVal ) {
case 1 : {
// do this
// return that;
}
case 2: {
// ... etc.
}
} // switch
}
unsigned int someFuncB( int someVal ) {
// similar to someFuncA();
}
unsigned int someFuncC( int someVal ) {
// similar to someFuncA();
}
unsigned int switchValue = someValue();
unsigned int innerValue = someOtherFunction();
unsigned int temp = 0;
switch( switchValue ) {
case 1 : {
temp = someFuncA( innerValue );
// either return temp, break, continue, or fall through
}
case 2 : {
temp = someFuncB( innerValue );
// same as above
case 3 : {
temp = someFuncC( innerValue );
// same as above
}
default : {
// default stuff here
}
} // switch
Comparing the two you will see that the 2nd version is easier to read and less cumbersome than the 1st. Yes the first version is valid legal C++ code, but is frowned upon because of how messy it can easily and quickly get. So where ever you can; turn that code into a function that is designed to do just that one thing.
EDIT
Another possibility is to design specific functions to do a task and as you said that your function takes 2 different enumeration values, you can look up the concept of functions that are designed to take bit flags. You will see this kind of code quite a bit in windows programming as well as OpenGL.
Another option is this: consider that fact you have an outer control switch, and inner control switch. Even if you have multiple cases, each case is independent with a specific unique ID. The same can be said for the inner switch cases. Knowing this you can create an associative mapping of all the statements in a combined matter using std::multimap<unsigned, unsigned> testCases and with this lookup table you can have it in a single statement with independent function calls to each map entry. cppreference : std::multimap
Your map might look like this:
testCases[1][1];
testCases[1][2];
testCases[1][3];
testCases[2][1];
testCases[2][2];
testCases[2][3];
testCases[3][1];
testCases[3][2];
testCases[3][3];
Where each index of the map is the logic or calculation you want to perform.
It can be quite confusing for someone reading the code-- indentation helps, but it can still be difficult to follow where the case and switch statements start and end. Most IDEs have support for finding a matching brace, but finding a matching break isn't generally a thing, so it can be difficult to even see where a case statement ends. (And technically case doesn't define scope whereas braces do, so it doesn't even have an end.)
If you get misaligned braces or accidentally mismatch where they should be, you can have odd things happen. Languages like Ada try to prevent that with strongly typed English-language specifiers.
If you are doing a lot of sub-switches, I would put them into another function and call it with the information it needs, then you could do a switch statement inside the method which is more modular, separate scope and clear what is going on.
A good practice to keep code concise is to do only one thing in a function. Using a switch already is a smell that your function is going to do different things. It all depend of your specific case.
One thing to look at is: is it coherent to manage all these cases in one class. Should you have one class per possibility, with an interface forcing to implement a function, instead of doing all the possibilities in a switch case.
In case you want to keep the switch, a good practice would be to not put code in it other than the switch. Each case just calls a function. This will already make stuff more readable.
Finally, are you using all the cases? If no, you code could be more clear by just implementing the pairs of values that you need:
if(TestName == Tests::Test1 && TestStatus == TestStatus::St1)
{
doThing();
}
To summarize:
This might be a smell that your code needs to be split in more classes to have only one responsibility per class (too many if and/or too many switches ar a sign of that). If you are sure that you need a switch, keep it as simple and clear as possible
I have a class, DBProc, which makes a connection to PostgreSQL, and allows user to submit queries/retrieve results.
Functionally, everything works.
The DBProc::connect() function takes an optional argument for connection type. The 3 variants are: direct, lazy, asynchronous.
I have code that instantiates the correct connection class according to user's choice. I initialize 3 unique_ptr<> beforehand, one for each possible connection class, then use an switch statement to choose the selected class type.
This all works fine...but
My preference would be to have ONE class var that holds a reference to
the connection class
(all the classes have the exact same functionality), but I see no easy way to do this.
'auto& currentConnection = lazyConnection' works fine in the switch statement, but of course goes out of scope after the code block.
If there was a way to create a var within a block and allow it to be seen outside the block, without 1st declaring it, that would work, but I don't believe that's possible in c++.
I can't declare it first because all these classes require initialization upon declaration.
So...c++atch 22 ;-)
So, every time I need to use the connection, I need a switch statement to select the right pointer.
I've looked at templates, unions, extern, and don't see a way to do it with any of these.
If anyone knows if there is a way to do this, please describe.
Here's a code snippet of class func:
bool DBProc::connect(ConnectionType type) {
...
unique_ptr<pqxx::connection> connect;
unique_ptr<pqxx::lazyconnection> lzy_connect;
unique_ptr<pqxx::asyncconnection> async_connect;
try
{
switch (type) {
case ConnectionType::direct : {
connect = make_unique<pqxx::connection>(connOpts);
break;
}
case ConnectionType::lazy : {
lzy_connect = make_unique<pqxx::lazyconnection>(connOpts);
break;
}
case ConnectionType::async : {
async_connect = make_unique<pqxx::asyncconnection>(connOpts);
break;
}
} catch
...
}
Working answer provided in comment by 'some programmer dude'
Why not have a std::unique_ptr to pqxx::connection_base which is the common base class for all connection types? – Some programmer dude
Simplified code:
unique_ptr<pqxx::connection_base> base_connect;
try
{
switch (type) {
case ConnectionType::direct : {
base_connect = make_unique<pqxx::connection>(connOpts);
break;
}
case ConnectionType::lazy : {
base_connect = make_unique<pqxx::lazyconnection>(connOpts);
break;
}
case ConnectionType::async : {
base_connect = make_unique<pqxx::asyncconnection>(connOpts);
break;
}
default:
error += "No valid connection type supplied (direct | lazy | async)";
return false;
break;
}
I am currently trying to figure out an alternative method for switch statements as the program I have the switch statements are getting really long and confusing. Therefore I thought it would be a good idea to use array of pointers to functions. I am using c++ and qt. But when I try and implement, I am getting the following error.
cannot convert 'CheckPl::comA' from type 'void (CheckPl::)()' to type 'void (*)()'
It would be much appreciated if someone would help me out with this or at least point me to correct direction.
[...] alternative method for switch statements as the program I have the switch statements are getting really long and confusing.
Extract each case block into a separate function; This way, the switch changes from a 10km long function to a dispatch function:
void dispatch_function()
{
switch(x)
{
case 1: do_case_1(); break;
...
case n: do_case_n(); break;
}
}
Therefore I thought it would be a good idea to use array of pointers to functions.
It's not a good idea (especially, not in the way you went about it - you are solving the xy problem). In C++, when you have a requirement for multiple functions that are called in similar conditions, you have the requirements for an abstract interface.
Your resulting client code should look like this:
std::vector<handlers> handlers; // filled with handler instances, one for each case
for(const auto& h: handlers) // replaces switch
if(h.fits_case(x)) // replaces case statement
{
h.do_case(x); // replaces case block
break;
}
It follows that your handler classes should inherit from a base class like this:
class handler_base
{
virtual bool fits_case(int x) = 0;
virtual void do_case(int x) = 0;
}
This is easy to understand (in both implementation and client code), it is modular, testable (you can test each case separately) and extensible (if you need a new case you only add the case and add it to the vector); It also doesn't use any pointers.
A pointer to a member function has to be stored in a variable of the appropriate type. A pointer to a member function is not compatible with a pointer to a function.
void (CheckPl::*mptr)() = &CheckPl::comA;
A pointer to a member function requires an instance to an object for invocation.
CheckPl c;
CheckPl *cp = &c;
(c.*mptr)();
(cp->*mptr)();
The hardest thing to remember about the above syntax is that the extra set of parentheses is required.
I am new to C++ and trying to learn the code for Extreme Tux Racer. In the code in the main method it says manager.Run(...). To me this looks like it is running the Run method of a manager object in the State namespace.
switch (g_game.argument) {
case 0:
State::manager.Run(SplashScreen);
break;
case 4:
g_game.toolmode = TUXSHAPE;
State::manager.Run(Tools);
break;
case 9:
State::manager.Run(OglTest);
break;
}
I assume that the manager object's run method has to be declared and defined somewhere. But I searched all of the included files for the word manager and could not find it. What am I missing here?
It looks like they set file name the same as class name, which is a good way to do. So in states.h, you could see all definition:
class State {
//...
static Manager manager; // manager is static member
//...
};
static member could be accessed by :: , . or -> operator.
State::manager.Run(..); // valid
State state;
state.manager.Run(..); // valid as well
State *pState = &state;
pState->manager.Run(..); // also valid
I have a lot of legacy code using macro of the form:
#define FXX(x) pField->GetValue(x)
The macro forces variable pField be in the scope:
.....
FIELD *pField = ....
.....
int i = FXX(3);
int j = FXX(5);
Is there way to replace the macro, without touching user code?
Since FXX(x) has a function invocation style, I thought about inline function or something similar.
UPD:
People just used to the macro, and I want to remain it as is.
How about using a find & replace function in your favorite editor...I think it would work fine in the example you gave in your question. Replace FXX with pField->GetValue and then remove the #define line
What is pField (besides a fine example of the abomination that is Systems Hungarian)? If, by chance, it's a global variable or a singleton or something that we only need one of, we could do a nifty trick like this:
int FFX(int x)
{
static FIELD *pField = ...; // remove this line if pField is global
return pField->GetValue(x);
}
Change the int types to whatever types you need it to operate on, or even a template if you need it to support multiple types.
Another alternative, suggested by #epatel, is to use your favorite text editor's find-and-replace and just change all the FFX(x) lines to pField->GetValue(x), thus eliminating the macro invokation in your code. If you want to keep a function invokation, you culd change FFX(x) to FFX(pField, x) and change the macro to take two arguments (or change it to a function that takes two arguments). But you might as well just take out the macro at that point.
A third alternative, is not to fix that which is not broken. The macro isn't particularly nice, but you may introduce greater problems by trying to remove it. Macros aren't the spawn of Satan (though this one has at least a few relatives in hell).
What you need is a function that relies on a variable being defined. The only way to do that is to declare that variable in the same scope as the function. But then your function would use that one instead of the one declared from where your function is called.
So I'm fairly confident it can't be done.
Well, if you can put this function definition where pField is already in scope:
int FXX(int x) { return pField->GetValue(x); }
Otherwise, there's no way to get pField into the the function without affecting existing code.
This may be a case where using the macro is the best alternative. Macros may be evil, but they are sometimes necessary. See http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.15
I would leave it as it is, but just for the sake of discussion, and depending on what parts of the code are 'untouchable' you could define a functor that takes a pField and initialize after the variable is created in the same scope:
class FFX_t {
FFX_t( FIELD * pField ) : field_(pField) {}
int operator()( int index ) {
return field_->GetValue( index );
}
private:
FIELD *field_;
};
// usage:
void f() {
FIELD * pField = //...
FFX_t FFX(pField); // added after pField construction
// ...
int a = FFX(5);
}
But I insist in that changing working code for the sake of it when it will not really add any value is useless.