On Fri, 29 Apr 2011, Joerg Schuelke wrote:
There is one problem with {$I %LINE%} and his friends, which restricts
the use of these directives. They are expanded even inside a macro
immediately, so, if you define a macro for debugging purposes, you
get the line and file info for the place of
Hi,
In 2008 there was a thread about FPC and Unicode resoure strings with the
conclusion that FPC does not support them.
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg10327.html
Has the situation changed in the meantime?
Does anybody know if Delphi supports Unicode resource
On 29 Apr 2011, at 09:43, Martin Schreiber wrote:
In 2008 there was a thread about FPC and Unicode resoure strings
with the
conclusion that FPC does not support them.
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg10327.html
Has the situation changed in the meantime?
No:
In our previous episode, Joerg Schuelke said:
Look in the manual under preprocessor $i (include)
Thats better then nothing, but if you want to include this information
in debugging information, and you won't write it again and again you
will need an expression which is usable inside an
michael.vancann...@wisa.be schrieb:
But what is the cleaner way? To defer the expansion of {$I %xxx%}
inside macros, or to define c-like macros __LINE__ and __FILE__, maybe
with nicer names?
Defer expansion. The use of {$I } is mandatory, since __LINE__ and
friends are valid
pascal
Martin Schreiber schrieb:
Hi,
In 2008 there was a thread about FPC and Unicode resoure strings with the
conclusion that FPC does not support them.
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg10327.html
Has the situation changed in the meantime?
Does anybody know if Delphi
Hello,
In free pascal/pascal/delphi it's necessary to declare a pointer to a
record, which is to be used inside the record to point to itself, before the
record itself without a type directive in between them for example:
// correct:
type
PMyRecord = ^TMyRecord;
TMyRecord = record
Hello,
I am not sure, maybe we discussed this before, maybe not.
I am getting quite sick of having to write IntToStr all the fricking time
like so:
begin
s := IntToStr(X) + ' ' + IntToStr(Y);
end;
So much typing for nothing ?!?
I could have written just:
begin
s := X + ' ' + Y;
end;
The Pascal way to avoid using too much IntToStr is:
begin
s := Format('%d %d', [X, Y]);
end;
Much shorter, no?
And you can configure in multiple ways how to format the numbers.
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist -
In our previous episode, Joerg Schuelke said:
No, since modifiers can be in any order, it could be a lot more than
two tokens.
I think if the compiler reeds the cdecl token he needs a lookup of
only one token to decide: is used as a modifier or a
identifier token.
No, since if the next
In our previous episode, Skybuck Flying said:
I would first like to remark about this: This is very newb unfriendly...
newbs might not know this... and will get frustrated by this
weird/odd/non-intuitive language construction.
It's in all manuals and books that describe pascal pointers that
On Fri, 29 Apr 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
But what is the cleaner way? To defer the expansion of {$I %xxx%}
inside macros, or to define c-like macros __LINE__ and __FILE__, maybe
with nicer names?
Defer expansion. The use of {$I } is mandatory,
In our previous episode, Hans-Peter Diettrich said:
I wonder why FPC broke Delphi compatibility by adding {$MODE}, instead
of choosing its own prefix for added compiler directives and macros.
FPC might not have been that Delphi compatible when this was introduced.
IIRC mode FPC is the
On 29/04/2011 09:25, Marco van de Voort wrote:
In our previous episode, Joerg Schuelke said:
No, since modifiers can be in any order, it could be a lot more than
two tokens.
I think if the compiler reeds thecdecl token he needs a lookup of
only one token to decide: is used as amodifier or a
In our previous episode, Martin said:
only one token to decide: is used as amodifier or a
identifier token.
No, since if the next token is deprecated he has the same devilish
tradeoff.
Not that I am advertising to change it, but the next token wouldn't be
deprecated ever (that would
Op Fri, 29 Apr 2011, schreef michael.vancann...@wisa.be:
I wonder why FPC broke Delphi compatibility by adding {$MODE}, instead of
choosing its own prefix for added compiler directives and macros.
Because it would mean yet another kind of directive, this is confusing.
My take on it is
In our previous episode, Dani?l Mantione said:
I wonder why FPC broke Delphi compatibility by adding {$MODE}, instead of
choosing its own prefix for added compiler directives and macros.
Because it would mean yet another kind of directive, this is confusing.
My take on it is that if
Joerg Schuelke wrote:
Am Thu, 28 Apr 2011 20:09:59 +0200
schrieb Joerg Schuelke joerg.schue...@gmx.de:
No further explanation needed. Nested comments do it.
I did not know that {$define mx:= ... (*$%LINE%*)} works.
So that's why (*$define mx:= ... doesn't work :-)
--
Mark Morgan Lloyd
Am 29.04.2011 10:23, schrieb Felipe Monteiro de Carvalho:
The Pascal way to avoid using too much IntToStr is:
begin
s := Format('%d %d', [X, Y]);
end;
Much shorter, no?
... or writestr(s,x,' ',y);
___
fpc-devel maillist -
Am Fri, 29 Apr 2011 09:58:08 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
I use an IDE macro to insert a predefined line, and then I just
change the constants I will log. The advantage of that way is that
you have full intellisense to specify the vars to dump, something
that is
type
TMyRecord = record
mPrev : ^TMyRecord; // not allowed.
end;
Marco, only if you happen to know from the top of your head, would it
be possible and without consequences to allow this kind of
construction? (i.e. a pointer reference to itself)
Best regards,
Flávio
Am 29.04.2011 15:51, schrieb Flávio Etrusco:
type
TMyRecord = record
mPrev : ^TMyRecord; // not allowed.
end;
Marco, only if you happen to know from the top of your head, would it
be possible and without consequences to allow this kind of
construction? (i.e. a pointer reference to
Am 29.04.2011 10:59, schrieb Hans-Peter Diettrich:
michael.vancann...@wisa.be schrieb:
But what is the cleaner way? To defer the expansion of {$I %xxx%}
inside macros, or to define c-like macros __LINE__ and __FILE__, maybe
with nicer names?
Defer expansion. The use of {$I } is mandatory,
Am 29.04.2011 00:02, schrieb Joerg Schuelke:
Am Thu, 28 Apr 2011 23:39:35 +0200
schrieb Hans-Peter Diettrichdrdiettri...@aol.com:
The bug resides in the dirty Delphi OPL definition.
Is it a bug or unspecified behavior? I think it is implemented in the
hope it works good enough.
If you
Hi!
I want to equip a program with a command line and plan to use a real
scripting language to interpret the user input. I've looked around a bit
(e.g. in the mailing list archives) and found some languages:
- PascalScript
- JavaScript
- Lua
- TCL
Only the latter has a command line friendly
On Fri, Apr 29, 2011 at 1:42 PM, Johann Glaser johann.gla...@gmx.at wrote:
Hi!
I want to equip a program with a command line and plan to use a real
scripting language to interpret the user input. I've looked around a bit
(e.g. in the mailing list archives) and found some languages:
-
On Sat, Apr 30, 2011 at 00:57, Florian Klaempfl flor...@freepascal.org wrote:
Am 29.04.2011 15:51, schrieb Flávio Etrusco:
type
TMyRecord = record
mPrev : ^TMyRecord; // not allowed.
end;
Marco, only if you happen to know from the top of your head, would it
be possible and without
Am 29.04.2011 08:52, schrieb Jonas Maebe:
On 29 Apr 2011, at 09:43, Martin Schreiber wrote:
In 2008 there was a thread about FPC and Unicode resoure strings with the
conclusion that FPC does not support them.
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg10327.html
Has the
28 matches
Mail list logo
