32bit on Windows 64-bit uses Wow64.. which has a bit of overhead as an
emulation layer. I believe it's the same one they use for ARM64 too. I can only
guess at how optimally it works performance-wise, but compiling a couple
thousand-liner utils was annoying. You could (at least on the machine I
-free.ru/gorg_public_a_1.0001.7z
Thank You,
Alexander
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
looks like threadid is assigned to getcurrentthreadid in an initthread()
function in thread.inc.
but: getcurrentthreadid looks to be mapped to a changeable thread manager which
is why that might seem weird in the docs..
--
Alexander Grotewohl
https://dcclost.com
"break" is a windows built-in. explains the first attempt.
--
Alexander Grotewohl
https://dcclost.com
From: fpc-devel on behalf of Tomas
Hajny via fpc-devel
Sent: Friday, November 27, 2020 11:16:26 AM
To: FPC developers' list
Cc: Tomas Hajny
Su
is needed to compile.
--
Regards,
Alexander
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
"make all install OS_TARGET=win32 CPU_TARGET=i386
FPC=C:\FPC\3.2.0\bin\i386-win32\fpc.exe" (since my machine is 64-bit
Windows)
Just now successfully compiled both i386-win32 and x86_64-win64 from
trunk r47572 with release FPC 3.2.0.
--
Regards,
[0;3'+ansi_colors[fg]+';4'+ansi_colors[bg]+'m'+s+#27+'[0m';
writeln(tmp);
end;
begin
PrintColor(2, 0, 'derp');
end.
Easy enough to remember pascal style color numbers.
--
Alexander Grotewohl
https://dcclost.com
From: fpc-
would -a disable optimizations? i guess it'd depend on the intended use of the
listings it generated
--
Alexander Grotewohl
https://dcclost.com
From: fpc-devel on behalf of J. Gareth
Moreton
Sent: Saturday, July 18, 2020 11:09:29 PM
To: FPC developers&
you're not using the crt unit are you? first because i think it doesn't support
utf8 and second because i think you can cause this by doing "if keypressed.."
without then doing readkey before exit.
--
Alexander Grotewohl
https://dcclost.com
Congrats to the FPC team for being a bit above the rest ;)
--
Alexander Grotewohl
https://dcclost.com
From: fpc-devel on behalf of Bart via
fpc-devel
Sent: Wednesday, April 22, 2020 4:21:03 PM
To: fpc-devel
Cc: Bart
Subject: [fpc-devel] FPC now supports
same.. lol
--
Alexander Grotewohl
https://dcclost.com
From: fpc-devel on behalf of Michael
Ring via fpc-devel
Sent: Wednesday, April 22, 2020 8:21:55 AM
To: fpc-devel@lists.freepascal.org
Cc: Michael Ring
Subject: Re: [fpc-devel] Possible error in generated
t are you also providing other memory
functions, for example to allocate? Is it passing a valid pointer back (one
that eventually gets to memset)?
Just a bit of a brainstorm.. sorry if I've oversimplified or missed the mark
entirely :)
--
Alexander Grotewohl
https://d
Hi,
Am 19.02.20 um 09:08 schrieb thaddy:
> Raspberry Pi, what OS, because you write armsf and the default on
> Raspbian (and other major distro's) is armhf.
Raspbian, which is armhf, yes.
The application is based on the hard-float ABI (just checked with
readelf -h). Still it is using the soft-fl
Dear all,
while investigating a bug in an application designed for ARM with
floating point emulation enabled, I stumbled upon the following problem:
When rounding large numbers to int64, some actually get rounded to
something negative, e.g:
round(1.5000E+018) => 150
or maybe don't use the variable name "result" because it might point to the special delphi "result" var and not yours?--Alexander Grotewohlhttp://dcclost.comOn Sep 28, 2019 4:15 PM, Alexander Grotewohl wrote:don't know off the top of my head but does the ord() bit se
wrong.--Alexander Grotewohlhttp://dcclost.comOn Sep 28, 2019 3:21 PM, Ozz Nixon wrote:When I evaluate the code - it is perfect. However, when I run the code, it raises a SIGSEGV - Segmentation fault. Yet, the code runs perfectly on Linux 64bit machine, and Mac
I'm assuming that's what the 'statementlist' means in the documentation
(rather than just 'statement')
On 9/19/2019 3:33 PM, Sven Barth via fpc-devel wrote:
Am 19.09.2019 um 21:07 schrieb Kirinn:
I've stumbled on a situation where a case statement compiles when I
wouldn't expect it to. I would
I miss the sushi in Japan too my dude.--Alexander Grotewohlhttp://dcclost.comOn Jun 16, 2019 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 ser
It seems to be working tho--Alexander Grotewohlhttp://dcclost.com___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
can't you just use an untyped parameter in a clearmem procedure you make yourself?procedure ClearMem(var m);--Alexander Grotewohlhttp://dcclost.com___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/ma
}
{
Unit for playing melodys on PC-Speaker.
For GNU/Linux 64 bit version. Root priveleges needed.
Written on FreePascal.
Copyright (C) 2019 Artyomov Alexander
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public
Not to mention the users who pick up FPC and have to port what they've
previously learned. That information is useful even if the 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
Windows.
I known cross-platform method, but say not about it.
For GNU/Linux need RAD IDE coincide power and possibles. This **systems** not
equal.
On Mon, 17 Sep 2018 08:53:23 -0700
Ralf Quint wrote:
> On 9/17/2018 6:08 AM, Alexander via fpc-devel wrote:
> > Why not allowed ?
&g
.
On Mon, 17 Sep 2018 14:21:54 +0200
Martin Schreiber wrote:
> Hi Alexander,
>
> It is not allowed to discuss MSEide+MSEgui themes here. I will answer on the
> MSEide+MSEgui mailing list:
>
> https://sourceforge.net/projects/mseide-msegui/lists/mseide-msegui-talk
> Archiv
**
issues ?
On nonfree drivers delays minimized and MSE have time for display img ?
Incorrect architecture for xorg ?
On Mon, 17 Sep 2018 08:46:08 +0200
Martin Schreiber wrote:
> On Monday 17 September 2018 05:51:17 Alexander via fpc-devel wrote:
>
> > I try use of MSEide,gui before
On Mon, 17 Sep 2018 07:52:24 +0200
Sven Barth via fpc-devel wrote:
> Alexander via fpc-devel schrieb am Mo.,
> 17. Sep. 2018, 07:20:
>
> > Lasarus use non native for FPC widgets, MSE non stable work.
> >
>
> Huh? Please explain that. Lazarus is *the* example for
plete.
By rework/combine exist IDEs or made new RAD IDE especially for GNU/Linux.
Good Luck,
Alexander.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
unexpected to the programmer, but to me this indicates
> using ranges with case of string is a bit dangerous.
>
> The trunk behaviour makes no sense to me at all.
>
> Is this a bug, or was it changed by design?
> If the latter, why?
>
Since I was involved in the design and imple
To be honest I agree with what he's saying. We're bending enums to do
things normal people just wouldn't (and shouldn't) do.
And seriously, "Delphi, Delphi, Delphi!" .. why don't we strive for
something a little better and make the people porting from Delphi bend a
little this way than us thei
concrete user experience.
This is IMHO a significant contributing factor of Pascal decline.
I would not argue this specific point (although I quite agree with Ondrej),
I just want to remind that the cost in terms of diminishing userbase
is real, and that makes me sad.
--
Alexander S. Klenin
_
https://www.freepascal.org/docs-html/ref/refse20.html#x50-680003.9
On 04/04/2018 01:32 PM, Ondrej Pokorny wrote:
On 04.04.2018 18:53, Jonas Maebe wrote:
On 04/04/18 18:44, Ondrej Pokorny wrote:
I want to stress that the compiler emits a warning on code that does
not have (and also cannot have
uses SysUtils; // inttostr
procedure blank(a: array of pointer);
var
i: longint;
begin
for i:=low(a) to high(a) do
// string(a[i]^):='';
string(a[i]^):='silly ~~~ '+IntToStr(i);
end;
var
s, i, l, {l,} y: string;
begin
blank([@s, @i, @l, {@l,} @y]);
writeln(s); writeln(i)
It sounds more like you're making a case for all integers to be
initialized to zero by default. I still fail to see any practical uses
other than wanting to not type "integer" twice.
Alex
On 03/24/2018 11:20 AM, Ondrej Pokorny wrote:
On 24.03.2018 15:46, Alexander Grotewohl w
03.03.2013 2:22, Sven Barth пишет:
On 02.03.2013 20:55, Sven Barth wrote:
Also there are open questions which require brainstorm:
1. Does Pascal needs other implementation of closures which is different
from anonymous methods implementation?
I would say no. After all the method implementation
On Wed, Mar 6, 2013 at 10:00 PM, Michael Schnell wrote:
> On 03/05/2013 05:17 PM, Alexander Klenin wrote:
>>
>> 1) Make sure "is" and "as" work with generic types -- maybe they already
>> are?
>
> "is" the generic type and/or "i
venient" types,
and use inheritance to factor out common code.
3) Implement partial specialization, in C++ style --
fundamental solution, but perhaps an overkill
in the light of the above.
--
Alexander S. Klenin
___
fpc-devel mailli
ting)
Is not "specialize" keyword there to prevent exactly this?
> specialize SomeType with (Something)
I would like to propose a modification to one of the principles we brought up
in this thread: "prefer keywords to punctuation ... but not to the
point of
ow why on earth the "sane" objFPC syntax still have
those angle brackets instead of normal round ones?
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
>> syntax is a nightmare to parse.
>
> But you need to anyway because of mode delphi, so what is the point?
It is hard to parse for humans as well as for the compiler.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.fr
extension may continue while the implementation
of (1) and (2) is in progress.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tue, Mar 5, 2013 at 3:34 AM, Martin wrote:
> On 04/03/2013 16:05, Alexander Klenin wrote:
>>
>> Anonymous functions (with good syntax, of course) fall in this category.
>> The world recognized that fact -- rather slowly, to be sure, but
>> remember that "while&q
gnment,
since ATree.VisitPreorder(TVisitor(X + 5)); is syntactically ambiguous.
So it becomes
ATree.VisitPreorder(TVisitor(Result := X + 5));
vs
ATree.VisitPreorder(lambda TVisitor as X + 5);
Finally, I disagree with unbalanced parenthesis -- but that's probably a typo?
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
a:
http://en.wikipedia.org/wiki/Ada_(programming_language)#.22Hello.2C_world.21.22_in_Ada
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
t.
> I dare you to propose a new movement or a new piece, and see how the chess
> community reacts.
With enthusiasm. See http://en.wikipedia.org/wiki/Chess_variant
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
th "lambda" and "as" syntax:
ATree.VisitPreorder(lambda TVisitor as X + 5);
Now, my argument is that (2) does indeed have only a marginal
advantage over (1),
but (4) is powerful enough to really make functional-style programming
practically
useful (as opposed to theoretica
*named* closure too
Also, Boian, I appreciate your enthusiasm very much, but please read
this thread from the start --
the implementation details you mention are extensively described in
the documents linked
from the first message.
--
Alexander S. Klenin
ymous procedure,
or intelligent enough optimizer to do that automatically. I have
some ideas on both fronts,
but I suggest we first discuss previous points.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
entClass;
);
P. S. Boian, could you please
stop top-posting and splitting your thoughts into so many emails?
It will make discussion much easier to follow.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.or
to the language at
various stages of its development -- some at the inception, some later.
Now, that does not mean that a particular Delphi implementation of
some features is optimal, and we do discuss options in this thread.
--
Alexander S. Klenin
___
fpc-d
agree with the plan. But I am not sure about the order -- perhaps
implement Delphi-compatible variant first, since it have to be done anyway,
and there is already a spec for it.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepasc
kname "mbait").
I am not suitable to the role of mentor in GSoC sense, since I am not
committer to
either of these projects, but I still can provide some help to my
students, if they choose to participate.
--
Alexander S. Klenin
___
fpc-devel
l, tuples will not be a type,
so you'll have to force a type by constructor:
s := TPoint(x,y).ToString;
or, as it is currently, by a special function:
s := Point(x,y).ToString;
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepa
On Sat, Feb 2, 2013 at 7:42 PM, Nikolai Zhubr wrote:
>
> Apparently the test suite database needs some love?
Wow, I did not even know such a thing existed! How is it populated?
--
Alexander S. Klenin
___
fpc-devel maillist - fpc
icated IMO:
> if f(x, res) then ...
> has to be rewritten as
> res, error := f(x); //or: (res,error) := f(x);?
> if error then ...
That depends on the type or err
> That's why I wonder about yet another syntax proposal. Your proposal
> *requires* that a record/tu
ry layout without VMT.
Oops... so, FPC "object" type always creates VMT -- even if there is
no virtual methods?
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
; "records without field names".
>
> I'm not sure what you exactly mean. In my proposal, that tuples are nothing
> but records, it's immediately clear whether and how every syntax extension
> can be implemented. Any "decoupling" risks to run into dead ends, because
> the implementation efforts are unpredictable.
I mean not decoupling of records, just of suggestion to allow defining
record types without field names.
> It would help a lot in understanding your ideas, when you mention the
> record-based implementation for every proposed syntax extension.
Will try -- I thought implementation was obvious (which does not mean
it is easy, of course).
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
nstructors).
So I would much prefer
TIntegerDynArray(1, 2, 3), TIntegerDynArray([1, 2, 3]), or maybe even
just [1, 2, 3] if appropriate automatic conversions are defined.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Mon, Jan 28, 2013 at 2:59 AM, Michael Van Canneyt
wrote:
>
>
> On Mon, 28 Jan 2013, Alexander Klenin wrote:
>> I have a compromise suggestion:
>> Implement for-index extension with the syntax:
>> for (k, v) in a do
>> this syntax is forward-compatible with bo
interface with optional
property CurrentWithKey: TValueKey
where TValueKey must be a record of two (or perhaps even more) fields.
for k, v in a do
will call CurrentWithKey for each item, assign first field to k, second -- to v.
When/if tuples will be introduced, no change will be needed here.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
number of magic operators,
since it unifies the meaning of comma-in-parameter-list, comma-in-open-array
and comma-in-array-index to be the same comma-in-tuple.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
quired)
and will give immediate benefit regardless of outcome of larger discussion.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
atter of taste,
and while I, by definition, think that my taste is best of all,
I'm quite aware that others may disagree with that :)
I'd just like to restate that, IMO, not much is gained by writing
TKeyValye = tuple (String, Integer); // Sven's variant
vs
TKeyValue = record key
if the expression becomes complex, programmes may add brackets --
as is already the case with other expressions.
OTOH, this is the point I am willing to concede --
the difference is rather small.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-
d be defined on array type.
> IMO tuples are *abstract* templates (mathematical notation) for *concrete*
> (record...) implementations. I see no need or purpose in the introduction of
> such an abstract type into any concrete language, except when that languages
> lacks an already exi
On Sun, Jan 27, 2013 at 12:11 PM, Alexander Klenin wrote:
> Nothin useful is gained by abbing extra pair of brackets.
Sorry, I mean "Nothing useful is gained by adding ..."
--
Alexander S. Klenin
___
fpc-devel maillist
tuple.
As Sven pointed out, the main problem with that is that expression type now
suddenly depends on context, which is quite a rare feature in
programming languages,
and is probably much bugger change to Pascal than this whole tuple business.
OTOH, define Tuple(x, 5) to mean (x, x,
y list (most importantly generics once type helpers
> are commited), so Alexander is free to give the task for implementation to
> his student.
>
Heh, I have started to write similar in form, but different in
substance proposal, but needed some sleep,
and you have beaten me to it :)
I want to
On Sun, Jan 27, 2013 at 3:51 AM, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
>> >
>> > Please take a look at this:
>> > http://blog.barrkel.com/2010/01/using-anonymous-methods-in-method.html
>>
>> While this article
On Sun, Jan 27, 2013 at 3:10 AM, Sven Barth wrote:
> On 26.01.2013 16:34, Alexander Klenin wrote:
>> Ok, then let's take just one step back:
>> SomeProc(lambda TProc1 as Writeln(aArg));
>>
>> This way, but problems are solved -- procedure type is specified
>>
he same value is
particularly important
compared to the general case of mass-assignment of arbitrary values.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ay,
I suspect the cost will be negligible, especially with the help of
clever enough optimizer.
Further, after that, since all events will become object instances anyway,
C#-style event stacking may become feasible, replacing rather cumbersome
hand-made chainin
On Sat, Jan 26, 2013 at 8:31 PM, Sven Barth wrote:
> On 25.01.2013 23:57, Alexander Klenin wrote:
>> You have also proposed lambda-expressions:
>>>
>>> map.Iterate(lambda TFPGMapLongInt.TIteratorProc(aKey, aData) as
>>> Writeln(aKey, ' => ', aDat
On Sun, Jan 27, 2013 at 12:26 AM, Paul Ishenin wrote:
> 26.01.13, 6:57, Alexander Klenin пишет:
>
> Why to invent a new solution if Delphi already have one:
> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/anonymousmethods_xml.html
>
On Sat, Jan 26, 2013 at 3:14 PM, Hans-Peter Diettrich
wrote:
> Alexander Klenin schrieb:
>> 2) Indeed, introducing tuples to Pascal might be an alternative
>> solution. Below is a proposal:
>> 2.1) Tuple definition. Tuple is an anonymous list of values, possibly
>> of
ay;
ProcWithmanyParams(@@p);
... etc
unfortunately, this will also require
for @@(v, i) in a do
which is not nice.
Another possibility is to resolve single element in brackets in favor
of a simple value, and require explicit call to Tuple
to disambiguate -- single-element tuples are useless anywa
w aka "for-key-in", will became a proper subset of it.
What do you think?
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
t when
>> using generics.
>
> Ah! So that is where those ifdefs in classes come from :) I always
> wondered...
>
Is the drop still present/essential? Perhaps optimizer is now good
enough to drop those ifdefs?
--
Alexander S. Klenin
__
ot its generics from .NET. The .NET compiler got it one version
> earlier. (D2007, native D2009)
>
> Probably the main reason for generics was access the 2.0 framework which was
> new (and used generics) going from D2006 to D2007
Quite probably, but that is still no reason for a
ce"
for so frequent usage.
A global generic functions (they are planned anyway, aren't they?)
will be sufficient:
Iterate :map :lambda
Writeln(aKey, ' => ', aData.ClassName);
end;
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
TFPGListLongInt = specialize TFPGList with (Integer);
>
Whatever the particular syntax, I do agree that the decision to use
angular brackets
was unnecessarily copied from C++ -- round ones (or, at least, square
ones) would be much better.
--
Alexander S. Klenin
thing it.
Still, if my proposal would be implemented, it is will also become
possible in FPC to allow
anonymous records as return types -- the user will have to use tuples
to deconstruct them.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-
posal could be better.
In my defense I could say that it is still better than for (almost?)
any other feature implemented in the last couple of years.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepasc
rence only.
User-defined iterators may return records with fields (value, key).
In the case of
for v in a
v may now be either a record or just a value, depending on the type.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
is could be useful for STL sets
for v key i in a do // new keyword = bad
> and is completely unlike any existing language idioms.
Do you mean idioms existing in Pascal, or general language idioms?
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
but I hope it demonstrates unambiguously the popularity of the feature.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl wrote:
> Am 25.01.2013 18:17, schrieb Alexander Klenin:
>>> Using indicies is against all principles of iterators.
>> I am not sure what princilpes you are talking about,
>
> The theory of iterators.
You mean Alexande
> // on a sidenote: what about a TDataSet enumerator? :)
It is not clear what should loop variable contain:
for v in MyDataSet do ... -- what is v?
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
e is a lack of a key. The fundamentalistic view then says we
> should not have for-in in Pascal, because it changes the fundamental
> property of a for-loop.
"fundamentalistic" is a right word here.
> For pragmantic reasons the for-in syn
, by contrast, is so simple that any 12-year old can
> get it.
Actually, I do teach young students (12 years old is somewhat too
young, but 13-14 is usual).
I can tell you they have *more* trouble with Pascal style of loop with indexing
as compared to Python's for-each with index.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
uot;traditional" form of loop is not even possible.
4) If there is no uniform method for iterating over containers, then
each container will define its own method,
with the end result that the language will be *more* complex for the
user, who will have to remember all these methods.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
en the first one,
regardless of the fact that is uses "simpler" language.
And yes, I have code for the second example in my working copy of
improved fcl-stl.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Fri, Jan 25, 2013 at 10:38 AM, Graeme Geldenhuys
wrote:
> On 01/24/13 23:26, Alexander Klenin wrote:
>>>>> If you want full fledged iterators, use classes.
>>>>
>>>> Please provide example of your suggestion for the case in the wiki.
>>>
>
On Fri, Jan 25, 2013 at 10:13 AM, Graeme Geldenhuys
wrote:
> On 01/24/13 19:36, Alexander Klenin wrote:
>>> Enumerators are not iterators.
>> Eh... actually, they are? Why do you think otherwise?
>
> Enumerators are limited in functionality. Iterators are the full-blown
It only for for-in last year, in the latest version of the standard.
I think it is reasonable to assume that next version of C++ might
include "for-in-index" syntax.
Unfortunately, I also think it is reasonable to estimate the timeframe
for that version as 5-7 years at least.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Fri, Jan 25, 2013 at 8:44 AM, Florian Klämpfl wrote:
> Am 24.01.2013 22:26, schrieb Alexander Klenin:
>> in all three cases, the effect will be more-or-less the same.
>
> In the first two cases the programmer knows that he does something
> strange, actually he can even adju
x27; ', c);
DeleteSomePartOfS;
i += 1;
end;
for c in s index i do begin
Writeln(i, ' ', c);
DeleteSomePartOfS;
end;
in all three cases, the effect will be more-or-less the same.
(Actually, my testing demonstrated that for-in loop does NOT cause a
that guideline.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Fri, Jan 25, 2013 at 7:30 AM, Florian Klämpfl wrote:
> Am 24.01.2013 20:36, schrieb Alexander Klenin:
>> That's debatable.
>
> As long as there is only some few line idea, there cannot debated much.
It is more: an idea with implementation and tests ;)
> Just an examp
not then the for loop can only behave as current for in loops.
>
Of course.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
n for the case in the wiki.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
1 - 100 of 411 matches
Mail list logo
