So when do we get this one then? ;-)

http://homepages.borland.com/dthorpe/blog/delphi/2004_08_01_archive.php#1092 11211041479238

Matt

So when do we get this one then? ;-) http://homepages.borland.com/dthorpe/blog/delphi/2004_08_01_archive.php#1092 11211041479238

Is it allowed for D9 win32 target?

If it is .not only, see the .NET faq item.

In another article I read on the same subject, this will not be just a .net feature. As a matter of fact most of the new constructs in D9 will be for win32 as well as .net

Is it allowed for D9 win32 target?

We'll have to wait for BorCon04.

If it is .not only, see the .NET faq item.

But it *is* a fairly standard concept (foreach is the widely used keyword..). It *will* arrive in Win32 at some point (if another Win32 version is released) and so why not get the jump on it? ;-) Make it ObjFPC if it's that troublesome ;-)

Matt

In another article I read on the same subject, this will not be just a .net feature. As a matter of fact most of the new constructs in D9 will be for win32 as well as .net

catch up time again ;-)

Matt

It appears in automated languages with in language container types.

How many native code generating compilers do you know with this construct?

. It *will* arrive in Win32 at some point (if another Win32

version is released) and so why not get the jump on it? ;-) Make it ObjFPC if it's that troublesome ;-)

It will depend if the implementation possibilities are sane, and if D9/win32 compability is to say before more data is available

Matt Emson wrote

> Is it allowed for D9 win32 target? We'll have to wait for BorCon04.

No it actually says that this will be for Win32 as well. I see no reason why it would not be.

Obviously they are at loss for features, so the 'far-fetched constructs' drawer was wide opened. I can understand the array, set and enumerated parts, because they are part of the pascal language.

But the IEnumerated interface part is really over the top. It requires the compiler to have 'knowledge' of certain complex types, which is a bad thing and totally arbitrary.

The last time they did that was with Variants, which has been a dirty mess every since. It destroys the beauty and strict typing of Object Pascal...

Michael.

04-08-11 21.08, skrev följande:

Isn't this the same with exception handling, which requires knowledge of Exception class.

Also, here is a forwarding of a question I asked on their discussion forum:

--------------------------------------

Is the iteration order guarantied, or is it undefined ?

In the latter case it allows the compiler to choose an optimized order, or to use several threads.
Olle Raab , 11.08.2004, 11:02am [link] [hide]

--------------------------------------

Olle: The iteration order when using IEnumerable interfaces is defined by the implementor of the interface, not by the language syntax. It is quite possible that the IEnumerable implementor may order or filter the returned data.

For data patterns, the for..in loop is equivalent to for x := Low(range) to High(Range) do. Note that loop induction optimizations may cause the generated machine code to use some other index representation, including eliminating the index entirely (increment pointer instead of index into array) or inverting the range (high to low, normalize by subtraction) but that the visible artifact is always low to high.

We have discussed unordered enumerators, specifically in the context of distributing serial loop iterations across multiple threads. This will only be done through a syntax extension that changes the language definition to allow out of order enumeration in that specific syntax. Danny Thorpe , 11.08.2004, 11:13am [link] [hide]

-------------------------------------

No, because you can raise an exception with any TObject. By default, the 'Exception' class is used as a base class, because it allows to set some standard message. There is no way for the RTL to know how to 'show' a TObject. In SysUtils, Exception is defined, and can be shown because it's 'message' property is known. SysUtils also sets a handler so the RTL can 'show' an Exception.

home: >ppc386 testp.pp
home: >./testp
Runtime error 217 at $08052074
$08052074
$080520CC
$0805B32B

home: >cat testp.pp
{$mode objfpc}
program testp;
begin
  Raise TObject.Create;
end.

So the compiler is 'agnostic' when it comes to exceptions. TObject is the base of all classes, so it is not arbitrary, it's part of the Object Pascal language specification.

I would prefer the compiler to stay agnostic when it comes to complex types such as variants, interfaces or whatever. At Borland, they obviously don't.

I remember making a remark once to a Borland Employee saying that "it is heresy to introduce Variants in a strongly typed language such as Pascal" to which I got the reply 'Yes, but the OS (=Win32) uses it, so...' :)

Reading the answer you got to the question of ordering, you hit the nail on the head. There is no way the compiler can guarantee the order of a certain IEnumerable interface. It depends entirely on the implementation...

It's of course something to show off with on developer conferences with a an audience of VB or Java programmers :-)

Michael.

> But it *is* a fairly standard concept (foreach is the widely used > keyword..) It appears in automated languages with in language container types.

Off the top of my head - Digital Mars D - fully compilerd native executable. There are more.

Matt

I don't like the very unspecific implementation. In properly designed languages/libraries there are several kinds of iterators, see e.g. the STL.

But is an iterator a language construct in C++ or just a standard STL class implementation ?

Michael.

I don't like the very unspecific implementation. In [SNIP, as this is a

matter of opinion, replace this with "other"]

languages/libraries there are several kinds of iterators, see e.g. the

STL.

Exactly, which is why I prefer the idea Borland has gone for. The STL is not a good idea.

Matt

But is an iterator a language construct in C++ or just a standard STL class implementation ?

The latter. STL is a syntactical nightmare and simply a preprocessor "hack". You could add a similar, external "hack" to FPC with a few months work. However, what's the point? Look at Digital Mars D. This language has a better way of doing things.

Matt

Huh? Templates and operator overloading afaik?

I thought is the MI, C++'s own baroque syntax and custom operator overloading the root of those problems.

Generic programming(templates) can be done cleanly it seems, see Ada, Java, C# etc, so that is not it.

And I think generic programming is eons more powerful and useful than this D9 syntactic sugar.

And I think generic programming is eons more powerful and useful than this D9 syntactic sugar.

As generics are in a [future?] version of .Net and D9 will implement a *lot* of new language features in Win32, generics may happen.

Matt

I doubt in D9, since otherwise they would have realised foreach in such way.

Matt Emson wrote

>I don't like the very unspecific implementation. In [SNIP, as this is a matter of opinion, replace this with "other"]

That's what I meant however my keyboard ate it ;)

The behaviour of the d9 iterators appear to me very unspecific. In which order does it iterate through the elements? What happens if I delete an element while iterating, maybe even the current. Does an iterator stay valid if I remove the element from the container? How can I change how the iterator behaves? etc.

I doubt in D9, since otherwise they would have realised foreach in such way.

No, this assertion is wrong. I'm not saying they *will* add the fore mentioned functionality, but foreach is part of the .Net standard constructs. C# has it, as does VB.Net. I expect this has come about as a way of keeping in line with those languages. They, after all, will also have generics at some point in the future too. It being back ported to Win32 can only be seen as a positive statement from Borland R&D etc.

Matt

Matt Emson wrote

Exactly, which is why I prefer the idea Borland has gone for. The STL is not a good idea.

Delphi doesn't have a decent containers library. TObjectList is derived from TList instead as being designed as a wrapper (if Borland had read the Danny Thorpe's book they would not implement it this way :-). TStringList is a cute class (I like it very much) and is an swiss army knife for Delphi, but nothing more, there are cases where other containers could do better.
Where are Hash Tables, B-Trees, etc? A simple interface for lists is not an innovation IMHO.
Ciao, Dean

Hello,

I think this is because the origin of this information is only a blog entry, no specification...

order does it iterate through the elements? What happens if I delete an element while iterating, maybe even the current. Does an iterator stay valid if I remove the element from the container?

See below.

How can I change how the iterator behaves? etc.

Implement the interface methods for iterating over the class according to one's wishes I suppose.

---

For Arrays: as indicated it's just a shorthand for a "for i := low(arr)
to high(arr) ...."

For IEnumerable: I guess they'll comply to the behaviour of the IEnumerable interface of .NET, so have a look there:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemcollectionsienumeratorclasstopic.asp

Outline:
- if the collection is changed while iterating over it, IEnumerable throws an exception
- no inherent thread safety
- behaviour (e.g. iteration order) specific to implementation

I think this syntactic sugar construct is better than nothing: At least I make a lot of mistakes regarding lost "-1" when specifying the upper bound when writing code to iterate over a TStringList or similar - or the imo stupid and repetitive "for i := low(xy) to high(xy) do begin" sequences all over the place in case of normal arrays.

What's more interesting for me is that it seems that there will be a Delphi compiler emitting native code again... :-)

Regards,
Thomas

One cent...