Am 03.07.2012 02:51, schrieb JC Chu:
isbinaryoperatoroverloadable() is called once. It first calls
internal_check() with the default (LHS, RHS) order. internal_check()
accepts or rejects the pair only if it recognizes the pair. Only if
(LHS, RHS) is not recognized, will internal_check() be cal
Am 03.07.2012 02:49, schrieb JC Chu:
Yes. I made that error in my first patch. The new compiler wasn’t
even able to compile itself…
I don't know whether you know this, but:
* testing the compiler compilation (as a first step) is best done using
"make cycle" in the compiler subdirectory (opti
Yes, it should. The bottomline is that cases treated as overloadable
must not be defined by the default interpretation, because the
overloaded interpretation will always take precedence. This is
probably why the ld.typ = orddef case is not handled by either
isbinaryoperatoroverloadable() or its u
On Tue, Jul 3, 2012 at 3:55 PM, Sven Barth wrote:
> I don't know whether you know this, but:
> * testing the compiler compilation (as a first step) is best done using
> "make cycle" in the compiler subdirectory (optionally "make fullcycle" if
> you changed something were a subset of the supported
Am 03.07.2012 12:23 schrieb "JC Chu" :
>
> On Tue, Jul 3, 2012 at 3:55 PM, Sven Barth
wrote:
> > I don't know whether you know this, but:
> > * testing the compiler compilation (as a first step) is best done using
> > "make cycle" in the compiler subdirectory (optionally "make fullcycle"
if
> > yo
Sven Barth wrote on Tue, 03 Jul 2012:
Am 03.07.2012 12:23 schrieb "JC Chu" :
Could you elaborate on that? Do I need to run the test suite with the
old compiler first?
* first do a "make cycle" on a unmodified checkout, then run the testsuite.
While "make cycle" is useful as a first test,
Hello all,
While I'm experimenting with DLLs generated by FreePascal, I made sure
that every exported function has its own try..except construct so that
no exception escapes from those functions. Instead, in the except part,
I do something like that:
on E: TObject do
begin
SetL
How to put longstrings globally on?
I tried with {$h+} in project compiler settings (other) with no effect.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Example of this "no effect"? {$H+} should do it.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Longstrings-tp5710228p5710229.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal
Am 2012-07-04 00:48, schrieb Rainer Stratmann:
How to put longstrings globally on?
I tried with {$h+} in project compiler settings (other) with no effect.
Safest method is not to use the generic type "string" in your code.
Instead use directly the string type that you need (i.e. "ansistring" or
10 matches
Mail list logo
