Re: [fpc-devel] "Blank slate" next version of FPC
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 > 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 try/finally. Also make sure you inline the MoveNext and > GetCurrent! > > 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 FPC). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Blank slate" next version of FPC
On Wed, Feb 20, 2019 at 4:35 PM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Even if declaring variables as close as possible to where the variable > will be used ( debugging wise not readability wise ) leads to more correct > code, the problem is to avoid the temptation to use them in other places > too. > Variables declared within a begin...end cannot be used elsewhere. (E.g. for var I:=0 to .. won't let you use I after the loop). > AFAIK, one of Pascal's primary design goals is to won't let you shoot > yourself in the foot, and IMO that feature is not in that direction. > I'd like to see an example how this is less safe. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Blank slate" next version of FPC
On Wed, Feb 20, 2019 at 3:52 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > Pascal is a language where declaration and use of variables is separated. > It makes it easy to see what variables are declared and what type they are. > Inline variables mess this up as a variable can be declared somewhere > inside the code. > Now I'm curious. Can you point me to a resource where Pascal is defined such that the separation of declaration from use is a central tenet? I'm not sure, but I doubt I ever look at the variable declarations to help understand the rest of the code... To me it seems like an artificial limitation which probably made compiler development easier (or compilation faster?). Yet most other languages didn't see the need for this limitation. (I see Pascal as a C-like language with superior readability. I want the speed of C AND be able to easily understand the code). > I use C++ to earn my living. I know why I'm not a fan of inline variables > as I've been biten by them often enough already. > > Can you provide an example of how inline variables can bite? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Blank slate" next version of FPC
> > > > > 1. it makes it easier to see the whole picture just looking at the loop > > > body, no need to scroll up; (The loop body might be just 10 lines of > code, > > > whereas the whole containing function sometimes has 1000s) > > > > > > 2. it isoltates the scope of such variable(s), therefore preventing > some > > > sorts of accidental misuse outside of e.g. the containing loop (which > still > > > do happen to me ocasionally in Pascal). > > > > I've already tried to make these points, nobody seems to buy it. IIRC > > Michael (vC) said that functions shouldn't be that long, so then it's > > not a problem (perhaps his world is perfect, but mine certainly isn't). > > Anyone can split a function in many others. It's not so difficult and, > actually, it should be done. > > > I'm mostly more interested in limiting the scope to prevent accidental > > use, like you. It can also offer more fine grained control of where > > managed variables get freed. > > Try to see restrictions as a good thing. > In this case, which Pascal doesn't allow to declare inline variables, > you must split big functions, which has many local variables, in > others to have a better understanding of the algorithm. At the end, > you might have a better design and reuse of the code. Everybody wins: > you, your code, Pascal team - as they don't need to change the > compiler - and Niklaus Wirth might not throw a curse in us. > > O dear, now I've dunnit... So the argument against is: (1) split your long functions, because you should; and (2) Wirth didn't do it, so good it is not. Long functions *might* be an indication of bad design, but you know, sometimes I have a long function that doesn't make sense to split. Here is a good article about inline vars: http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html What's not to like about for var I:=0 to Count-1 do.. ? Or var MyDict:=TDictionary.Create; Marcos says restrictions are good. The above restricts the number of lines of code while being just as (or more) readable! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Blank slate" next version of FPC
> > 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 feature is where we draw the > line. We won't implement it and we are also inclined to say "patches *not* > welcome" for that. > > Regards, > Sven > > To add a dissenting voice, from someone who has followed FPC development for more than 10 years and used to be very exited about FPC/Lazarus... Sven's statement just about seals it for me. So then FPC's main goal isn't Delphi compatibility any more? I for one will use inline variable declarations and therefore say goodbye to FPC. Not to start a pro-vs-con discussion in this thread, but personally I see only advantages in more fine-grained control of variable scope. (Plus it has been irritating me for more than 25 years to go to the top to declare variables [and no, auto-declarations by the IDE doesn't fix it for me; e.g. if generics are good, why not duck typing?]). Yes, Embarcadero has done some horrid things to the language, but I don't see this as one of them. As a big fan of the Pascal language, I'd rather break compatibility and see the language evolve than the stoic attitude of the core devs as seen on this list. (And inline vars doesn't break anything!) If Oxygene was open source and (CPU) native, I wouldn't even been reading this list... /2c ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
On Wed, Oct 26, 2016 at 12:48 PM, Michael Van Canneyt < mich...@freepascal.org> wrote: > > > On Wed, 26 Oct 2016, Maciej Izak wrote: > > 2016-10-26 11:56 GMT+02:00 Michael Van Canneyt : >> >> As long as it's really a separate mode (plus maybe modeswitches for >>> selected features, that other modes might profit from) I don't see a problem with adding an Oxygene mode. >>> Indeed. This is the reason modes were invented. >>> >> >> >> This is obvious. I won't touch the holy OBJFPC mode ;). Ever. I am >> worried about the speed of reviewing patches and integrations. For example: >> Management operators are key feature for many elements in Oxygene mode. >> Today I am 28 years old. I think that maybe before my 40th birthday FPC >> team decide to merging Management Operatos into trunk -,- . If Oxygene >> patch is next, which relay on MO... 80th birthday? >> > > > Specially when they are as invasive as yours. You are in essence > converting pascal to a C++ clone with this MO patch. Is it so bad that this > is discussed thoroughly first ? > > +1 for Oxygene mode. An Oxygene mode to me will be like early Christmas and the next 10 years' Christmases rolled together! I disagree that modernizing Pascal is making it into a C++ clone. Why not take the best features of C++ while keeping Pascal readable? (FPC did that allready with I+=2, not that I'm arguing this is more readable. A better example would be ** vs. Power() - a no-brainer if you ask me, though I'd prefer ^ which was in Algol). Allowing EMB to dictate the future of Pascal is just wrong. Look what they've done with parallelism compared to Oxygene's clean (Pascal-like) approach. How is TParallel.For Pascallish? The difference seems to be that Pascal purists don't want to add keywords, while Oxygene adds many new keywords (eg. nullable, future, async, for parallel, is not, etc). And then for some flame-bait: I like declaring variables inside begin..end; ;-) To me it looks perfectly Pascallish if it starts with var.. and it is necessary anyway for duck typing, nullable types, etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Wed, Jul 22, 2015 at 9:45 PM, Ralf Quint wrote: > On 7/22/2015 10:47 AM, Sven Barth wrote: > >> > var A := SomeClassInstance.SomeFunction; >> >> While I agree that type inference /might/ be useful I don't agree with >> inline variable declarations. One of the main points of Pascal is declare >> before use. >> >> +100 > > Things like this is just because people are trying to be lazy, not because > this does improve code (human readable or otherwise). > Someone who is trying to use a construct like the one mentioned above is > nothing but lazy, is not properly designing his/her software. And that is > against what Pascal should stand for. > Humans miss a lot of times a third hand, but this isn't likely to happen > that we grow one anytime soon. So get used to properly using what you > have... > > Ralf > > Ralf, I guess I'm talking about losing the third hand and join all the other languages with two hands (so, minus the var block before begin :-) ). This is not about being lazy, but about being less verbose. Or in other words shorter text which is more expressive and more readable. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Wed, Jul 22, 2015 at 8:15 PM, Marco van de Voort wrote: > In our previous episode, Paul van Helden said: > > > Yes, so for example we currently have: > > > > if not (X is TSomeClass) then .. > > if not (5 in [1,2,3]) then .. > > > > What is wrong with a language evolving to allow (in addition to the > > above)?: > > Evolution in languages is like the evolution in organisms. Those who evolve > wrong or expend energy on features that are not contributing to survival > eventually perish. > > So basically it all boils down to benefit/cost tradeoff, with cost both > implementation AND maintenance. > > Understood. I'm not trying to make completely practical points here. I'm just trying to add to the conversation about improving the language which I love. And I'm not even suggesting anything new: these are concepts already embraced by main-stream languages. For new projects Object Pascal seems to be going the way of the dinosaur and I would like to see my favourite compiler (FPC) compete with more than Delphi. Oxygene, for example. If FPC+Lazarus is simply the anti-Delphi (to clarify: the open source alternative to / clone of Delphi), then I guess I am barking up the wrong tree. It just seems that this group is the only hope for an open source modern Pascal right now... :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Wed, Jul 22, 2015 at 7:47 PM, Sven Barth wrote: > > > I'm not a compiler programmer, but it almost seems like laziness that > the second case is not possible already? Maybe something is really hard > with multi-word operators? > > The compiler is geared towards single word operators (combined with their > precedence). > Is it technically infeasible to expand this to two-word operators? SQL did it.. > > Convenience should be added to this. Take for example type inference. If > the compiler can easily figure out the type of a result, why should I have > to declare a variable first with the appropriate type? Of course that means > to allow var declarations inside the code block. Something I've always > wanted to see in Pascal since my brief stint with C++ in the early 90s. The > standard argument against is probably "that is unPascallish" or that it is > moving away from strong typing. I disagree: if the compiler can figure > things out before runtime you still have strong typing. So, for example, I > would like to declare something like this anywhere inside a begin..end > block: > > > > var A := SomeClassInstance.SomeFunction; > > While I agree that type inference /might/ be useful I don't agree with > inline variable declarations. One of the main points of Pascal is declare > before use. While this is somewhat violated with Delphi compatible generics > there one could at least argue that the specialized type is implicitly > declared by the generic declaration... > I have never managed to understand why "declare before use" is so important to Pascal. I get the bit about strong typing and doing everything possible to eliminate errors at compile time, but I still don't get why. If this is central to what makes something "Pascal", I would love to be pointed to a good explanation. I'm not trying to be a pain here. I've been programming in Pascal, full time, for most of my life. It has always puzzled me why everything has to be declared first. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Wed, Jul 22, 2015 at 7:43 PM, Jonas Maebe wrote: > On 22/07/15 19:24, Paul van Helden wrote: > > What is wrong with a language evolving to allow (in addition to the > above)?: > > > > if X is not TSomeClass then .. > > if 5 not in [1,2,3] then .. > > > > I'm not a compiler programmer, but it almost seems like laziness that > > the second case is not possible already? > > If the "not" operator is overloaded in TSomeClass, "not TSomeClass" can > be a valid expression in itself. "not in" could never be anything else, > but consistency is also very important. > > Additionally, keeping the compiler fast and maintainable (and able to > produce sensible error messages when syntax errors are found) conflicts > with arbitrary word orders. Calling that laziness is a bit blunt. > Well, apologies for using the word "laziness". I simply meant that to someone who doesn't understand the complexities of compiler programming it seems as (almost) such. I still believe (in my ignorance) that it shouldn't be all that hard to have multi word operators like in SQL, but what do I know. I have personally found little use for operator overloading and I would be happy to have such restricted to things other than "not" or "not is". > > IMO the design philosophy should be: "if it is more readable it > > should be allowed". > > Allowing multiple ways to say the same thing generally does not increase > readability, even if in isolation it can look fine. > > There are always multiple ways to say the same thing, and especially in programming, so I don't understand your point. Perhaps I can try to explain myself: The only reason I have stuck with Pascal for more than two decades is because of the way the written language *looks*. I find it pleasing compared to other languages. So please understand my arguments as coming from that perspective. I may be wrong technically or practically, but this is how I feel and I am sure there are others that feel the same. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On Mon, Jul 20, 2015 at 8:39 PM, Marcos Douglas wrote: > On Mon, Jul 20, 2015 at 3:14 PM, Ralf Quint wrote: > > [...] And quite frankly, what I have seen in object oriented code > > in recent years, I would rather take as a negative example of evolution, > of > > ways/things not to go/do... > > That is true. > Many programmers think that coding using object orientation only > because they use an object-oriented language. They also think that > using a more "cool" syntax makes your code more "professional". > > But some evolutions in a language could be a good thing, as Sven have said. > > Yes, so for example we currently have: if not (X is TSomeClass) then .. if not (5 in [1,2,3]) then .. What is wrong with a language evolving to allow (in addition to the above)?: if X is not TSomeClass then .. if 5 not in [1,2,3] then .. I'm not a compiler programmer, but it almost seems like laziness that the second case is not possible already? Maybe something is really hard with multi-word operators? I like Pascal because it is more readable than Java, C#, Ruby, Haskell, etc. IMO the design philosophy should be: "if it is more readable it should be allowed". Convenience should be added to this. Take for example type inference. If the compiler can easily figure out the type of a result, why should I have to declare a variable first with the appropriate type? Of course that means to allow var declarations inside the code block. Something I've always wanted to see in Pascal since my brief stint with C++ in the early 90s. The standard argument against is probably "that is unPascallish" or that it is moving away from strong typing. I disagree: if the compiler can figure things out before runtime you still have strong typing. So, for example, I would like to declare something like this anywhere inside a begin..end block: var A := SomeClassInstance.SomeFunction; It *looks* like JavaScript's (etc) weak typing but it is not. The compiler will catch any mischief that may follow with the variable A. We've eliminated a line of code that needs to be changed if the type of the function result changes. And to me it still looks very Pascallish.. I can carry on.. tuples can save lots of lines of code while at the same time making it more readable. How as that not "cool"? :-) (or functional for that matter!) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC language/dialect MODE, Generics.Collections and new branch
On Fri, Jul 17, 2015 at 4:09 PM, silvioprog wrote:
>
> I don't know if a new dialect would be widely accepted by all developers
> (specially veteran pascal programmers), but if it could become things more
> practical and more productive, I would be in favor of just "{$ mode
> ObjPas}". =)
>
>
Veteran Pascal programmer here...
I haven't really started using it yet, but I read through the whole Oxygene
documentation the other day. (Didn't take long ;-) )
The Oxygene dialect is absolutely beautiful in my opinion. Lots of things
in there that I've been wanting for decades and many stupid things dropped
completely. Silly example: var declarations when you need them like C.
Practical example: parallel programming built into the language as opposed
to Delphi XE7/8's really ugly solutions with their "parallel library". (I
can go on with examples with the OP's permission).
I agree with the OP that the Delphi language had become uglier and uglier.
I want a programming language that looks good when I write it. This is why
I am still using Object Pascal and not Java or C#. If FPC's only goal is
Delphi compatibility, then perhaps I won't be on this list anymore some
years from now.
The world is looking for a new language. That is why we recently got
Google's Go and Apple's Swift. I believe a modern and clean dialect of
Object Pascal has a "leg-up" on both of these.
Now, this is related but OT: CPU-native compilation is becoming outdated
just like Assembly programming did. I always used to _hate_ .NET and Java,
but using a platform's own stack must surely be the future. Example: Delphi
XE8 cannot produce a binary for Android on Intel Atom. With Java you would
never have encountered this problem. (There are a lot of tablets currently
being produced with Atom processors).
So will FPC "embrace the future"? Or is the project only geared toward
"veteran pascal programmers" that don't share my vision?
Best regards,
Paul van Helden.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux thread priority mess (and possible implementation)
Hi All, "Threads are evil"? http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf Interesting view point. Perhaps that is why FPC doesn't bother too much about thread priorities? :-) Regards, Paul. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?
On 20/05/2010 12:19, Matt Emson wrote: Graeme Geldenhuys wrote: OK we just confirmed that you have no clue about OOP or design patterns, HAHAHAHAHAHAHAHAHAHA!! Wow. Your ego is too much for me. so I'll stop replying to your posts. Good. Please stop replying to the entire thread at the same time. None of us understand design patterns, honest. We're all wasting your valuable time. You are wasting my time and not contributing to the discussion at hand. Right... "can't get my own way - throw toys out of pram.", I think I have your measure. Dear All, Sometimes when this list has a busy day, I consider unsubscribing or at least having my email client file the messages into a folder automatically (which means I never get around to reading it). Can we all please agree to have "chatty" style messages done in an IRC channel, or wiki discussion page, or whatever? For example, while I enjoyed the joke link as much as anyone else, imagine how full our inboxes would be today if everyone who read it thought themselves important enough to reply to the whole list "Those are brilliant. I love the Java one". (Sorry Graeme). I follow this list because I learn so much from it. I don't want to unsubscribe from it, so may I kindly suggest a little restraint so that the messages remain either questions or helpful answers? Even a debate like this is OK if the arguments are well presented and the volume of messages remain low. Having a heated debate with dozens of messages in one morning on an email list is not optimal, IMO. At least in a forum one could unsubscribe from a particular thread. Please realize that your message is reaching thousands of inboxes and might only really be interesting (apart from entertainment value) to a few. This thread (as are most others) is interesting, but many of the messages are not. Sure, if you want to share a relevant and funny joke like Vinzent did and you believe it will lighten up everybody's day, send it, but can we at least agree on some restraint? It is certainly entertaining to see Greame blowing his top, but so are soap operas, and I don't really have the time for it. (Sorry again Graeme - please don't ever leave fpc-devel, your efforts are hugely appreciated and you are much respected I'm sure). Or do I have it completely wrong and the fpc-devel list is small so anything goes? Another message that doesn't add valuable content! (This one). Are there rules or guidelines for what gets discussed here and how? My suggestion would be to go through a checklist like this before you hit the Reply button: 1. Is it a. a relevant question; or b. a helpful answer (will someone learn from it?); or c. a well thought-out technical argument to an important debate (with examples, references, etc)? d. none of the above (No) 2. Did I spend more than a few minutes crafting it? 3. Have I re-read it at least 3 times before imposing it onto thousands of inboxes and committing it to permanent record? If your answer is No to any of the above, consider working on your message a bit more or not sending it. These messages generate content that will outlive us all. Tip (imo): if a message doesn't start with a salutation, perhaps then the checklist needs to be consulted. (And listing your credentials and extensive experience might only be of interest to a recruiter). Or perhaps a little chit-chat is OK too. We are a community of social animals after all. But perhaps we can restrain ourselves on days with lots of posts so as to not lose readers? Or perhaps we don't care about losing lurkers like myself. You decide, but my delete-button-finger is aching! Kind regards, Paul. B.t.w. this message fails my proposed checklist! ;-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug?
On 2010/01/31 10:30 AM, Daniël Mantione wrote:
This behaviour is intentional to allow you to read instead of just
write the function result. The incompatibility just affects recursive
procedures without parameters, which seldomly occurs, because normally
the parameters determine the behaviour of the function, and a
recursive function without parameters would prevent you writing a
mechanism that makes the recursive function terminate.
Only if the behaviour of the recursive function is controller by
global variables, then you can actually write a recursive function
without parameters. Because this is so seldom, and the desire to read
from the function result is extremely common, there is a strong case
for this behaviour.
OK, thanks. Also to Cobines for pointing out $mode delphi works as (I)
expected. I'm deliberately writing new units to compile with $mode
objfpc so I still have lots to learn. I do think a compiler hint would
be nice, either at the method declaration ("Hint: Overloaded function
without parameters may conflict with function result value.") or when
using the function name as the result in code ("Hint: Ambiguous use of
function name; use () if you wanted to call the overloaded function
instead"). Or perhaps I must get used to using() for functions without
parameters, and even better: give me another $mode where (like C++)
MethodName; is equivalent to @MethodName, so I'd be forced to use (). :-)
Indeed Borland did invent "result" as a method to read from the
function result, so FPC had to support that too.
I must say I prefer Result. It reads much easier, so I'd say it is more
to the spirit of Pascal than to have to use () to disambiguate things.
(So Borland /did/ actually invent some useful stuff)
Being able to read the result is +1 Pascal, -1 C. If only I can have
"var I, J: Integer;" anywhere between a begin and end and (inline)
method implementations inside class definitions... sigh :-)
And to regain my productivity: to figure out how to debug with Lazarus
the way I'm used to in Delphi...
Regards,
Paul.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug?
Of course Thanks Cobines! I have never used the function name instead of "Result", but of course you can. Using () after a function to me seems so C-like and un-Pascallish but it works. But it is things like this that trip up people coming from Delphi, I guess. Isn't this a potential improvement to the compiler though: scan for overloaded functions before assuming that it is the result value (like Delphi does)? (Or warn about overloaded functions without parameters, similar to mode objfpc disallowing parameter names that are the same as methods?) On 2010/01/31 09:46 AM, cobines wrote: Isn't the "GetValue_overloaded" in 1: Result:=GetValue_overloaded the return value of the function? Maybe you should call it this way: Result:= GetValue_overloaded() That's why I think you get the warning. The reason you might be getting random results is that the return value has not been initialized. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Compiler bug?
Hi All,
I hope I'm doing something really dumb, but I have to say it is stuff
like this that is really disheartening to me. I've been using
FPC/Lazarus for a year now and I have to report that my rate of
development (compared to Delphi) has slowed down significantly...
The following simple program shows that calling an overloaded method
from its "twin" returns garbage:
program project1;
{$mode objfpc}{$H+}
type
TMyClass = class
public
function GetValue_not_overloaded: Integer;
function GetValue_overloaded: Integer; //overload; -- nice feature
not having to specify "overload"!
function GetValue_overloaded(SomeValue: Integer): Integer; //overload;
end;
function TMyClass.GetValue_not_overloaded: Integer;
begin
Result:=1;
end;
function TMyClass.GetValue_overloaded: Integer;
begin
Result:=2;
end;
function TMyClass.GetValue_overloaded(SomeValue: Integer): Integer;
begin
case SomeValue of
1: Result:=GetValue_overloaded; // compiler warning: "Function
result variable does not seem to be initialized" (!)
2: Result:=GetValue_not_overloaded;
else
Result:=3;
end;
end;
var
C: TMyClass;
R: Integer;
begin
C:=TMyClass.Create;
R:=C.GetValue_overloaded; // direct call works
WriteLn('Correct value: ', R);
R:=C.GetValue_overloaded(2); // overloaded function calls non
overloaded function, works
WriteLn('Correct value: ', R);
R:=C.GetValue_overloaded(1); // should return 2, I'm getting random
numbers starting with 422...
WriteLn('Random value: ', R);
ReadLn;
end.
I have tested this with Lazarus 0.9.28.2 (release) and its FPC 2.2.4, a
fresh build of Lazarus from SVN and FPC 2.4.1 as well as FPC 2.5.1 from
SVN. The only difference is the actual incorrect value returned! The
value isn't really random, it is the same each time a specific binary is
run and always start with 422...
FPC 2.2.4: 4221677
FPC 2.4.1: 4223590
FPC 2.5.1: 4220774
Now (assuming I'm not doing something dumb) if this had been a bug in
FPC trunk I can understand, but how can such a (common?) use case not
have been spotted over all these versions?
Perhaps it is bad form to use overloaded functions in such a way, and
perhaps I'm just frustrated because I'm using an old version of Delphi
to debug my code, then when I compile it in Lazarus my app implodes. I
like the latest debugger improvements but I still cannot inspect an
array element. (If there is a way, please let me know).
Regards,
Paul.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Record with dynamic array of same type
I can't even compile it with FPC 2.0.4 (the oldest FPC version I have lying around, and which was released in August 2006). What was the previous FPC version that you used and which could compile the above? (And if there is a good reason, could the error message be more descriptive?) I guess it should be possible to give an error similar to what Kylix does: tt.pp(9) Error: Type 'TMyRecord' is not yet completely defined Sorry, I was confused. It must have been something I tried some months ago and abandoned. The source file is more recent than the compiled executable. I do hope someday soon it will be possible with FPC to TMyRecord = record Id: Integer; Name: String; ChildRecords: array of TMyRecord; end; :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Record with dynamic array of same type
Hi All, In the beginning of this year I could compile this: TMyRecord = record Id: Integer; Name: String; ChildRecords: array of TMyRecord; end; ...but now with FPC 2.2.4 I get "Error: Illegal expression" on line 4 Why the change? (And if there is a good reason, could the error message be more descriptive?) Regards, Paul. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
