“new” keyword and “default” constructors

DWScript SVN version just introduced support for the “new” keyword and “default” constructors.

The syntax is similar to that of Oxygene/Prism, you can now create a new instance with

obj1 := new TSomeObject;
obj2 := new TSomeOtherObject(param1, param2);

By default, the above syntax will be duck-typed to the .Create constructor of a given class, but you can alternatively specify a “default” constructor (one per class) to select a specific named constructor that “new” will use:

type TSomeClass = class
   constructor ImTheOne; default;
end;

The Oxygene syntax is also extended in two ways, you can use “new” on a metaclass variable:

type TSomeObjectClass = class of TSomeObject;
...
var ref : TSomeObjectClass;
...
obj := new ref;

And you can further use it on an expression that returns a metaclass by placing it between brackets:

function TOtherClass.GetMetaClass : TSomeObjectClass;
...
var o : TOtherClass;
...
obj := new (o.GetMetaClass)(param1, param2);

The brackets are not just there to make it look like Turbo Pascal-era code, they are required for disambiguation, f.i. the two lines

obj1 := new TSomeClass(param);
obj2 := new (TSomeClass(param));

are compiled as a syntax variation of

obj1 := TSomeClass.Create(param);
obj2 := TSomeClass(param).Create;

The “new” keyword is also planned to be used as the basis of dynamic array instantiation.

Faster compiler, constant records, $include_once

Executive summary of recent DWS changes from the bleeding edge:

  • Compiler/parser performance improved by about 15%.
  • Added support for constant records declaration.
  • The $include_once directive is now supported, it will include a file only if it hasn’t been already included (be it by a previous $include_once or a regular $include).
  • Fixed some issues with script-side Exception.StackTrace method for wrapped Delphi-side exceptions.
  • Fixed-size arrays accesses with constant indexes are now checked at compile-time.
  • Multiple minor fixes, refactorings, minor optimizations and unit test coverage improvements.

Something “big” is also brewing in the DWScript lab, if not quite ready for prime-time just yet 😉

A Fistful of TMonitors

…or why you can’t hide under the complexity carpet 😉

As uncovered in previous episodes, one of the keys behind TMonitor performance issues is that it allocates a dynamic block of memory for its locking purposes, and when those blocks end up allocated on the same CPU cache line, the two TMonitor on the same cache line will end up fighting for the cache line, resulting in a drastic drop of performance and thread contention. The technical term for that behavior is false sharing.
(more…)