Boian hit it exactly; we're doing this cast to store values in the
TStrings Objects[] property. The current platform we're targeting is
Linux 32-bit, but we'll probably go to 64-bit at some point too, and it
would be nice if the cast continued to work as is.
Craig
1. Why not use dummy
1. Why not use dummy class like class tmyenum(tobject) e: myenumtype;
end;?
(extra typing is something like (objects[i] as tmyenum).e instead of
typecasting, but you can [have to] Free it: it's normal object)
Why would that be better than a simple typecast? Typecasting to/from an
I wrote an answer.
You (or other FPC core team members) should write a blog post about this
and explain this situation in more complete description, instead write
it as comment on someone's blog. This way, other people would see a
better and more comprehensive responses from FPC side.
http://shootout.alioth.debian.org
Regex program is still missing. It was discussed some time ago.
Did any licensing competent FreePascal developer try to contact
http://www.regexpstudio.com/TRegExpr/TRegExpr.html about self-proclaimed
TRegExpr - Freeware Delphi Regular Expressions Library...
What is wrong with the regular expression support in Free Pascal ?
Is it not powerful enough for the shootout benchmark ?
Yes, it cannot handle the regular expression the benchmark uses.
DaniКl
And the engine (with the word free) I referenced works.
I bet there are other free pascal
Go to translatable web site
leads to error dump:
can't read locale_admin_url: no such variable
while executing
lang::util::localize ${locale_admin_url}
invoked from within
if {[string equal [ad_quotehtml [lang::util::localize
${translatable_website}]] 1]} {
append __adp_output
1. I18N Message Conflicts shows pl_PL locale conflicts. Is it right or is it
wrong? (I want to check ru conflicts if any.)
2. Would it be better if this or similar questions were posted as bugs?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
In the math unit are the CompareValue functions only for signed integers. Why
not
for DWORD and QWORD?
I guess, that it's Delphi mimicing implementation (because it is Delphi-like).
And it can be tricky to distinguish signed and unsigned expression values.
Like,
a: qword;
a-1 --- ???
If someone thinks, that there is something in these changes, there is no need
to change anything in the compiler.
It may be implemented as some IDE plugin: auto substitution of some keywords
and names (using comments to store display-names while naming all keywords as
they are and names as
With Sun Java and MS J++ or .NET J# I try to use single Java code files and
I believe the financial leverage makes good Java IDE (IntelliJ IDEA or Eclipse)
hard to pursue (in this meaning).
If I get it right, FPC or Lazarus don't have resources to do it.
My point was: instead of trying to
('3616538624','3616669696') and ('D790','D792 ')
If I get it right, you can translate borders (a and b: strings in some formats)
to numbers (x and y) and do something like
for i:=x to y do
begin
// many bad and good things
end;
If the numbers are supposed to be in some special
5356 - does not compile under win32 (ppc1 does not stop compiling pp.pas
[neither fails, nor succeeds])
(memory usage in process list freezes at 31444 Kb)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
representable in an exact way on any IEEE standard-compliant fpu. The
Of course. But the result of format is user-oriented. User is not supposed to
know about negative zero, denormal numbers, negative infinity and the whole
IEEE 754.
If the user is supposed to understand that -0.000 means a
http://en.wikipedia.org/wiki/Negative_zero
Jonas
Nice link: In science, #8722;0 may be used to denote a quantity which is less
than zero, but which is too small in magnitude to be rounded down to #8722;1.
Format primarily produces strings for users, not for programmers.
Why do you think that scientific notation is used by default?
I personally prefer -0.000 in this case.
It's just a personal preference.
A weak argument:
If you write a program grandma should use, you can always add an extra check
if she complains (and it will be only one of the many extra
I didn't see anyone mention it, but the last revisions are not being made
correctly (WinXP-sp2, i386).
There is a problem in rtl\win32 with fpcmemdll.dll (make tries to treat it like
.exe).
There is a feature with '-Rfp' option of 'cp' program: if you enter path with
incorrect slash
Not sure about the 'feature' you mention.
Regards John
There is a feature with '-Rfp' option of 'cp' program: if you
enter path with incorrect slash (microsoft's '\' instead of
'/'), you get somewhat strange errors with all 'exampledirs='
in makefile.fpc (problem is in the
I have troubles with compiling array with char index that uses
cyrillic characters.
As you use unicode, you could index it from 0 to 10 and access like
my_array[char_to_code(char_itself_or_string_or_array_to_take_char_from_the_beginning)].
If I get it right, widechar is word, char is
---
Mime-Version: 1.0
X-Mailer: mPOP Web-Mail 2.19
X-Originating-IP: [194.150.126.26]
Date: Tue, 23 May 2006 18:27:07 +0400
Reply-To: =?koi8-r?Q?=F0=A3=D4=D2=20=EB=CF=D3=C1=D2=C5=D7=D3=CB=C9=CA?= [EMAIL
PROTECTED]
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
In recent binutils the program pwd.exe (it returns current directory name) is
omitted.
But makefile fails with a hint You need GNU utils package... (well, it does
not explicitly write, that it needs binutils).
Why don't emit You need GNU utils package... (pwd.exe)?
(PWD.EXE and some versions
Sorry, these two letters were accidentally sent personally.
To Felipe Monteiro de Carvalho:
probably Windows will become totally utf16 (not really unicode, but
at least utf16) really soon (at least in newer versions in a way
incompatible with current ones).
A small correction, utf16 is
I myself don't have unsolved problems with alignment in records.
I only point at some inconsistency with 16-byte alignment by default: variables
are 16-bytes aligned and their members of type int64 may have addresses not
divisible byt 4.
{$PACKRECORDS n} has almost nothing to do with this
{$PACKRECORDS n} has almost nothing to do with this inconsistency.
It does, since the member alignment is defined by {$packrecords n}
You shouldn't get big gaps them between different variables if you
specify a small alignment. You may get them between different record
members if you
It seems, that docs are outdated.
Default data alignment in records is expected to be wordly (i386, win32).
But if a record has int64 (or qword) element, I get unexpected overheads.
It's easily avoidable (with {$PACKRECORDS 1} or {$A1}; even with {$A-} [which
is expected to work only on MAC,
Suppose you have an array of b. Then, with a size of 12, there would be no
guarantee that an access to b.ab is aligned. So, the compiler pads the
record to a multiple of the largest field.
DaniКl
I didn't state that it's useless. It's just unexpected as it is.
The result is the same both
Is FPC going to support SSE extensions for x86 on higher level?
(There is MMX unit, which tests processor for presence of
mmx/sse/sse2/3dnow/3dnow/3dnowdsp extensions and defines types for data stored
in MMX registers (however, docs mention signed types and don't mention longword
to be stored
Sometimes RTL dataspace, including run time error numbers (may be some debug
information), is corrupted because of poor programming. It's a reason for
getting strange messages like Run time error 998 (may be omitting line number
information etc).
FPC has implemented e.g. some checks for
Even with -va switch I can't find a clue in the following situation (you may
substitute other units and function):
program A;
uses sysutils,windows;
const B:shortstring='1.txt';
begin DeleteFile(B); end.
I get Incompatible types...PChar expected.
The reason is in the windows unit.
But first
I didn't dig sources, but is it really hard to make them equally
fast? (By the way, the speed difference was less, than I expected.)
They are equally fast if you turn on register variables and if enough
free registers are available (e.g. on a PPC; possibly also on an x86
if you have
Something new at the end of message.
They are equally fast if you turn on register variables and if enough
free registers are available (e.g. on a PPC; possibly also on an x86
if you have a very simple loop and little or no variables used both
before and after the loop).
It's wrong.
The Windows Kernel works in a priority level of program execution
(main process) and sub processes (child process).
Each priority tells Windows what queue to place the processes.
If your parent process is Norma then the child process does not have
effect except that it's priority on executing
No, it's a very common cases on all cpus which have a reasonable
amount of available registers.
With 3-4 dynamical arrays and several parameters?
What can I do to speed up dynamical arrays?
What can I do to speed up static arrays?
I mean: what is the shortest way to estimate speed?
I
If you really want to speed up both cases you need to use pointers and
increase the pointer value in each iteration. This saves the indexing in
every iteration.
Thank you, that was informative. Here are the results (one program at the end
for completeness):
ap^:=app^; inc(ap);
It's been a while since I developed for Windows, so I do not know if
the following function is deprecated or not, or even will work on all
Windows versions:
SetPriorityClass
You can set the process priority at runtime as far as I remember
(please take a look at MSDN for better information
Because of the copy-on-write mechanism. The reference count must be
checked each time you do a write. This is normal. It's the same in
Delphi, and a good reason for avoiding dynamic arrays.
You can use pointer arithmetics in FPC, it works as a dynamic array, but
without the overhead.
This
Original order:
Total:8199ms
Total:12038ms
Reversed order:
Total:9526ms
Total:13332ms
And on my machine it doesn't matter, whether I reverse them or even split.
When it will be more urgent (it will) I will:
1. Create pseudo dynamical arrays with GetMem() or something
2. Compare all
This is not important message.
I posted such a message as bug report 4986:
**
Running fpc 1.pp makes 1.exe,
running fpc 1.pp. makes 1.pp.exe,
running fpc 1.pp.. makes 1.pp..exe,
running fpc 1.pp.. makes fpc 1.pp..exe.
**
Ok, it's not a
Was there an attempt to automatically convert source of dos program for TP with
much system-dependance? Of course, there are places that can not be converted
without hands (some VGA tricks etc), but it could be possible to highlight such
places..
Does anyone know such a tool for legacy
38 matches
Mail list logo
