C++ branch

[eipstackgroup]

C++ branch

[atimin]

Hi, Dick!
I think that is a great idea. I would like to take part in it because I want to use OpENer in my own project, but have some difficulties because it isn't written in C++. Actually I wanted to re-write it. I can't say that I have as big experience with C++ as you do, but I'm familiar to the project and could be helpful. Write there atimin @ gmail . com to connect with me.

[MartinMelikMerkumians]

Hello Dick,

I understand your point, and will be happy to support you, especially as there seems to be a need for a C++ variant of the OpENer.

Although I would suggest, that you should not develop a C++ OpENer version as a branch of the C OpENer, as the two version will probably soon diverge significantly.
Instead, you should push your new branch into a new repository.

Would it be an option for you to also host your C++ OpENer under the EIPStackGroup, as I would like to hold OpENer and its variations under a common interest group?

[liftoff-sr]

Hi Martin,
Thanks for your support. I should have updated ODVA CD's in a week or so. Yes, I can work under the EIPStackGroup if I can commit to a repo there. There is no definitive time period for the work yet. Progress will be as a result of need and spare time, and likely result in erratic surges of code generation.

Also, I am unwilling to assign copyrights on open source work that I do. Of course there is no problem honouring copyrights of others. But I don't assign my work. I think this results in a joint copyright scenario for source files which are evolutionary in nature. For new modules I would simply put in my copyright. I hope this is not in contradiction with any agreement you have with others for this group?

Regards,

Dick

[liftoff-sr]

Flipback and others:

The cplusplus branch is now worth looking at. It targets a larger machine without severe memory constraints, which nowadays, could mean a $20 Raspberry PI. That is not to say this re-design uses a ton more of memory, but rather it is not concerned about running out of memory. It also scales upwards to thousands of objects because modern efficient C++ containers where used. The container approach was chosen by weighing size, lookup speed, and simplicity. For the class registry, a hashtable was chosen. For attributes, instances, and services, a sorted std::vector of pointers was chosen, augmented with a binary search strategy on object id.

Attributes and services can be added at any time, not only at class instantiation time as before, where effectively a reservation of empties was done.

All files must be compiled with the C++ compiler now, and most are more than mere C code, i.e. actually C++.

Main objects now have constructors and destructors.

This allowed the DeleteAllClasses() function to go from 34 lines down to 1.

I am somewhere in the middle on variable name length, and that depends also on the context. I found function parameters were sometimes simply too long and became a distraction, so I shortened a number of them without any serious loss of clarity.

For now, the code is in the "cplusplus" branch at

https://github.com/liftoff-sr/OpENer/tree/cplusplus

IMHO, it is in every way better than the C version, but I don't like C any more and I use linux on even very small hardware now. YMMV.

Flipback, can you share with this project your File Object support? I don't mind doing the integration if you can get me the code.

[liftoff-sr]

You can now build it on linux for linux, or build it on linux for windows using mingw.
I renamed it CIPster. Development from me will now slow down after the fast and furious transition to something I can use and maintain.

The commit log tells the story, along with the README.md file. FYI, when I build for windows, it is typically a command line program and I do it on linux using mingw tools. CMake is my friend. Your mileage may vary, I think CMake and Mingw on windows should be OK too.

I just built it for 64 bit windows and ran it on my Ubuntu 16.04 x86_64 system. As I launched it from the command line, linux knew to run it under wine64. Then I could talk to it with the Molex tool, which is also running on Wine in the same box.

The "build on linux" instructions are in the README.md file.

The next step is to create a mailing list for it, so other developers have a means to know how to contribute.

As you study the code, you will see that I am not bashful about change, and that I have an established style that minimizes my anxiety in working on projects for which I am not being compensated. I value simplicity and human readability. I do not easily stray from things I've found to work in the past, i.e. I am old.

Enjoy.

Out.

Martin, I hope you are OK and did not get hit by a car. I thank you for your and the other contributor's work. It was my intention to become part of a team. But I found no basis of a team here and decided to fork the project. I have no Ill feelings about that and hope that you also do not. You are welcome to come write C++ code if that is an interesting challenge.

[MartinMelikMerkumians]

Hi Dick,
Sorry, that it took me so long to answer. I had been sick the last weeks and could not answer.
As a lot of the work done in the OpENer project is sponsored, I had to contact my sponsors on behalf on adding your project to the EIPStackGroup. Unfortunately, the decision is not made until now and seems to be of no relevance anymore.

I wish you good look with your fork and be sure there are no hard feelings for your choice to fork the OpENer project.

Best wishes,
Martin