1

If a unit can be placed after interface section or implementation, is there a difference in terms of code-performance? which one is preferred?

For example,

unit Example;

interface 

uses
  UnitA;  // preferred here?

implementation

uses
  UnitA;  // or here?

end.
justyy
  • 5,831
  • 4
  • 40
  • 73

2 Answers2

7

Is there a difference in terms of code performance?

I'm not clear what that means. If you want to know whether it changes runtime performance, then no. If you mean something else, please define what you mean.

Which one is preferred?

It depends. If you need to refer to symbols from the imported unit in the importing units interface section, the unit must be imported into the interface section. If you only refer to imported symbols in the implementation section you can do it either way.

If Unit1 uses Unit2, and Unit2 uses Unit1, then they cannot both do so by importing into the interface sections. That leads to a circular reference error. One way to escape that is to move one of the imports to the implementation section.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • I'd say implementation `uses` is to be preferred where it's possible, even if both variants are viable. – Uli Gerhardt Oct 14 '15 at 10:57
  • @UliGerhardt I wouldn't. If you have a clear ordering that says that `UnitLower` is at a lower lever than `UnitHigher`, then I would always put the import of `UnitLower` in the interface section of `UnitHigher`. That way if I ever mistakenly try to import `UnitHigher` from `UnitLower` the compiler will object immediately. – David Heffernan Oct 14 '15 at 11:06
  • Thanks. David answers my question. accept this answer – justyy Oct 14 '15 at 11:11
4

Code performance, no. All initialization sections of the used units will be called before the actual unit initialization section is called.

It does impact how the compiler and linker resolve names, though. Usually, it's better to use the smaller scope (implementation), unless the larger one (interface) is needed. It will help to minimize issue like circular references, and better "encapsulate" implementation details.

LDS
  • 336
  • 1
  • 4