From: "Daniël Mantione" <[EMAIL PROTECTED]>
> 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 prope
Op Thu, 19 Oct 2006, schreef Yury Sidorov:
> 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 prop
> 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
From: "Daniël Mantione" <[EMAIL PROTECTED]>
> 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.
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
On Thursday 19 October 2006 09:39, 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.
___
fpc-devel maillist - fpc-deve
Vinzent Hoefler wrote:
On Thursday 19 October 2006 08:31, 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
Op Thu, 19 Oct 2006, schreef Micha Nelissen:
> 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 ?
I don't know, but there should be a way to request
On Thursday 19 October 2006 08:31, 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
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Micha Nelissen wrote:
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
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 th
Op Thu, 19 Oct 2006, schreef Peter Vreman:
> > 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
> > t
>>> Would be nice if somehow smartlinking could be 'smartened' to optimize
>>> this out. (Conditional initialization for group of
>>> variables/functions?)
>>
>> 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
> 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 variable
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
<->
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.
Op Wed, 18 Oct 2006, schreef Micha Nelissen:
> Daniël Mantione wrote:
> >
> > Op Wed, 18 Oct 2006, schreef Micha Nelissen:
> >
> >> Would be nice if somehow smartlinking could be 'smartened' to optimize
> >> this out. (Conditional initialization for group of variables/functions?)
> >
> > Yes
Daniël Mantione wrote:
>
> Op Wed, 18 Oct 2006, schreef Micha Nelissen:
>
>> Would be nice if somehow smartlinking could be 'smartened' to optimize
>> this out. (Conditional initialization for group of variables/functions?)
>
> Yes :) I thought at least a hundred times about it during the last t
Op Wed, 18 Oct 2006, schreef Micha Nelissen:
> 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 ou
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/functi
Op Wed, 18 Oct 2006, schreef Michael Van Canneyt:
>
>
> On Wed, 18 Oct 2006, Peter Vreman wrote:
>
> > >> 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 i
On Wed, 18 Oct 2006, Peter Vreman wrote:
> >> 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
>> 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.
That is the best solution. It will then als
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 ap
25 matches
Mail list logo