-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
As proposed in the issues section: Object-Oriented interface + Example #35
Conversation
Added an object-oriented interface for the library with a small example.
Hi Michael, |
I had a closer look and got some questions:
over:
|
Hi Patrick, hope you had a nice, relaxing vacation.
Thanks for your feedback! On 22 Aug 2016 4:11 p.m., "Patrick Brünn" notifications@github.com wrote: I had a closer look and got some questions:
struct Child : Parent { over: class Child : public Parent {
— |
Just had another thought. Maybe it is a bad idea to implement count as a template parameter. This limits the use of the function to cases where the size is known at compile time. What do you think? |
Thanks, my vacation was fine and relaxing, I hope you take your time, too. I am fine with further discussion next week. My opinion about the array functions is: I don't like them. The code looks to redundant. And as you stated we are passing them by value. Today I tried different approaches to combine the arrays and the normal functions but in the end an interface with a signature like this: (void *buffer, size_t buffer_size) seems the most appropriate solution to me.
Another open point is potential resource leakage and wasting with GetHandle()/ReleaseHandle(). I would like to encapsulate that inside of a handle_guard (something like std::lock_guard). And when we are about handles.
In case this is really useful, it could be easily advanced for access by indexgroup/offset. But to be honest I have no idea how your real world applications look like and if they would benefit from such an interface (Thats what I meant here #26). |
commit 39d2ea2 should show what I meant with "handle_guard". |
I finally found the time to have a look at your ideas.
Imagine: auto intVar = AdsVariable<uint32_t>(netId, port, symbolName); // Connects to ads variable (gets handle?)
intVar = 1; // Writes 1 to remote variable
uint32_t x = intVar; // Reads value of variable and saves it to x
auto intArr = AdsVariable<uint32_t>(netId, port, symbolName, count);
intArr[0] = 1; // Writes to index 0
uint32_t x = intArr[0]; // Reads only value at index 0
std::vector<uint32_t> x = intArr; // Reads array to vector What do you think? Regards |
Forget 3. I played around a bit and don't expect a problem anymore. |
I didn't have too much time but the interface idea intrigued me. Here is my first result: There are some shortcomings but I really like that the following code at least compiles: void test()
{
const AmsAddr adsAddr;
AdsVariable<int> var(adsAddr, "test", 10); // int array
AdsVariable<char> var2(adsAddr, "test"); // char variable
int readValueFromArray = var[1];
std::vector<int> readCompleteArray = var;
var[2] = 23; // Write to array
var2 = 'A'; // Write to value
char readValue = var2;
} What do you think? |
I tried to integrate that into dev-ooi
still missing:
preview:
|
Looks nice! On the missing parts:
And now a problem I ran into when playing around a little: How can we solve that?
Regards |
Sidenote: AdsClient.h does not compile with Visual Studio 2015.
You seem to be quite familiar with modern C++. Do you often use ? I know what bind does but I have never had the opportunity to use it. I just don't think about that. How did you start using it? |
SInce you opened the OOI branch I guess we can close this pull request and start a new one for the OOI branch. |
Hi,
I proposed an object-oriented interface for the library earlier.
This is my first shot.
My attention was to reduce the hassle of using the current interface.
For me, the major drawbacks of the original library are:
I tried to solve them like this:
The whole thing is a header-only addition to make it easy to include.
Every feedback is welcome.
Regards
Michael