AfaikNo argument about the fact that it does represent a significant amount of work and, of course, any change has the potential of introducing unforeseen bugs.
- for ref counted types it is different.
- Enormous amount of work, chances on bug introduction. (and before you easily step over this, we are still committing bugfixes every month from the initial translation in 1999)
Moreover most people only have a few lines of API code. If they care that much, turn warnings off for that piece of code.
No argument about the fact that it does represent a significant amount of work and, of course, any change has the potential of introducing unforeseen bugs.
It's a bit of "problem" when one's entire program is pure API. Lots of warnings and it's probably more work to turn of the warnings than to change the API definitions.
But then I think it is better for such cases that those manage their own API (e.g. new automated translations), than doing manually such huge changes to the currently hand maintained ones. That is simply not an option.Thank you.. <chuckle>.
Good luck!
Here is a related question, if I were to change the definitions of those APIs I use in my programs (IOW, the changes would be manual and individually tested to be correct), would there be any interested in including the "cleaned up" definitions of those APIs ? (this question is _mostly_ to determine if any effort on my part in that regard could benefit other people, if it wouldn't then, I would most likely not do it.)
Obviously, the number of APIs I would update would also be very limited compared to the number of APIs available. I doubt it would exceed a few hundreds at most.
I'm not interested. Doing some, and some not will only invite more discussion.Fair enough. Thank you for being clear about that.
@Thaddy:Out is initialization from within a method or procedure. Var does not .... They are distinctly different. Out is more strict than var. Although out is compatible with var, but not every var with out.
can you give an example of what code would be broken ?... as far as I can tell, the only difference between a "var" parameter and an "out" parameter is that "out" informs the compiler that the parameter will be written to and not just read. What happens to the parameter does not change.
Some windows apis have macros that specify if the parameter is in, out or inout.This has not always been the case: only when the MS compilers were able to support this. So MS rewrote / redocumented their API's at that point.
At least e.g. commctrl and mmsysten afaik do. I'm not sure if older apis also do.
I hope you agree with my explanation and example, btw.But of course!
For external APIs that don't use managed types (e.g. those Windows APIs that do not use interfaces) there shouldn't be a difference.That is, it turns out that the conversion in the Windows API "var" to "out" constraints only a large amount of work, and there are no other reasons.
Here is a related question, if I were to change the definitions of those APIs I use in my programs (IOW, the changes would be manual and individually tested to be correct), would there be any interested in including the "cleaned up" definitions of those APIs ? (this question is _mostly_ to determine if any effort on my part in that regard could benefit other people, if it wouldn't then, I would most likely not do it.)
Obviously, the number of APIs I would update would also be very limited compared to the number of APIs available. I doubt it would exceed a few hundreds at most.
That would be really helpfulI certainly understand the developers reluctance of doing it as a "project" assigned to one individual. In the case of FPC, it seems to me that the FPC/Lazarus user community could "pitch in" cleaned up definitions and little by little end up with definitions that are as clean as they can be,