In main I create the params object and create the camera_param obj to perform modifications on the params obj.
main.cpp
1 2 3 4 5 6 7 8 9 10
SimpleBlobDetector::Params params_1; //settings object
camera_param cp;
while (true){ std::cout << "test to console" << std::endl;
cp.set_cam_vars(params_1);
cp.print_cam_vars(params_1);
...
...
}
I set the set_cam_vars to set zero values for params.minThreshold
= 0 and params.maxThreshold = 0. Yet, when I read both params.minThreshold
and params.maxThreshold in print_cam_vars I get 50 & 5000 as values instead of 0. Why isn't it zeroing as instructed? What am I doing wrong?
I have searched the entire solution for 5000 and 50 and it comes up nowhere. I don't think its garbage values -- its the same before and after a reboot; the same after repeat executions.
You are passing in your params object by value. This means that the object inside the camera_param::set_cam_vars() is not the same object as the one in the calling code, but is a copy of it. Changing the values of the object in the method, does not change the values of the copy of the object in the calling code.
If you want the method to operate on the same object as the one in the calling code, you need to pass it by reference. In C++, this means that you define the argument to be a reference, as jonnin has shown you.
I understand (I think). Passing by reference (code below) required the following changes to .cpp/.h/main.cpp posted to make sure I pass by reference correctly.
However, still getting the unusual camera variables 50 and 5000. I'll have to dig deeper elsewhere or fix what's not right below. I may have put too many & for the stated objective.
I'm curious - why are you passing by reference into camera_param::print_cam_vars()? What are you trying to achieve by that?
EDIT:
Also, why are set_cam_vars() and print_cam_vars() members of the camera_param class? They have no impact on the state of that class at all. Shouldn't they be free functions instead?
To your latter statement, I don't have a supertight reason why I set_cam_vars() and print_cam_vars() to members of the camera_param class except I felt I had better organization by grouping like functions together in a reusable container(s).
>>why passing by reference into camera_param::print_cam_vars().
Shotgun approach. I'll remove it. In other words it doesn't matter here (the &) since the var is not shedding its value (just print -- copy does fine)
print_cam_vars() is independent from set_cam_vars(), hence its garbage values may be from SimpleBlobDetector::Params params_1. I think you must consider constructor of SimpleBlobDetector::Params instead.
To your latter statement, I don't have a supertight reason why I set_cam_vars() and print_cam_vars() to members of the camera_param class except I felt I had better organization by grouping like functions together in a reusable container(s).
So, you're basically using the class as a namespace, to group together related things. You can just use a namespace for that - there's no need for the overhead of defining a class.
Or, if you really want to keep the class, at the very least you can make those methods static. They don't impact the state of any object, so there's no need to instantiate an object in order to use them.
The other need met with class creation was moving excessive code into seperate files (.cpp/.h) while thinning out main. Coding was becoming a victim to a really crowded main.cpp.
How (or can it be done) do I use namespaces or free standing functions to move code out of main.cpp? Got to manage main.cpp better.
Having different files has no connection at all with organising code into classes, namespaces, libraries or anything else.
How can it be done? You just... put the functions (or whatever) into different files. That simple.
You can have classes in separate files. You can have multiple classes in the same file. You can use multiple files to define the methods of a single class, if you like.
You can have namespaces in separate files. You can use multiple namespaces in the same file. You can use the same namespace in multiple files.
?? It looks like you DID that. The way you presented the code here, you have a h file, its cpp file, and a third file for main.cpp.
generally you put things that go together into one pair of files:
- the main program, and if it needs one, its own .h file
- a class, and its h file, and for tightly coupled inheritance situations the parent/child classes may end up in just 1 pair of files (small, simple classes usually this is OK) or may each be in their own file (usually better for bigger complex stuff or reusable items (less tightly coupled, eg a base you use for several other classes should stand alone).
- free floating functions that do similar things, like all your input/output routines
and so on. Just organize it in a way that
1) no file is too big
2) stuff that belongs together is together unless violating #1 (in that case, find a way to divide it into smaller meaningful parts
3) reusable chunks are in stand alone files that can be put into other programs without baggage
4) it is easy for someone who knows nothing about your program to follow the flow and find the parts they are interested in. They shouldnt have to open 7 files to look at your input/output, they should only have to open 2 (a cpp and an h).
common sense can go a long, long way here. There are style guidelines and all kinds of 'rules' on the 'best' ways to do these things, but at the end of the day, good common sense will carry you far and a bit of experience will get you the rest of the way as you learn over time how other people do these things and get a zen-like feel for what is expected by other programmers.
* remember that templates use a .h file differently from other code. Keep that in mind if you have any or when you get there.
while I said some of it is common sense and 'felt' -- be consistent. Inconsistency is the enemy of programming, in pretty much every way.
Don't know what the problem was, but the program is functioning just fine pretty much as you see above minus a & in print_vars. Putting it (&) back in doesn't reproduce what the problem was either. I'm glad b.c for now want to keep the main.cpp/.h .cpp/.h format. I will also keep in mind the advice(they should only have to open 2 (a cpp and an h). for readability and find a balance there. The settings code takes up a lot of space so moving this out would be helpful now that it can be shown to be possible. And that just a start.