On 7/30/13, Sven Barth wrote:
> Please ensure that you attach a complete example that should be
> compileable.
There is already a bugreport about that Internal Error:
http://bugs.freepascal.org/view.php?id=18967
It is resolved as "Probably fixed in the mean time".
It should be re-opened (by some
On 30 Jul 2013, at 04:17, Noah Silva wrote:
> 2013/7/29 Jonas Maebe
>
>> If your source code is in UTF8 but you do not tell this to the compiler,
>> it will directly pass the "garbage" in your source code to the Win32 APIs.
>> After all, there is no way for it to know what else it should with i
On 07/30/2013 04:29 AM, Noah Silva wrote:
No, UTF16 only needs more memory if most of the text is ASCII. It
actually uses less than UTF8 in the average case for Japanese, for
example.
Of course you are right here.
Linux OS API in most cases is 8 Bit,
I assume by 8bit, you mean variabl
Hello,
I would like to ask state of implementation unicode rtl - if I has figured
it correctly it is developed in branches/unicode. When I try to compile it
(with fpc release 2.6.2) and use define FPC_UNICODE_RTL, I will get errors
like:
variant.inc(82,10) Error: Illegal type conversion: "Text" to
On 29 Jul 2013, at 14:52, ko paka wrote:
> Hello,
>
> I would like to ask state of implementation unicode rtl - if I has figured
> it correctly it is developed in branches/unicode. When I try to compile it
> (with fpc release 2.6.2) and use define FPC_UNICODE_RTL, I will get errors
> like:
> var
Hi,
>
> >> If your source code is in UTF8 but you do not tell this to the compiler,
>
...
> > tried that some of the time. I have never had any problems other than
> the
> > Windows Console issue.
>
> As mentioned before, that causes the compiler to directly pass your UTF-8
> data around with a
On 30 Jul 2013, at 12:04, Noah Silva wrote:
It causes the compiler to interpret the string constants in your
program
as UTF-8 rather than as unknown binary data, and hence convert them
at run
time to the current ansi code page when assigning them to an
ansistring/shortstring. This is unrela
Thank for the reponse - I will keep eye on both branches, but for now I
will stay with ansi rtl and will somehow patch problematic parts in our
code.
tomas
On Tue, Jul 30, 2013 at 10:12 AM, Jonas Maebe wrote:
>
> On 29 Jul 2013, at 14:52, ko paka wrote:
>
> > Hello,
> >
> > I would like to ask
FPC offers the +=, -=, etc., statements swiped from C. Is there any
reason why ++ and -- are not similarly supported? I know that we have
inc() and dec(), but I'd say that ++ and -- are easier to type.
___
fpc-pascal maillist - fpc-pascal@lists.fre
On Tue, July 30, 2013 17:03, Timothy Groves wrote:
> FPC offers the +=, -=, etc., statements swiped from C. Is there any
> reason why ++ and -- are not similarly supported? I know that we have
> inc() and dec(), but I'd say that ++ and -- are easier to type.
General side note with no intention t
If you dig in the mailing list a while ago, there's a fact revealed there.
The C style operator was actually a 3rd party contribution, not the initial
feature design.
One of the reason people who prefer Pascal is because it's easier to read,
not easier to type. A brainfuck code would be the easies
In our previous episode, leledumbo said:
> If you dig in the mailing list a while ago, there's a fact revealed there.
> The C style operator was actually a 3rd party contribution, not the initial
> feature design.
And mostly accepted for easy conversion purposes, not to write new code.
_
Tomas Hajny wrote:
On Tue, July 30, 2013 17:03, Timothy Groves wrote:
FPC offers the +=, -=, etc., statements swiped from C. Is there any
reason why ++ and -- are not similarly supported? I know that we have
inc() and dec(), but I'd say that ++ and -- are easier to type.
General side note wi
On 30.07.2013 18:20, Mark Morgan Lloyd wrote:
Now specifically to your question - I believe that one of the reasons may
be the fact that Pascal does not support unary arithmetic operators in
postfix notation. The fact that C allows using them with both prefix and
postfix notation makes them even
On 30.07.2013 18:16, Marco van de Voort wrote:
In our previous episode, leledumbo said:
If you dig in the mailing list a while ago, there's a fact revealed there.
The C style operator was actually a 3rd party contribution, not the initial
feature design.
And mostly accepted for easy conversion
On Tue, 30 Jul 2013 20:12:29 +0200
Sven Barth wrote:
> On 30.07.2013 18:16, Marco van de Voort wrote:
>[...]
> Also +=, etc are not true operators in FPC like they are in e.g. C++,
> but they are internally translated to "a := a + b", etc. So potential
> sideeffects need to be remembered here.
On 30.07.2013 20:24, Mattias Gaertner wrote:
On Tue, 30 Jul 2013 20:12:29 +0200
Sven Barth wrote:
On 30.07.2013 18:16, Marco van de Voort wrote:
[...]
Also +=, etc are not true operators in FPC like they are in e.g. C++,
but they are internally translated to "a := a + b", etc. So potential
sid
In our previous episode, Mattias Gaertner said:
> > Also +=, etc are not true operators in FPC like they are in e.g. C++,
> > but they are internally translated to "a := a + b", etc. So potential
> > sideeffects need to be remembered here.
>
> That's not entirely true. For example "a:=a+b" is al
Am 30.07.2013 09:34, schrieb Bart:
On 7/30/13, Sven Barth wrote:
Please ensure that you attach a complete example that should be
compileable.
There is already a bugreport about that Internal Error:
http://bugs.freepascal.org/view.php?id=18967
It is resolved as "Probably fixed in the mean tim
(If +=, -= etc. would have been copied from Algol68 and not from C, it would
have been written +:= -:=, which looks more pascal-like. And the acceptance
for these constructs would be wider, I assume. Just an optical note to that
theme).
Beside of the question, if ++,--,+=,etc. fit into Pascal
On 30 Jul 2013, at 22:17, Gerhard Scholz wrote:
> Beside of the question, if ++,--,+=,etc. fit into Pascal or not, there stays
> the question: is it a plus?
> I expected that
> a[i] += 3
> compiles better than
> a[i] := a[i] + 3
> I expected that the computation of a[i] is done only once, but th
On 7/30/13, Florian Klaempfl wrote:
> It makes no sense to reopen it if no complete example how to reproduce
> it is provided.
Neither does opening a new one with a complete example in thiws case IMHO.
But that ship has sailed. A new bugreport has been created, with
example: http://bugs.freepasc
> Syntax and generated code are in principle unrelated. The reason you don't
get the optimised version of the code, is probably because you used global
variables
I second that. People who uses C style short unreadable code approach
usually state they get more optimized code, yet the compiler is ac
23 matches
Mail list logo
