Konstantin Münning wrote:
I would hapily contribute the code for a better MemAvail/MaxAvail
function if that's the problem. I would like to be able to use the
latest compiler which now I definitely can't as I must have the BP7
compatibility which is very good in 1.0.10.
IMO we have two
A friend has found some obvious errors in the FPC syntax description,
and I found some more errors. Here is our current list:
==
page Expected Error Description
Jamie McCracken wrote:
Yes, but the poster was asking whether the compiler never decided by
itself to inline something (even if no inline directive was
specified). That's not the case currently.
well thats soemthing you should add to your to do list. Automatic
inlining can deliver a
listmember wrote:
Inline variable initializers, such as:
...
function Something(...): Boolean = False;
var
Integer1: Integer = 15;
Boolean1: Boolean = False;
String1: String = 'SOME TEXT';
begin
end;
Such constructs are subject to frequent misinterpretation :-(
I assume that
Jamie McCracken wrote:
For me I prefere clarity above less typing (besides if you want to write
realy short code, you sould use APL)
I totally agree with you in this case - we dont want or need cryptic c
stlye syntax in any version of Pascal.
ACK.
However, in general Pascal has poor
Jamie McCracken wrote:
I don't understand, why are these forward declarations so evil ?
More code bloat, more typing and they get in the way. They dont give me
anything useful in return.
Please show me a piece of code where they are in the way. Code bloat?
They don't cost anything
Jamie McCracken wrote:
Garbage collection is largely no issue when using the Owner concept in
TComponent, using TObjectList, etc.
True and thats why I suggested ref counting Tobjects only so that no
manual memory management is required. I tend to make heavy use of TList,
Tstringlist and
Angelo Bertolli wrote:
Begin..End is redundant - you have to indent them to make em readable
anyways.
Not at all; I certainly don't indent them, and I'm a fanatical
indenter.
Agreed. I really can't understand why some people indent like this:
if ...
then
begin
...
Jamie McCracken wrote:
Those lazarus tools are great but they require advance knowledge of
those tools that new users wont have (at least somebody using lazarus
for the first time is not going to know all the keyboard shortcuts). Not
having to rely on hacks around the coding inefficiency of a
Jamie McCracken wrote:
Hans-Peter Diettrich wrote:
You obviously missed that a compiler does not only consist of scanner
and parser, but that optimizers and code generators also have to be
implemented. For multiple target platforms and CPU's...
The new dialect simply makes the syntax
Michael Van Canneyt wrote:
It's a simple fact:
90% if not more of all pascal code out there is Delphi code. Being able to
compile and
re-use that is FAR more important than changing the fact that begin/end is
required in
pascal.
ACK.
You want to make some 'Auto-Maintained' variable
Gerhard Scholz wrote:
...
I'm not sure, at least
.L9:
movw %dx,-12(%ebp)
.Ll3:
suggests that the target is not an integer, but instead is a (possibly
unsigned) word type. Please check again!
...
This is the result of the compilation: ppc386 tord -al (shortened of
Peter J. Haas wrote:
I write in German language because I'm not able to translate my
statement comprehensibly. Maybe anybody can translate it for people,
which don't can read German.
Sorry for OT, please ignore the following if you don't understand
German(s) ;-)
...
Ich hatte bei den Mails
L505 wrote:
...
But compiled with delphi compiler, or freepascal? I wonder if they have a
specific restriction where you can only compile the code on their compilers...
Not that I know of but.. I thought maybe you guys had come across something
like
that
The System.pas unit is special. In
alphax wrote:
It seems a bug in FPC 2.0.0.(Delphi 7.1 also has this bug)
Assumes there is an object(not class) declaration, the object has a
IInterface field. If we declare another object derive from it, in the cleanup
procedure of that decendant leak to clear the IInterface references.
Ivàn Caballero Cano wrote:
I want to konow if there is a units like Turbo Vision For Borland Turbo
Pascal for Free Pascal.
There are a Units o something else that help to build windows, check
box, list box, like Turbo Vision but for Free Pascal??
Do you mean a library for GUI or Console
Michael Van Canneyt wrote:
What is the performance difference between a hash() and a binary search on
an ordered list ?
IMO perfomance heavily depends on the use of the lists. An ordered list
requires some efforts when entering or removing items, and typically
requires more comparisons than a
Bram Kuijvenhoven wrote:
function MyOverloadedFunc:boolean; alias MyOverLoadedFuncNoParams;
function MyOverloadedFunc(i:integer):boolean; alias MyOverLoadedFuncInt;
Another note is that the 'alias' keyword might already be in use for some
other purpose (I don't exactly remember which), so
Yury Sidorov wrote:
So what way should we go?
1. Leave RTL string types as is (PChar/AnsiString) and perform conversion
from Unicode if needed.
No problem.
2. Define new types PSysChar/SysString to correspond either PChar/AnsiString
or PWideChar/WideString depending from OS type.
It's
Marcel Martin wrote:
I think Marco is right. Basically, when the compiler has to
code Inc(x,SomeConstant), the only sensible behaviour it is
expected to have is to regard the constant as being of the
type of x. So, if x is a Longword and if SomeConstant equals
-1, either it adds $
Yury Sidorov wrote:
I found that try...except and try...finally do not work if SysUtils unit is
not used (exception handling code is not called).
This behaviour is compatible with Delphi. It allows to exclude some
procedures from being linked to the executable, when no exception
handling is
Marcel Martin wrote:
Why not? I expect that the compiler evaluates constant expressions, and
creates the best code for the resulting values.
The best code is, before all, the correct code.
So we have to find out what is *correct*.
In the case of Inc(x, SomeConstant) the value of the
Marcel Martin wrote:
Unexpected overflows? The overflows occur or not according to
simple rules, perfectly defined, which ones depend on the types
of the operands.
Unexpected as depending on the values, not on the types. When the ranges
of the possible operands are known, it's also
L505 wrote:
| With regards to gnu linux:
| How about the Elf format?
| Is it possible to export code from an elf? (i.e. export functions)
|
Okay, I researched the topic. Of course, yes, you can export functions from
an executable
on linux. But freepascal doesn't seem to like it just
Graeme Geldenhuys schrieb:
Bounds is used a lot in Delphi and LCL applications.
So for delphi compatibility we now need to duplicate Delphi bugs in FPC
too? FPC DELPHI.
It's not a bug, it's a commonly accepted graphics model.
The only thing I'm missing is a distinction between rectangles
Graeme Geldenhuys schrieb:
FPC finally has a working TMultiReadExclusiveWriteSynchronizer
implementation (tiOPF implemented it's own), but I don't know if that
implementation is available for FPC 2.4.x yet, or if it is still only in
Trunk. Either way, TXXXConfig classes could use the same
Marco van de Voort schrieb:
The problem is not the programming (since a dedicated person could probably
start with a translated glibc in a good month), but the continuous
maintenance (for every distribution separately, since they could use
different kernels, options etc) , and interoperability
Marco van de Voort schrieb:
The Kylix-like addition of an C compiler would help to solve such
issues, that arise from the use of *any* C code with FPC.
Well, since this is about a maintenance problem, it would only solve
it if the maintenance of the C compiler would be lower than the
Michael Schnell schrieb:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must take care to ensure that control of the memory is not
removed from the ARM
processor while it is performing this instruction.
This seems to apply
Graeme Geldenhuys schrieb:
Looking at the rtl/unix/cthread.pp unit, I noticed two $Warning lines sayin
that setting or getting thread priority is not implemented for any unix
system. WHAT???
I then thought I would go ahead and do the implementation. Seeing that
cthreads using libc and POSIX
Daniël Mantione schrieb:
Yes, but in a multi-cpu system giving up the timeslice is a very bad
idea, because the lock might be released a few clock cycles later by the
other cpu; you would waste the rest of time slice while you could be
crunching.
IMO the default implementation should work
Paul van Helden schrieb:
Threads are evil?
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
Interesting view point. Perhaps that is why FPC doesn't bother too much
about thread priorities? :-)
IMO the author neglects the existence of realtime systems, which have to
deal
Michael Van Canneyt schrieb:
Sad but we found a new (really very old) bug with spaces:
http://bugs.freepascal.org/view.php?id=9964
If you pass -osome file with spaces.exe or -osome file with
spaces.exe fpc generates only a file with only some part.
[...]
Are you sure the bug is in FPC ? I
Marco van de Voort schrieb:
Does Lazarus set the working directory for the compiler as you expect it to
be? Keep in mind that a relative path is always dependant on the working
directory, not relative to the project.
I'd expect that the working directory is set to the directory of the
Mattias Gaertner schrieb:
Lazarus sets the working directory to the project directory when
calling the compiler.
Fine :-)
The 'in' modifier works here.
It didn't work for me with relative pathes, like
uses myUnit in '..\myUnit.pas';
(Windows, obviously ;-)
While Lazarus could find that
Mattias Gärtner schrieb:
The 'in' modifier works here.
It didn't work for me with relative pathes, like
uses myUnit in '..\myUnit.pas';
(Windows, obviously ;-)
Hint: Both compiler and lazarus automatically changes the path delimiter
and searches exact/lower/upper case for the file name
Mattias Gärtner schrieb:
Replacing units can be done with the search path.
But only when the search for used units exactly follows the search path,
and does not look into the directory of the using unit first. Is this
guaranteed?
DoDi
___
Michael Schnell schrieb:
In fact I did a (quite low priority) research on how to port FPC to a
new CPU such as NIOS and Blackfin and found that it of course is doable
somehow. While NIOS seems to look more doable, as it's quite similar to
MIPS (and ARM), Blackfin has a much more complex
Martin schrieb:
You can have an editor that displays and edits the content in any format
you like and validates it at the same time. But it saves it in the
current format after all.
so you edit:[b]key[/b] 1
and the editor saves: bkey/b 1
should read
and the editor saves: bkey/b
Jeppe Johansen schrieb:
I would be interested in knowing whether it would be feasible to create
DSP backends for FPC. I recently had the experience of using a TMS320C26
which probably has to be programmed in assembler due to the limits of
the instruction set. But I hear newer DSPs use
I'm just curious, does there exist descriptions for the various SVN
branches (purpose, maintainer, state)?
Florian has offered me an new branch, for my parser etc. projects, but
he seems to be very busy right now. So I'll present a roadmap of my
activities, all around the parser and compiler:
I know that the in filespec is part of the Delphi syntax, but what
is it really good for?
AFAIK it's not allowed to rename units this way, and since (currently)
only absolute filenames are implemented, I really wonder why FPC allows
to use it everywhere?
IMO the filespec should allow for
Jonas Maebe schrieb:
AFAIK it's not allowed to rename units this way, and since
(currently) only absolute filenames are implemented,
That is incorrect. Relative file names do work. They are resolved
relative to the current working directory of the compiler.
So what's the current working
Jonas Maebe schrieb:
The stand-alone preprocessor code ($PreprocWrite, commandline
option -m) does not compile since a long time. I could it make work
again, and already supplied the according patch in Mantis.
And as I replied in mantis two days ago, a) that option is not
documented in the
Jonas Maebe schrieb:
That is incorrect. Relative file names do work. They are resolved
relative to the current working directory of the compiler.
So what's the current working directory?
The current directory when the compiler was started. E.g.:
c:\pp\src ppc386 project\test.pas
-
Jonas Maebe schrieb:
I know that the in filespec is part of the Delphi syntax, but
what is it really good for?
AFAIK it's not allowed to rename units this way, and since
(currently) only absolute filenames are implemented,
That is incorrect. Relative file names do work. They are resolved
Michael Schnell schrieb:
IMHO a lot more interesting than ISO-Pascal, Modula, Oberon:
What about Delphi-Prism on that behalf. ?
(This supposedly would be easier to make working using a .NET/MONO-code
generating backend compiler than by attempting to reproduce the
appropriate functionality
Michael Schnell schrieb:
I just stripped down the machine files for a no_cpu machine (all
fakes), with some documentation about the required units etc.
Is this based on what we already have for X86, ARM, etc, or does it
fork to another set of ARC implementations ? If fork, is it intended
/
Michael Schnell schrieb:
I feel that Lazarus as an IDE and component library is more desirable
than Visual Studio. AFAIK there is no version of the Prism compiler that
runs on Linux or Mac.
A platform independent solution would implement the IDE, compiler etc.
in .NET/Mono, so that it can
Michael Van Canneyt schrieb:
The cure is far worse than the problem, because it is still trying to
combine 2 systems that are basically incompatible.
Bottom line is: don't use 'in' for the uses clause; use the command-line
option to specify the location of the sources.
Then we could start
Michael Schnell schrieb:
If you want paralel, take vector pascal, and implement it in e.g. the
FPC or
objfpc dialect.
I suppose this is a good idea, even tough I suppose that the .Net
parallel paradigm is a lot more broadly known than that of Vector
Pascal. so Hans-Peter might want to add VP
Florian Klaempfl schrieb:
Hans-Peter Diettrich schrieb:
But since some abstract links already exist (class type
variables for machine specific descendants), these links could be
exchanged at runtime,
One problem are all the used constants describing the target
architecture. We discussed
Michael Van Canneyt schrieb:
A platform independent solution would implement the IDE, compiler etc.
in .NET/Mono, so that it can be used immediately on every platform,
that supports .NET. AFAIK Java development systems went the same way...
Huh ? That would be the day ? AFAIK Java doesn't
Jonas Maebe schrieb:
Furthermore, at least two of the users have already posted in this
thread saying that they use this functionality (both in FPC and in
Delphi). Therefore I don't think it is a good idea to remove or change it.
ACK. My concern is about new users with (possibly) new uses of
Jonas Maebe schrieb:
I suspect that disk I/O is the narrowest bottleneck,
that can not be widened by parallel processing.
Unless you are doing a cold compile, the main bottlenecks in the
compiler are the memory manager (mostly the allocation of memory,
freeing is faster), zero-filling new
Michael Schnell schrieb:
That's questionable, depending on the real bottlenecks in compiler
operation. I suspect that disk I/O is the narrowest bottleneck,
I doubt this. The disk-cache does a decent work here. gcc can do this
very effectively on a higher layer, as for each source file gcc is
Michael Schnell schrieb:
M68K machine, which in turn seems to have inherited from the ARM.
I suppose: vice versa :).
At least I found files with comments from/for ARM.
.., but it doesn't allow to support multiple machine back-ends in one
program.
Do you think it would be an advantage to
Florian Klaempfl schrieb:
Memory throughput is a bottleneck, I/O not really. So multithreading has
a real advantage on NUMA systems and systems where different cores have
dedicated caches. One or two years ago, I did some experiments with
asynchronous assembler calls and it already improved
Marco van de Voort schrieb:
Nobody is talking about removing ? It is more a matter of not expanding, and
not guaranteeing too much (more) wrt to it. Specially since DoDi in other
posts seemed to state that he wanted to use it to override which unit is
selected in multiple sources in path cases.
Geoffrey Barton schrieb:
It now recognises the mnemonic 'cpsie' but not the following 'i'.
The 'msr' instruction should also allow the interrupts to be
enabled/disabled as
msr primask,r0
but msr gives an unknown identifier error for 'primask' and all the
other 'special' register names
Michael Schnell schrieb:
On 07/13/2010 02:49 PM, Hans-Peter Diettrich wrote:
But when FPC processes every source unit in a project only once, the
file cache is not very helpful.
Obviously, a sufficiently huge cache can avoid any disk I/O bottleneck
when doing the 2nd+ build
Jeppe Johansen schrieb:
I think that'll only complicate things. I think the compiler should be
able to do anything, down to lowest level. Just like you have CLI, HLT,
FXSTOR, WRMSR, etc instruction support in x86
Then many users will wonder why their application with included ASM from
Marco van de Voort schrieb:
One must keep in mind though that he probably measures on a *nix, and there
is a reason why on Windows the make cycle takes twice the time on Windows.
One of these issues are memory mapped files, that can speed up file
access a lot (I've been told), perhaps
Bernd Mueller schrieb:
Users, who do embedded stuff (without OS) NEED FULL control over the
controller. I agree with Jeppe, that the compiler should not restrict
something.
In this case I don't understand how FPC is useful at all. I cannot
create executable files for such a device...
Michael Schnell schrieb:
One of these issues are memory mapped files, that can speed up file
access a lot (I've been told), perhaps because it maps directly to the
system file cache?
AFAIK File Mapping is used a lot and very successfully with Linux, but
it _is_ available with NTFS.
I've
Marco van de Voort schrieb:
In our previous episode, Michael Schnell said:
On 07/14/2010 12:00 AM, Hans-Peter Diettrich wrote:
One of these issues are memory mapped files, that can speed up file
access a lot (I've been told), perhaps because it maps directly to the
system file cache?
AFAIK
Thaddy schrieb:
Programmers are not very imaginative in naming. It is plainly helpfull
to be able to rename a file if another file with a different content.
Just in the FPC compiler case many unit names are hard coded, while the
files to use reside e.g. in a specific machine directory,
Michael Schnell schrieb:
On 07/13/2010 11:18 PM, Hans-Peter Diettrich wrote:
When we rely on an OS file chache, we can read all files entirely into
memory, instead of using buffered I/O.
Loading the complete file instead of parts of it would do unnecessary
memory copies.
How that? Of course
Thaddy schrieb:
Hans-Peter Diettrich wrote:
Memory management can not normally be parallelized.
What's this then: http://topsoftwaresite.nl/ You are talking cows dung.
It is actually in production at one of the largest stockbrokers in Europe.
You should have written : It is hard to do
IMO compiler messages slow down compilation a lot. When messages are not
really output (prevented by message level...), then a lot of procedure
calls and string operations can be avoided, when the message preparation
is bypassed at all.
verbose.Message1 ff. could check the level (and exit
Marco van de Voort schrieb:
I don't think we ever going to give an up front carte blanche for a massive
rewrite to go into trunk. That is simply not sane.
ACK. I'm more concerned about work that is blacklisted for some reason.
A subsmission will always be judged on performance and
Jonas Maebe schrieb:
This technique is well known and implemented by virtually all memory
managers these days (it's called pooling, or freelists). FPC's default
memory manager also does that (up to a certain allocation size).
Unless you create huge pools, it does not affect total memory
Daniël Mantione schrieb:
IMO compiler messages slow down compilation a lot.
How do you know this, did you benchmark or is it just your opinion?
Common knowledge, proved by experience.
[...]
Sounds reasonable to me, but wether it will speed up compilation is
another question. Anyway,
Jonas Maebe schrieb:
Apart from specific scenarios, memory mapping can easily be slower than
direct reads. The main reason is that you get round trips to the OS via
hardware interrupts whenever you trigger a page fault, instead of doing
one or more (relatively cheap compared to interrupts)
Marco van de Voort schrieb:
Will it do harm when I create more than one branch, e.g. one for general
optimizations? Can other people contribute to such an branch as well?
Keep in mind that running many branches long term will only increase the
amount of management to keep them in sync, makes
Florian Klaempfl schrieb:
IMO compiler messages slow down compilation a lot.
How do you know this, did you benchmark or is it just your opinion?
Common knowledge, proved by experience.
Please profile the compiler first, people did this already.
This is what I'm going to do now.
Does
Florian Klaempfl schrieb:
Unless you are doing a cold compile, the main bottlenecks in the
compiler are the memory manager (mostly the allocation of memory,
freeing is faster), zero-filling new class instances (and partially
resetting the register allocator) and tobject.initinstance.
I wonder
Sergei Gorelkin schrieb:
I had benchmarked that, and submitted some patching some (already long)
time ago. Those patches inserted calls to CheckVerbosity before blocks
of messages of rarely used verbosity, like V_Tried.
But the patches have been rejected? For what reason?
This way it was
Florian Klaempfl schrieb:
Hans-Peter Diettrich schrieb:
I see the biggest benefit in many possible optimization in the scanner
and parser, which can be implemented *only if* an entire file resides in
memory.
Include files, macro expansion and generics make such optimizations hard
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
zero it again, so where is the gain in that ?
While it's in the freelist, the helper task
... thread ...
zeros it so when it is
allocated again, it needs no zeroing again.
But that then zeroes every deallocation.
Michael Schnell schrieb:
With small blocks there is no concurrency (as in case of conflict, the
second thread will use medium.
Just an idea: When the lists contain many entries, they could be split
into buckets. Then the currently searched bucket(s) could be locked
against use by other
Tomas Hajny schrieb:
This cannot be done because people should have the chance to use custom
error files to override message verbosities.
Couldn't this be delegated to an custom message handler?
Not sure if I understand here. Do you mean that instead of changing few
letters in the message
Sergei Gorelkin schrieb:
Not necessarily. When all currently used files reside in memory, every
(recorded) token can contain an pointer (or offset) into the file
buffer. This may reduce the number of required string copies (not yet
fully researched).
You normally shouldn't ever need to
Sergei Gorelkin schrieb:
The issue was that, whenever compiler needs to output a message, it:
- loads a messagefile (once in a session)
- looks up the message by number
- performs the parameter substitution (this involves AnsiStrings, so is
somewhat heavy)
- only then checks if it should
Since some time I'm trying to separate the syntax from the semantics
processing in the parser. It turned out to be quite complicated, so that
I want to use some methodology. (Yes, I've been warned ;-)
For profiling and debugging I want to have both the old and new code in
the same executable
Florian Klämpfl schrieb:
For profiling and debugging I want to have both the old and new code in
the same executable file
I don't think this is a good idea.
My proposal is:
- make a proof of concept for a part of the parser, e.g. ptype.pas, then
we profile the old and the new compiler with
Alexander Klenin schrieb:
In the first step I'll enclose all semantical code into begin-end,
so that it can be easily hidden (folded) in the Lazarus IDE.
This is not needed -- you can use {$REGION} ... {$ENDREGION}
directives instead.
I'll need begin-end anyways, when the code becomes a
Adem schrieb:
Focus of that 'test' was to see how TopMM compares with FastMM (both
Delphi only), which turned out that FastMM is 50% faster than TopMemory.
... and FPC:
FPC_x86/FastMM: 2.24
On Windows7_x64, *64bit binary* compiled with FPC runs about *30%
faster* than 32bit binary.
I
Adem schrieb:
And, the code I used was this.
[...]
MemoPerformance.Lines.Add(Format('Time: %n', [Time3 * 1E-6]));
Node1.Free;
end;
Can you show the time for Node1.Free as well?
Fast allocation can result in slow deallocation...
DoDi
___
Florian Klämpfl schrieb:
My proposal is:
- make a proof of concept for a part of the parser, e.g. ptype.pas, then
we profile the old and the new compiler with valgrind with code which
stresses this part.
- then we decide if it's worth to continue
Thanks for pointing to ptype.pas, these
Juha Manninen schrieb:
BTW, is there some way of having both 32bit and 64bit FPC/Lazarus
coexist in the same machine?
With Lazarus it is easy. You just compile it and rename the binary. It does
not need to be installed.
But it's suggested to invoke both with a different -pcp
Adem schrieb:
On 2010-07-17 17:37, Hans-Peter Diettrich wrote:
Can you show the time for Node1.Free as well?
Fast allocation can result in slow deallocation...
*FPC_x86*
Time to Create: 632.7
Time to Destroy: 471.69
*FPC_x64*
Time to Create: 489.4
Time to Destroy: 468.94
What about
One requirement in a transformation into OOP is the replacement of all
affected procedures by methods, and of many (currently global) reference
variables by class members. When e.g. later multiple parser instances
are created, one for every unit to compile, the current compiler
directive
Michael Schnell schrieb:
On 07/19/2010 11:40 AM, Hans-Peter Diettrich wrote:
One requirement in a transformation into OOP is the replacement of all
affected procedures by methods, and of many (currently global)
reference variables by class members. When e.g. later multiple parser
instances
Michael Schnell schrieb:
BTW what about GS ? If same is just restored after preemption, this
could be used by the compiler to point to the Threadvar area.
Since it turned out that loading segment registers is very time
consuming on newer (i486+) processors, the memory management was changed
Michael Schnell schrieb:
Since it turned out that loading segment registers is very time
consuming on newer (i486+) processors, the memory management was
changed from segmented (16 bit) into paged (32 bit flat). Segment
registers never should be changed by an application,
Not really, The OS
José Mejuto schrieb:
It is not 100% cdecl, const records in safecall must be passed as
reference while in cdecl a copy of the record is being passed.
Copies IMO make no sense here, when const protects the record elements
from any modifications. That's why a compiler should be free to pass
Sven Barth schrieb:
Well... for Linux exists no safecall convention and the only library
that might profit from it is XPCOM which uses cdecl procedures that are
compatible with the idea of safecall.
But if we implement safecall on Linux to be used with XPCOM
...then we might make XPCOM
Sven Barth schrieb:
Safecall is a Borland invention and only available in Delphi to simplify
COM development
AFAIK SafeCall and SafeArray are Microsoft inventions, in the
introduction of OLE/COM. Borland had to understand and implement the
related functionality in the language and compiler.
Michael Schnell schrieb:
IMO the OS provides means to allocate an thread-local memory block
(Thread Local Storage), whose content *can* be used for threadvars.
AFAI understand, in Linux (any architecture) the OS just preserves a
count of registers and the (e.g. C) compiler just uses one of
1 - 100 of 951 matches
Mail list logo
