Re: [fpc-pascal] Property Attributes

Am 02.05.2016 08:59 schrieb "Mazo Winst" : > > Hello, > > http://wiki.freepascal.org/Property_attributes. > > 1 - Is there any plans to merge the branch which contains the implementation of class attributes for the next release? The 3.0.x series won't contain this feature.

Re: [fpc-pascal] UnicodeString and surrogate pairs

Am 30.04.2016 08:24 schrieb "Michael Schnell" : > > On 04/29/2016 11:09 AM, Graeme Geldenhuys wrote: >> >> >> No, because UTF-8 doesn't use surrogate pairs. > > Really ? > > I understand that "surrogate pairs" is combining a printable character (i.e on of the nearly 2^32 UTF

Re: [fpc-pascal] FPC create unit path

On 27.04.2016 21:57, Graeme Geldenhuys wrote: > On 2016-04-27 20:39, Darius Blaszyk wrote: >> Is there a way to have FPC to create the requested >> folder? > > I asked the same thing years back, and I was told that no, it's not the > job of the compiler, but rather the job of the build script or

Re: [fpc-pascal] Class/Record helpers on genericd?

Am 25.04.2016 22:44 schrieb "Anthony Walter" : > > Sven, > > Correct me if I'm wrong, but didn't you add support for class/record helpers on generics? For example I'd like to be able to add methods to dynamic arrays: > > type > TArray = array of ; > TCompare =

Re: [fpc-pascal] Build in a C compiler

Am 20.04.2016 13:29 schrieb "Rainer Stratmann" : > > Am Mittwoch, 20. April 2016, 07:05:10 schrieb Mark Morgan Lloyd: > > No. Pascal and ALGOL are closely related, C and ALGOL are closely > > related. Pascal and C are not so closely related. > > As you can see here

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

Am 18.04.2016 07:58 schrieb "Jürgen Hestermann" : > And why was a directive implemented to use 0-based indices > even for strings but none for 1-based indices in dynamic arrays? > IMO the latter would be much more desired. The usual reason: Delphi compatibility. If

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

Am 15.04.2016 18:37 schrieb "Jürgen Hestermann" : > > Another advantage of having 1-based indeces in dyn. arrays > would be that you could store indeces in unsigned integers > while with 0-based indices high() may give -1. Indices in Pascal are always signed. Regards,

Re: [fpc-pascal] Error: Internal error 2014052302 on changing some common units

Am 15.04.2016 13:40 schrieb "Dennis" : > > whenever I change the source of a common unit (that is used by many other units), when I compile with lazarus 1.7 +FPC 3.1.1, this error will appear in the messages > "Error: Internal error 2014052302". Are you sure that you're

Re: [fpc-pascal] A better way?

Am 15.04.2016 13:58 schrieb "Ryan Joseph" : > > > > On Apr 15, 2016, at 5:13 PM, Tony Whyman wrote: > > > > unit unitA; > > > > interface > > > > type > > > > class TClassA > > private > > FClassBObject: TObject; > > public > >

Re: [fpc-pascal] A better way?

Am 15.04.2016 11:22 schrieb "Dennis" : > > >> > You could describe it as typecast done in the var clause of a method. The right hand identifier is not restricted to function parameters. >> >> While it works using "absolute" for a public API is rather unsafe (I'd only use

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

Am 15.04.2016 10:47 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > Is there also a switch > > {$OneBasedDynArrays On} ? > > No more confusion about first and last element index. > > You really should be using low() and high() instead. ;-) Definitely (and they also work for

Re: [fpc-pascal] A better way?

Am 15.04.2016 08:46 schrieb "Ryan Joseph" : > Does this look like more work than using $includes? Maybe I need to seriously considering reorganizing my projects to work like this but it just feels wrong for some reason. > > = > > unit Globals; >

Re: [fpc-pascal] A better way?

Am 15.04.2016 10:46 schrieb "Tony Whyman" : > > Ryan, > > If you want to get rid of (ugly) typecasts then maybe you should investigate the "absolute" keyword. You get a lot of examples in the LCL. For example, here's one I chose at random: > > function

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

Am 14.04.2016 23:22 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-04-14 19:27, Sven Barth wrote: > > We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is > > used (it's a local switch). > > Wow, learnt someth

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

On 14.04.2016 19:36, leledumbo wrote: >> Is there any chance to add a class like Delphi's TStringBuilder to FCL? It > would be very useful to port Delphi code libraries to Free Pascal. > > That exists mainly to overcome the read-only, 0-based string implementation > limitations in Delphi NextGen,

Re: [fpc-pascal] A better way?

Am 14.04.2016 10:45 schrieb "Ryan Joseph" : > > > > On Apr 14, 2016, at 3:02 PM, Tony Whyman wrote: > > > > Reading through your post, I hope that you are aware that most circular dependencies can be avoided by referencing other units

Re: [fpc-pascal] Initialization in Shared Libraries

On 13.04.2016 21:30, Mazola Winstrol wrote: > 2016-04-13 15:56 GMT-03:00 Jonas Maebe >: > > > And hence you can just initialise those variables in the > initialization section of the library and finalize them (if >

Re: [fpc-pascal] Implicit Operator Overloading

Am 10.04.2016 22:15 schrieb "Mazola Winstrol" <mazofei...@gmail.com>: > > 2016-03-07 3:53 GMT-03:00 Sven Barth <pascaldra...@googlemail.com>: >> >> Am 06.03.2016 22:09 schrieb "Mazola Winstrol" <mazofei...@gmail.com>: >> > >

Re: [fpc-pascal] FPC generated executables and digital signatures

Am 08.04.2016 13:20 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > Hi, > > I don't visit Windows much, but was doing some testing on a Win7 VM. > Every time I run my FPC generated executable I get a Security Warning > dialog pop up and it mentions a "Unknown Publisher", and I

Re: [fpc-pascal] Class vs Object type

Am 06.04.2016 16:28 schrieb "Dennis" : > > objects unit contains >TObject = OBJECT > CONSTRUCTOR Init; > PROCEDURE Free; > FUNCTION Is_Object(P:Pointer):Boolean; > DESTRUCTOR Done; Virtual; >END; > > > On the other hand, objpash.inc contains

Re: [fpc-pascal] Class vs Object type

Am 06.04.2016 13:23 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > Hi, > > I use Class and Object data types frequently in my code. I like the fact > that Object data types can be used without first instantiating an > instance and it gets freed automatically. Note: with the

Re: [fpc-pascal] Class vs Object type

Am 06.04.2016 14:06 schrieb "Tomas Hajny" : > > On Wed, April 6, 2016 13:26, Michael Van Canneyt wrote: > > On Wed, 6 Apr 2016, Graeme Geldenhuys wrote: > > Hi, > > >> I use Class and Object data types frequently in my code. I like the fact > >> that Object data types can be

Re: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more?

Am 04.04.2016 13:21 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-04-04 12:06, Michael Van Canneyt wrote: > > 1. Using UTF8 is a choice of lazarus. Other people may prefer UnicodeString. > > On Windows, UnicodeString is more 'natural' or 'native'. > > Based on

Re: [fpc-pascal] Class constructor called unconditionally

Am 31.03.2016 17:28 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-03-31 16:06, Michael Van Canneyt wrote: > > > I am guessing it comes from C++/Java/C#, which AFAIK do not have > > the 'initialization' section. But that's just a guess. > > [my personal opinion - feel

Re: [fpc-pascal] Class constructor called unconditionally

Am 31.03.2016 15:33 schrieb "silvioprog" : > After read this explanations, is there some compiler option to make FPC with this same Delphi behaviour? I'm using MODE DELPHI. No, there is not. Currently class constructors (and destructors) are called always. Regards, Sven

Re: [fpc-pascal] How to crosscompile i386-linux from X86_64-win64

Am 30.03.2016 10:39 schrieb "ulrich" <rom...@cbox.cz>: > > Dne 29.3.2016 v 12:19 Sven Barth napsal(a): >> >> Am 29.03.2016 10:30 schrieb "Jonas Maebe" >> <jonas.ma...@elis.ugent.be >> <mailto:jonas.ma...@elis.ugent.be>>: >>

Re: [fpc-pascal] History of the Cardinal data type?

Am 29.03.2016 17:27 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-03-29 16:13, Marco van de Voort wrote: > > Cardinal is the Wirthian designation for the default unsigned integer, > > just like "integer" is for signed. > > Thanks Marco, that fulfils my curiosity. :) > >

Re: [fpc-pascal] How to crosscompile i386-linux from X86_64-win64

Am 29.03.2016 10:30 schrieb "Jonas Maebe" : > > On 29/03/16 09:58, ulrich wrote: >> >> what parameter(s) need to cross-compiling i386-Linux from X86_64-win64 ? > > > It is not possible, because the needed 80 bits extended type is not supported on Win64, and we don't have

Re: [fpc-pascal] Mangle name in fpc-FreeBSD ?

Am 21.03.2016 13:57 schrieb "fredvs" : > > > Even on Win64 that would have been wrong as there TLibHandle is 64-bit as > well and it also defines MSWINDOWS. > > Hello Sven. > > I am unforgivable to not have seen that wrong declaration. > > And to not have deeply check code from

Re: [fpc-pascal] Mangle name in fpc-FreeBSD ?

Am 21.03.2016 00:33 schrieb "fredvs" : > > Aargh. > > Indeed, the declaration of variable for the library-handle was wrong. > And FreeBSD is more strait than Linux and Windows. Even on Win64 that would have been wrong as there TLibHandle is 64-bit as well and it also

Re: [fpc-pascal] Mangle name in fpc-FreeBSD ?

Am 20.03.2016 00:57 schrieb "fredvs" : > PS: This is a great victory who will solve (I hope) other library-related > problems. > PS2: Are there limitations of using dlsym() vs GetProcedureAdress() ? > PS3: If dlsym() is cross-platform too, should I update all my codes that use >

Re: [fpc-pascal] Mangle name in fpc-FreeBSD ?

Am 14.03.2016 16:16 schrieb "fredvs" : > > Hello. > > I have problem to access methods from a C library. > > For FreeBSD, the methods cannot be accessed (but ok for Linux and Windows). > > In FreeBSD, LoadLibrary(aac.so) is working but all GetProcAdress() for each > method fail.

Re: [fpc-pascal] Fpc 3.0 Bug: type specialization and operator overload

Am 12.03.2016 22:45 schrieb "Mazola Winstrol" : > > Hello, > > Fpc version: 3.0 (the one provided by Lazarus). > > Please confirm if this is a bug regarding operator overloading and type specialization. It is a quite difficult to explain, but i will try. > [snip] > > It seems

Re: [fpc-pascal] Primitive Record Wrappers

Am 11.03.2016 08:19 schrieb "Michael Van Canneyt" <mich...@freepascal.org>: > > > > On Fri, 11 Mar 2016, Sven Barth wrote: > >> Am 11.03.2016 04:16 schrieb "silvioprog" <silviop...@gmail.com>: >>> >>> >>> On

Re: [fpc-pascal] Primitive Record Wrappers

Am 11.03.2016 04:16 schrieb "silvioprog" : > > On Sun, Mar 6, 2016 at 7:21 PM, Mazola Winstrol wrote: > [...] >> >> Please see the code in attachments and send your suggestions / remarks. > > > Thanks for share. > > How do I use the the

Re: [fpc-pascal] CMem issue?

Am 08.03.2016 01:51 schrieb "silvioprog" : > > Hello, > > I got an AV in the CMem unit. To reproduce the problem just compile and run this code below: > > === code === > > program project1; > > {$mode delphi} > > uses > Classes, SysUtils, cmem; > [Snip] > === /code ===

Re: [fpc-pascal] Implicit Operator Overloading

Am 06.03.2016 22:09 schrieb "Mazola Winstrol" : > > Hello, > > Fpc: 3.0 > > Should the compiler to allow the definition of two operator overloading with the same parameters and diferent result types? > > e.g: > > code > > TMyRecord record > class operator

Re: [fpc-pascal] Fpc Bug: Type specialization with Generics and Operator Overloading in Diferent Units

Am 06.03.2016 19:55 schrieb "Mazola Winstrol" : > > Hello, > > Fpc version: 3.0 (the same included with lazarus 1.6). > > > Please confirm if it is a bug: > > If i declare a generic record with overloaded add operation, i need to specialize the type in the same unit for the

Re: [fpc-pascal] Fpc Bug 3.0: Generics and Operator Overloading

Am 06.03.2016 19:42 schrieb "Mazola Winstrol" : > > Hello, > > Fpc version: 3.0 (the one included with Lazarus 1.6). > > Please confirm if it is a bug: it seems the compiler doesn't handle operator overloading properly when using generic record with local specializations.

Re: [fpc-pascal] Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Am 06.03.2016 17:00 schrieb "Serguei TARASSOV" : > >> So in my taste the {$MODE DELPHI} should have been support not only > >> language > >> features but all common libraries too, at least RTL/DB. All FPC > >> extension/modifications could be added in FPC mode. Not easy but >

Re: [fpc-pascal] compile Link Smart option, is it -XX or -CX?

Am 03.03.2016 09:26 schrieb "Dennis" : > > According to http://www.freepascal.org/docs-html/prog/progse30.html > > the smartlink option on the command line is -CX > but in Lazarus ver 1.42, >Compilation and Linking > Linking > Link Smart is -XX They are

Re: [fpc-pascal] Access violation in an empty project declaring heaptrc

Am 03.03.2016 03:07 schrieb "silvioprog" : > Now, if you compile and run this project below with -gh: > > program project1; > > {$mode objfpc}{$H+} > > begin > end. > > You will get: > > Heap dump by heaptrc unit > 47 memory blocks allocated : 1173/1280 > 47 memory blocks

Re: [fpc-pascal] Primitive Record Wrappers

Am 01.03.2016 04:08 schrieb "Mazola Winstrol" : > Is there any way to overcome this? Is there any way to tell the compiler to ignore some operators depending on the specialization type? No, there is not. Better not use operators other than the assignment ones or provide

Re: [fpc-pascal] Primitive Record Wrappers

Am 29.02.2016 16:13 schrieb "Mazola Winstrol" : > > I have noticed that, by using generics, we can't overload arithmetic operators. > > E.g.: > > ... > class operator Negative(A: TNullableType): T; > ... > > class operator TNullableType.Negative(A: TNullableType): T; > begin

Re: [fpc-pascal] Primitive Record Wrappers

Am 27.02.2016 09:36 schrieb "Maciej Izak" : > > 2016-02-27 4:38 GMT+01:00 Mazola Winstrol : >> >> In the code bellow, the generic type TNullableTyple is implemented (and incomplete for now). >> > > It can be done more optimal with incoming operators

Re: [fpc-pascal] Codepage + class helper raises "Error identifier idents no member ..."

Am 26.02.2016 20:31 schrieb "silvioprog" : > > Hello, > > Consider the following code: > > === code === > > program project1; > > {$mode objfpc}{$H+} > //{$codepage utf8} > > uses Classes; > > type > TFoo = class helper for TStream > public > procedure Bar; > end; >

Re: [fpc-pascal] Include directive for current procedure/method/function name?

Am 26.02.2016 01:35 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-02-26 00:15, Graeme Geldenhuys wrote: > > Anybody know if there is something like that in FPC? > > No worries, found it. Seems Thunderbird doesn't search as well as > Firefox. ;) > > > I was looking for

Re: [fpc-pascal] Building FPC for Windows X64

Am 25.02.2016 12:19 schrieb "Justin Smyth" : > When I try to build lazarus it fails , yet it I build the i386-win32 copy it works fine – its not lazarus it’s the copy of fpc I have created as I get the same error on a older copy of lazarus ( 1.2.6 as an example) Since

Re: [fpc-pascal] Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Am 25.02.2016 02:00 schrieb "Mr Bee" : > Maybe FPC devs should give us the "rule" or policy about what kind of change that is acceptable and not acceptable. So when we think of something new we could look at the rule and if it's doesn't comply then we don't need to bother to

Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Am 24.02.2016 16:44 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > Bo Berglund wrote: >> >> On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth >> <pascaldra...@googlemail.com> wrote: >>> >>> What

Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Am 24.02.2016 12:30 schrieb "Bo Berglund" <bo.bergl...@gmail.com>: > > On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth > <pascaldra...@googlemail.com> wrote: > > > >What would really help here would be the warning that Jonas mentioned... > >

Re: [fpc-pascal] Compiler Mode?

Am 24.02.2016 13:10 schrieb "Maciej Izak" : > > 2016-02-24 12:48 GMT+01:00 Anthony Walter : >> >> On another forum a Free Pascal user opined that {$MODE DELPHI} is wrong and should not be used other than for people or companies trying to convert Delphi code to

Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Am 23.02.2016 23:28 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > Serguei TARASSOV wrote: > >> There is no perfect way so why the language extension is the safest >> (remember recent discussion about IfThen pseudo-function). > > > More relevant to your situation, I

Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

On 23.02.2016 17:21, Serguei TARASSOV wrote: > Michael Van Canneyt wrote >> I hope you will send the same mail to embarcadero/Idera. >> When they added methods to TPoint, they broke have the VCL code ? >> >> To avoid this, we would need to freeze the code as soon as it is released. > > Compared

Re: [fpc-pascal] Android porting ideas

Am 21.02.2016 19:36 schrieb "Michalis Kamburelis" : > > > > 1) All the file I/O in the FPC RTL is not available so what possible work arounds are there for loading data from files? > > Actually, all the IO in FPC works perfectly. You can read / write > files just like on

Re: [fpc-pascal] Primitive Record Wrappers

Am 21.02.2016 03:02 schrieb "Mazola Winstrol" : > > 2016-02-20 3:24 GMT-02:00 Michalis Kamburelis : >> >> The major problem there is that it's difficult to force it to be >> always initialized with zeroes. Currently, a non-global variable of >>

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

Am 20.02.2016 08:55 schrieb "Maciej Izak" : > > Notifications events already works in Generics.Collections. ;P > Which reminds me that I wanted to work on integrating them... Regards, Sven ___ fpc-pascal maillist -

Re: [fpc-pascal] Primitive Record Wrappers

Am 20.02.2016 06:25 schrieb "Michalis Kamburelis" : > I remember a thread on fpc-devel "Pascal Smart Pointers Idea + ARC > implementation" where the original author (Maciej Izak) was already > working to overcome this: >

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

Am 19.02.2016 20:47 schrieb "silvioprog" <silviop...@gmail.com>: > > On Fri, Feb 19, 2016 at 4:20 PM, Sven Barth <pascaldra...@googlemail.com> wrote: > [...] > >> It doesn't matter whether it is requested over here or on Mantis. I'm against adding not

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

Am 19.02.2016 14:45 schrieb "silvioprog" <silviop...@gmail.com>: > > On Fri, Feb 19, 2016 at 10:24 AM, Sven Barth <pascaldra...@googlemail.com> wrote: >> >> Am 19.02.2016 12:45 schrieb "silvioprog" <silviop...@gmail.com>: >> >

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

Am 19.02.2016 12:45 schrieb "silvioprog" : > > Hello, > > I have a friend here in Brazil that added the `notify` support to the FGL lists, however he sented it to this Github PR [1]. I'm against that. That would negatively impact the performance of these lists. Regards,

Re: [fpc-pascal] Please someone explain this to me

Am 11.02.2016 00:23 schrieb "Anthony Walter" : > > For those who didn't understand what I meant by using regions in the interface section rather than include files, here is an image of what is essentially in SysUtils currently: > >

Re: [fpc-pascal] Please someone explain this to me

Am 11.02.2016 11:41 schrieb "Anthony Walter" : > > > This won't be changed. Period. > > Sven, not to be argumentative, but you do get that for a long time programmers have learned how to write code and use libraries by examining them? My goal is simply to make it easier for the

Re: [fpc-pascal] Please someone explain this to me

Am 10.02.2016 15:55 schrieb "Juha Manninen" <juha.mannine...@gmail.com>: > > On Wed, Feb 10, 2016 at 4:09 PM, Sven Barth <pascaldra...@googlemail.com> wrote: > > What about include files included by other include files? > > Ok, that is a nasty situation

Re: [fpc-pascal] Please someone explain this to me

Am 10.02.2016 21:03 schrieb "Anthony Walter" : > But to ask again, what's the purpose of using include files for the interface section of units when most everything in the interface sections remain unchanged among different platforms? Surely we can move all those the parts back

Re: [fpc-pascal] Please someone explain this to me

Am 10.02.2016 11:11 schrieb "Anthony Walter" : > > Marc, > > Your suggestions only work if a unit declaring the function is in your uses clauses. In the scenario I described that is clearly not the case. > > Additionally, and in a different scenario, when the identifier IS

Re: [fpc-pascal] Please someone explain this to me

Am 10.02.2016 00:32 schrieb "Ralf Quint" : > > On 2/9/2016 2:58 PM, Anthony Walter wrote: >> >> I really don't like the include files with Lazarus and Free Pascal for the following reason: >> >> How the am I supposed to know which file is including an include file? >> >>

Re: [fpc-pascal] IfThen() intrinsic removed

Am 05.02.2016 10:46 schrieb "Lukasz Sokol" : > > On 05/02/16 09:22, Lukasz Sokol wrote: > > Hi, > > > > On 04/02/16 21:33, Michael Van Canneyt wrote: > >> > >> > >> On Thu, 4 Feb 2016, Felipe Monteiro de Carvalho wrote: > >> > >>> Disappointed :( > >> > >> Well, such is life.

Re: [fpc-pascal] Ararat Synapse UDP Rx Speed (Mbps)

Am 05.02.2016 09:42 schrieb "Jonas Maebe" : > > > > On 04 Feb 2016, at 23:36, Brian wrote: > > > > A test with two Linux (Ubuntu 14.04) PC's each with a 1Gbps NIC , with one PC > > sending 300byte packets directly to the other PC (no switch involved) .

[fpc-pascal] IfThen() intrinsic removed

Hello together! The IfThen() intrinsic has been removed again. There will be *no* replacement in the foreseeable future. This is not up for discussion. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] if-then-else expression

Am 03.02.2016 12:11 schrieb "Serguei TARASSOV" : > > On 03/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote: >> >> Date: Tue, 2 Feb 2016 19:43:02 -0700 (MST) >> From: silvioprog >> >> >>> >The problem with Iff() is:1) it either retains normal

Re: [fpc-pascal] if-then-else expression

On 02.02.2016 10:25, Michael Schnell wrote: > On 02/01/2016 09:35 PM, Maciej Izak wrote: >> >> >> x := if true then 0 else 1 > > Here a keyword and a statement just optionally returns a value, Same is > ignored in all legacy code but can be use it you want to and do know > what you do. > >

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 15:39 schrieb "Serguei TARASSOV" <se...@arbinada.com>: > > On 02/02/2016 15:16, fpc-pascal-requ...@lists.freepascal.org wrote: >> >> Date: Tue, 2 Feb 2016 14:36:25 +0100 >> From: Sven Barth<pascaldra...@googlemail.com> >> >>

Re: [fpc-pascal] if-then-else expression

On 02.02.2016 20:22, John Lee wrote: > So (Sven) to clarify, assume that your original ifthen [patch is now in > latest svn compiler although more work will needed to do x:=if a then b > else c;? j The IfThen() is in trunk though it will at least be renamed. The if-then-else expression would in

Re: [fpc-pascal] if-then-else expression

Am 02.02.2016 22:51 schrieb "geneb" : > > On Tue, 2 Feb 2016, Dmitry Boyarintsev wrote: > >> On Tue, Feb 2, 2016 at 4:40 PM, geneb wrote: >> >>> So it's not solving a /problem/ it's lessening an inconvienence(sp!). >>> >>> I would've gone with IIf(). :)

Re: [fpc-pascal] Error compiling FPC trunk under Linux

On 02.02.2016 19:12, Fabio Luis Girardi wrote: > > > 2016-02-02 16:07 GMT-02:00 Jonas Maebe >: > > > What is the version of your starting compiler? > > > 3.1.1 revision 32800. I don't remember the revision the compiler that >

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 11:12 schrieb "Serguei TARASSOV" : > > On 02/02/2016 10:54, fpc-pascal-requ...@lists.freepascal.org wrote: > >> On Tue, 2 Feb 2016, Michael Van Canneyt wrote >>> >>> >>> On Tue, 2 Feb 2016, Serguei TARASSOV wrote: > No, the second is always better because safer.

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 08:34 schrieb "Anthony Walter" : > > Sven, > > I missed this post when you made it a two days ago. If someone hasn't already asked, does your implementation support short circuit evaluation? > > For example: > > BasketCount := IfThen(ShoppingList <> nil,

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 10:20 schrieb "Felipe Monteiro de Carvalho" < felipemonteiro.carva...@gmail.com>: > > If other people already use "iif" then maybe it is better to use the same name? > > Also I vaguely remember at least a few functions in existing code > named IfThen which would conflict with the new

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 10:41 schrieb "Serguei TARASSOV" : > > On 02/02/2016 10:29, fpc-pascal-requ...@lists.freepascal.org wrote: >> >> 2016-02-01 10:59 GMT+01:00 Michael Schnell: >> Same here. I see no reason to differ from it. Introducing new >> incompatibility is

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 11:27 schrieb "Michael Van Canneyt" : > > > > On Tue, 2 Feb 2016, Serguei TARASSOV wrote: > >> On 02/02/2016 10:54, fpc-pascal-requ...@lists.freepascal.org wrote: >> >>> On Tue, 2 Feb 2016, Michael Van Canneyt wrote On Tue, 2 Feb 2016, Serguei

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 10:38 schrieb "Marco van de Voort" : > > - I like ;) > > I don't see the point. And if a funky character is needed then use another > one, don't add a third overload to &. (statement to intrinsic instead of > statement to identifier and octal) He meant to use "if"

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 16:11 schrieb "Martin" <f...@mfriebe.de>: > > On 02/02/2016 13:24, Sven Barth wrote: >> >> >> > Look at the "iif" as an statement and the things will be simple. >> >> BECAUSE. IT. IS. *NOT*. A. STATEMENT! >> It ne

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 11:42 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > Michael Van Canneyt wrote: > >> Call me old fashioned, but then I think >> foo:=iif(Condition1, >>iif(Condition2, ThenExpr1, ElseExpr1), >>iif(Condition3, ThenExpr2, ElseExpr2)); >>

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 13:38 schrieb "Andreas Berger" : > > > On Tue 02/02/2016 09:27, Jonas Maebe wrote: >> >> >> The parameter evaluation order issue is irrelevant in this context: Delphi guarantees left-to-right (or used to anyway, this may have changed), FPC doesn't guarantee

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 13:51 schrieb "Serguei TARASSOV" : > > On 02/02/2016 13:41, fpc-pascal-requ...@lists.freepascal.org wrote: >> >> Date: Tue, 02 Feb 2016 10:32:28 -0200 >> From: Andreas Berger >> >> >> On Tue 02/02/2016 09:27, Jonas Maebe wrote: >>> >>> >

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 02.02.2016 13:56 schrieb "Serguei TARASSOV" : > > On 02/02/2016 13:41, fpc-pascal-requ...@lists.freepascal.org wrote: >> >> Date: Tue, 02 Feb 2016 13:22:01 +0100 >> From: Jonas Maebe >> >> Michael Van Canneyt wrote on Tue, 02 Feb 2016: >> >>

Re: [fpc-pascal] New feature: IfThen() intrinsic

On 01.02.2016 20:33, Marcos Douglas wrote: > On Mon, Feb 1, 2016 at 5:06 PM, David Butler wrote: >> Speaking personally, the reason why I like Pascal syntax over C is exactly >> because it isn't short. I prefer the verbosity of Pascal rather than >> "cryptic" syntax of the C

Re: [fpc-pascal] New feature: IfThen() intrinsic

On 01.02.2016 20:50, Dmitry Boyarintsev wrote: > On Mon, Feb 1, 2016 at 2:47 PM, Sven Barth <pascaldra...@googlemail.com > <mailto:pascaldra...@googlemail.com>> wrote: > > If we would go the route of such an if-expression instead of an > intrinsic then just leav

Re: [fpc-pascal] if-then-else expression

On 01.02.2016 21:14, Sven Barth wrote: > Hello together! > > Time for the next flame. I've attached a patch which implements an "if > Condition then ThenExpr else ElseExpr"-expression for those that want to > play around with it. It follows the same principles as the &

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 01.02.2016 09:26 schrieb "Maciej Izak" : > > 2016-02-01 8:59 GMT+01:00 Marco van de Voort : >> >> The only really bad thing is the name, as Florian already said, with the >> versions in strutils and math. The clash with delphi compatible functions >> should

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 01.02.2016 09:35 schrieb "David Butler" : > > This is usually called "inline if". > > Maybe call it "inlineif" or "iif", e..g > > x := iif (a < 3, 1, 2) > > or even > > x := iif a < 3 then 1 else 2; I personally would have preferred "if a < 3 then 1 else 2", but a

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 01.02.2016 11:21 schrieb "Alexandrov Alexandru" < alexandru.alexand...@gmail.com>: > > IIf or IfThen (I opt for IIf) are trivial functions. The result of the Math function must be the same as the System ones. Why do you care which one apply? Because there is a semantic difference. The new

Re: [fpc-pascal] New feature: IfThen() intrinsic

On 01.02.2016 21:02, silvioprog wrote: > On Mon, Feb 1, 2016 at 4:47 PM, Sven Barth <pascaldra...@googlemail.com > <mailto:pascaldra...@googlemail.com>> wrote: > > On 01.02.2016 20:33, Marcos Douglas wrote: > > On Mon, Feb 1, 2016 at 5:06 PM, Da

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 01.02.2016 13:29 schrieb "Michael Van Canneyt" : > > > > On Mon, 1 Feb 2016, Maciej Izak wrote: > >> 2016-02-01 13:09 GMT+01:00 Michael Van Canneyt : >>> >>> >>> No. The compiler already uses &. >>> >>> & means 'the following is an identifier even

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 01.02.2016 15:58 schrieb "Maciej Izak" <hnb.c...@gmail.com>: > > 2016-02-01 15:42 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: >> >> Maciej is in so far right that the intrinsic could indeed be named "if" and the only way to call it woul

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 01.02.2016 16:07 schrieb "Michael Van Canneyt" <mich...@freepascal.org>: > > > > On Mon, 1 Feb 2016, Sven Barth wrote: > >>> >>> And modifying the scanner for this exception is a REALLY bad idea. >> >> >> Maciej is in so far

Re: [fpc-pascal] New feature: IfThen() intrinsic

Am 01.02.2016 17:00 schrieb "silvioprog" : > > On Mon, Feb 1, 2016 at 12:48 PM, leledumbo wrote: >> >> > Looks good and clever. Logical choice. How often you have variables with & >> prefix? >> >> Only when I use ORM with automapping of properties

Re: [fpc-pascal] New feature: IfThen() intrinsic

On 31.01.2016 16:14, Vojtěch Čihák wrote: > what is difference in produced assembler between ifthen(); and classic > if - then - else? === code begin === i := IfThen(x < 42, 32, 49); === code end === is equivalent to === code begin === if x < 42 then i := 32 else i := 49; === code end

Re: [fpc-pascal] New feature: IfThen() intrinsic

On 31.01.2016 16:09, silvioprog wrote: > Wooow! I did a request about it many years ago, however it was rejected > because the limitation in the generic feature at that time. This implementation has nothing to do with generics. It's a compiler magic function, just like Writeln() and thus it can

<    9   10   11   12   13   14   15   16   17   18   >