Some relevant Bugs

Elements Oxygene
1

For loop iterator variable is changeable and it ignores the condition [i to x] and runs endless!
Have a look:

      for i := 0 to 10 do
      begin
        writeln(i);
        i := i + 1; ---------------------> actually this shouldnt work!
      end;

When i gets the value of 10, it just ignores the condition of: i to 10 and just continue running, even i gets the value of 11 and more

2)I dont actually know if this is a bug, but when i call DisposeAndNil(myRawIntPtr) it doesnt compile and throws some errors like: “Error: Unknow type element 138”

3)This case im not sure as well if this is by design or a bug, however:
When i want to create a custom rangetype, like:

          TCustomRange = -1..10000; 
          var v: TCustomRange ;
          //when i press Start, it throws this error:
           //"E(0) Internal Error: Unknown type ID: f"

4)This case im not sure as well if this is by design or a bug, however:
When i want to create a custom set of type, like:

 //------------------------------> was possible in Delphi/fpc/objectpascal as well                                        
TMySet = set of integer; //or
TAlphabet = set of 'A'..'Z';                   //was possible in Delphi and other Pascal dialect

5)This case im not sure as well if this is by design or a bug, however:
When i want to create a custom variant (C/C++ Union) type, like:

      TUnionType = record       //------------------------------> was possible in Delphi/fpc/objectpascal as well
      case IsTrue: boolean of
        True: (field1, field2, field3..fieldn: string);
        False: (field1: array[1..8] of byte);
      end;

best regards

Shpend

2

Thanks, logged as bugs://77271

3

Thanks, logged as bugs://77272

4

Thanks, logged as bugs://77273

5

We do supports sets, but only for limited subset, sets of integer shouldn’t be possibly in any language as it would take 2^32 bits, ie 536870912 bytes of memory.

We don’t support union types (not like that at least). On .NET we support FieldOffset/StructLayout, and on Island and Toffee we support [Union] as an attribute which makes each field in the struct be laid out at 0 (like union in c)

6

Can you tell me what platform you targetted to get these errors?

7

Thanks at first for the reply :slight_smile:

Sry i’ve forgotten to list my system-data:

Ok:
Windows 10
Intel i7 CPU
8GB DDR 3 RAM
Visual Studio Community 2015
RemObject Oxygene Island

8

Unfortunately, it still doesnt work on Island, here the code, i may be wrong at its syntax:

      Data = record	
        public
          [Union]
	  Field1: String;
          [Union]
	  Field2: Int32;
          [Union]
	  Field3: Boolean;
      end;
9

Hrmm, it should be placed on the record but it seems the attribute isn’t visible yet. I’ll log an issue for it thanks.

1 Like
10

Thanks, logged as bugs://77274

11

Meanwhile, can you tell me how you got the error for DisposeAndNil? That doesn’t seem to show here.

12

But just a thrown question, why did you actually put the variant record concept out of Oxygene?

I actually was thinking that this is a nice concept in both, C/C++ as well in pascal^^

Because i find that, you are able to do reall cool stuff with these concepts and often optimized/pwell performance stuff :stuck_out_tongue:

                begin
		  var mPtr: ^int64;
	          disposeAndNil(mPtr);
		end;    //raise: internal Error: Unknown Element 138
13

But, for instance: fpc did this like this:

http://www.freepascal.org/docs-html/3.0.0/ref/refsu17.html

Its about there intern Set defintion.

14

Mostly, because I really don’t like the way the syntax is in Pascal, it implies “Istrue” is a real thing, while it’s not.

But with unions (ie in vnext you can do this in Island and Toffee) the concept itself works fine:

type
  [Union]
  MyUnion = public record
    a: Double;
    b: Int64;
  end;

Yes but note the remark about “limited to 255 items”, set of integer has 2^32 items.

Thanks, reproduced. That shouldn’t compile at all, since ^Int64 has no dispose method.

15

Ah ok, thanks for your opinion :slight_smile:

My last question in my heart :joy: :joy:

Could you reintroduce the goto,label statements, for instance, as an extra compiler option or something like that, the thing is, why i am still interessted in those low-level concepts are, you have so much possibilities for own implementations, ideas and optimized, and well performed code, WHEN you know what you are doing^^

PS:
But DisposeAndNIl(…) doesnt even work for classes, nevermind which type of.

Where does DisposeAndNIl actually work?

16

They are supported:

ABC: ;
goto ABC;

the ; after : is required since we had : as an operator before introducing label. It can however also be used to break/continue out of multi level loops:

outerloop: 
  for i: Integer := 0 to 10 do begin
    for j: Integer := 0 to 15 do begin 
       ... break outerloop;
    end;
  end;
1 Like
17

bugs://77272 got closed with status fixed.

18

bugs://77274 got closed with status fixed.

19

really good!

Im pretty impressed how fast and precisely you work!

Would it be a point, to reintroduce the Mark “Label” for goto statements, IMHO its more symantic-sugar ^^
But just a little peek, would also not being a problem when not.

    Label ABC:
    ABC:
    begin
      //code which gets executed when gotois reached
    end;
  //More code....
    goto ABC
1 Like
20

yeah problem is that that’s not really the label syntax, it used to be:

label abc;
begin
  goto abc;
  abc:

end;

Introducing label as a keyword now would break all code that uses label as an identifier.