Alexander Klenin wrote:
On Thu, Oct 22, 2009 at 02:07, Sergei Gorelkin sergei_gorel...@mail.ru wrote:
As I tried to say earlier, having distinct StepNext() and Current()
functions is somewhat redundant, except the purpose of Delphi compatibility.
Rationale: the for..in loop manages the iterator
Paul Ishenin пишет:
Marc Weustink wrote:
I can see a use for using iterators in a for loop, however they should
be declared with some keyword.
Something like
type
TListIterator = iterator(TList, init_func, next_func, check_func)
function init_func: Boolean;
function next_func:
Vinzent Höfler пишет:
Sergei Gorelkin sergei_gorel...@mail.ru:
4) The syntax 'for element in list using TListIterator' is kind of
redundant. I'd suggest:
for element in list.GetForwardIterator do ..., or even
for element in list.GetSubItems(arguments) do ...
Wat's the return type
Paul Ishenin wrote:
Sergei Gorelkin wrote:
Probably yes. A possibility to use any type which has certain
methods/operators instead looks attractive, but I'm afraid it would be
hard to fit that into existing compiler model.
Sorry, what is TIterator? Is this like to the previosly suggested
Peter Popov пишет:
if OOP is about data encapsulation, why are we using global constants and
types?
You forget that units already provide one encapsulation level. This has
been a distinct feature of Pascal long before C++ introduced namespaces.
This means that Unit1.PI and Unit2.PI are two
Graeme Geldenhuys пишет:
2009/10/16 Paul Ishenin webpi...@mail.ru:
Sealed class is a class which can't be derived by another class. This one is
fully supported by delphi.
Would you mind explaining this - I never saw the benefit of a sealed
class. Using myself as an example. Say I develop some
Sergei Gorelkin wrote:
Sergei Gorelkin wrote:
Vincent Snijders wrote:
I admit these are mere hints at a possible bug, but if I were
maintainer of that code, I would take another look at it.
I will :-)
Vincent, what command(s) did you use to get that log?
What options were used when
Vincent Snijders wrote:
I admit these are mere hints at a possible bug, but if I were maintainer
of that code, I would take another look at it.
I will :-)
Sergei
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Sergei Gorelkin wrote:
Vincent Snijders wrote:
I admit these are mere hints at a possible bug, but if I were
maintainer of that code, I would take another look at it.
I will :-)
Vincent, what command(s) did you use to get that log?
What options were used when compiling the packages
Florian Klaempfl wrote:
Sergei Gorelkin schrieb:
Florian Klaempfl wrote:
So, who will be the first to creat a Mantis entry? :-)
I gave you both access to trunk/compiler/msg, so please update things as
needed ;)
Actually write access and commit as need :)
Ok, that simplifies things: no need
Vincent Snijders wrote:
Vincent Snijders schreef:
While running valgrind on fpcdoc, I got a warning in
Maybe you are interested in the valgind output. See attachment.
That check should be removed altogether, in both WideString and
UnicodeString routines.
I just checked with Delphi, it
dmitry boyarintsev пишет:
Hello FPC-Developers
Is there anyone maintaining compiler messages translations? I have
some fixes for them and utf-8 format.
I know i should post them to bug tracker, but is there anyone to
review and accept (or reject) fixes?
I was just intending to write almost
Florian Klaempfl wrote:
So, who will be the first to creat a Mantis entry? :-)
I gave you both access to trunk/compiler/msg, so please update things as
needed ;)
Actually write access and commit as need :)
Ok, that simplifies things: no need to pollute Mantis, and can do
several
dmitry boyarintsev wrote:
On Tue, Oct 6, 2009 at 7:13 PM, Sergei Gorelkin sergei_gorel...@mail.ru wrote:
So, who will be the first to creat a Mantis entry? :-)
Please do so. Unicode version should proof useful for Lazarus, as well.
It looks like UTF-8 version should be added, and cp1251 can
Hello,
It looks that I could finally figure out why the hell every type
conversion was done involving an intermediate temp.
This happened because node processing order was a bit incorrect.
See the attached patch. Since argument of firstpass is passed by
reference, freeing the old node before
Michael Van Canneyt wrote:
On Thu, 10 Sep 2009, Florian Klaempfl wrote:
Mattias Gaertner schrieb:
On Thu, 10 Sep 2009 17:52:44 +0200
Florian Klaempfl flor...@freepascal.org wrote:
Ivo Steinmann schrieb:
1. Using =nil or Assigned should result in the same.
Afaik not, this was one of the
Dariusz Mazur wrote:
Michael Van Canneyt pisze:
On Thu, 27 Aug 2009, Michael Van Canneyt wrote:
On Thu, 27 Aug 2009, Dariusz Mazur wrote:
Hi
I use DOM from fcl-xml both for Delphi and FPC development.
I work with older version, till I notice serious bugs. Today i've
upgrade it from
Dariusz Mazur wrote:
Hi
this is my first approach to implement canonical transform
fromds:CanonicalizationMethod
Algorithm=http://www.w3.org/TR/2001/REC-xml-c14n-20010315/
its used in XADES sign.
can somebody review it, if its interesting
First of all, it ignores the fact that DOM is
Dariusz Mazur wrote:
I'd suggest you to find a test suite (some examples are contained
directly in the text of w3.org specification, others may be ripped
from opensource projects that support canonicalization, like libxml2)
and verify your unit against it.
I draw from libxml2. First i
Michael Van Canneyt wrote:
Hm. Something strange with compilation. I reversed the patch, because
xmlutils.pp does not compile with the patch.
Strange that I didn't notice the first time I called make ?
Could you look at FPC compilation and make a new patch ?
To my knowledge,
- To make it
Dariusz Mazur wrote:
Hi
Is any way to convert xml to canonical form when DOM is used
Currently not, but I have plans to add this functionality to the XML
writer (it's the matter of writer, not of the DOM).
Regards,
Sergei
___
fpc-devel maillist
Inoussa OUEDRAOGO wrote:
Hi
At http://blogs.embarcadero.com/abauer/2009/05/29/3
This could drastically reduce Lazarus executable size.
Doubt that. Just another feature ported from .NET, the same effect may
be achieved by changing property accessor to the function which will
check the
Leonardo M. Ramé wrote:
I found a difference between Delphi's SetPropValue function with its
counterpart in FPC. In Delphi, this function is case insensitive, while in fpc
it is case sensitive.
Am I correct?
The property name comparison (ending up in GetPropInfo(TypeInfo:
PTypeInfo; const
Hello,
Just as the subject says...
Sergei
Index: pass_2.pas
===
--- pass_2.pas (revision 13026)
+++ pass_2.pas (working copy)
@@ -146,7 +146,8 @@
'guidconstn',
'rttin',
'loadparentfpn',
-
Sergei Gorelkin wrote:
Attached is a one-line fix that makes programs a couple of bytes smaller
by preventing creation of empty threadvar tables when threadvars are not
actually used.
The condition Assigned(TAsmList.First) always evaluates to True
because the list contains at least one marker
Marco van de Voort wrote:
(maillist maintainer/jonas: I wrote a similar message from a non-subscribed
email addr. It can be discarded, sorry)
I needed a html parser, and am not in a hurry, so I decided to check FPC's
own first, in the hope that I can at least make some documentation in the
wiki
Hello,
(As a side effect of digging into issue #13237):
When OpenExeFile is called with an empty filename argument, it
apparently opens stdin and crashes immediately thereafter trying to seek
in non-seekable stream.
The filename is empty whenever GetLineInfo is called with the address
that
Florian Klaempfl wrote:
Sergei Gorelkin schrieb:
Hello,
Looking at the changes to rtl/win/tthread.inc made in r12761, I see that
'thread helper window' is pretty well unused, as CM_EXECPROC message is
never posted to it (grepping rtl sources for CM_EXECPROC shows that).
So maybe ThreadWndProc
Micha Nelissen wrote:
Sergei Gorelkin wrote:
Looking at the changes to rtl/win/tthread.inc made in r12761, I see that
'thread helper window' is pretty well unused, as CM_EXECPROC message
is never posted to it (grepping rtl sources for CM_EXECPROC shows that).
TThread.Synchronize is supposed
Hello,
Looking at the changes to rtl/win/tthread.inc made in r12761, I see that
'thread helper window' is pretty well unused, as CM_EXECPROC message is
never posted to it (grepping rtl sources for CM_EXECPROC shows that).
So maybe ThreadWndProc function and window creation/destruction code in
Graeme Geldenhuys wrote:
The point is that you will probably have a File Open dialog that gives
the filename to TMemo.LoadFromFile. The the file dialog could collect
the filename and optional encoding to pass on to LoadFromFile.
Even if TStringList has the optional encoding parameter, prior
Graeme Geldenhuys wrote:
So would it maybe help if we took a peek at what those frameworks have
done. Clearly they managed to do it right as no developers or users
are complaining! So I guess Free Pascal could learn from them and
don't have to go through the whole RD process. Study what those
Graeme Geldenhuys wrote:
Then for backward compatibility use UTF-8 as the only string type.
That's what UTF-8 was designed for - backward compatibility. That's
also the reason LCL uses UTF-8.
You cannot use *only* utf-8, the existing ShortString, AnsiString and
Wide/UnicodeString types have
Michael Schnell wrote:
The more I think about it the more I like this solution. I think it's
better then the previous idea of a string with encode information
inside it.
Would Lazarus be able to follow ?
Do you think it's possible to have the compiler take care of any
necessary
Graeme Geldenhuys wrote:
On Sun, Nov 23, 2008 at 10:19 AM, Mattias Gaertner
[EMAIL PROTECTED] wrote:
On Sat, 22 Nov 2008 23:05:43 +0200
For example the lazarus IDE typically holds 50 to 200mb sources in
memory. If this would be changed to unicodestring (2 byte per char) then
the IDE would need
listmember wrote:
This is my thick-day. So, permit me to ask this:
Are you really saying that strings occupy 50 MB Lazarus's memory footprint?
I just checked (using Process Explorer, under Windows) and this is what
I see:
Working set: 2,216 K
Peak Working set: 26,988 K
I can't see where
Daniël Mantione wrote:
Instead UTF-8, you need to make sure the string has enough characters
left, and then compare multiple characters. Heck, you even need to take
care of the fact the the combining cedille can be encoded in 2, 3 or 4
bytes.
In this example it may be more efficient to
Michael Schnell wrote:
I prefer it to be counted in bytes. If it is counted in Bytes then I
can build a routine that counts in real chars. And we already have a
lot of code to handle utf-8 inside ansisstring which depends on that.
Counting the elements in real chars is very ineficient.
Michael Schnell wrote:
I don't really understand your question.
I think would would need to have two different function
UTF8ElementlLength(UTF8String) and UTF8PointLength(UTF8String), first
giving the string length in code elements (byte) and second giving the
length in code points (unicode
Graeme Geldenhuys wrote:
On Fri, Nov 21, 2008 at 11:08 PM, Graeme Geldenhuys
[EMAIL PROTECTED] wrote:
I thought you guys might find this interesting. It's a new 27 page
document describing Unicode support in D2009.
http://dn.codegear.com/article/38980
Seeing that I don't own D2009 and only
Graeme Geldenhuys wrote:
Has anybody else got sample test code that clearly shows the claimed
significant speed gain in using UTF-16 for Windows API's? If so,
could you please post the code and your comparative results (timing
values). I think most people perception was that ANSI API's will
Graeme Geldenhuys wrote:
I couldn't find a single program or editor that could display that
file correctly. Pretty amazing that one file can defeat all programs.
:-)
Programs I tried:
Kate (kde editor)
gEdit (Gnome editor)
Firefox 3 (did the best out of the lot)
vi (disastrous)
Graeme Geldenhuys wrote:
On Thu, Aug 14, 2008 at 1:14 PM, Marco van de Voort [EMAIL PROTECTED] wrote:
How does this argument fit with XML which also uses UTF-8 as the de
facto standard encoding. And seeing that fpdoc uses XML for the
documentation files, can I use the actual Unicode characters
Mattias Gaertner wrote:
On Wed, 6 Aug 2008 19:41:27 +0100
Inoussa OUEDRAOGO [EMAIL PROTECTED] wrote:
Hi,
TAVLTree in avl_tree.pp is not thread safe due to the node
allocation and de-allocation done through the global
declared NodeMemManager variable. TAVLTreeNodeMemManager
implementation is
Jesus Reyes wrote:
our friend javivf has reported the following issue, should he create a bug
report?
(rest skipped)
This can be fixed by the attached patch.
In general, it is a good idea to test xml's for well-formedness before
committing :)
Regards,
Sergei
Index: system.xml
Michael Van Canneyt wrote:
On Fri, 23 May 2008, Graeme Geldenhuys wrote:
Vincent Snijders wrote:
Sergei Gorelkin schreef:
1) Typing: TBitArray (classesh.inc line 308) is declared as array of
Cardinal. It means that on 64-bit platforms it will consist of QWord's.
No, cardinal is 32 bits
Martin Friebe wrote:
...
Many of the occurrances look like
SetLength(s, count);
move(str^, s[1], count);
where s is a local variable, not used before. So currently it would be
safe to skip uniquestring.
But I consider this as a trap, because future changes may act on s
before, without
Graeme Geldenhuys wrote:
I just noticed that it is common usage to call
SomeForm.Create(Application), which is now not possible. As it stands
now, it breaks your fpGUI article's demo application as well, which I
don't want to do. :)
In fact, TSomeForm.Create(Application) should work and
Schindler Karl-Michael wrote:
Hi,
I tried the test suite and found that the readme should be improved.
This is what I did:
...
It would also be great to update the test results URL. The current one
(http://www.freepascal.org/cgi-bin/testsuite.cgi) seems not valid after
domain name change
Graeme Geldenhuys wrote:
On 14/03/2008, Sergei Gorelkin [EMAIL PROTECTED] wrote:
Btw, strange to hear about 255 character limit on Linux. Its headers
define MAX_PATH value as 4097.
I thought the same at first, but then realized there is a difference
between filename length and path length
Sergei Gorelkin wrote:
It turns out that for longer filenames fpreaddir() failes with errno=22
(invalid argument).
Here is what I could find out:
In fpc, sizeof(dirent) is equal to 275, while gcc reports
sizeof(dirent64)=276. Moreover, Linux kernel expects buffer for
getdents64 syscall
Graeme Geldenhuys wrote:
Under Linux the maximum file length is 255 character. Gnome's Nautilus
allows that length. Any larger and Nautilus or a terminal command like
'cp' complains.
FindFile / FindNext however seems to have a 253 character limit! Why
the difference when the OS can
Joost van der Sluis wrote:
I've compiled your program and it gives a nice error-message about a
missing 'begin'.
I also used fpc version 2.2.0, and that also works. (i386-linux and
x86_64-linux)
So was there also something else?
Looks like there wasn't. At my site, with trunk version of
Sergei Gorelkin wrote:
No, it wasn't the last one, found yet another :(
Again, nothing in testsuite could detect it, so I wrote one.
A thing to note is that two last tests (pchar_to_widestr and
chararray_to_widestr) currently don't fail at least on win32 because
compiler keeps generating
Sergei Gorelkin wrote:
I'll be digging further in.
Here goes. I modified the test so that it fails reliably, and patched
the compiler so that is doesn't fail again.
It was a bit tricky to get a string with refcount=1 without telling the
compiler to take its address.
As for the patch, I could
Hello,
Ran into it while compiling Lazarus. It appears that, while many
sophisticated checks are done in tcallnode.maybe_create_funcret_node,
the obvious case when function result destination is one of the
function's arguments, is not checked. To be honest, I noticed that
earlier for the
Peter Vreman wrote:
The example that is provided doesn't fail. Because when calling foo the value
of -4(%ebp) is
loaded in %eax and that value is used in the function foo. The setlength() will
create a new
string and store that at -4(%ebp) of the calling function. But doesn't change
the
Hello,
I noticed that, within a unit, all interface wrappers (groups of
'WRPR_*' symbols) are placed into one assembler unit together with
unit initialization/finalization code (sorry, do not know the exact term
for assember unit).
As a consequence, init/final code pulls in *all* interface
Jonas Maebe wrote:
I think I've fixed this in r9626, could you check again? At least on
darwin/ppc, cycle and testsuite seem to work fine with your patch (but I
didn't check it without my changes as well).
I got the testsuite perform fine with TEST_OPT=-O2.
However, I could not build a
Sergei Gorelkin wrote:
I had isolated the issue, it is maybechangetemp() in ncgld.pas. If I
modify this function to always return false, the issue is gone. Actually
the failure is caused by incomplete deallocation of the AnsiString temp
variable - its initialization and finalization code
Sergei Gorelkin wrote:
Florian Klaempfl wrote:
Ok, so I guess we can change this. Anybody volunteer to implement it :)?
Well, if there is no hard time schedule imposed on this, I can try. I've
started all this, after all :)
I had investigated the issue. Surprisingly enough, changing
Florian Klaempfl wrote:
Help me, why do we need dfa :)?
I am not sure that we need the particular DFA from optdfa.pas, but
something to reduce conservativeness of escape analysis is definitely
needed. Otherwise, temps that are needed for just one particular case of
x:=f(x) are being
Florian Klaempfl wrote:
Ok, so I guess we can change this. Anybody volunteer to implement it :)?
Well, if there is no hard time schedule imposed on this, I can try. I've
started all this, after all :)
Sergei
___
fpc-devel maillist -
Jonas Maebe wrote:
The next logical step would be returning all automated types in
parameters, which would get rid of quite a pack of implicit
finalization code.
And thoroughly break Delphi compatibility at the same time :) Especially
for assembler routines this could result in quite a few
Jonas Maebe wrote:
Thanks, I've applied your patch. I'm also testing a patch for the
function result handling (there was another issue: the fact that the
fake result variable is actually implemented as an absolute variable
referring to the actual function result, causing an extra absolute
Florian Klaempfl wrote:
Are you sure with the strings?
Yes. Any function that returns a string is supplied with one more
argument than it was declared. After calling the function, register eax
(which is used to contain the non-parameter result) is not used.
Here is a simple example:
Daniël Mantione wrote:
Okay, that explains it. The memory stream is the only solution to seek in
a sane way. Now we could switch to Delphi behaviour, but to be honest, I
don't want to enforce the memory stream to everyone who wants to use a
compressed stream; it should be usable on plain
Daniël Mantione wrote:
I agree, but I would like to be carefull about one thing: zstreams read
from pipes or sockets. If someone closes a socket zstream early, a seek to
end would result in an exception. Is there a way we can detect a stream to
be seekable?
Probably no, and it's
Graeme Geldenhuys wrote:
Beats me, I thought that might be needed for querying a object for
interfaces it supports... As far as CORBA is concerned, I'm just
shooting in the dark here... Information on CORBA usage is limited
and I can't find any FPC code examples to give me hints. It seems
Hello,
I was wondering why Pascal statements like
Inc(SomePointer, sizeof(WideChar)) are compiled into two assembler
commands (mov ecx,2; add [location],ecx).
I found out that tcginlinenode.second_incdec checks second argument to
be an ordinal constant. In my case, however, the second argument
Peter Vreman wrote:
Below are the number that i get when i compiled fppkg from r9259. These show
only 3% improvement.
But also small bits help and i'll apply the patches after some cleanups.
Looks like I was too optimistic in my first estimation :) Still, testing
the fppkg project
Peter Vreman wrote:
I gave the patch a quick try and the speed stays the same for compiling the
compiler sources. Can
you explain how you did measure the performance gain?
First, I compiled the compiler using -gl switch in order to have
procedure names in logs.
Then I compiled a project (it
Hello,
I have noticed a strange thing with FPC-generated assembler code.
The Pascal code is very simple:
program test;
{$mode objfpc}{$h+}
type
TObj = class(TObject)
public
destructor Destroy; override;
end;
destructor TObj.Destroy;
begin
writeln('TObj.Destroy');
end;
begin
end.
Graeme Geldenhuys wrote:
No idea?? They seem to fluctuate after each run, but the overall
result (which tests are faster) are always constant. Have a look at
the code, if there is a better way of testing this. The code is pretty
simple. Just loop and create 10,000 objects in each loop.
Your
Graeme Geldenhuys wrote:
Any idea why Delphi in a virtualbox still beats FPC? Delphi seems
considerably faster and it's in a virtual machine. Oh, and I'm using
a stock standard single core Intel P4 CPU 2.40GHz and it hasn't got
any special virtualization features built in.
Also not, that
Tomas Hajny wrote:
Đ#65533;авоН Đ#65533;Ń#65533;онин wrote:
Michael Van Canneyt wrote:
I think it's better to implement a string message dispatcher for this
instead of adding RTTI (which is already bulky as it is). Do not forget
that the widget set is very lazarus specific, and has
Joost van der Sluis wrote:
program testbug9751;
{$mode objfpc}{$H+}
uses
Classes, SysUtils, mysql41dyn;
var hmysql : PMYSQL;
begin
// InitialiseMysql; -- remove the comment and the leakage is gone
repeat
InitialiseMysql;
hmysql := nil;
hmysql := mysql_init(hmysql);
// Comment
Jonas Maebe wrote:
On 18 Jul 2007, at 14:08, Jonas Maebe wrote:
Install the IDE setuid.
That would be an extremely bad idea with the current stability record
of the IDE.
Not to mention that it allows you to open and overwrite any arbitrary file.
Looking at that kernel patch, I see
Thursday, April 05, 2007, 11:45:34 AM, Vinzent wrote:
VH Sorry, I always forget that most people are not like me and just use
VH subroutine names without caring where they come from, while I'm used to
VH always prefix the unit names to the subroutines and thus simply
VH removing Windows from
Hello,
I was porting to Linux some Windows code which uses critical
sections API, and got 'Identifier not found' error on InitializeCriticalSection
and
DeleteCriticalSection symbols. After searching through RTL code, I
discovered that abovementioned functions are named InitCriticalSection
and
Wednesday, April 04, 2007, 3:00:55 PM, Vinzent wrote:
After
searching through RTL code, I discovered that abovementioned
functions are named InitCriticalSection and DoneCriticalSection. At
the same time, the EnterCriticalSection and LeaveCriticalSection are
not renamed, so code using them
Wednesday, April 04, 2007, 5:13:43 PM, Vinzent wrote:
VH On Wednesday 04 April 2007 12:59, Sergei Gorelkin wrote:
But EnterCriticalSection/LeaveCriticalSection also exist in Windows
API. And they are implemented in System unit without changing names.
Therefore, to make my code cross-platform
Thursday, March 15, 2007, 2:56:10 PM, Sergei wrote:
SG Are you sure that the bug 8492 is caused by the merge? There are
SG hardly any changes in dom.pp that could cause it (Attribute.Normalize
SG was changed to Attribute.DataType, but both do not affect xmlcfg
SG functionality). Moreover, I
Friday, March 16, 2007, 2:16:17 AM, Ales wrote:
AK Sending as attachment. The program just reads 'Options/Video/ResX' and
AK writes to console, then tries to change it in the file.
AK Neither GetValue nor SetValue work. GetValue always gets defaults,
AK SetValue does nothing.
AK Ales
Looks
Thursday, October 26, 2006, 3:47:37 PM, Micha Nelissen wrote:
MN Graeme Geldenhuys wrote:
+begin
+ sString := '';
+ for i := 1 to pIntLen do
+sString := sString + ' ';
+ Result := sString;
+end;
MN I object to the inefficiency of this implementation. Isn't there a
MN routine in
Hello,
I've hit another segfault, this time it was code calling
WinApi function GetTempFileName(). Resolving the call explicitly to
Windows.GetTempFileName() works. It appears that problem is
in cross-platform analog of GetTempFileName() that is contained in SysUtils
unit.
Looking at the RTL
Friday, September 01, 2006, 11:48:17 AM, Daniël wrote:
DM Op Fri, 1 Sep 2006, schreef Sergei Gorelkin:
function GetTempFileName(Dir,Prefix: PChar; uUnique: DWORD; TempFileName:
PChar):DWORD;
(note that it's not compatible with WinApi because 'stdcall' is
missing!)
Naturally, under Windows
Hello,
While porting some Delphi code, I found the following two
incomatibility issues. Should I report them as bugs?
Sample 1: It compiles both in Delphi and FPC, but FPC executable fails
at runtime. Delphi inserts temporary string variable and conversion
(array of char - string), but FPC
Thursday, August 31, 2006, 12:35:33 PM, Michael wrote:
MVC On Thu, 31 Aug 2006, Sergei Gorelkin wrote:
Hello,
While porting some Delphi code, I found the following two
incomatibility issues. Should I report them as bugs?
Sample 1: It compiles both in Delphi and FPC, but FPC executable
Thursday, July 13, 2006, 4:04:05 PM, Felipe wrote:
FMdC The error code is: 193 0x00C1 N/A %1 is not a valid Win32
application..
FMdC But that doesn´t make sense.
May be, for some reason DLLs are created without the relocation
information (or with malformed relocation info)? When you just
Hello,
Currently, TStream.Read and TStream.Write methods are abstract.
This means that each and every descendant of TStream must override these
methods with their implementation.
FCL has many read-only or write-only TStream descendants, which
override Read or Write methods just to indicate that
On Friday, June 30, 2006, 6:46:48 PM, Michael Van Canneyt wrote:
MVC There is a difference for the implementor of streams:
MVC By keeping the method abstract, you FORCE the implementation of a method
MVC in a descendent.
MVC The compiler will warn you if you try to instantiate a class which has
201 - 292 of 292 matches
Mail list logo
