Re: [fpc-devel] Aligned dynamic arrays

Ryan Joseph schrieb am Do., 28. März 2019, 03:01: > Here’s the basic structure: > > [header][padding][offset][head] > > [head] being the start of the elements (the pointer to the first element > of the array) and aligned to the requested amount. Keep in mind the head is > the pointer which is

Re: [fpc-devel] Aligned dynamic arrays

Am 28.03.2019 um 15:17 schrieb Ryan Joseph: Also I don't think that a simple "do alignment or not" will be sufficient. What kind of alignment do you pick? What if the user needs more alignment? So it would probably be best to add a new SetLengthAligned of which the second argument is the

Re: [fpc-devel] Aligned dynamic arrays

Am 28.03.2019 um 18:41 schrieb Ryan Joseph: Now I’m using “cd /rtl; make all FPC=/path/to/compiler” to build the RTL but this is obviously slow and unnecessary. Is there a quicker way to build just the unit which contains dynarr.inc and have all the objects files to be put in the correct

Re: [fpc-devel] Implicit cast from Char/String to array of Char

Am 25.02.2019 um 08:09 schrieb Ondrej Pokorny: Hello! Implicit cast from Char/String to array of Char: is this a wanted behavior or is it a compiler bug? (Btw. MODE DELPHI behaves the same). program Project1; {$mode objfpc}{$H+} procedure A(AC: array of Char); var   C: Char; begin   for C

Re: [fpc-devel] Good timing metric test program?

J. Gareth Moreton schrieb am Mo., 25. Feb. 2019, 19:14: > The compiler isn't a valid case because the input source is different > (because of the very changes made to said compiler). It needs to be a > project that doesn't share anything with the compiler (except the run-time > libraries), so

Re: [fpc-devel] Getting built-in string type

Am 28.02.2019 um 03:11 schrieb Ryan Joseph: Sending this again to see if it gets through (posts getting blocked again). On Feb 26, 2019, at 2:43 PM, Ryan Joseph wrote: In my implicit generic specialization code I have one place where I get a string const node (stringconstn) which the

Re: [fpc-devel] "Blank slate" next version of FPC

Am Mi., 20. Feb. 2019, 12:07 hat Nikolai Zhubr geschrieben: > So I'm just wondering, what is wrong with such approach that it is > considered so harmfull for Pascal? (Not talking here about possible > excessive complexity of actual implementation in compiler, and not > talking about the exact

Re: [fpc-devel] "Blank slate" next version of FPC

Am 22.02.2019 um 07:06 schrieb Paul van Helden: On Fri, Feb 22, 2019 at 2:35 AM Ben Grasset > wrote: On Sat, Feb 16, 2019 at 5:44 PM Benito van der Zander mailto:ben...@benibela.de>> wrote it can turn out the enumerators are slower than an old

Re: [fpc-devel] Regressions on i386-win32 and x86_64-win64

Am 02.03.2019 um 22:57 schrieb J. Gareth Moreton: Hi Nikolai, I don't even know the testsuite URL myself - I just run the regression tests as found under "fpc/tests", which is fairly public given there's a readme file there explaining how to run them. Nikolai is talking about the result

Re: [fpc-devel] "Blank slate" next version of FPC

Am Mi., 20. Feb. 2019, 20:45 hat gabor geschrieben: > W dniu 2019-02-16 o 23:37, Benito van der Zander pisze: > > So are inline variables coming soon? > > > http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html > > Who cares ininline variables since we do not have dynamic

Re: [fpc-devel] Successful implementation of inline support forpure assembler routines on x86

Martok schrieb am So., 17. März 2019, 21:47: > Am 17.03.2019 um 18:57 schrieb Florian Klämpfl: > > How is it better than intrinsics support (similiar to gcc/icc etc.)? > It *exists*? > > Remember how long it took to get PopCnt support? How about the rest of the > BMI? > TBM? AES-NI? Newer AVX? >

Re: [fpc-devel] TRegistry and Unicode

Bart schrieb am Do., 14. März 2019, 19:34: > On Wed, Mar 13, 2019 at 6:43 PM Bart wrote: > > > That was the easy part. > > TXMLRegistry does not seem to support Int64. > Any reason for that? > > If it's an oversight (support for that was only recently added for > Windows) should I try and

Re: [fpc-devel] Typed constants

Ryan Joseph schrieb am Mo., 18. März 2019, 00:50: > I just realized that typed constants exist and may need to be supported as > constants for generics but I’ve never used them myself (not sure when they > were introduced). > > First test gives an error so it makes me wonder if they’re buggy and

Re: [fpc-devel] Successful implementation of inline supportforpureassembler routines on x86

J. Gareth Moreton schrieb am So., 17. März 2019, 23:27: > I think one of the main issues with intrinsics is that you don't have much > control over where results are stored. Unless you're chaining a load of > intrinsics together in a mess of function calls in actual parameters, the > result is

Re: [fpc-devel] Successful implementation of inline support forpureassembler routines on x86

J. Gareth Moreton schrieb am So., 17. März 2019, 22:26: > I do have a slight concern when it comes to intrinsic support, because > support will be needed to be added for all platforms, (virtually) all > instructions and tested to see if they expand into the expected > instruction, along with

Re: [fpc-devel] Publish some of FPC's internal cross-platform functionality

Am 10.03.2019 um 11:43 schrieb Anton Shepelev: Michael Van Canneyt to Anton Shepelev: Thank you, but how do I translate the return value of GetLastOSError into a value of InOutRes? The translation functions are privately implemented in sysos.inc . You can copy them. It is open source, after

Re: [fpc-devel] Publish some of FPC's internal cross-platform functionality

Anton Shepelev schrieb am Sa., 9. März 2019, 18:09: > It would relieve the programmer of writing conditionally > compiled OS-specific code sections for such basic operations > as are already implemented in FreePascal's internals. I, > for example, have to do it whenever my Windws/Unix program >

Re: [fpc-devel] Publish some of FPC's internal cross-platform functionality

Anton Shepelev schrieb am Mo., 11. März 2019, 15:12: > Sven Barth to Anton Shepelev: > > >>Since we already have cross-platform functions FileRead > >>and FileWrite, would not it be useful to have them set the > >>InOutRes variable, or to publish a facility for converting > >>the value of

Re: [fpc-devel] TRegistry and Unicode

Am 15.03.2019 um 00:04 schrieb Bart: On Wed, Mar 13, 2019 at 6:43 PM Bart wrote: That was the easy part. Since all values written are now UnicodeString, WriteStringList in XMLREG implementation now writes a sequence of UnicodeChar representations to the registry. Previously it wrote

Re: [fpc-devel] Question about packages

Am 16.03.2019 um 01:14 schrieb J. Gareth Moreton: Hi everyone, This might be a painfully basic question, but I'm just trying to get to grips with the difference between Lazarus packages and FPC packages.  How do FPC packages work normally and what's their relation to Lazarus packages? I

Re: [fpc-devel] FPDoc - TH is a row-level tag?

Michael Van Canneyt schrieb am Fr., 22. März 2019, 09:20: > > > > If it's not by design, there are a grand total of 15 files XML files in > > both FPC and Lazarus that use the TH tag. So, not a big issue to fix in > XML > > source. > > Probably not. > Though we don't know how many third party

Re: [fpc-devel] Closures repo

Ryan Joseph schrieb am Do., 21. März 2019, 22:43: > > > > On Mar 21, 2019, at 5:01 PM, Blaise Thorn wrote: > > > > Thursday, March 21, 2019 11:48 PM +03:00 from Ryan Joseph < > r...@thealchemistguild.com>: > >> Then maybe he’ll hear this and respond. > > > > I just did. > > Oh, you’re the

Re: [fpc-devel] Suspicion about TThread.Synchronize

Am Mi., 6. Feb. 2019, 18:45 hat Luca Olivetti geschrieben: > El 6/2/19 a les 17:05, Sven Barth via fpc-devel ha escrit: > > Am Mi., 6. Feb. 2019, 11:27 hat Luca Olivetti > <mailto:l...@ventoso.org>> geschrieben: > > > > Of course I cannot reproduce the

Re: [fpc-devel] Suspicion about TThread.Synchronize

Am Mi., 6. Feb. 2019, 11:27 hat Luca Olivetti geschrieben: > Of course I cannot reproduce the issue with a simpler test program :-/ > Without a way to test it I can't do anything. So either you need to find the issue yourself or you need to manage to create a simpler example. Regards, Sven >

Re: [fpc-devel] "Blank slate" next version of FPC

Am Sa., 16. Feb. 2019, 23:44 hat Benito van der Zander geschrieben: > > > but we try as much as possible to break old code. > > > I have noticed that. All my code has been broken by the codepage aware > strings and TEncoding > Introduction of the codepage aware AnsiString was one of the

Re: [fpc-devel] "Blank slate" next version of FPC

Am Fr., 15. Feb. 2019, 10:07 hat James via fpc-devel < fpc-devel@lists.freepascal.org> geschrieben: > I'm interested in starting (or joining) a discussion on the next (*non* > backwards compatible) version of FPC. Instead of being classically object > oriented, there is merit in examining a model

Re: [fpc-devel] commits for merging to 3.2 ?

Am Mo., 11. Feb. 2019, 15:13 hat Marco van de Voort < c...@pascalprogramming.org> geschrieben: > Op 2/11/2019 om 2:38 PM schreef Sven Barth via fpc-devel: > > > If Sven says to merge them, I will. >> > > If the testsuite isn't saying otherwise you have a green li

Re: [fpc-devel] "Blank slate" next version of FPC

Am Sa., 16. Feb. 2019, 09:58 hat Michael Van Canneyt geschrieben: > > > On Sat, 16 Feb 2019, J. Gareth Moreton wrote: > > > Hm, fair enough. Seems a bit strange to not like a new feature, although > > Delphi did start getting a bit bloated in places. Ah well! > > Compatibility is never a bad

Re: [fpc-devel] "Blank slate" next version of FPC

Am 19.02.2019 um 11:12 schrieb George Bakhtadze: Also third party library developers suffering from absence of a dependency manager (yes, I'm aware of Online Package Manager). Recently was started a project of such tool. But it's initiator doesn't use FPC so FPC compatibility for it will have

Re: [fpc-devel] "Blank slate" next version of FPC

Am Mi., 20. Feb. 2019, 08:36 hat Paul van Helden geschrieben: > and FPC's goal to remain Delphi-compatible. >>> >>> >>> So are inline variables coming soon? >>> http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html >>> >> >> We have already decided internally that this

Re: [fpc-devel] commits for merging to 3.2 ?

Am Mo., 11. Feb. 2019, 10:07 hat Marco van de Voort < c...@pascalprogramming.org> geschrieben: > > Op 2/10/2019 om 9:47 PM schreef Martin: > > I am not sure if there is a place for the indent to merge (or absent > > thereof) can be checked? > > > > Once merged, the svn log, but before? Will the

Re: [fpc-devel] Detecting SSE and AVX compiler options

Am So., 3. Feb. 2019, 07:28 hat J. Gareth Moreton geschrieben: > As an example of a function that can benefit from a speed-up under > x86_64... the floor() and floor64() functions: > > function floor64(x: float): Int64; > begin > Result:=Trunc(x)-ord(Frac(x)<0); > end; > Please keep in

Re: [fpc-devel] Detecting SSE and AVX compiler options

Am So., 3. Feb. 2019, 18:29 hat J. Gareth Moreton geschrieben: > To reassure, I'm aware that "float" is normally "extended" outside of > x86_64, and I would keep my changes constrained to that platform. > This statement is not correct: the default floating point type for nearly all of FPC's

Re: [fpc-devel] Detecting SSE and AVX compiler options

Am Mo., 4. Feb. 2019, 14:15 hat J. Gareth Moreton geschrieben: > Oh right, okay, so x86_64-win64 is Double (even though Extended is > supported), but other x86_64 platforms are Extended, right? A little bit > odd, but I'll keep an eye out in that case. > Correct. Though Extended is not

Re: [fpc-devel] class operator overloads

Am 16.04.2019 um 22:59 schrieb Ryan Joseph: On Apr 16, 2019, at 4:51 PM, Sven Barth via fpc-devel wrote: It's the same problem there. The thing however is that FPC's operator overloading support is quite old (compared to Delphi's) and it's possible that it is even older than the support

Re: [fpc-devel] class operator overloads

Am 16.04.2019 um 18:21 schrieb Ryan Joseph: Nagging question I had that I would like answered. I was told that we can’t have operator overloads on classes (only records) because there is a potential temporary class that could be created and thus some kind of automatic memory management would

Re: [fpc-devel] Operator overloading and {$mode delphi}

On 4/13/19 11:28 PM, Bart wrote: > Hi, > > This example is taken from the documentation: > https://www.freepascal.org/docs-html/ref/refse103.html > > {$mode delphi} //compiles in {$mode objfpc} or {$mode fpc} > {$h+} > > Type > TMyRec = record a,b : integer; end; > > operator = (x,y :

Re: [fpc-devel] Successful implementation of inline support for pure assembler routines on x86

J. Gareth Moreton schrieb am Fr., 15. März 2019, 12:33: > P.S. Though this feature can be used for implementing intrinsics, it is > not a direct replacement for them because instructions like SHUFPS cannot > be flexibly encoded due to its immediate operand (i.e. it has to be a raw > number... it

Re: [fpc-devel] Building from source...

Kevin Lyda schrieb am Mo., 13. Mai 2019, 02:20: > I note that there's a git mirror hosted at > https://github.com/graemeg/freepascal which is kept up to date (last > commit, 17 minutes ago). I want to use it to do two things - first to > test a proposed patch and second on my own systems to

Re: [fpc-devel] Class management operators

Ryan Joseph schrieb am Fr., 24. Mai 2019, 22:26: > > > > On May 24, 2019, at 1:17 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > This is not desired, because it would mean that for *all* assignments > between *any* cl

Re: [fpc-devel] Class management operators

Ryan Joseph schrieb am Sa., 25. Mai 2019, 19:55: > > > > On May 24, 2019, at 2:46 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > Object Pascal isn't a full ARC language however. Also it is not > something that one can enable o

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am So., 26. Mai 2019, 17:05: > > > > On May 24, 2019, at 4:49 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > Please don't. They're legacy types (even though we don't consider them > obsolete

Re: [fpc-devel] When will the next version of FPC be released?

Am 02.06.2019 um 16:39 schrieb Ryan Joseph: I just tried to declare these 2 procedures in 3.3.1 and got an error. You can declare them in the reverse order with no problem. A bug? generic procedure DoThis(msg: T); begin end; procedure DoThis(msg: TObject); // Overloaded identifier "DoThis"

Re: [fpc-devel] Standard generic classes

J. Gareth Moreton schrieb am Di., 4. Juni 2019, 22:40: > Hi everyone, > > I may be missing the obvious here, but I've noticed that there are some > notable absences in the Free Generics Library. While there's a standard > list and a map and the like, there aren't any of the special lists like >

Re: [fpc-devel] Standard generic classes

J. Gareth Moreton schrieb am Mi., 5. Juni 2019, 14:27: > Still, saying all that, maybe there's room for improvement in rtl-generics > in the form of refactoring, like I've found in the compiler itself in a few > places. When you say 'heavyweight', do you mean it's a little slow > sometimes or

Re: [fpc-devel] Standard generic classes

J. Gareth Moreton schrieb am Mi., 5. Juni 2019, 11:54: > Hah, oh that sounds fun! > > I would develop something more lightweight and efficient, but that would > just make a 4th poison to choose from. > As Ben mentioned there is also LGenerics which is a third party library, so there already is

Re: [fpc-devel] Standard generic classes

J. Gareth Moreton schrieb am Mi., 5. Juni 2019, 14:52: > Sounds fair. I would be trying for a refactoring approach, in that the > API and outward behaviour is identical to before (i.e. a black box), but > the inner workings are better. I noticed that one potential source of > improvement is

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

Am 07.06.2019 um 22:45 schrieb Ryan Joseph: On Jun 7, 2019, at 3:50 PM, Sven Barth via fpc-devel wrote: generic procedure MemCopy(Dest, Src: specialize TPointerType.PT; Len: PtrUInt); begin while Len > 0 do begin Dest^ := Src^; Inc(Dest); Inc(

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

Am 07.06.2019 um 22:54 schrieb Ryan Joseph: On Jun 7, 2019, at 4:51 PM, Sven Barth via fpc-devel wrote: It has been part of FPC from the beginning of generics. It allows the parser to differentiate easier that a specialization is following. This was less important when only type

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

Am 07.06.2019 um 21:06 schrieb Ben Grasset: On Fri, Jun 7, 2019 at 2:35 PM Jonas Maebe > wrote: None of these can be defined as a type in parameter lists. Keep in mind that "^Type" defines a new type. Semantically, it's at the same level as

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

Am 07.06.2019 um 18:37 schrieb Ben Grasset: For example, consider the following code, that implements a generic "memcpy"-style procedure using a static advanced-record method: program Example; {$mode Delphi} type   TMem = record   public type     PT = ^T;   public     class procedure

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

Am 07.06.2019 um 23:17 schrieb Ryan Joseph: On Jun 7, 2019, at 5:06 PM, Sven Barth via fpc-devel wrote: No. The generic keywords are part of mode ObjFPC. The only thing I plan to do is to move the whole idea of generic keywords to a modeswitch, but that is neither here nor there currently

Re: [fpc-devel] Postfix operator overload or default properties

Am 07.06.2019 um 22:41 schrieb Ryan Joseph: Does that make sense? I’d like to scratch the idea of default properties and do this instead if it was permitted. No. FPC is not going down that operator madness. Regards, Sven ___ fpc-devel maillist -

Re: [fpc-devel] Postfix operator overload or default properties

Am 07.06.2019 um 22:50 schrieb Ryan Joseph: On Jun 7, 2019, at 4:47 PM, Sven Barth via fpc-devel wrote: Am 07.06.2019 um 22:41 schrieb Ryan Joseph: Does that make sense? I’d like to scratch the idea of default properties and do this instead if it was permitted. No. FPC is not going down

Re: [fpc-devel] Postfix operator overload or default properties

Am 07.06.2019 um 23:06 schrieb Ryan Joseph: On Jun 7, 2019, at 4:56 PM, Sven Barth via fpc-devel wrote: Because I don't want to open the can of worms that is going to be overloading the postfix "operator". People are going to abuse the hell out of it (they will with default

Re: [fpc-devel] Standard generic classes

Marco van de Voort schrieb am Sa., 8. Juni 2019, 13:43: > > Op 2019-06-06 om 16:57 schreef Ben Grasset: > > On Wed, Jun 5, 2019 at 11:11 AM Sven Barth via fpc-devel > > > <mailto:fpc-devel@lists.freepascal.org>> wrote: > > > > You could try t

Re: [fpc-devel] When will the next version of FPC be released?

Michael Van Canneyt schrieb am Sa., 1. Juni 2019, 14:13: > > > On Sat, 1 Jun 2019, Sven Barth via fpc-devel wrote: > > >>> > >>> specialize ClearMem(pt); > >>> > >>> With implicit specialization: > >>> >

Re: [fpc-devel] When will the next version of FPC be released?

Michael Van Canneyt schrieb am Sa., 1. Juni 2019, 12:00: > > > On Fri, 31 May 2019, Ryan Joseph wrote: > > > > > > >> On May 30, 2019, at 4:18 PM, Ryan Joseph > wrote: > >> > >> I didn’t realize generic functions were in the trunk. I’m not sure I > got this implemented properly so it requires

Re: [fpc-devel] Standard generic classes

J. Gareth Moreton schrieb am Mi., 5. Juni 2019, 18:06: > > *for *X := 0 *to *Min(BUFFER_SIZE, DataLeft) *- 1 do* > *begin* > { Do some work that doesn't modify DataLeft } > *end*; > > Say that Min is given the *pure *directive, BUFFER_SIZE is a *const *and > DataLeft is a property or some

Re: [fpc-devel] When will the next version of FPC be released?

Ben Grasset schrieb am Sa., 1. Juni 2019, 22:49: > On Sat, Jun 1, 2019 at 10:58 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> I personally consider it a worthwhile addition. >> > > What version did Delphi add that in? I honestly

Re: [fpc-devel] Class management operators

Ryan Joseph schrieb am Fr., 24. Mai 2019, 17:43: > Another thing I forget to mention. Since I was looking at management > operator stuff in the compiler I was curious, why don’t classes support > management operators? The infrastructure is already there for built-in > reference types like

Re: [fpc-devel] Object upgrades

Nikolay Nikolov schrieb am Do., 30. Mai 2019, 00:52: > So, what's with all this FUD surrounding operator overloading not > working with objects? Did you even test it, before screaming "legacy!"? :) > He's talking about operator overloads that are members of the object like what was introduced

Re: [fpc-devel] Object upgrades

Am 16.06.2019 um 17:43 schrieb wkitt...@windstream.net: On 6/16/19 10:23 AM, Ryan Joseph wrote: Charlie, I’m still not seeing my own messages posted if gmail can determine that a message coming in from a list is one you sent, it does not pass it on back to you... there's no way to turn this

Re: [fpc-devel] Object upgrades (new)

Ryan Joseph schrieb am Sa., 15. Juni 2019, 20:43: > > > > On Jun 15, 2019, at 12:50 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > I don't see a need to add management operators to objects. Objects have > constructors

Re: [fpc-devel] Object upgrades (new)

Am 15.06.2019 um 17:17 schrieb Ryan Joseph: { I think the old thread “Object upgrades” got broken during the server move so I’ll try to start a new thread and see if this gets posted } Another question. I’m not sure it’s possible but I did try to add management operators to objects and found

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am Mo., 10. Juni 2019, 21:31: > > > > On Jun 10, 2019, at 3:25 PM, Ben Grasset wrote: > > > > Result in your example is the size of a pointer in all cases, which is > fine / exactly what you'd expect it to be. > > > > Sorry, if I dereference the size is still of TBase. I

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 20:35: > > > > On Jun 10, 2019, at 2:21 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > There exist only two assignment operators, namely "Implicit" (aka := in > mode ObjFPC

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am Mo., 10. Juni 2019, 20:31: > > > > On Jun 10, 2019, at 2:26 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > Also FPC doesn’t have something “self” but for the class level so you > need to cast the

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 03:00: > Sorry to bring this up again but I had a thought today while working > regarding class operator overloads in classes (i.e. operators that are > members of classes). > > If the operators in classes allowed another parameter for the left sided >

Re: [fpc-devel] Copy/move operator

Ryan Joseph schrieb am Di., 18. Juni 2019, 16:09: > Not sure about inline though, I don’t think the compiler inlines these > operators at all. FPC seems to have lots of non-inlinable code these days > which is too bad. Maybe the LLVM backend will fix that someday? > Those operators can't be

Re: [fpc-devel] Object upgrades (new)

Am 17.06.2019 um 19:56 schrieb wkitt...@windstream.net: And yes, both are again different from classes. yeah, i'll have to see if i can figure out what classes are and if they are one of the old-school objects or records... yeah, i'm getting old and rarely dabble in pascal code any more

Re: [fpc-devel] Object upgrades (new)

schrieb am Di., 18. Juni 2019, 03:27: > >> *this is an example of a traditional record and a traditional object as > i > >> think of them... > > [snip] > > > > These would still work as is in FPC. > > > right but are they objects, classes or advanced records? > Your example showed a couple of

Re: [fpc-devel] XML node dump feature

Am 25.06.2019 um 06:20 schrieb Marģers . via fpc-devel: - Reply to message - Subject: Re: [fpc-devel] XML node dump feature Date: otrd., 25 jūn., 03:16 From: Ben Grasset To: FPC developers' list const A: TVec3F = (X: 1.2; Y: 2.4; Z: 3.8); B: TVec3F = (X: 2.1; Y: 4.2; Z:

Re: [fpc-devel] Object upgrades (new)

schrieb am Mo., 17. Juni 2019, 14:15: > On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote: > > schrieb am Mo., 17. > > Juni 2019, 02:07: > > > > what always confused me these days is that records and objects were > one thing > > back in the (TP6) da

Re: [fpc-devel] Copy/move operator

Ryan Joseph schrieb am So., 16. Juni 2019, 15:29: > I just came across an efficiency issue when using management operators > that I’d like to fix before the next release and we have backwards > compatibility problems. > > Basically the problem is that the Copy operator doesn’t know if the source

Re: [fpc-devel] Overloading standard functions

Marco van de Voort schrieb am Mi., 19. Juni 2019, 16:09: > > The answer I see: none because any identifier may become "builtin", > > > start to hardly conflict with any declarations with the same name and > > become PITA for code maintainer. > > > No, since the default is that the local

Re: [fpc-devel] Overloading standard functions

Виктор Матузенко schrieb am Mi., 19. Juni 2019, 16:25: > > > ср, 19 июн. 2019 г. в 17:10, Marco van de Voort >: > >> >> No. Such guarantees/constraints on a long term basis would paralyse the >> project too much. We try to avoid breaking backwards compatibility as >> much as possible, but we

Re: [fpc-devel] Copy/move operator

Ben Grasset schrieb am Mi., 19. Juni 2019, 16:21: > On Tue, Jun 18, 2019 at 11:08 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Those operators can't be inlined, because they're called from helper >> code, not from the compiler direc

Re: [fpc-devel] Copy/move operator

Ben Grasset schrieb am Mi., 19. Juni 2019, 23:45: > On Wed, Jun 19, 2019 at 5:02 PM Ryan Joseph wrote: > >> It’s used for making reference counted types at the user level. >> > > I'm not sure why you'd necessarily need to implement Copy specifically for > that kind of thing, though. Initialize

Re: [fpc-devel] [] property overloads

Michael Van Canneyt schrieb am Do., 20. Juni 2019, 22:05: > But maybe the compiler people can see a reason why this should not be > allowed. > It will need to be be allowed for Delphi compatibility anyway: https://bugs.freepascal.org/view.php?id=29056 Regards, Sven >

Re: [fpc-devel] [] property overloads

Marcus Marques da Rocha schrieb am Fr., 21. Juni 2019, 12:24: > It is possible to do that using variant type. I have done it as below: > Though this is not very type safe. So a correct solution in the compiler for overloading is definitely desired. Regards, Sven >

Re: [fpc-devel] Inlining problem and LEB128

Am 23.06.2019 um 01:10 schrieb J. Gareth Moreton: This one is for Jonas in particular, but also to address a minor issue in general. Currently, you can get away with specifying the "inline" directive for a function in just the implementation section of a unit, and the function will be

Re: [fpc-devel] Record types with unbounded trailing data

Am 24.06.2019 um 05:57 schrieb J. Gareth Moreton: We can't really use a new keyword to define an unbounded array, so I'm wondering if we can work with the syntax for open arrays.  For example, say we redefined LOGPALETTE to the following: LOGPALETTE = record   palVersion : WORD;  

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 14:28: > > > > On Jun 10, 2019, at 3:13 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > A basic principle of operator overloads is that existing, internal > operators are no

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 15:28: > > > > On Jun 10, 2019, at 9:25 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > The operator for assigning one class instance to another exists and is > internal thu

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 16:26: > > > > On Jun 10, 2019, at 9:31 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > The +-operator is not defined internally thus it is allowed to be > overloaded. (is it really tha

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am Mo., 10. Juni 2019, 19:56: > Also FPC doesn’t have something “self” but for the class level so you need > to cast the return value. Btw adding “ClassSelf” is something I’ve wanted > for a while, so I can reference the class type within the class declaration. > What are

Re: [fpc-devel] Object upgrades (new)

schrieb am Mo., 17. Juni 2019, 02:07: > On 6/16/19 6:44 PM, Ryan Joseph wrote: > > > > > >> On Jun 16, 2019, at 6:00 PM, Benito van der Zander > wrote: > >> > >> Objects are much more useful than classes or records > > > > Now that’s an inflammatory statement! :) But seriously, I do miss record

Re: [fpc-devel] modeswitch multihelpers

Stefan Glienke schrieb am Mo., 13. Mai 2019, 14:54: > In fact it will use the last one that was found and fwiw this is imo bad > and error prone behavior - I guess everyone has had that happen at least > once that with some version change or update of some code some clash > happened - especially

Re: [fpc-devel] Could the following be merged to 3.2.0 please (committed by Sven)

Marco van de Voort schrieb am Sa., 18. Mai 2019, 19:56: > > Op 2019-05-18 om 19:10 schreef Martin: > > See the list below. I wonder if they could be merged? > > If Sven sees no problems ( just say the word), and I'll merge them. > No problems from my side :) Regards, Sven >

Re: [fpc-devel] fpcmake

Kevin Lyda schrieb am Di., 21. Mai 2019, 22:04: > Looking at using fpcmake and it comes up short. I'm wondering if some > patches to it would be acceptable. Broken down by section... > > In [install] it would be nice to be able to specify some other file > locations. Specifically, man pages

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am Fr., 24. Mai 2019, 01:20: > I’m doing some work to upgrade old-style objects including class > operators/management operators and better construction. > Please don't. They're legacy types (even though we don't consider them obsolete) and geared towards the TP behavior and

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

J. Gareth Moreton schrieb am So., 19. Mai 2019, 13:18: > Regarding the C-style assignment operators, some of the packages that come > with the compiler use them, and trying to build everything without the -Sc > flag will result in errors. Outside of that, the biggest one that stands > out is

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

Jonas Maebe schrieb am So., 19. Mai 2019, 13:29: > On 19/05/2019 13:25, Sven Barth via fpc-devel wrote: > > And don't get me started about ">>". That one is going to annoy me > > enough once I add support for nested specializations -.- > > Current C++ stand

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

Michael Van Canneyt schrieb am So., 19. Mai 2019, 13:51: > > > On Sun, 19 May 2019, Jonas Maebe wrote: > > > On 19/05/2019 13:25, Sven Barth via fpc-devel wrote: > >> And don't get me started about ">>". That one is going to annoy me > >>

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

Marco van de Voort schrieb am So., 19. Mai 2019, 14:04: > > Op 2019-05-19 om 13:50 schreef Michael Van Canneyt: > > Current C++ standards requires a space between the two > signs for > > nested templates, so I think it would be fine if we were to require > > that as well. Although I supposed

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

J. Gareth Moreton schrieb am So., 19. Mai 2019, 05:17: > Yes, I'm jumpy, especially as you always like to open your responses > with a direct insult of some kind - yes, I checked. You want to kill me > or ban me from the mailing list, go right ahead. I'm sure Free Pascal > will survive without

Re: [fpc-devel] "inline" issue

Am 26.04.2019 um 18:29 schrieb J. Gareth Moreton: That's good to know - thanks Sven. This might be a silly question, but what error messages do you get if you put "inline" in a method's implementation etc? I'm wondering if I should develop a patch that ensures the conformance for inline

Re: [fpc-devel] "inline" issue

Am 26.04.2019 um 22:41 schrieb J. Gareth Moreton: On 26/04/2019 21:29, Sven Barth via fpc-devel wrote: ... You did read what Jonas said in the bug report? Adding "inline" in the implementation section for the interface section would need to lead to a change of the interface

Re: [fpc-devel] Possible idea... "safe" subroutines/methods

J. Gareth Moreton schrieb am So., 5. Mai 2019, 05:11: > One problem I do have with FPC and its optimiser is that -O4 is > specifically said that it may cause side-effects and even tongue-in-cheek > says "beware". To me, this is bad design because it discourages the end > users from using the

<    1   2   3   4   5   6   7   8   >