Chad Berchek schrieb:
All the problems we've seen with const used in various contexts with
different data types--AnsiString, ShortString, records, etc.--are the
result of one fundamental problem, which is the language design. Const
is not clearly defined. All problems mentioned stem from this.
> For completeness and playing Devil's Advocate, I do have to
> ask whether
> pre-v9 (i.e. pre-UltraSPARC) systems are relevant any more.
>
QEMU emulates V8. That's why I had to "downgrade".
Ludo
___
fpc-devel maillist - fpc-devel@lists.freepas
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 what's important is you _always
Martin wrote:
- See difference to normal "const" is " that it must be passed by
reference."
I had not read about it before, but I think constref is a huge step in
the right direction. It eliminates my fundamental grief with the current
implementation.
Specifically, the way const is now "def
On 09/07/2011 00:59, Max Vlasov wrote:
On Sat, Jul 9, 2011 at 3:14 AM, Martin wrote:
function CRCConstString(constref Str: string): integer;
does what you describ
Hmm, it's interesting.. Some observations:
- constref is implemented in 2.5.1, right? Unfortunately I can not
test it right now in
On Sat, Jul 9, 2011 at 3:14 AM, Martin wrote:
> On 09/07/2011 00:09, Max Vlasov wrote:
>>
>> The answer is indirect referencing. it's a workaround that probably
>> will solve the problem, but I must admit that I don't know what is the
>> exact performance price. The compiler when it detects const
On 09/07/2011 00:09, Max Vlasov wrote:
The answer is indirect referencing. it's a workaround that probably
will solve the problem, but I must admit that I don't know what is the
exact performance price. The compiler when it detects const s:
ansistring could switch to passing not the actual addres
On Fri, Jul 8, 2011 at 2:05 PM, Jonas Maebe wrote:
> The main proposals I've seen were
> a) treat const string parameters the same as value parameters (i.e., get rid
> of the current const behaviour)
> b) the same as a), combined with a very conservative heuristic to apply the
> optimization in ca
Ludo Brands wrote:
membar and stbar are instructions available as of sparc v9. To get fpc
running on a sparc
For completeness and playing Devil's Advocate, I do have to ask whether
pre-v9 (i.e. pre-UltraSPARC) systems are relevant any more.
I've got one remaining Sun4m system (SPARCstation 2
Ludo Brands wrote:
membar and stbar are instructions available as of sparc v9. To get fpc
running on a sparc command line option that does the same?
I wonder whether this would be worth considering on a per-OS basis?
Working from memory, when I last looked I think that Linux initialised
the
>
> maybe -uFPC_HAS_MEMBAR.
>
Mmm. Didn't expect that a command line undefine would override a define in
the code. I'll give it a try.
Thanks, Ludo
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinf
2011/7/8 Ludo Brands :
> membar and stbar are instructions available as of sparc v9. To get fpc
> running on a sparc def_system_macro('FPC_HAS_MEMBAR'); in compiler/options.pas. Is there a
> command line option that does the same?
maybe -uFPC_HAS_MEMBAR.
Vincent
_
membar and stbar are instructions available as of sparc v9. To get fpc
running on a sparc http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Friday 08 July 2011 12:05:02 Jonas Maebe wrote:
> The main problem here is that FPC's exception handling is based on
> setjump/longjump. This technique has a relatively high overhead for
> "try", but low overhead when an exception actually occurs (of course,
> since exceptions are supposed
Martin schrieb:
c) keep the current behaviour, but add functionality to the compiler
to help debug problems that can occur as a result of problems that can
occur as a result of this behaviour
Concrete: add means to ignore "const" with managed types.
Further debugging aids as far as feasable.
On Thursday 07 July 2011 19:22:27 Florian Klämpfl wrote:
>
> Why? 2) is exactly the same? The const contract with the compiler is
> broken.
>
> Besides this, people like Martin Schreiber won't be happy if a procedure
> suddently eats hundreds of extra clock cycles for nothing.
>
Here you are very t
Am 08.07.2011 12:05, schrieb Jonas Maebe:
However, looking at the generated assembly, I can't believe there
isn't a more efficient way to handle the implicit try-finally. It
feels to me like that is where the problem is. There is a lot of code
and several function calls that go into implementing
On 08/07/2011 11:05, Jonas Maebe wrote:
On 08 Jul 2011, at 05:51, Chad Berchek wrote:
I'm more interested now in a solution. The solutions I've seen so far
have potential, but in my opinion most of them seem like they are
more complex, would be more overhead, and produce worse performance
than
On 08 Jul 2011, at 05:51, Chad Berchek wrote:
The problem comes down to the specs though, or rather the lack
thereof. As I have searched the web and read some docs at
Embarcadero, things have only become more ambiguous. It seems that
everyone repeats the same basic explanations but never f
Op Thu, 7 Jul 2011, schreef Chad Berchek:
The problem comes down to the specs though, or rather the lack thereof. As I
have searched the web and read some docs at Embarcadero, things have only
become more ambiguous.
You are looking in the wrong places. Both Turbo Pascal and Delphi came
wit
20 matches
Mail list logo
