I am trying a recent development version of the BOINC software out on my openSUSE Tumbleweed system.

Test result example:

Markus_Elfring@Sonne:/var/lib/boinc> /usr/local/bin/boinccmd --client_version
1. request processing started
2. request processing started
3. request processing started
Client version: 7.25.0

Would you like to reconsider function implementation details accordingly?

Do you find another test result example interesting for further clarification of technical details?

Markus_Elfring@Sonne:/var/lib/boinc> /usr/local/bin/boinccmd --client_version
main() started
RPC_CLIENT::authorize() started
RPC::do_rpc() started
1. RPC_CLIENT::get_reply() before while loop
RPC::do_rpc() finished
RPC::do_rpc() started
2. RPC_CLIENT::get_reply() before while loop
RPC::do_rpc() finished
RPC_CLIENT::exchange_versions() started
RPC::do_rpc() started
3. RPC_CLIENT::get_reply() before while loop
RPC::do_rpc() finished
RPC_CLIENT::exchange_versions() finished
Client version: 7.25.0
main() finished

Are there so many RPC calls needed?

Would you become interested to discuss the software behaviour and implementation details any more also by the means of analysis tools like cwrap?

What is it that you're trying to accomplish?

You had a question for the developers, but when they asked you for more information, you refused to give them anything.
You thought you knew much more about this software than the people who programmed it.
You went as far as becoming the first person ever (that I know of) to be banished from the development channels.
And still you want to discuss the program, its underlying software etc. while you clearly show to know nothing about it, and have no desire to learn about it.

Why?

What is it that you're trying to accomplish?

I hope that further improvements can be achieved also for this software.

You had a question for the developers, but when they asked you for more information, you refused to give them anything.

It took a while until I could append relevant information (with different chances for a better understanding).

You thought you knew much more about this software than the people who programmed it.

I occasionally dare to present some development concerns and corresponding adjustment ideas.

You went as far as becoming the first person ever (that I know of) to be banished from the development channels.

Will such a case provide further opportunities to discuss involved communication difficulties?

And still you want to discuss the program, its underlying software etc.

Yes.

while you clearly show to know nothing about it, and have no desire to learn about it.

I suggest to reconsider also this view.

Why?

I imagine that change acceptance will eventually grow.

I write as someone who knows next to nothing about programming, certainly next to nothing when it comes to modern programming languages but what you posted gives no clue to me about the problem you wish to solve or how to solve it.

If you could state clearly what the problem is and why it is a problem and how any proposed solution would improve things, I for one would at least find some meaning in your post.

I write as someone who knows next to nothing about programming,

Some of the published information and corresponding ideas affects software development topics.

certainly next to nothing when it comes to modern programming languages

Such a fact can be fine for various users.

but what you posted

Would you become interested in any more public information from linked sources?

gives no clue to me about the problem you wish to solve or how to solve it.

Which hints would you like to clarify further (for known issues for example)?

The class “RPC” provides two member functions which were designed in the way that status codes are returned as integral values.
How do you think about the application of C++ exceptions instead?

Most here are not programmers but end users of the BOINC client albeit probably more knowledgeable than the average user.

Your scatter gun approach will cause most to gloss over your posts rather than provide any answers. If you described the problem as seen by an end user and how the alternative you suggest might help, you might get a more positive response than posting a link to a number of issues, many of which will not apply to a fair proportion of users for example the first one which will only affect those who run multi-cpu tasks.

Your scatter gun approach will cause most to gloss over your posts rather than provide any answers.

A few BOINC maintainers requested to continue the clarification of some software experiences by this forum interface.

If you described the problem as seen by an end user

Such surprising behaviour was reported also in the BOINC issue tracker.

and how the alternative you suggest might help, you might get a more positive response

Software development interests and corresponding resource requirements are challenging, aren't they?

than posting a link to a number of issues, many of which will not apply to a fair proportion of users for example the first one which will only affect those who run multi-cpu tasks.

There are recurring programming concerns involved.
Will any stories become more attractive for additional users?

If you described the problem as seen by an end user

How many of such users would be interested in better run time characteristics for a program like boinccmd?

and how the alternative you suggest might help, you might get a more positive response than …

The statement “RPC rpc(this);” can be searched in source files.
I got the impression then that the mentioned identifier is used only for a local variable in several member functions.
The shown function call trace excerpts indicated that multiple remote procedure calls would be performed so far.
Objects would be constructed for the variable “rpc” so often accordingly.
Can you imagine that the software implementation would benefit from the design adjustment to define such a variable only once and reference the corresponding object at the other source code places?

If you described the problem as seen by an end user

How many of such users would be interested in better run time characteristics for a program like boinccmd?

and how the alternative you suggest might help, you might get a more positive response than …

The statement “RPC rpc(this);” can be searched in source files.
I got the impression then that the mentioned identifier is used only for a local variable in several member functions.
The shown function call trace excerpts indicated that multiple remote procedure calls would be performed so far.
Objects would be constructed for the variable “rpc” so often accordingly.
Can you imagine that the software implementation would benefit from the design adjustment to define such a variable only once and reference the corresponding object at the other source code places?

I can imagine that supplying the helpdesk with the information that they are requesting would be far more productive than posts like this.

Would you become interested to discuss the software behaviour and implementation details any more also by the means of analysis tools like cwrap?

No

The class “RPC” provides two member functions which were designed in the way that status codes are returned as integral values.
How do you think about the application of C++ exceptions instead?

No. This will require a major code redesign without any real benefit. But instead it will add one hidden issue: if the function returns error, but this is not a critical error, and the application execution could continue, it's safe to ignore such an error codes, but if the function will throw an exception instead - you have to catch it, otherwise if there will be nobody who catches this exception - application will just crush. We definitely don't want to have this.

Can you imagine that the software implementation would benefit from the design adjustment to define such a variable only once and reference the corresponding object at the other source code places?

No, I can't because it won't fix any issue and since we have no performance issues as well - there is no reason to change the current behavior and do a redesign.

This will require a major code redesign without any real benefit.

It seems that there are further persuasion efforts needed to benefit more from the application of C++ exceptions.

But instead it will add one hidden issue: if the function returns error, but this is not a critical error, and the application execution could continue, it's safe to ignore such an error codes,

I suggest to reconsider return value ignorance.

but if the function will throw an exception instead - you have to catch it, otherwise if there will be nobody who catches this exception - application will just crush.

Are there opportunities to adjust implementation details in desirable directions?

We definitely don't want to have this.

How will circumstances evolve further for such development concerns?

Can you imagine that the software implementation would benefit from the design adjustment to define such a variable only once and reference the corresponding object at the other source code places?

No, I can't because it won't fix any issue and since we have no performance issues as well -

You probably find other change possibilities more interesting at the moment.
The software run time characteristics can be adjusted accordingly.

there is no reason to change the current behavior and do a redesign.

Some interests can eventually grow for known development concerns.

Of course, if the current design and implementation of BOINC causes you such great upset, there's nothing stopping you from re-writing it to your satisfaction. There is one major proviso - your implementation of BOINC complies with the API for the project applications and thus your version of BOINC will run any project out there in the public domain. Also your version of BOINC would have to be covered by the same license as the normally available version (GNU Lesser General Public License v3.0) if you were to distribute it for use by others.

Of course, if the current design and implementation of BOINC causes you such great upset, there's nothing stopping you from re-writing it to your satisfaction.

I occasionally adjusted some implementation details.

There is one major proviso - your implementation of BOINC complies with the API for the project applications and thus your version of BOINC will run any project out there in the public domain.

Some adjustments are possible.

It is just challenging to integrate further development ideas so that more users can benefit also from corresponding software evolution.

It is just challenging to integrate further development ideas so that more users can benefit also from corresponding software evolution.

You simply have to explain clearly what improvements you have made, and provide the actual code you have written in a form which can be tested automatically for compatibility.

That's how collaborative enterprises operate.