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 f
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 th
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 variabl
>
>
> > > 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
>
> 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 i
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
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
>
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
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 w
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 ..
> >
>
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...
>
>
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.
__
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@l
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 t
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 behaviou
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 imp
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 p
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 gue
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 mess
19 matches
Mail list logo
