Tool Palette API (native)

Better main Toolbar/menu services

Splash Screen and About Box services (native and managed)

Syntax highlighting services (adding new syntax highlighting styles)

Code-insight services (for adding new code-insight handlers)

Compiler

XML doc option for compiler in IDE

This compiler option will generate an XML file with the same "first name" as the original source file, in the same directory as the source file. All comments beginning with /// will be extracted into the XML file.

For example, if your source file is named "myfile.pas" the output file will be named "myfile.xml".

New for Win32 and .NET

for..in..do enumeration syntax

This enumeration syntax is commonly referred to as "foreach" syntax.

Function inlining

Diamondback has an INLINE compiler directive and compiler option {$INLINE AUTO|ON|OFF}. The INLINE directive can be specified at end of function declaration. and longname option {$INLINE ON/AUTO/OFF} can be specified before compiling function body (not for per statements).
{$INLINE ON} is the default. Inline function declared with INLINE directive will be expanded at the call site.
{$INLINE AUTO} is ike {$INLINE ON}, except the compiler tries to make an inline function even if the INLINE directive is not specified, if the function code size is less than or equal to 32 bytes. With {$INLINE OFF}, the inline directive is ignored for function declarations and inline functions are not expanded at the call site.
Here is a simple example.

{$APPTYPE CONSOLE}
procedure Sum(N :Integer): Integer; inline;
var
  I: Integer;
begin
  Result := 0;
  for I := 1 to N do
    Inc(Result, I);
end;
procedure Test;
begin
  WriteLn(Sum(10));
end;
begin
  Test;
end.

// procedure Test is equivalent to:
procedure Test;
var
  t1, t2, t3, t4: Integer;
begin
  t1 := 10;
  t2 := 0;
  for t3 := 1 to t1 do
    Inc(t2, t3);
  t4 := t2;
  WriteLn(t4);
end.

Inlining rules

1. Don''''t rely on $INLINE AUTO when you''''re trying to measure the performance or code differences of inlining.  $INLINE AUTO is more restrictive / less likely to select your routines for inlining than when you declare the function with the inline directive.
2. Look out for cross-unit effects.  Inlining a routine at a call site within its own unit is a very different situation than inlining a routine imported from another unit.  Also, compiling the other unit at the same time as compiling the call site (build all) is a different situation than inlining a function that was loaded from a precompiled.dcu.
3. $INLINE AUTO is considerably more experimental than declared inlines.  Our primary objective with $INLINE AUTO right now is to verify that your programs continue to work as they do without inlining, and maybe some functions get inlined here and there as well.  $INLINE AUTO will not be the default setting, will probably never be the default setting, and will not be recommended for general coding scenarios.  $INLINE ON is the default and recommended path.  $INLINE AUTO is the corner case.
4. It''''s acceptable for this release for the compiler to refuse to inline a routine in seemingly trivial situations.  We can sort out the corner cases on a time permitting basis as long as inlining works in specific useful cases.
5. When diagnosing a case that does not inline, carefully whittle down the contributing factors until the test case does inline:  parameters and local variables of the inlined function, parameters and local variables at the call site, same unit or cross-unit, build all or load from dcu, compiler options such as range checking or overflow checking, and so forth.
6. Functions are not inlined across package boundaries.  Functions can be inlined between units within a package, though.
7. Virtual methods are not inlined.  This includes methods declared virtual, dynamic, or message, and all methods of interfaces and dispinterfaces.
8. Functions are not inlined between circularly dependent units.  The interface and implementation sections of unit A must be fully compiled before unit B calls to functions in unit A may be inlined.
9. The RTL and VCL will receive light inlining (by explicit declaration) where the benefits are the greatest.  The "macro" functions in Windows.pas, for example, will be marked for inlining. VCL in general, though, will not be marked for extensive inlining, partly for schedule reasons and partly because the VCL core units are heavily circular.
10. Functions implemented using asm blocks are not inlinable.
11. Functions with open array parameters are not inlinable.  (dynamic arrays and static arrays are ok)
12. Functions that refer to private or protected members of a class are not inlinable except within methods of that class itself (or possibly descendents, in the case of protected)
13. Functions that refer to symbols declared in the implementation section of a unit are not inlinable.  Such types are not addressable outside of their unit of definition.
14. This list is not complete and may contain errors or omissions.

support for compiling Unicode and UTF8 source files

Multi-unit namespaces

Unicode identifiers

The Delphi compiler now supports Unicode characters in source code identifiers, and in symbols imported from assembly metadata.

• Unicode characters are accepted in identifiers only when the source file encoding is UTF8 or UCS2. High-ascii chars in an identifier in locale-based source will produce an “invalid character” error message just as it did before. Note that source code given to the compiler by the IDE is always encoded in UTF-8. You’ll see differences with the command line compiler since it has to read the files directly.
• The compiler is oblivious to the actual content of the Unicode chars. It sees them only as an opaque UTF8 payload. There is no analysis to see if a Unicode char is a special whitespace or punctuation char that probably shouldn’t be allowed in a program identifier. Validation of the unicode chars may be added in the future.
• Unicode identifiers are handled as case-insensitive strings, just as with traditional Pascal identifiers

• 上一页  [1] [2] [3] [4] [5]  下一页