Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » [Proposal] Adding a GLLock struct to GLCtrl
Re: [Proposal] Adding a GLLock struct to GLCtrl [message #54737 is a reply to message #54734] Fri, 04 September 2020 22:28 Go to previous messageGo to previous message
Klugier is currently offline  Klugier
Messages: 1076
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello Xemuth,

Quote:
Since my proposal symply call used function in ExecuteGL() I don't fairly see how it could grow up the maintenance needed on the package


Every new line of code requires some kind of maintenance for example you need to test if it's working after modifying some code nearby. This generates costs. The question here is do we really need them? I know that risk is very small, but it could happen. In software engineering everything is possible. It could be automated for example with unit tests then you shouldn't care.

Quote:

Both solution have the same purpose : Giving the OpenGL Context to allow GL Commands, The difference come from the timelive of the context, ExecuteGL() Release it when reached the end of function when the struct / function allow you to decide when releasing it. I think (maybe it's naive) both solutions complements each other and it is the developper job to choice the well suited one for is need at the moment. I see this choice like allocating on heap or stack depending on what you need, both allow you to reserve space for a data however the difference between both are huges and it is the developper job to chose the well suited one at a time.


There are several schools there. We could give people more freedom or restrict them to use only one approach. Both ways have it's pluses and minuses. From my long-term experience more freedom leads to unnecessary discussions. How many times I had situation like this:
- Hay I implemented that that way?
- Hey do you know that you can implement it that way and it is much better than your current approach?
- I am not sure my approach is fine.
- Hey read this article about my approach they said that it is better
- I found this article and it says mine is better
- ...

With one approach the above discussion will never happen. Until no one decides to modify framework to gave people choice Wink So as you noticed not everything is black and white.

Quote:

I see this choice like allocating on heap or stack

Hey, let's create garbage collector and forget about the choice. Now everything is allocated on stack Wink

The final decision is up to Mirek as a owner and maintainer of OpenGL package. I am here for constructive discussion Smile

Klugier


U++ - one framework to rule them all.

[Updated on: Fri, 04 September 2020 22:28]

Report message to a moderator

 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Changing default standard from c++14 to c++17 (2020.2 Release)
Next Topic: RegExp
Goto Forum:
  


Current Time: Mon May 20 23:48:05 CEST 2024

Total time taken to generate the page: 0.00955 seconds