Re: [fpc-devel] Why/how does the compiler have a non-trivial number of memory leaks after over two decades of development?

I'm somewhat surprised to see all the mentions of try-finally in response to this. The issues I found and described here are all clearly just simple cases of variables being created and then never freed. Part of what likely leads to this is that the compiler relies in many places on checking

Re: [fpc-devel] FreeInstance

Forgot to mention a record or object with at least one method will get to the first part also, but never the FreeInstance part as they can never have destructors. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] FreeInstance

> I’m still trying to find this with no luck. Doing a quick search for the word "freeinstance" in the compiler source shows two places where it looks for a member function with that name in the global "current_structdef" variable. I'm fairly certain the one you're looking for is in a function

Re: [fpc-devel] FreeInstance

> On Wed, Aug 1, 2018 at 11:27 AM, Ryan Joseph wrote: > Yeah, this is the first place I looked but current_structdef is always nil so it never progresses past that point. > Is this test program not enough to get FreeInstance called? You need to declare a class, and give that class at least one

[fpc-devel] Why/how does the compiler have a non-trivial number of memory leaks after over two decades of development?

I was feeling inquisitive today, so I added 'SetHeapTraceOutput('log.trc');" to the first line of pp.pas and built myself a debug copy of the compiler using Lazarus. After building the following very simple program: program Test2; {$mode objfpc}{$H+} procedure TestProc(const S: String); begin

[fpc-devel] What's the status on the "record default field" functionality?

AFAIK it's been working for over a year in a separate branch. The smart pointer example demos worked perfectly as far as I could tell. Is there a particular reason it hasn't been added to the main codebase the way management operators were? ___ fpc-devel

Re: [fpc-devel] The 15k bounty: Optimizing executable speed forLinux x86 / LLVM

On Sun, Oct 28, 2018 at 12:40 AM J. Gareth Moreton < gar...@moreton-family.com> wrote: > Part of my incentive is that I like to design games and am also an amateur > mathematician, both fields that can benefit from speed gains, so if I can > make Free Pascal into something that is suitable for

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

On Thu, Oct 25, 2018 at 3:06 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Simon Kissel schrieb am Do., 25. Okt. > 2018, 08:54: > >> - Complete the LLVM branch of FPC. It looks like Jonas has stopped >> working on it two years ago, which is a pity. >> > > I personally

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

On Sat, Oct 27, 2018 at 8:47 AM Jonas Maebe wrote: > On 27/10/18 05:45, Ben Grasset wrote: > You also need "opt" if you want to perform full optimizations (or just > use clang, which a.o. combines the functionality of llc and opt). > > There's one more problem I forg

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

On Sat, Oct 27, 2018 at 6:46 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Except of course for optimizations that can be done on the platform > independent node tree. > That specifically is IMO the "key" to a higher compiler-wide level of optimization capabilities, as

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

On Sat, Oct 27, 2018 at 8:22 PM Ozz Nixon wrote: > * Sorry for off topic - just that grabbed my "What did he just say?" > button.. > Huh? I said "Also linked lists absolutely everywhere, that would perform much better as array based lists." Meaning, exactly the same thing you just implied. You

[fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. You ha

I've been happily building 64-bit FPC natively on Windows for over five years now. It works fine. It is stable. There is no logical reason whatsoever to use a 32-bit to 64-bit FPC cross compiler in 2018 if you are running 64-bit Windows natively, and anyone who thinks there is doesn't use Windows

Re: [fpc-devel] Array assignment operator

On Sat, Nov 3, 2018 at 8:01 AM Schindler Karl-Michael < karl-michael.schind...@web.de> wrote: > Hi > > I would like to use a simple assignment operator for arrays, with which > all elements of an array are assigned to the same value, similar to an > extended initialize, not to zero but to a value

Re: [fpc-devel] Array assignment operator

On Sat, Nov 3, 2018 at 4:44 PM Gennady Agranov wrote: > Hi, > > Leaving aside the reason why the MiSchi's solution doesn't work the main > question is still not answered :) > > If you have integer dynamic array "MyArray" is there a way for the > following statement to compile and work correctly:

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

On Sat, Oct 27, 2018 at 1:38 PM Florian Klämpfl wrote: > That it is useful to work on table based exception handling for all targets > Not arguing with that at all. I was just trying to point out that I'm not a fan of the idea that FPC's code generators are "good enough" as is.

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

On Mon, Nov 5, 2018 at 12:22 PM Tomas Hajny wrote: > I'd appreciate if this part of the discussion related to importance of TP > compatibility is finished for everybody. For what it's worth my original message only mentioned the TP thing in passing, and I specifically said it was a "different

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

t wrote: > > On 11/3/18 7:09 PM, Ben Grasset wrote: > >> (The same could be said about the various other wildly outdated bits of > >> information on the overall site and the fact that it gives > >> now-hugely-irrelevant topics like "porting from TP7" such pr

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

nting." On Sun, Nov 4, 2018 at 7:41 AM wrote: > On 11/3/18 7:09 PM, Ben Grasset wrote: > > (The same could be said about the various other wildly outdated bits of > > information on the overall site and the fact that it gives > > now-hugely-irrelevant topics like &qu

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

in various ways, many not necessarily related building Lazarus specifically. As I said I've been building it myself for years, and I use it daily. On Sun, Nov 4, 2018 at 6:16 AM Jonas Maebe wrote: > On 04/11/18 00:09, Ben Grasset wrote: > > s just one example, I've seen more than one instance

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

I just strongly disagree that there's much merit or reality to the overall concept people keep floating here that FPC's *actual *user base consists largely of a magical non-stop stream of 50+ year olds who have randomly decided out of the blue to "pick up Pascal again" and re-live the whimsical

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

e code isn't > already written. > > > On 11/4/2018 7:41 AM, wkitt...@windstream.net wrote: > > On 11/3/18 7:09 PM, Ben Grasset wrote: > >> (The same could be said about the various other wildly outdated bits of > >> information on the overall site and the fact that

Re: [fpc-devel] x86_64 Optimizer Overhaul

On Sat, Dec 15, 2018 at 2:37 PM Martok wrote: > In any case, FPC's cmem on Win32 calls into mscvrt, and that is so slow > that I > killed the test code after a couple of minutes, where even FPC-builtin was > done > after 10 seconds. > Interesting. On Win64 I've found it to be consistently

Re: [fpc-devel] x86_64 Optimizer Overhaul

On Sat, Dec 15, 2018 at 1:01 PM Martok wrote: > I just tested something, and I'm a surprised by how big the difference is. > Should this really be surprising at all though? To me it seems obvious why that would be the case. Delphi the compiler (not the IDE) is not written in Pascal. It's

Re: [fpc-devel] x86_64 Optimizer Overhaul

On Sat, Dec 15, 2018 at 1:14 PM J. Gareth Moreton wrote: > P.S. This thread is supposed to be for the x86_64 optimizer overhaul that > I presented! > Despite the other reply I just sent about the memory management stuff I also agree here! Your changes look very beneficial and it would be nice

[fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

TSize and TPoint, the other two advanced records defined there, have (well, mostly, they're also missing a couple) all record parameters in their method signatures declared "const", for what is presumably performance / efficiency reasons. That is to say, record parameters specified without "var",

Re: [fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

On Sat, Jan 26, 2019 at 7:06 PM Marco van de Voort < f...@pascalprogramming.org> wrote: > Anyway, a patch would be welcome. > Ok, I'll work one up that merges properly against the current trunk versions. Thanks for the quick response also, I was actually not sure who had written those files...

Re: [fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

On Sun, Jan 27, 2019 at 8:00 AM Marco van de Voort < f...@pascalprogramming.org> wrote: > I wonder though that maybe makes passing properties etc difficult? > As far I know "const" has no tangible effect on how properties can be passed. Here's a little example to demonstrate: program Test;

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

On Mon, Mar 25, 2019 at 5:34 PM Ben Grasset wrote: > To be properly cross-platform, it should really generate something like > "-Fu..\..\units\$fpctarget" > I meant to say, "generate something like that specifically for Windows." Perhaps just have an IFDEF UN

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

On Sun, Mar 24, 2019 at 6:22 PM Bart wrote: > Extract from fpc.cfg from 3.0.4 (created by offcial installer) > # searchpath for units and other system dependent things > -FuC:\devel\fpc\3.0.4/units/$fpctarget > -FuC:\devel\fpc\3.0.4/units/$fpctarget/* > -FuC:\devel\fpc\3.0.4/units/$fpctarget/rtl

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

On Tue, Mar 26, 2019 at 2:33 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Those paths are not handled relative to the compiler binary, they are > handled relative to the current directory when calling the compiler. The > compiler does not differentiate whether a

Re: [fpc-devel] Closures repo

On Thu, Mar 21, 2019 at 4:40 PM Blaise Thorn wrote: > Should you be interested in writing tests, I could give you the acess. > I'd also be very interested in assisting with this, now that I'm aware you're willing to provide access to the repo. ___

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

On Fri, Feb 22, 2019 at 1:07 AM Paul van Helden wrote: > How do you make a (for in) enumerator with a record? I don't use them for > exactly this reason, and they did seem to be another useful language > feature that turned out to be poorly implemented by Embarcadero. (Haven't > checked with

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

On Sat, Feb 16, 2019 at 5:44 PM Benito van der Zander wrote > it can turn out the enumerators are slower than an old school loop > The trick with enumerators is to never make them classes, and use advanced records instead, I've found. This way you avoid the heap allocation and the implicit

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

On Sun, Feb 17, 2019 at 3:15 AM Florian Klämpfl wrote: > This is a property of production compiler code. > I'm not sure about that. I don't think FPC's codebase is (for the most part) a mess, although the style is a little bit inconsistent sometimes.

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

%al,%al > 004012C2 75cc jne0x401290 > > Nearly every line is accessing some memory, when it could keep everything > in a few registers. amd64 has 16 registers, but fpc seems to only know > three when records are involved > > > > Cheers, &

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

Inlining of pure assembler functions would actually be immediately, specifically useful to me! I've been having a go at improving FPC scores on "BenchmarksGames", and was so far successful with Binary Trees simple by throwing a really good threading library at it, however, there are some

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

To clarify my last message, what I had said previously was that FPC needs *either* inlinable assembler *or* intrinsics. Just basically something that ultimately can be called as a "normal" Pascal function, but that does *not* end up as an un-inlined function call. I have no preference as to how

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

On Sun, Mar 17, 2019 at 1:57 PM Florian Klämpfl wrote: > > How is it better than intrinsics support (similiar to gcc/icc etc.)? > Well, it wouldn't be better than a literal equivalent to those intriniscs, if that's what we're talking about. By which I mean, like, say how in Clang/GCC (or

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

On Fri, Feb 15, 2019 at 4:07 AM James via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > 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 with

Re: [fpc-devel] Fppkg

On Mon, Feb 4, 2019 at 9:53 AM Martok wrote: > the first-ever fppkg.exe invocation on a machine > Do people actually use fppkg for anything? More specifically what is the point of integrating it with Lazarus, which already has the OPM? ___ fpc-devel

Re: [fpc-devel] Vectorisation, optimisation etc.

On Wed, Mar 27, 2019 at 11:32 AM J. Gareth Moreton < gar...@moreton-family.com> wrote: > So with the false start that was pure inline assembly, I like to talk > about how to move forward with FPC, or at least with x86_64. > It occurred to me today, aren't you the person who fixed the -Sv

Re: [fpc-devel] Vectorisation, optimisation etc.

On Sat, Apr 6, 2019 at 6:56 PM Jeppe Johansen wrote: > Perhaps but it's a nightmare in so many places to satisfy requirements for > potential uses. Ideally the programmer would specify minimum alignment > requirements per type > Actively worrying about alignment in the vast majority of cases is

Re: [fpc-devel] Vectorisation, optimisation etc.

On Sat, Apr 6, 2019 at 5:27 PM Jeppe Johansen wrote: > That can't happen or won't benefit much, before the compiler supports > super-natual alignments. So there's a deeper level of support needed. > I'm fairly confident the existing functionality could be improved upon in a useful way. Gareth

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

On Sat, Apr 13, 2019 at 6:04 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Maybe we should mention that in the documentation... > AFAIK it's never been possible to use FPC-style operator overloading in mode Delphi... is it supposed to be allowed? For example: unit

Re: [fpc-devel] Compiler picks wrong overload

On Wed, May 22, 2019 at 12:53 PM Pascal Riekenberg wrote: > No one? This is a showstopper! > FWIW, you can comment out the new TBytes definitions as a temporary fix. They are not actually used anywhere in the FPC codebase. More broadly I think the bigger problem is FPC's internal

Re: [fpc-devel] Closures/anonymous functions update

On Sat, May 18, 2019 at 2:57 PM Ryan Joseph wrote: > I wanted to make an alternate capture mode as an optimization for closures > that don’t get passed outside of their scope but I wasn’t able to figure > this out yet (using old-style objects instead of classes). It’s a waste to > allocate a new

Re: [fpc-devel] Minor request with case else branches

On Fri, May 24, 2019 at 5:46 PM J. Gareth Moreton wrote: > Whenever I come across a section of code in my own projects where "*else * > ;" is necessary, or any empty branch for that matter, I put a "{ Do > nothing }" comment just to make it absolutely clear that the block is > there deliberately

Re: [fpc-devel] Constants in generics patch

On Tue, May 21, 2019 at 12:23 AM Ryan Joseph wrote: > I believe I got it all tested and it’s fully functional now (another user > has been tested it also as you’ll see in the notes). > That's me! And yeah, I'd love to see some movement on this as it's an extremely powerful / useful feature.

Re: [fpc-devel] Standard generic classes

On Tue, Jun 4, 2019 at 4:40 PM J. Gareth Moreton wrote: > I may be missing the obvious here, but I've noticed that there are some > notable absences in the Free Generics Library. > All of that stuff is available in "rtl-generics" (currently trunk-only, but AFAIK works on 3.0.4 if you copy the

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

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 Copy(Dest: PT; Src: PT; Len: PtrUInt); static; inline;

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

On Fri, Jun 7, 2019 at 3:26 PM Jonas Maebe wrote: > So if you add something in it that is in fact the same as a regular type > definition, something is wrong. > What exactly is "wrong" there, though? In a world where they both worked, doing this, as we've discussed: procedure Proc(Param:

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

On Fri, Jun 7, 2019 at 3:44 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > No, I think you *missed* the point. "^Type" defines a new type. "0..5" > defines a new type. "set of (Alpha, Beta, Gamma)" defines a new type. > "record a, b: longint end" defines a new types. All

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

On Fri, Jun 7, 2019 at 1:47 PM Jonas Maebe wrote: > It would be inconsistent to only allow such declaration for pointers, > and not for other types (a programming language should strive to be as > orthogonal as possible, with as few exceptions as possible). > I can't think of any particular

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

On Fri, Jun 7, 2019 at 3:44 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > "0..5" defines a new type. "set of (Alpha, Beta, Gamma)" defines a new > type. "record a, b: longint end" defines a new types. > Building on my last reply, also, here's an example that shows what I

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

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 > "0..5" and "record a, b: longint end;". > Right, that's the point. There's nothing else that

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

Two final things: A) I didn't really make this thread with to imply I necessarily wanted *someone else* to implement this. What I ultimately was trying to figure out is basically would I be wasting my time if I was able to implement this on my own, probably under a new modeswitch (maybe

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

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 had no idea it was a thing. Makes it seem especially strange that they still don't have

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

On Sat, Jun 1, 2019 at 6:00 AM Michael Van Canneyt wrote: > I don't think this syntax is a good idea. > > What with overloads ? > > Procedure MyProc(a:T); > Procedure MyProc(a : TObject); > > How do I know which one will be called ? > I think it would have to work like: if something is a

Re: [fpc-devel] Standard generic classes

On Wed, Jun 5, 2019 at 11:11 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > You could try to adjust the FGL unit to use the pluggable sorting system > introduced here: > https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=41167 > Wouldn't that system itself need

Re: [fpc-devel] Object upgrades

On Mon, Jun 10, 2019 at 1:56 PM Ryan Joseph wrote: > I don’t think this is possible. Just did little test and the size of > “result” is always the size of the base class. Does this work? > Result in your example is the size of a *pointer* in all cases, which is fine / exactly what you'd expect

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

On Sun, Jun 9, 2019 at 11:26 AM Florian Klämpfl wrote: > Yes, but this has *nothing* to do with the output of -vp. Nothing. > My point with that was more just getting at "clearly typed pointer aliases are not actually that big of a deal internally for FPC", as in it doesn't really matter if it

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

On Sun, Jun 9, 2019 at 8:11 PM Dmitry Boyarintsev wrote: > One can't do > function myFunc(var a: record a,b: integer; end): integer; > the record type has to be declared separately. > Of course not. That would be rather nonsensical, *for very obvious reasons*, that I've already gone out of my

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

On Sun, Jun 9, 2019 at 11:23 AM Ryan Joseph wrote: > var > a: ^integer; > begin > DoThis(a0); I'm assuming "a0" was just a typo there?... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

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

On Sun, Jun 9, 2019 at 8:37 PM Bernd Oppolzer wrote: > the base type must have been declared already > Well, not necessarily in FPC, because generics, but that would just follow the same way generic parameters are currently "filled in later" in all other areas. On Sun, Jun 9, 2019 at 8:37 PM

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

On Mon, Jun 10, 2019 at 6:21 AM Martin Frb wrote: > If you did have "procedure P1(x: ^Byte); overload;", how would you call it? > I would think it should be compatible *not* with this: type PB = type ^byte; but with anything declared like this: type PB = ^byte; On Mon, Jun 10, 2019 at 6:21

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

On Mon, Jun 10, 2019 at 12:15 AM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > You've been told before. Variable types are not the same as parameter > types. > That *doesn't matter* in any *practical *sense. How you *used *something declared as "^Type" would always be the same no

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

> > On Sun, Jun 9, 2019 at 10:28 PM Dmitry Boyarintsev < > skalogryz.li...@gmail.com> wrote: > >> t's kinda what language designers HAVE to do. >> It's nice just to throw out the "next-big-thing-cool-idea" out there and >> make yourself look smart. >> But you actually HAVE to think everything

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

On Sun, Jun 9, 2019 at 9:19 PM Dmitry Boyarintsev wrote: > Ah... I found it now. It's all about generics. Well, there's nothing I > can argue about here. > Well, not *really.* As I stated in the original message, it's just as useful for non-generic procedures or non-generic anything else. On

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

On Sun, Jun 9, 2019 at 10:28 PM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > Distantly? you're proposing to introduce a reference-to-type declaration > within a parameter. Without giving it any name. > Fine. But that would requires a type-casting within the code to the same > type as

Re: [fpc-devel] Copy/move operator

On Mon, Jun 17, 2019 at 5:57 PM Ryan Joseph wrote: > The copy operator is always called on all assignments. Try actually > running that and you’ll see. :) > Actually, after thinking about it some more, here's what I'd actually write (in a perfect world where it was possible.) program Test;

Re: [fpc-devel] Copy/move operator

On Sun, Jun 16, 2019 at 9:30 AM Ryan Joseph wrote: > Here’s a little example of the problem. What I propose is that we either > add a 3rd boolean parameter to the Copy operator or add a new Move operator > which is preferred over the Copy operator if it exists (this is much more > work obviously

Re: [fpc-devel] XML node dump feature

On Mon, Jun 24, 2019 at 4:11 PM J. Gareth Moreton wrote: > "constexpr" is essentially to C++ as "pure" would be to FPC. Some of the > methods that involve pointers and var parameters (which is probably the > closest equivalent to the "&" parameters in C++) may be flagged as impure > because

Re: [fpc-devel] XML node dump feature

On Tue, Jun 25, 2019 at 1:20 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Correct. Though considering that we're talking about *compile time* the > compiler *could* treat consts (in {$J-} mode) as constants if pure > functions are involved... > I'd be fine with the

Re: [fpc-devel] XML node dump feature

On Tue, Jun 25, 2019 at 11:58 AM J. Gareth Moreton < gar...@moreton-family.com> wrote: > While pure and inline do have a lot of overlap and, internally, probably > share some features for convenience (like a copy of the node tree), they > are not the same > Oh yeah, not arguing that at all. Again

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

On Mon, Jun 24, 2019 at 12:41 AM Michael Van Canneyt wrote: > If you want to get rid of warnings, define it as > LOGPALETTE = record > palVersion : WORD; > palNumEntries : WORD; > palPalEntry : array[0..(MAXINT div sizeof(PALETTEENTRY)] of > PALETTEENTRY; > end; > Wouldn't that

Re: [fpc-devel] XML node dump feature

On Tue, Jun 25, 2019 at 3:23 PM denisgolovan wrote: > e.g. what about returning dynamic arrays? Like: > > type TIntArray = array of Integer; > function ArrInit(): TIntArray; > begin > SetLength(Result, 1); > Result[0]:=1; > end; > Stuff like that is pretty much impossible, because you can't

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

On Sun, Jun 9, 2019 at 10:00 PM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > Should the flowing code (inside of DoSomething body) be ok as well? > ((^Integer)(b))^ := a^; > I mean, like *many, many, many *things, yes it is technically possible for that to be valid Pascal syntax. As

Re: [fpc-devel] Copy/move operator

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 directly. The LLVM backend won't change anything here. > Is there any real purpose to

Re: [fpc-devel] Copy/move operator

On Wed, Jun 19, 2019 at 12:01 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > It wouldn't matter if the function is called Copy, operator:= or > "jdjfjsje". Once a copy management operator is defined the record type is > considered "managed" and thus all assignment

Re: [fpc-devel] Copy/move operator

On Wed, Jun 19, 2019 at 5:45 PM Ben Grasset wrote: > 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 o

Re: [fpc-devel] Copy/move operator

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 and Finalize would be much more relevant, I'd say.

Re: [fpc-devel] Copy/move operator

On Wed, Jun 19, 2019 at 6:19 PM Ryan Joseph wrote: > Because a copy isn’t necessarily an assignment. See the dynamic array > example again. The only way the record knows it was copied into the array > is via the copy operator. > I guess what I'm trying to get at is: A) Most of the time, the

Re: [fpc-devel] XML node dump feature

On Sat, Jun 22, 2019 at 4:36 PM J. Gareth Moreton wrote: > I've noticed you're particularly keen on pure functions... what's the > main use that you envision for them? > I'm not the same person of course, but I'm pretty excited about them in regards to the initialization of constants. E.G. I'd

Re: [fpc-devel] Copy/move operator

On Mon, Jun 17, 2019 at 5:57 PM Ryan Joseph wrote: > The copy operator is always called on all assignments. Try actually > running that and you’ll see. :) > Yeah, I noticed that afterwards once I checked. I'm not sure how much sense that actually makes when the TList is a function *result* as

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

On Sat, May 4, 2019 at 5:31 PM J. Gareth Moreton wrote: > I figure data-flow analysis will address everything eventually, but I > can't promise the compiler won't become very inefficient as a result. > I mean no offense by this, and note that I think you've done more for FPC in the last year

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 10:09 AM Marco van de Voort < f...@pascalprogramming.org> wrote: > You clearly didn't read the message fully. It is not about compiler/not > compile, but in the case of not compile what the error is and where. > It occurs at the same place it always has, because the

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 12:29 PM Michael Van Canneyt wrote: > I would think this is a given... > After all, they are valid characters in a single line string now, that > must be kept > for backward compatibility. > One more question in this general regard... what would be the most desirable way

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 9:30 PM Ryan Joseph wrote: > I must have missed something, why would a single apostrophe be anything > besides just another character? I thought another use of `` strings would > be that you don’t need to escape apostrophes using ‘'. > I didn't really think it should be.

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Ok, here's a link to my github fork implementing the multi-line string functionality. It now includes complete support for user-selected line ending settings, using the directive syntax suggested by Michael. So, for example, if you view the output of

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 1:32 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > const SomeString = `Whatever > bar > blubb > foobar`; > You can do: const SomeString = `Whatever bar blubb foobar`; Not that I think the "ugliness" argument makes any sense whatsoever. I

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 6:01 AM Marco van de Voort wrote: > - Basically a shorthand, the solution with + works fine. There also > could be $includefileasstring or something, one of the few extensions in > recent years that I have been in favor of. > > In conclusion: it is a solution in search of

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 9:28 AM wrote: > personally speaking, i liked the initial idea but i can now easily see why > it is > only allowed in source code comments... there's a world of difference > between > them... in one case, the formatting stays put and doesn't affect anything > else... in

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

e a matter of just what people think the overall best way to go about it is. On Wed, Jul 3, 2019 at 9:29 AM Ben Grasset wrote: > This has been discussed I think several times in the past, but I thought > I'd bring it up once more as it has never made sense to me that FPC happily >

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 9:35 AM Marco van de Voort wrote: > New magic characters in the scanner. Yeah. Really nice (NOT!) It's not magic. It's exactly the same thing as the single quote currently is, but denoting multi-line strings specifically. On Thu, Jul 4, 2019 at 9:35 AM Marco van de

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 10:06 AM wrote: > don't get me wrong... i'm not against it if someone wants to develop it > but i am > Well, I already have, and it literally works (including syntax highlighting support in SynEdit for those who do use Lazarus.) See an earlier comment of mine in this

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 10:30 AM Ryan Joseph wrote: > Just put it up on GitHub so we can test it. We’re not getting anywhere > going back and forth over email. > Will later today. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 9:32 AM Marco van de Voort wrote: > E.g. where in this very long thread do the proponents actually balance > the need for a language feature against an IDE feature (to decode a > multiline string in + form into a popup, let user perform edit, and then > + it again). > >

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 9:14 AM Marco van de Voort wrote: > Take a large pascal file with several strings. Normal, non multi-line > strings. > > Now, as a thought experiment, remove the closing ' from one of the > strings at the top. > > In the case of no multiline string support: error on the

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 12:29 PM Michael Van Canneyt wrote: > I would think this is a given... > After all, they are valid characters in a single line string now, that > must be kept > for backward compatibility. > That's what I was kind of thinking myself. I just wanted to get an initial

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Wed, Jul 3, 2019 at 9:29 AM Ben Grasset wrote: > classic round-bracket-plus-apostrophe multi-line-Pascal-comment syntax. > I meant "round-bracket-plus-asterisk" here, of course. ___ fpc-devel maillist - fpc-devel@lists.free

  1   2   3   >