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
