function func:integer; cdecl;
Most of the time yes, sometime no like the following :
procedure proc( CONST AParametter : integer );
IMHO this time, Delphi compatibility is a very strong point.
Is there anything to be compatible with? Does Delphi/win32 use this in any
way?
I wrote:
What about +-+000 and ++-+0 though?
And does StrToInt in the current sysutils check this?
An unhandled exception occurred at $0040A462 :
EConvertError : +-000 is an invalid integer
$0040A462
$0040172F
To answer my own question: that one is invalid according to current sysutils
Rather..
var
i: integer;
begin
i:= StrToInt(s);
if (s = '0') or (i 0) then
writeln('S is an integer, and i is now: ', i)
else
writeln('S is not an integer: ', s);
end;
Alternatively:
function IsInteger(s: string; i: integer);
begin
result:=
Pierre Free Pascal wrote:
Please report any problems encountered during installation or use
of this beta.
As nobody else reported anything meanwhile...
Obvious problems first:
1) In ftp://ftp.freepascal.org/fpc/beta/2.2.0a/go32v2/separate/ files
demo.zip, gdbdos.zip, and makedos.zip are
Jonas Maebe wrote:
This is not true. You can perfectly compile a compiler using the
previous' release rtl.
Sure this is not the question.
E.g. the people developing using the fp IDE often
do this (because they have a project for the compiler, but that one does
not automatically compile the
Is there anything to be compatible with?
Yes, that is syntax used by Delphi.Net
Does Delphi/win32 use this in any way?
No, but if someday Delphi/win32 has to support attributes it will
certainly use the same syntax
and FPC will be ready.
--
Inoussa O.
L schrieb:
I wrote:
In KOL, Kladov also returns a zero with his Str2Int function if string is
bad.
You may be thinking.. but what if the string really is a zero and we want to
know that it is?
Well then we can do this:
if (s = '0') or (StrToInt(s) 0) then writeln('S is an integer');
if
On 19 Oct 2007, at 11:21, Micha Nelissen wrote:
Jonas Maebe wrote:
On 19 Oct 2007, at 11:00, Micha Nelissen wrote:
Elaborate please ? You mean debugging of the compiler, but don't
you always work on new compilers ? When debugging, you could copy
the ppu to the old RTL if you're using an
On 19 Oct 2007, at 11:00, Micha Nelissen wrote:
Jonas Maebe wrote:
It's not a good idea to make the compiler dependent on features
not available in the RTL of the previous release, as this can
complicate debugging quite a bit.
Elaborate please ? You mean debugging of the compiler, but
But IMHO, if a new langage feature have to be introduced,
a feature already implemented in Delphi, it will be good
to make it compatible. Mainly for code sharing.
There already is a Delphi compatibility compiler switch. There could be
a Delphi.NET (and maybe a Chrome) compatibility
It's because the Odd function is an assembler function, and the
compiler can't yet inline assembler functions. I guess this stems from
the time that the compiler was not very good at inlining nor at
removing stack frames. I would probably be best to simply remove all
assembler
On Fri, 19 Oct 2007, Paul Ishenin wrote:
Michael Van Canneyt wrote:
Ok, no problem - lets it be ppu. We only need some way of accessing that
data.
Is ppu reading methods already exists in RTL or another fpc package?
The ppu unit does what you need. It is used by the
On 19 Oct 2007, at 13:14, Micha Nelissen wrote:
Jonas Maebe wrote:
This is not true. You can perfectly compile a compiler using the
previous' release rtl.
Sure this is not the question.
It is the question because this is actually done by several people.
E.g. the people developing using
On 19 Oct 2007, at 10:05, Michael Schnell wrote:
It's because the Odd function is an assembler function, and the
compiler can't yet inline assembler functions. I guess this stems
from the time that the compiler was not very good at inlining nor
at removing stack frames. I would probably
Jonas Maebe a écrit :
On 18 Oct 2007, at 16:17, mm wrote:
The inlined code shouldn't be much bigger than the calls to Odd(). So,
why aren't they inlined? Is there a reason you did so?
It's because the Odd function is an assembler function, and the compiler
can't yet inline assembler
Michael Van Canneyt wrote:
Well, the unit is in the compiler directory, and is not meant for distribution.
It can only be in the compiler directory, otherwise it's impossible to bootstrap
the compiler (i.e. compile the compiler the first time).
The RTL is always compiled before the compiler
On Fri, 19 Oct 2007, Jonas Maebe wrote:
On 19 Oct 2007, at 10:28, Micha Nelissen wrote:
Michael Van Canneyt wrote:
Well, the unit is in the compiler directory, and is not meant for
distribution.
It can only be in the compiler directory, otherwise it's impossible to
bootstrap the
Jonas Maebe wrote:
It's not a good idea to make the compiler dependent on features not
available in the RTL of the previous release, as this can complicate
debugging quite a bit.
Elaborate please ? You mean debugging of the compiler, but don't you
always work on new compilers ? When
18 matches
Mail list logo
