Am 30.12.2011 02:00, schrieb Martin:
Florian wrote at http://bugs.freepascal.org/view.php?id=20907
FPC has a good enough dfa, however it is only activated when compiling
with -Oodfa:
c:\fpc\svn\compilerfpc ..\tw20907 -vw -Oodfa
Is that documented somewhere ? Is that production read or
Florian Klämpfl wrote:
Am 30.12.2011 02:00, schrieb Martin:
Florian wrote at http://bugs.freepascal.org/view.php?id=20907
c:\fpc\svn\compilerfpc ..\tw20907 -vw -Oodfa
Is that documented somewhere ? Is that production read or beta?
Beta. I'am not aware of any missing stuff, but it's mainly
In our previous episode, Florian Kl?mpfl said:
c:\fpc\svn\compilerfpc ..\tw20907 -vw -Oodfa
Is that documented somewhere ? Is that production read or beta?
Beta. I'am not aware of any missing stuff, but it's mainly untested.
I tried yesterday, and couldn't cycle with it.
On 30 Dec 2011, at 10:26, Florian Klämpfl wrote:
Beta. I'am not aware of any missing stuff, but it's mainly untested.
I tried to activate by default it during the development of the JVM port (since
the JVM will abort if it detects an uninitialized read), but it caused compiler
crashes. I'll
30.12.2011 14:42, Jonas Maebe пишет:
On 30 Dec 2011, at 10:26, Florian Klämpfl wrote:
Beta. I'am not aware of any missing stuff, but it's mainly untested.
I tried to activate by default it during the development of the JVM port (since
the JVM will abort if it detects an uninitialized
Am 30.12.2011 12:13, schrieb Sergei Gorelkin:
30.12.2011 14:42, Jonas Maebe пишет:
On 30 Dec 2011, at 10:26, Florian Klämpfl wrote:
Beta. I'am not aware of any missing stuff, but it's mainly untested.
I tried to activate by default it during the development of the JVM
port (since the JVM
On 30 Dec 2011, at 12:13, Sergei Gorelkin wrote:
With #15523 applied, the compiler can be cycled, but it emits hundreds of
warnings which have to be fixed because cycling is done with -Sew these days.
Passing an uninitialized variable to a var-parameter should cause a hint, not a
warning.
30.12.2011 15:18, Florian Klämpfl пишет:
I played with this yesterday and what about extended Initialize to
support unmanaged types? In case of an unmanaged type it just calls
fillchar.
I was rather thinking about 'varout' (or so) parameter type, which was suggested already several
times in
Hi all,
I'm in the middle of adding to the typelib importer the automatic generation
of a component implementing a sink for the events created by the com object.
It'll use the EventSink object I wrote a while ago and will generate the
components Onxxx properties and the corresponding function
In our previous episode, Ludo Brands said:
I'm in the middle of adding to the typelib importer the automatic generation
of a component implementing a sink for the events created by the com object.
It'll use the EventSink object I wrote a while ago and will generate the
components Onxxx
Is the use of {$ifdef LCL} to
encapsulate the Ole container in a fpc unit acceptable or is this a
herecy?
Heresy, and worse, it will simply not work. A typical lazarus
release then would have a FPC version with the LCL disabled
and compiled with -Ur, and including the source
On 29 Dec 2011, at 14:18, Sven Barth wrote:
On 29.12.2011 13:49, Jonas Maebe wrote:
On 28 Dec 2011, at 23:28, Sven Barth wrote:
1) as it seems to be a rather usual practice in Java, would it be possible
to disable the Constructor should be public warnings if the target cpu is
the JVM?
On 30.12.2011 15:25, Jonas Maebe wrote:
On 29 Dec 2011, at 14:18, Sven Barth wrote:
On 29.12.2011 13:49, Jonas Maebe wrote:
On 28 Dec 2011, at 23:28, Sven Barth wrote:
1) as it seems to be a rather usual practice in Java, would it be possible to disable the
Constructor should be public
My assumptions for this idea are:
1. Pointers to classes are mostly stored on the heap, in slow RAM.
What's fast RAM?
That would be the CPU L1 cache ;)
2. Nested/delegated classes incur a pointer access penalty, the deeper the
nesting the higher the penalty.
Why? Nested classes are not
Skybuck Flying schrieb:
2. Nested/delegated classes incur a pointer access penalty, the deeper
the nesting the higher the penalty.
Why? Nested classes are not a problem in OPL, more in C++ (multiple
inheritance!).
Nested classes are a problem because of the pointer overhead.
For example
Am 30.12.2011 12:47, schrieb Sergei Gorelkin:
30.12.2011 15:18, Florian Klämpfl пишет:
I played with this yesterday and what about extended Initialize to
support unmanaged types? In case of an unmanaged type it just calls
fillchar.
I was rather thinking about 'varout' (or so) parameter
16 matches
Mail list logo
