Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On 03.02.2014 18:52, Martin Frb wrote: On 03/02/2014 15:25, Martin Frb wrote: On 03/02/2014 14:37, Sven Barth wrote: Nevertheless FPC provides the correct operator precedence (no matter whether overloading is used or not, because that is done at a different level of the parser): - power - unary

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On 03/02/2014 15:25, Martin Frb wrote: On 03/02/2014 14:37, Sven Barth wrote: Nevertheless FPC provides the correct operator precedence (no matter whether overloading is used or not, because that is done at a different level of the parser): - power - unary plus/minus - product/divison - additi

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Mon, Feb 3, 2014 at 11:02 AM, Martin Frb wrote: > Parsed yes, but if it comes to evaluation, then you get {$T-} (@a)^ > "cant dereference an untyped pointer" or similar > > @a^ always works. All I was asking is if the documentation should state it > more clearly that ^ is (As part of the iden

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On 03/02/2014 16:02, Martin Frb wrote: @a^ always works. All I was asking is if the documentation should state it more clearly that ^ is (As part of the identifier) done before ^ done before @ of course. For the rest, I am happy, never mind, if it is an operator or not.

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On 03/02/2014 15:38, Dmitry Boyarintsev wrote: On Mon, Feb 3, 2014 at 10:25 AM, Martin Frb > wrote: It does not state if or if not it is an operator. And also give no indication on its precedence, or if it is applied before or after operators. This is

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Mon, Feb 3, 2014 at 10:25 AM, Martin Frb wrote: > It does not state if or if not it is an operator. And also give no > indication on its precedence, or if it is applied before or after operators. > > This is not so much about he -a^ (which is a (very) constructed case), but > about @a^ which

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On 03/02/2014 07:58, Michael Van Canneyt wrote: As for unary minus: this is the same as a binary minus in arithmatic expressions. On 03/02/2014 14:37, Sven Barth wrote: Nevertheless FPC provides the correct operator precedence (no matter whether overloading is used or not, because that is done

Re: [fpc-devel] [fpc-pascal] overload question (variant vs enum subrange)

Anybody? Is this designed? Or is this a bug? Shall I put it on Mantis? On 26/01/2014 19:48, Martin Frb wrote: TFoo1 is a sub range of FFoo And it seems to match both TFoo and variant. project1.lpr(24,3) Error: Can't determine which overloaded function to call project1.lpr(15,11) Hint: Found

Re: [fpc-devel] function overload ?

If you're not worried about the slight speed hit and extra space on the stack for the return value of "My" you could always have it as a Variant? function My(const a : Integer) : Variant; Then assign it to whatever variable? - Dennis Fehr On 14-02-03 12:54 AM, Gennadiy Poryev wrote: Hi!

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

Am 03.02.2014 14:52, schrieb Martin Frb: On 03/02/2014 10:48, Sven Barth wrote: So unary minus (and also unary plus which is a valid operator as well!) binds stronger than multiplication. Just using -al c := -a *b; c := (-a) *b; c := -(a *b); The unary - is applied first. Though it makes n

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

Am 03.02.2014 12:17, schrieb Michael Van Canneyt: On Mon, 3 Feb 2014, Sven Barth wrote: Am 03.02.2014 12:04, schrieb Michael Van Canneyt: On Mon, 3 Feb 2014, Sven Barth wrote: Am 03.02.2014 08:58, schrieb Michael Van Canneyt: As for unary minus: this is the same as a binary minus in ari

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On 03/02/2014 14:07, Martin Frb wrote: On 03/02/2014 13:47, Jonas Maebe wrote: On 03 Feb 2014, at 14:28, Martin Frb wrote: The reason I did get to that, is because I have to reproduce the behaviour (for fpdebug). And when scanning/evaluating a pascal expression/statement, it works well to h

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On 03/02/2014 13:47, Jonas Maebe wrote: On 03 Feb 2014, at 14:28, Martin Frb wrote: The reason I did get to that, is because I have to reproduce the behaviour (for fpdebug). And when scanning/evaluating a pascal expression/statement, it works well to handle the "." (and also []()^) as operat

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On 03/02/2014 10:48, Sven Barth wrote: So unary minus (and also unary plus which is a valid operator as well!) binds stronger than multiplication. Just using -al c := -a *b; c := (-a) *b; c := -(a *b); The unary - is applied first. Though it makes no difference to the result. However with

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On 03 Feb 2014, at 14:28, Martin Frb wrote: The reason I did get to that, is because I have to reproduce the behaviour (for fpdebug). And when scanning/evaluating a pascal expression/statement, it works well to handle the "." (and also []()^) as operator. So that is haw the "." ended on t

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Mon, 3 Feb 2014, Martin Frb wrote: On 03/02/2014 07:58, Michael Van Canneyt wrote: On Mon, 3 Feb 2014, Martin Frb wrote: This does not include: ^ deref - unary minus . accessing a member of a class/record (not unary) To my knowledge, the . and ^ are not considered operators, they are

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On 03/02/2014 07:58, Michael Van Canneyt wrote: On Mon, 3 Feb 2014, Martin Frb wrote: This does not include: ^ deref - unary minus . accessing a member of a class/record (not unary) To my knowledge, the . and ^ are not considered operators, they are "part of the identifier". Ok, so they

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Mon, 3 Feb 2014, Tomas Hajny wrote: On Mon, February 3, 2014 12:10, Sven Barth wrote: Am 03.02.2014 12:04, schrieb Michael Van Canneyt: On Mon, 3 Feb 2014, Sven Barth wrote: Am 03.02.2014 08:58, schrieb Michael Van Canneyt: As for unary minus: this is the same as a binary minus in arith

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Mon, February 3, 2014 12:10, Sven Barth wrote: > Am 03.02.2014 12:04, schrieb Michael Van Canneyt: >> On Mon, 3 Feb 2014, Sven Barth wrote: >>> Am 03.02.2014 08:58, schrieb Michael Van Canneyt: As for unary minus: this is the same as a binary minus in arithmatic expressions. >>> >>> No

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Mon, 3 Feb 2014, Sven Barth wrote: Am 03.02.2014 12:04, schrieb Michael Van Canneyt: On Mon, 3 Feb 2014, Sven Barth wrote: Am 03.02.2014 08:58, schrieb Michael Van Canneyt: As for unary minus: this is the same as a binary minus in arithmatic expressions. Not quite. Take this example

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

Am 03.02.2014 12:04, schrieb Michael Van Canneyt: On Mon, 3 Feb 2014, Sven Barth wrote: Am 03.02.2014 08:58, schrieb Michael Van Canneyt: As for unary minus: this is the same as a binary minus in arithmatic expressions. Not quite. Take this example: === output end === So unary minus (and

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Mon, 3 Feb 2014, Sven Barth wrote: Am 03.02.2014 08:58, schrieb Michael Van Canneyt: As for unary minus: this is the same as a binary minus in arithmatic expressions. Not quite. Take this example: === output end === So unary minus (and also unary plus which is a valid operator as well!)

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

Am 03.02.2014 08:58, schrieb Michael Van Canneyt: As for unary minus: this is the same as a binary minus in arithmatic expressions. Not quite. Take this example: === code begin === program toppriotest; {$mode objfpc} {$modeswitch advancedrecords} type TTest = record i: Longint; cl

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

Am 03.02.2014 10:42, schrieb Hans-Peter Diettrich: // p:= -@i; // if enabled, next line will crash This should not compile, unary - is not applicable to addresses. It compiles, because Martin has defined a operator overload for PInteger (look at his code). And as long as no internal opera

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

Martin Frb schrieb: Further, it appears that ^ has a higher precedence than unary - IMO pointer/address arithmetic (should) follows its own rules. Unary - and @ should not be applicable to addresses. @ also is restricted to arguments which *do* have an address, i.e. not applicable to arithm

Re: [fpc-devel] function overload ?

On Mon, 3 Feb 2014, Gennadiy Poryev wrote: Hi! I had a dream :) Wouldn't it be nice if a function overload took care not only of formal parameter list (per docs) but also of result type? So the following may work function My(const a : Integer) : AnsiString; overload; function My(const a : I