Florian Klaempfl wrote:
This is wrong. Asynchronous means that the procedure call is put into
a queue and not immediatly handled if no thread is in the pool.
Further, your code doesn't handle efficient parameter passing.
Especially this needs compiler support.
peter green schreef:
I fully agree with you. I would like the object oriented way of strings
also - but I stopped asking for that ;) There are a lot of advantages
over the small amount of disadvantages.
Which object orientated way of doing strings?
As I see it there are three main ways of
peter green schreef:
I have just checked the manual and I don't see anything I can use to
make sure my custom type starts at a predictable state initially
(nessacery so they assignment operator can safely clean up before
making the assignment). Nor do I see anything to do automatic clean up
Could anyone, please, contribute your thoughts and feelings as for
unicode in actual Delphi 2009? i have no possibility to download this
and experiment :(
I am a betatester for the Tiburon (D2009) release and it is rather good.
The unicode support is not flawless (yet) but it is well
Graeme Geldenhuys wrote:
Please add to the list... :-)
eg:
1..) My I have the following class names?
type
TMyåClaß = class(TObject)
end;
2..) What about function and parameter names?
type
TMyåClaß = class(TObject)
public
property
Alexander Klenin wrote:
FStat: Integer; static; virtual;
Creates one instance of the variable per class, including derived classes.
To implement it, compiler might either reserve a VMT slot for a pointer
to the variable instance or just assign a fixed offset from the VMT.
Hallvard
Or maybe a new switch: COMPUTATIONALLYWRONG_MATHEMATICALLYCORRECT ON/OFF?
Although an assumed standard, lot´s of modern calculations depend on a
mod being able to assume a negative value.
Regards,
Thaddy
Florian Klaempfl wrote:
Dmitry Lizorkin schrieb:
That FPC never claims to be iso
Daniël Mantione wrote:
Op Tue, 28 Oct 2008, schreef Thaddy:
Or maybe a new switch: COMPUTATIONALLYWRONG_MATHEMATICALLYCORRECT
ON/OFF?
There is no need for such a switch. No programs needs it, because if
you need to positive value you need just one if statement.
Or the beautiful iso
I may have misread or may be misinformed. But: divergence between win32
and .net was on the roadmap..
And what's wrong with buying in to a dedicated project. It is sound
business if the product is tops. Sounder than Kylix at the time.
(although imho that business was - still is -sound, but
Vinzent Höfler wrote:
Thaddy wrote:
Or maybe a new switch: COMPUTATIONALLYWRONG_MATHEMATICALLYCORRECT
ON/OFF?
Although an assumed standard, lot´s of modern calculations depend on
a mod being able to assume a negative value.
Conceptually it's just the difference between modulo (mod
Florian Klaempfl wrote:
- it solves none of the real MT problems
No. I agree: if a programmer or architect doesn't understand MP the
syntax sugar might be misleading and prone to misinterpretation.
But that is already the case with TThread. You wouldn't believe the
times I had to correct
Florian Klaempfl wrote:
Thaddy schrieb:
I consider parallel as syntactic sugar:
Yes it is sugar ;)
smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
Just observing the thread I'd like to add some real world examples where
OpenMP like additions can be very effective.
Not because something can't be done otherwise, but because it has
syntactical advantages.
That said, even with the addition of a parallel for syntax and the
like (paralell while
Your example shows just how accurate Widestring should be interpreted:
It just only shows it is a two ore more byte sequence to represend a
single character. It doesn't say anything about the content or the use
of a specific (meta) encoding like UCS2 or Unicode16.
If the discussion is about
Yes, this is possible and even proven to be possible. I have a fieldtest
delphi bytecode compiler from borland inprise times. Never made it to
market, but it works.
Ask Codegear of they are willing to give you a specimen of this oldy.
I can ask this if you like: very good contacts.
Thaddy
dmitry boyarintsev wrote:
I can ask this if you like: very good contacts.
Could you ask them, please?
I will email Nick and David if they would be willing to (put it in the
museum).
No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus
I remember that the Delphi to java bytecode compiler isn't feature
complete. I can't be: it will not be possible to compile any old delphi
program into java byte code for several reasons. But it is possible to
create Java bytecode with a - safe - subset of pascal syntax. It is also
possible to
I wrote this from the perspective of a compiler, not from the
perspectiev of a framework.
So, I fully agree with your response. It is a more elaborate version -
with corrections - of what I ment.
Marco van de Voort wrote:
In our previous episode, Thaddy said:
I remember that the Delphi
But it IS possible to use the compiler itself with the frameworks that
are native to the bytecode platforms. That in itself isn't rocket science.
That was the ratio behind Borland experiments with a java bytecode
compiler: and it never reached maturity because the library issue was
the mayor
Michael Schnell wrote:
Thaddy wrote:
Yes, this is possible and even proven to be possible. I have a
fieldtest delphi bytecode compiler from borland inprise times.
This is Pascal byte code not Java byte code. Any bowser can run Java
byte code (via the Java Virtual Machine that is installed
Michael Schnell wrote:
You make a mistake : I am talking about JAVA VM bytecode.
Thanks for pointing that out.
I did not ever hear about this, but I did learn about Pascal byte code
ages ago, so I was mistaken :(.
I have send out the emails as promised. Let's hope you can toy around a
Michael Schnell wrote:
- One should not attempt to implement Java or C# language constructs in
Pascal.
Oxygene / Delphi Prism seems to do this very successfully. But of
course the compatibility to the existing code base is limited.
Well, the first remark is indeed questionable. As you
Marco van de Voort wrote:
IMHO strict private has nothing to do with strictness, except for the first
word. It has to do with micromanaging visibility, something I do not agree
with, not in the least because the exact use is highly a matter of taste.
I would prefer to keep it far from FPC
Alain Michaud wrote:
Vinzent Höfler wrote:
Alain Michaud wrote:
Hi,
Not exactly related to this thread, but worth mentioning:
Some time ago I was interested in (numerical) computing some
Bessel function to the highest precision!
I looked at MMX, SSE, SSE2, SSE3, SSE4, FP87,
Sooky Boo wrote:
Found a solution.
Copy() only works for one level deep and since using fpc 2.2.4 the
array became two levels deep.
Solution copy array A to array B using copy, then for each element of
array B copy nested array from A to B.
Mattias Gärtner wrote:
Hi,
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
For example:
a:=TMyClass.Create;
b:=TMyClass.Create;
if @a.test = @b.test then writeln('the same method');
This results in strange behaviors, when using
Mattias Gärtner wrote:
Zitat von Michael Schnell mschn...@lumino.de:
Mattias Gärtner wrote:
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
Seems perfectly logical to me (@ = Address of, in this case code
address, the code is the
Marco van de Voort wrote:
In our previous episode, Thaddy said:
afaik widestrings are reference counted in Delphi. PWideChars not.
Yes, but not by Delphi but by COM.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
About the naughty naughts:
This is also the cause of many problems and the main cause of the ssl
certificate hack:
www.paypal.com\0filtyhacker.cr
see ASN.1 and X509. PASCAL strings (with length before string) are for
good reason part of many a specification... C strings are convienient,
but
Florian Klaempfl wrote:
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
This is exactly my point about sealed classes. When you design the
product or class, you have NO way
Florian Klaempfl wrote:
Paul Ishenin schrieb:
I have compared what d2010 TObject has and found a few differences:
1. Dispatch method is virtual
2. new method: class function UnitName: string;
3. new method: function Equals(Obj: TObject): Boolean; virtual;
4. new method: function
TObject should NEVER -xcuse me for shouting - contain rtti information
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Alexander Klenin wrote:
I have started testing the new for..in code.
The very first test I tried found a bug ;-)
---
const S = 'abc';//???
var ch: Char;
begin
for ch in S do Writeln(ch);
end.
---
I suppose you refer to the fact that the compiler should never allow this ;)
Or do you
Marco van de Voort wrote:
Neither do I.
While I think it would be best to use native encoding on all platforms as
much as possible, that is an opinion. However not using native encoding for
general processing is nuts. So we need the UTF8 type anyway.
Just to make a small point: the choice
Jonas Maebe wrote:
On 17 Nov 2009, at 12:04, Graeme Geldenhuys wrote:
I asked a question about a compiler hint in the fpc-users mailing list.
As JoshyFun suggested, is it not maybe better to change FillChar()
definition so first parameter is a out parameter - to prevent
unnecessary compiler
Giuliano Colla wrote:
I've never found the C++ way (Button-Click) more telling than FPC way
(Button.Click), on the contrary I find it cumbersome, but of course
you're free to think otherwise.
Huh? Button.Click is perfectly legal in C++... Although it does not mean
a dereference, but a
Jonas Maebe wrote:
Delphi compatibility. And Delphi does that because COM requires this
behaviour.
Yes, but.. As I hinted before that is because COM is reference counted
on an intermediate level by a certain OS. A simple (but performance
cost) change of the memorymanager can fix that for
Jonas Maebe wrote:
If you change the behaviour of out so that such parameters are no
longer finalised before the routine is entered, then the above will
cause a memory leak. You can verify this by changing the out rec
parameter into var rec.
Then this is definitely not a sextopod but an
Without COM, FPC wouldn't have out parameters.
And because there would be no difference between var and out then, it also
wouldn't have the hint. Case dismissed. ;)
Vinzent.
Yup.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Nikolai Zhubr wrote:
I'd guess this would require huge work and substantial modifications
to the language though.
The compiler then has to assert all possible codepaths... Do you think
that's a viable option?
___
fpc-devel maillist -
How does your patch handle this? :
if a then
if b then
DoSomething;
else
DoOtherThing;
Syntax error
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Aleksa Todorovic wrote:
else is handled as part of if b then - the closest preceeding if:
This would break almost all my code.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
As well as both
if a then
DoSomething
else
DoOtherThing;
and
if a then
DoSomething;
else
DoOtherThing;
At least to me they are :-)
This feature is so unclean and so poorly informed about WHY the ; is
a part of the language.
First of all, Pascal is not a line based language.
On 6/9/2010 9:26 AM, Graeme Geldenhuys wrote:
In the bug report is a patch.
http://bugs.freepascal.org/view.php?id=16682
Regards,
- Graeme -
It's not a bug. Plz withdraw (0..9)(1..10?)
___
fpc-devel maillist -
On 6/9/2010 5:07 PM, Mattias Gärtner wrote:
* KOL probably has it's own too
no
Yup, no.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 parallization
The link
Michael Schnell wrote:
On 07/13/2010 06:27 PM, Jonas Maebe wrote:
b) indeed also because of the searching for filenames with different
cases.
It might sometimes indeed make sens to not be forced to use the same
name for the unit and the file containing it's source code.
So using in with
Marco van de Voort wrote:
In our previous episode, Thaddy said:
Ok, you write always cheerful, I was merely pointing out it is not
clean, but useful :))
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
A fact has nothing to do with emotions. Check that code. Then write a
review.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
That's not a test. A) 32/64 and B) You should test parallelization, i.e.
threads over multi processors (pref quadcore or more) to see the effect
of topmemory vs the rest.
Try the included test from topmemory. It is in no way biased, but shows
what every manamers bottleneck is.
On 27-10-2010 14:32, Birger Jansen wrote:
Hi all,
I have the following code that throws an error in FPC and runs fine in Delphi:
procedure TForm1.BitBtn1Click(Sender: TObject);
var
MyStringGrid: TStringGrid;
begin
MyStringGrid := TStringGrid.Create(nil);
try
MyStringGrid.RowCount
that is syntactically correct for
Delphi.
Btw, I have worked around it by changing this for kol.pas by hand.
Is this a documented issue or should I submit a bugreport?
Regards,
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
Is this a documented issue or should I submit a bugreport?
Can you please provide an example? The following code compiles for
2.4.0, 2.4.2rc1 and 2.5.1 (from the weekend):
Regards,
Sven
I will try to isolate it. kol.pas is a little fat bastard :)
Small example, 2.5.1 trunk from today
---
program Project2;
{$APPTYPE CONSOLE}
uses windows;
{$DEFINE SHOULD_COMPILE_IN_FPC } // add dot after {
{$IFDEF SHOULD_COMPILE_IN_FPC}
type
PPValueA = ^TPValueA;
PPValue = PPValueA;
pvalueA = packed record
pv_valuename: PAnsiChar;
efforts, I will report the actual cause of the issue.
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
something about it, like with the GNU
compiler set. That one is also prone to a lot of features, btw,
especially cross platform.
Just my two cents. Euro cents are used only virtual anyway.
Thaddy
___
fpc-devel maillist - fpc-devel
Marco, there has been a Bhoem GC for delphi on my website for many years
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 12-11-2010 13:07, Marco van de Voort wrote:
In our previous episode, Thaddy said:
Marco, there has been a Bhoem GC for delphi on my website for many years
Please add it to the wiki, together with whatever experiences you have with
it.
___
fpc
On 14-11-2010 13:22, Vincent Snijders wrote:
would be evaluated every time. S
the O(N^2) stems from the fact that it is hard to get the ith
character in a a UTF8String in O(1). Suppose it is o(N), then the loop
is O(n^2).
Vincent
Hard to is implementation detail and not part of any algorithm. A
for finalization and adapt
heap.inc and do a make clean/make all?
Tobject descendants may require finalization before the garbage
collector cleans them, hence my question.
Or do I need more steps?
Regards,
Thaddy
___
fpc-devel maillist - fpc-devel
On 15-11-2010 10:22, Vincent Snijders wrote:
Maybe I did not understand Thaddy, but to give you O(1) access to the
ith character, I was thinking about a a translation table of the utf8
string, with key=index (1..length) and value=offset in bytes to the
ith character. Such a translation table
On 15-11-2010 14:50, Marco van de Voort wrote:
Oh. Am I supposed to do that? :-)
Yes, please :-) , but others are welcome...
(I just collect info about this subject because it is a recurring white
elephant. Regularly there is talk about it, but nobody has seen a working
implementation, and
On 15-11-2010 14:59, Michael Van Canneyt wrote:
You must finalize, because ref. counting of interfaces etc. need to be
taken
care of. Interfaces may live outside the FPC memory space, and are
therefor
not accessible to the GC. If you want to let the GC collector handle all
that, you're in
rather ambitious goal) FPC version.
Regards,
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
even in a
asynchroneous context..
On 16-11-2010 4:12, Hans-Peter Diettrich wrote:
Thaddy schrieb:
Actually, I am *calling* the destructor in the finalizer, not copying
it. AFAIK this should take care of it.
IMO destructors and finalizers are mutually exclusive, I remember a
note like Why
On 17-11-2010 10:01, Michael Schnell wrote:
On 11/15/2010 02:04 PM, Thaddy wrote: ...
If you want to extend a compiler to allow for garbage collection,
would it not be appropriate to have it manage an additional type of
variables that is supposed to be garbage collection enabled
pointers
would not be surprised at all if the Boehm GC would perform equal
or better after the removal of this sub allocator.
Regards,
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
suggests something like we have in KOL. But that is there
for other reasons: no class ;-)
Is anyone doing anything in converting KOL to 64 on their own? We would
be interested and share our efforts, since there is a lot of demand from
the community.
Regards,
Thaddy
On 24-11-2010 21:32, Michael Van Canneyt wrote:
On Wed, 24 Nov 2010, Anton Kavalenka wrote: Get stdout handle
(duplicate it under linux),
create pipe,
replace the stdout (keeping the old stdout) for current process with
write handle of pipe,
There are following problems with FPC
Under
No, it will not be thread-safe. You'll have to do it over and over
again for
each thread.
I have some code by Peter Below on archive for that, that also works
on FPC win. The implementation part of that unit can be adapted for
nixen.
the file is called streamio.pas and can be easily found
On 25-11-2010 9:21, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
No, it will not be thread-safe. You'll have to do it over and over again for
each thread.
Just curious:Why not? I thought it was safe if you flushed before you created
threads?
Writing to
On 25-11-2010 9:49, Marco van de Voort wrote:
solid solution. *without* the rewrites :)
IIRC there is a pointer in the filetype that points into the buffer.
(bufptr). Just copying that means they still point into the same pointer.
___
Yes, They (input,
On 25-11-2010 10:24, michael.vancann...@wisa.be wrote:
They are threadvars in trunk:
ThreadVar
ThreadID: TThreadID;
{ Standard In- and Output }
ErrOutput,
Output,
Input,
StdOut,
StdErr : Text;
Michael.
___
That's not Delphi
On 25-11-2010 10:46, Anton Kavalenka wrote:
How to reinitialize RTL to have new threads started with working
output file (i.e. without need of rewrite).
regards,
Anton
In Delphi it works - with a critical section - without re-initialization
because it's var,
In FPC there's no easy
On 25-11-2010 10:52, Anton Kavalenka wrote:
?? 25.11.2010 11:39, Thaddy ???(??):
Yes, How standard is standard? when you make it a threadvar.
Should I submit a bug report? It seems like I should:
Because the file drivers allow for redirection anyway and with good reason
On 25-11-2010 11:01, Jonas Maebe wrote:
On 25 Nov 2010, at 10:52, Anton Kavalenka wrote:
Due to incompatibility of RTL between FPC and Delphi my capturing
tricks not work.
BTW what the real reason to make these files as threadvar?
To prevent multiple threads writing to stdin/stdout/sterr
To quote some fiction: There can be only one.
In the context of stdxxx.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 25-11-2010 11:08, Michael Schnell wrote:
But what are the instances for threads connected to ?
This is - should be - opaque.
Regard,
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
.
It should definitely not be a threadvar in my opinion.
Hey, It's Friday!
Regards,
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 25-11-2010 20:15, Anton Kavalenka wrote:
At 25.11.2010 19:57, Jonas Maebe wrote:
On 25 Nov 2010, at 13:21, Jonas Maebe wrote:
the std streams should be on a per process basis (implementation as
var), not on a per thread basis (Iimplementation as threadvar).
Not only is this not Delphi
On 25-11-2010 18:57, Jonas Maebe wrote:
Actually, that won't work because the different threads will then work on a
common buffer but with distinct pointers into it. A better solution is probably
to do this in the intialisation code of each thread instead:
{$ifdef unix}
On 29-11-2010 10:36, Michael Schnell wrote:
On 11/29/2010 10:25 AM, Marco van de Voort wrote:
Do you use 2.4.2 as starting compiler?
I used the latest compiler I was able to install successfully:
Free Pascal Compiler version 2.5.1 [2010/11/22] for i386
Trunk (i.e. 2.5.1 and higher) should be
On 29-11-2010 19:33, Sven Barth wrote:
Just thinking: wouldn't objects in FPC achieve the same as
records-with-methods in Delphi? If objects would be extended with
sealed even the sudden vmt problems mentioned some time ago would
be gone with simple
On 29-11-2010 20:31, Sven Barth wrote:
You are aware that I'm talking about object (the old TP style OOP)
not class (the Delphi style OOP)? object is deprecated in Delphi
since I don't know how long, but in FPC it's still maintained and even
extended.
But what do you mean with elegant vmt
There seem to be a couple of stringresources missing in sqldb.pp latest
checkout, make clean, make all
/FPC/2.5.1/packages/fcl-db/units/i386-win32 -di386 -dRELEASE sqldb.pp
sqldb.pp(765,32) Error: Identifier not found SCommitting
sqldb.pp(779,37) Error: Identifier not found SCommitRetaining
The resourcestrings are in dbconst, and I forgot to commit that. This
has been fixed meanwhile.
Tnx
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Sorry if this is already picked up as it IMHO should have been. I missed
some mails due to a server crash.
Today I encountered a similar issue with using threadvars for the input,
output and err variables in system when trying to use the input as a
win32 sync handle with the CreateFile API.
On 3-12-2010 13:22, Thaddy wrote:
---
CreateFile;
/lpFileName/
Use the CONIN$ value to specify console input.
Use the CONOUT$ value to specify console output.
CONIN$ gets a handle to the console input buffer, even if the
*SetStdHandle*
http://msdn.microsoft.com/en-us/library
On 3-12-2010 13:38, Michael Van Canneyt wrote:
On Fri, 3 Dec 2010, Thaddy wrote:
Sorry if this is already picked up as it IMHO should have been. I
missed some mails due to a server crash.
Today I encountered a similar issue with using threadvars for the
input, output and err variables
Note the console IO functions are *as I read it and can show it* are
supposed NOT to share a single handle. Only the use of the std file
names should guarantee a common handle and that is where FPC fails my tests.
The redirection for other purposes on a OS level call under windows and
posix
On 3-12-2010 13:52, Michael Van Canneyt wrote:
As said in my other mail:
The behaviour of Input, Output, StdErr is not governed by OS rules,
but by the pascal standard.
Michael.
My understanding has always been that the PASCAL syntax allowed for
console IO in a way that encapsulates the
On 13-1-2011 21:40, Sven Barth wrote:
WideString on Windows has no reference counting, thus everytime a
WideString is assigned it needs to be copied.
Not exactly true. widestring is com marshaled and thus has reference
counting on the com level. afaik .
As long as your memorymanager is com
On 14-1-2011 13:21, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
Widestring will also grind the application to a halt due to being COM
based
on Windows.
How that?
WideString on Windows has no reference counting, thus everytime a
WideString is assigned it needs to be copied.
I'm not
current trunk doesn't build. fails on pxlib
- make clean
- make all
- make zipinstall
Platform i-386-win32
OS XP sp3
Bootstrap 2.4.2
---
make[3]: Entering directory `C:/FPC/2.5.1/packages/pxlib'
make all LINKSMART=1 CREATESMART=1
make[4]: Entering directory `C:/FPC/2.5.1/packages/pxlib'
On 31-1-2011 2:06, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
Is the hashtable *really* rebuilt with every push and pop of another
symtable? It would be much easier to have a hashtable per symtable,
that deserves no further modifications. When all hashtables use the
same hash
On 4-7-2011 17:42, Ludo Brands wrote:
Just spent an hour debugging a runtime error 217. No information just
runtime error 217, compilation aborted under lazarus and with lazbuild.
Rebuild fpc with debug information and ran the offending compile command
from the command line (on solaris). FPC
On 5-7-2011 12:34, Felipe Monteiro de Carvalho wrote:
Maybe the compiler should start issuing hints or warnings for all
places where one uses const with ansistring, so that people who don't
care about the speed advantage can start removing those const
ansistrings from their code base.
Yes, but
On 9-7-2011 3:29, Martin wrote:
On 09/07/2011 02:14, Chad Berchek wrote:
Specifically, the way const is now defined (or not...) is
disturbing because it leaves out important details. In C++, you can
pass by value or reference, or by pointer which is a value but is
used to make references. But
I can see the messages in the changelogs of Delphi:
Reason: FPC compatibility
There is a risk of an endless loop here, or a deadlock of some sort 8-)
Good news: the new Firemonkey framework is already 100% compatible with
Freepascal by design.
On 6-8-2011 12:16, Jonas Maebe wrote:
Hi,
See
they could even save more time, it they would use Lazarus ;-)
That's the one part they - Embarcadero - are still miles ahead in
productivity and reliability. Lazarus is workable - more than that - but
still cannot compete with Delphi in productivity - but that of course is
for Windows only.
1 - 100 of 199 matches
Mail list logo
