Hi,

Does the CmdLine variable in the System unit exist for Delphi/TP/... compatibility ?

Micha

Op Wed, 18 Oct 2006, schreef Micha Nelissen:

Hi, Does the CmdLine variable in the System unit exist for Delphi/TP/... compatibility ?

Delphi compatibility.

By the way, I have a patch ready which turns it into a property, which prevents some code being pulled in Hello World kind of apps.

Daniël

That is the best solution. It will then also be readonly.

Do you get rid of the duplicate argc/argv and cmdline, then ?

Code like

{$if defined(MSWINDOWS) or defined(OS2)}
  { finally release the heap if possible, especially
    important for DLLs }
  for i:=0 to argc do
    sysfreemem(argv[i]);
  sysfreemem(argv);
{$endif}
{$if defined(LINUX) or defined(BSD)}
  sysfreemem(cmdline);
{$endif}

seems rather strange to me...

Michael.

Op Wed, 18 Oct 2006, schreef Michael Van Canneyt:

No. Because cmdline is a Pchar which points to the heap, it cannot be calculated on the fly; that would be a memory leak. Instead it is calculated on the first use. This means however that it still needs to be deallocated just like before.

Daniël

Daniël Mantione wrote

By the way, I have a patch ready which turns it into a property, which prevents some code being pulled in Hello World kind of apps.

Would be nice if somehow smartlinking could be 'smartened' to optimize this out. (Conditional initialization for group of variables/functions?)

Micha

Op Wed, 18 Oct 2006, schreef Micha Nelissen:

Yes :) I thought at least a hundred times about it during the last ten years, but I never came up with an idea that is both clean and doable in implementation.

Daniël

I thought there was already one ? 'unit export' or something alike, where you can re-export all types defined in another unit in this unit. If nothing is used from that unit, it is completely smartlinked out, including initialization/finalization.

Micha

Op Wed, 18 Oct 2006, schreef Micha Nelissen:

I have considered the use of units. But if you need a unit for something like cmdline, and start applying this technique to other things in the system unit, it becomes one mess of helper units.

I wasn't aware of this specific feature, but cleanness I don't think we should go this route.

Daniël

Daniël Mantione wrote

I have considered the use of units. But if you need a unit for something like cmdline, and start applying this technique to other things in the system unit, it becomes one mess of helper units.

To be able to smartlink this situation, you *need* to group them somehow. Units are the least intrusive way, I think. They could be named silly/long, like system_cmdline etc...

Micha

Daniël Mantione wrote

something like cmdline, and start applying this technique to other things in the system unit, it becomes one mess of helper units.

Btw, I don't think have any right to say this, looking at all the include files in the fpc source itself ;-). unix <-> linux <-> objpas <-> inc ....

Micha

That is impossible. The linker is 'stupid' in that sence. And it also should not be trying to be smart. Otherwise it will fail in other situations. Maybe you remember what the (currently disabled) VMT optimizer did for the LCL. It removed methods that the LCL expected to be there.

That is again not possible. Even if nothing is exported the initialization can do some specific os settings or update some system unit settings. Examples are the heaptrc and lineinfo units.

Op Thu, 19 Oct 2006, schreef Peter Vreman:

Was this a bug or does there exist a fundamental problem with removing unused methods?

Daniël

Peter Vreman wrote

That is impossible. The linker is 'stupid' in that sence. And it also should not be trying to be smart. Otherwise it will fail in other situations. Maybe you remember what the (currently disabled) VMT optimizer did for the LCL. It removed methods that the LCL expected to be there.

That's a bug in the LCL IMHO. We shouldn't be messing around with internals.

Micha

It isn't really doing much with the internals. I've to admit that nowadays better solutions are available, but thats something different. The case shows that users can do this. There is no language construct that forbids it. So optimizing this with a smart linker may break such code. Problem only is till what level should a smart linker detect this. IMO, ppl will always be smarter and find a valid case where things get broken.

Marc

Marc Weustink wrote

It isn't really doing much with the internals. I've to admit that

It reads/searches the VMT pointers themselves, right ? Is that supposed to work in the language ?

Micha

Marc Weustink wrote

The case shows that users can do this. There is no language construct that forbids it. So optimizing this with a smart linker may break such code.

Yes, it may. So what?

There's hell a lot of code that is generally possible within the language. Still it can be unportable, plain wrong, only work in certain situations etc. pp. Read: It still may break.

So "no language construct that forbids it" is no excuse, especially when you're digging around in internal compiler constructs.

Otherwise I'd expect some of my old code to work with FreePascal - where I outsmarted TPs heap manager to be able to free parts of dynamically allocated arrays.

IMO, ppl will always be smarter and find a valid case where things get broken.

This highly depends on your definition of "valid". My opinion: If it ain't guaranteed by the language, it ain't valid.

Vinzent.

Op Thu, 19 Oct 2006, schreef Micha Nelissen:

I don't know, but there should be a way to request the VMT-index of a virtual method, and then such a method should count as used. For example, calling virtual methods from assembler is a low level thing I'd rather like to be possible.

Daniël

I'm speaking about correct and portable code working in all situations. The only point is that the linker doesn't recognize the reference being used.

So "no language construct that forbids it" is no excuse, especially when you're digging around in internal compiler constructs.

I'm not digging in internal compiler constructs, I'm using a defined class layout and RTTI. No internal magic is used. (unless you define RTTI as internal)

A valid case is a piece of code where you and I will agree on that is should work.
The only thing guaranteed by the language is that if you follow its definitions, it will compile. Nothing more nothing less.

Marc

Marc Weustink wrote

The only thing guaranteed by the language is that if you follow its definitions, it will compile.

No. That's syntax. I'm talking about semantics.

Vinzent.

Peter Vreman wrote

situations. Maybe you remember what the (currently disabled) VMT optimizer did for the LCL. It removed methods that the LCL expected to be there.

After some thinking, the VMT optimizer can be enabled, but should not remove any published methods. Those may be referenced from streaming LFMs etc.

Micha

From: "Daniël Mantione"

I already implemented optimization of CmdLine for smartlinking for WinCE some time ago. It is controlled by HAS_CMDLINE define. And CmdLine is declared as function in WinCE system unit.

CmdLine as property will be great, but I found that property getter/setter need to be declared before property declaration in the interface part. This will garbage a global namespace with private getters/setters.

Is it possible to make compiler to accept getters/setters not declared in the interface part, but implemented in the implementation?

Yury Sidorov.

another way to solve this would be to allow use of public and private outside classes.

Op Thu, 19 Oct 2006, schreef Yury Sidorov:

I think it is not so easy, because the actual implementation (variable, function), affects code that uses the property. The implementation part of the unit does not necessarily have already been compiled when the unit is used.

Daniël

From: "Daniël Mantione"

I see the following way to implement it:

For example the compiler was found the following declaration of global propery:

property DrawMode: integer read GetDrawMode write SetDrawMode;

If GetDrawMode and SetDrawMode was not declared before, the compiler assumes that declaration is standard:

procedure SetDrawMode(const Value: integer);
function GetDrawMode: integer;

The compiler can internally declare setter and getter and mark them like compilerproc (or in other way) to hide from global namespace.

Yury Sidorov.