#2. Does the exception handling architecture provide easy
to the call stack and other potentially useful information
about the exception?
Yes, the frame pointer is passed
#3. Is there (planned) support for object serialization?
#4. Is there (planned) support for object persistence (like
wxWindows is a good library/framework indeed. But why do we need a pascal interface
to it ? It adds too many layers to the whole system.
eg: to create a button = pascal-layer-wxWindows-gtk+/motif/win32-window system
window.
Do we really need these layers ? (wrapper wrapping a wrapper
Hello again -
Still testing the new 1.9.0 beta compiler (Win32), I have come across
another issue which is much easier to demonstrate:
Take the following program:
program asmtest;
procedure myasmstuff;
var
BOB : dword;
begin
asm
mov eax,BOB
xor eax,eax
mov
When porting a Kylix/Delphi project to FPC (version 1.9.0 Linux) I've
encountered this small problem using class methods:
When I pass an object instance as parameter in class methods I have a sigsev
like in this example
program TestFail;
uses
SysUtils;
Type
TMyObject = Class
private
When porting a Kylix/Delphi project to FPC (version 1.9.0 Linux) I've
encountered this small problem using class methods:
When I pass an object instance as parameter in class methods I have a
sigsev
like in this example
Am I doing something wrong or is a bug I've found?
It was a bug in the
Hmm, here it returns
-bash-2.05b$ ./bugtest
TMyObject
-bash-2.05b$
with
Free Pascal Compiler version 1.9.1
Compiler Date : 2003/11/11
Compiler Target: i386
on FreeBSD
So it could be it that is already fixed after 1.9.0
Great, :-)
One more question, where can I find the version
Marco,
Let me see if I understand your concern...
wxWindows is a good library/framework indeed. But why do we need a
pascal interface to it ? It adds too many layers to the whole system.
eg: to create a button = pascal-layer-wxWindows-gtk+/motif/win32-window system window.
How does LCL work-
Peter,
Thanks for clearing things a little further!
I see that many responses refer to Delphi compatibility. I understand
that the FP compiler has a switch that tells it to compile the pascal
code as Delphi code. In that sense, I'd expect FP to provide a superset
of the Object Pascal dialect.
Marco,
Let me see if I understand your concern...
Most of the things you replied to aren't my comments, anyway.
wxWindows is a good library/framework indeed. But why do we need a
pascal interface to it ? It adds too many layers to the whole system.
eg: to create a button =
On Thu, 13 Nov 2003, Marco van de Voort wrote:
Marco,
Let me see if I understand your concern...
Most of the things you replied to aren't my comments, anyway.
wxWindows is a good library/framework indeed. But why do we need a
pascal interface to it ? It adds too many layers to the
On Thu, 13 Nov 2003, Demian Lessa wrote:
Peter,
Thanks for clearing things a little further!
I see that many responses refer to Delphi compatibility. I understand
that the FP compiler has a switch that tells it to compile the pascal
code as Delphi code. In that sense, I'd expect FP to
I see that many responses refer to Delphi compatibility. I understand
that the FP compiler has a switch that tells it to compile the pascal
code as Delphi code. In that sense, I'd expect FP to provide a superset
of the Object Pascal dialect. And that is true indeed!
There are some
On Thu, 13 Nov 2003, Marco van de Voort wrote:
The LCL is much more than a widget set. It is the base building block of a
RAD system. And also it quite Delphi VCL compatible in spirit (to allow easy
porting).
Moreover wxWindows is relatively recent. It wasn't around in a stable form
RTTI is enabled by a switch {$M+} and it is also inherited
by descendant classes.
Just like Object Pascal...
That is already supported by an fpc extension allowing
static members. Just add the static directive after the
field.
ok, another feature not found in Object Pascal!
Thanks,
Michael,
As to that, the answer is simple: RTTI for all objects would
blow up your executable. RTTI information takes up a *lot* of
space in your executable. It's a burden, and people who don't
need it should have the chance not to use it. This is impossible
if you force RTTI in
There are some extensions yes, and in the future, foreign
OSes and processors might cause some more extensions.
However in general we reluclantly add features, usually
because the main argument from most people is it would
be nice to have , and there are many more reasons
not to
ok, another feature not found in Object Pascal!
Be careful here... FPC implements Object Pascal too. Say 'Delphi' if you
mean Delphi. Object Pascal in son eclusively Borland (though they originated
it in it's Delphi instance.)
Matt
___
fpc-pascal
Marco,
I'm not debating whether a feature should or should not be considered
for inclusion in FP. It just occurred to me that class attributes are
constructs that have *real* use beside just stylish correctness. Class
methods have been implemented, right? Aren't them just as equivalent to
Marco,
Let me see if I understand your concern...
wxWindows is a good library/framework indeed. But why do we need a
pascal interface to it ? It adds too many layers to the whole system.
eg: to create a button = pascal-layer-wxWindows-gtk+/motif/win32-window system
window.
How
19 matches
Mail list logo
