I would like to draw your attention to a new feature announced on the FPC mailing list: Dynamic array extensions. In short:
- support for array constructors using "[...]" syntax
- support for Insert(), Delete() and Concat()
- support for "+" operator
- support for dynamic array constants (and variable initializations)
What is your opinion on that ?
I would like to draw your attention to a new feature announced on the FPC mailing list: Dynamic array extensions. In short:on one hand it nice not to have to write those pesky init routines, on the other I have no idea why it is needed to become an intrinsic, until I get some insight on that I can't really comment. I guess it makes things both better and worst. Its better because now + becomes standard, stable, when I see it on piece of code that I debug, I know exactly what it does, it is worst well I guess you know why. Now you have to type all kinds of staff and your code moves a bit farther away from math symbolism. You could say I'm on the fence on that.
- support for array constructors using "[...]" syntax
- support for Insert(), Delete() and Concat()
- support for "+" operator
- support for dynamic array constants (and variable initializations)
Sounds ok, however: The "+" operator is effectively an alias for concat(), and it will be an intrinsic, which means that existing "+" operator overloads for dynamic arrays will no longer compile. Intrinsic operators cannot be overloaded, hence it will no longer be possible to custom define the "+" operator to do a mathematical elementwise addition of numerical vectors/matrices.
With the "+" operator hijacked, all other obvious mathematical operators i.e. -, *, / for numeric vectors are effectively obliterated. We would either have to revert to procedural style as in turbo pascal days, such as in function add (V1, V2: TVector): TVector; or declare extra container classes for numeric vectors / matrices, to which mathematical operators can be applied.
What is your opinion on that ?
Oh by the way becoming like swift is a bad thing not a good one :P (just kidding)
Well the logical thing for dynamic arrays is really concat after all, because it not necessarily holds data that you can perform vector math on.
Where can we say that we want to keep the + operator as it is?I agree.
probably the only solution is combo of both :Where can we say that we want to keep the + operator as it is?I agree.
With the "+" operator hijacked, all other obvious mathematical operators i.e. -, *, / for numeric vectors are effectively obliterated. We would either have to revert to procedural style as in turbo pascal days, such as in function add (V1, V2: TVector): TVector; or declare extra container classes for numeric vectors / matrices, to which mathematical operators can be applied.
@circular, @lainz
WriteStr(s, 'Hello number ', 10, '!');
I would like to draw your attention to a new feature announced on the FPC mailing list: Dynamic array extensions. In short:
- support for array constructors using "[...]" syntax
- support for Insert(), Delete() and Concat()
- support for "+" operator
- support for dynamic array constants (and variable initializations)
Sounds ok, however: The "+" operator is effectively an alias for concat(), and it will be an intrinsic, which means that existing "+" operator overloads for dynamic arrays will no longer compile. Intrinsic operators cannot be overloaded, hence it will no longer be possible to custom define the "+" operator to do a mathematical elementwise addition of numerical vectors/matrices.
With the "+" operator hijacked, all other obvious mathematical operators i.e. -, *, / for numeric vectors are effectively obliterated. We would either have to revert to procedural style as in turbo pascal days, such as in function add (V1, V2: TVector): TVector; or declare extra container classes for numeric vectors / matrices, to which mathematical operators can be applied.
What is your opinion on that ?
Addendum to that: the "+" operator is now connected to a "ArrayOperators" modeswitch.
As far as I understand, + is an alias to on, - an alias to off, (or vice versa) they are interchangeable, he only drawn your attention to the - because it is easy to miss, if he had used off instead then the note would not have been necessary.QuoteAddendum to that: the "+" operator is now connected to a "ArrayOperators" modeswitch.
Thank you. Guess that is an acceptable solution.Why is it "-" in this case rather than "OFF" ?
{$modeswitch ArrayOperators-} // Note the "-"
QuoteAddendum to that: the "+" operator is now connected to a "ArrayOperators" modeswitch.
Thank you. Guess that is an acceptable solution.Why is it "-" in this case rather than "OFF" ?
{$modeswitch ArrayOperators-} // Note the "-"
The syntax is as follows:
{$MODESWITCH XXX}
{$MODESWITCH XXX+}
{$MODESWITCH XXX-}
The first two will switch on feature XXX, the last one will switch it off.
QuoteAddendum to that: the "+" operator is now connected to a "ArrayOperators" modeswitch.
Thank you. Guess that is an acceptable solution.Why is it "-" in this case rather than "OFF" ?
{$modeswitch ArrayOperators-} // Note the "-"
Addendum to that: the "+" operator is now connected to a "ArrayOperators" modeswitch.
If the modeswitch is active then the "+" operator overload is not possible and the compiler will warn if such an overload is in scope. If the modeswitch is not set, then everything is as before.
The modeswitch is enabled by default in Delphi modes, because that's why the feature was added. To disable the modeswitch there use this:
{$mode Delphi} {$modeswitch ArrayOperators-} // Note the "-"
Because modeswitches currently don't support ON/OFF, only +/- (the latter can also be used with other switches, like e.g. $ScopedEnums). :-[