Am 14.07.2019 um 04:08 schrieb J. Gareth Moreton:
Just a thought that I'd chuck in on this... I did wonder how practical
it would be to store checksums of all compiled procedures and the like
and to look for collisions. When studying how the compiler is built,
I noticed a lot of the
Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton:
On another note, I do think pass_2 (pass_generate_code) could use some
refactoring. I don't like how "flowcontrol" is a global variable.
Though it's unlikely to happen, such a state variable not being tied
to a management object (e.g.
So what's the verdict so far? Do I have your blessing to start work on this?
Because of its complexity, I'll do one of my PDF design specs as well.
Admittedly my mind is drifting a little bit because I want to see how
much optimisation can be done at the node level (e.g. converting "x * 1"
to
On 14/07/2019 00:12, Martok wrote:
>
>> In Delphi's type system (and in C, C++, and C#), the valid values for an
>> enum are always all values that fit within its storage size, and that
>> storage size is fixed.
>>
>> In FPC's type system (and in Ada and Java), the valid values for an an
>> enum
On 14/07/2019 04:08, J. Gareth Moreton wrote:
> Just a thought that I'd chuck in on this... I did wonder how practical
> it would be to store checksums of all compiled procedures and the like
> and to look for collisions. When studying how the compiler is built, I
> noticed a lot of the internal
On 13/07/2019 15:13, Ryan Joseph wrote:
>
>
>> On Jul 13, 2019, at 8:21 AM, Jonas Maebe wrote:
>>
>> In which scenarios do you need such a custom "move" operator, rather
>> than simply allowing the compiler to just copy the data from one place
>> to the other without calling a destructor on the
Am 14.07.2019 um 14:18 schrieb Jonas Maebe:
>> Side note: if this was done 100% consistently (and it does make sense!), the
>> PACKENUM directive would be completely useless. There is no point in being
>> able
>> to specify the storage size of an enum when it can be and is ignored at will.
>
>
> On Jul 14, 2019, at 8:55 AM, Jonas Maebe wrote:
>
> The question then still remains: why would a user want to call a copy
> operator when the data is just moved from a temp to another place?
> Having an explicit copy operator when there is no use case for it only
> requires programmers to
On 14/07/2019 15:53, Martok wrote:
> Am 14.07.2019 um 14:18 schrieb Jonas Maebe:
>>> Side note: if this was done 100% consistently (and it does make sense!), the
>>> PACKENUM directive would be completely useless. There is no point in being
>>> able
>>> to specify the storage size of an enum when
On Sun, 14 Jul 2019, Ryan Joseph wrote:
On Jul 14, 2019, at 8:55 AM, Jonas Maebe wrote:
The question then still remains: why would a user want to call a copy
operator when the data is just moved from a temp to another place?
Having an explicit copy operator when there is no use case for
> If you want to nitpick, the compiler will perform 1/2/4 byte writes for
> enums of those sizes, so the full reserved data is in fact
> used/initialised. Again: the only relevant part in this discussion is
> the valid values. The reserved/used/accessed/written/... storage size is
> unrelated to
Looks like we have a deal then! Break away code from "pass_1" into
"pass_semantic".
Thanks for your support Florian - I'll start making plans.
Gareth aka. Kit
On 14/07/2019 19:45, Florian Klämpfl wrote:
Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton:
So having a long think over the past
> On Jul 14, 2019, at 11:58 AM, Michael Van Canneyt
> wrote:
>
> You are assuming here that there is a problem. Has it occurred to you that
> maybe there is no problem and that a solution is simply not needed?
How is this not a problem? Sorry I don’t follow you.
Regards,
Ryan Joseph
Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton:
> So having a long think over the past day, I'm starting to turn against the
> second idea I had because it would require
> complex state variable tracking and is just asking for a new bug to be
> introduced, not to mention that the additional
>
On Sun, 14 Jul 2019, Ryan Joseph wrote:
On Jul 14, 2019, at 11:58 AM, Michael Van Canneyt
wrote:
You are assuming here that there is a problem. Has it occurred to you that
maybe there is no problem and that a solution is simply not needed?
How is this not a problem? Sorry I don’t
> On Jul 14, 2019, at 12:40 PM, Michael Van Canneyt
> wrote:
>
> Maybe there is no need for a move operator ? I have not seen any argument
> that makes the need for this operator crystal clear.
>
> When I read your proposal, my first thought was: "solution looking for a
> problem."
Look at
16 matches
Mail list logo