On 09/07/2011 02:14, Chad Berchek wrote:
Specifically, the way const is now "defined" (or not...) is disturbing because it leaves out important details. In C++, you can pass by value or reference, or by pointer which is a value but is used to make references. But what's important is you _always_ know what it's going to do. If you pass something by reference and modify that instance via another reference, they're all going to change, because they are the same instance. And if you pass by value, it's the opposite. The point is, though, you always know what it's going to be.

Imagine if we took C++ and redefined the pass by reference syntax as "the compiler might pass by value or reference, depending what it feels like". Result? Boom. Tons of carefully written code would suddenly break.

...
If we *knew* that const meant it would be by reference, then that immediately eliminates the confusion in the case of ShortString and records; modifying one instance through several references affects them all, as expected. What the programmer says happens; there can be no "bug", except in the programmer's own knowledge.


We do know:
http://www.freepascal.org/docs-html/ref/refsu58.html#x135-14500011.4.4
A constant argument is passed by reference if its size is larger than a pointer. It is passed by value if the size is equal or is less then the size of a native pointer.

Of course if you want to rely on this, you must ensure the size of your type does ot change (a records definition can be chnaged, and that would have consequences for "const" param). But then, if you rely on it, but some compiler $IF and $FAIL in the code, to ensure it only compiles if your assumptions are met.

Personally I thing this page would be a good place to document the properties of "const" param with regards to ref-counted types...


_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to