Jump to page: 1 25  
Page
Thread overview
August 21

from core.sys.posix.sys.mman:

version (linux)
{
    enum MAP_SHARED     = 0x01;
    enum MAP_PRIVATE    = 0x02;
    enum MAP_FIXED      = 0x10;

    enum MAP_FAILED     = cast(void*) -1;

    version (MICROBLAZE)
        private enum DEFAULTS = true;
    else version (Alpha)
    {
        private enum DEFAULTS = false;
        enum MAP_ANON = 0x10;
        enum MS_ASYNC = 1;
        enum MS_SYNC = 2;
        enum MS_INVALIDATE = 4;
    }
    else version (SH)
        private enum DEFAULTS = true;
    else version (ARM_Any)
        private enum DEFAULTS = true;
    else version (IBMZ_Any)
        private enum DEFAULTS = true;
    else version (IA64)
        private enum DEFAULTS = true;
    else version (HPPA_Any)
    {
        private enum DEFAULTS = false;
        enum MAP_ANON = 0x10;
        enum MS_SYNC = 1;
        enum MS_ASYNC = 2;
        enum MS_INVALIDATE = 4;
    }
    else version (M68K)
        private enum DEFAULTS = true;
    else version (TILE)
        private enum DEFAULTS = true;
    else version (X86_Any)
        private enum DEFAULTS = true;
    else version (MIPS_Any)
    {
        private enum DEFAULTS = false;
        enum MAP_ANON = 0x0800;
        enum MS_ASYNC = 1;
        enum MS_INVALIDATE = 2;
        enum MS_SYNC = 4;
    }
    else version (RISCV_Any)
        private enum DEFAULTS = true;
    else version (SPARC_Any)
        private enum DEFAULTS = true;
    else version (PPC_Any)
        private enum DEFAULTS = true;
    else
        static assert(0, "unimplemented");

    static if (DEFAULTS)
    {
        enum MAP_ANON = 0x20;
        enum MS_ASYNC = 1;
        enum MS_INVALIDATE = 2;
        enum MS_SYNC = 4;
    }
}

Like you pretend that enum DEFAULTS is not a workaround the limitations.

August 21
On 8/21/2023 8:39 AM, Basile B. wrote:
> from core.sys.posix.sys.mman:

Spelling it out for each variation makes it easy to read.

With C system headers, I often have to run the preprocessor over it and examine the resulting file to decipher what's really happening with the algebra soup.

August 21
On 8/21/2023 8:39 AM, Basile B. wrote:
> Like you pretend that `enum DEFAULTS` is not a workaround the limitations.

I would not use the DEFAULTS, but would spell it out for each system. Then it looks like a table, with rows and columns, and makes it easy to see which setting is for which system.
August 21
On Monday, 21 August 2023 at 16:19:25 UTC, Walter Bright wrote:
> On 8/21/2023 8:39 AM, Basile B. wrote:
>> Like you pretend that `enum DEFAULTS` is not a workaround the limitations.
>
> I would not use the DEFAULTS, but would spell it out for each system. Then it looks like a table, with rows and columns, and makes it easy to see which setting is for which system.

you have to read top down to see what DEFAULTS do.
August 21
On 8/21/2023 9:26 AM, Basile B. wrote:
> On Monday, 21 August 2023 at 16:19:25 UTC, Walter Bright wrote:
>> On 8/21/2023 8:39 AM, Basile B. wrote:
>>> Like you pretend that `enum DEFAULTS` is not a workaround the limitations.
>>
>> I would not use the DEFAULTS, but would spell it out for each system. Then it looks like a table, with rows and columns, and makes it easy to see which setting is for which system.
> 
> you have to read top down to see what DEFAULTS do.

That's why I wouldn't use the DEFAULTS approach. Just make a table.
August 21
On Monday, 21 August 2023 at 18:01:20 UTC, Walter Bright wrote:
> On 8/21/2023 9:26 AM, Basile B. wrote:
>> On Monday, 21 August 2023 at 16:19:25 UTC, Walter Bright wrote:
>>> On 8/21/2023 8:39 AM, Basile B. wrote:
>>>> Like you pretend that `enum DEFAULTS` is not a workaround the limitations.
>>>
>>> I would not use the DEFAULTS, but would spell it out for each system. Then it looks like a table, with rows and columns, and makes it easy to see which setting is for which system.
>> 
>> you have to read top down to see what DEFAULTS do.
>
> That's why I wouldn't use the DEFAULTS approach. Just make a table.

However that approach was used. It really looks like an alternative to a version OrOr. There are plenty of other examples in drutime sources.

Sure at some point there is also the problem of the unix standards...Every distribution can choose its own value for the flag of this func or that one...which creates complexity in C `define`s, but should not in D. There is a problem that is not solved.
August 21
On 8/21/2023 11:46 AM, Basile B. wrote:
> However that approach was used. It really looks like an alternative to a version OrOr. There are plenty of other examples in drutime sources.

Druntime was written by many people, and does not exhibit consistent best practices.

> Sure at some point there is also the problem of the unix standards...Every distribution can choose its own value for the flag of this func or that one...which creates complexity in C `define`s, but should not in D. There is a problem that is not solved.

I've dealt with enough professional C .h files to conclude that #ifdef algebra is the worst solution. This includes the ones I have written.

The objectives of minimizing keystrokes and maximizing clarity are only rarely aligned.

I understand that many of D's design decisions are out of step with conventional wisdom. They aren't the result of reading about best practices, but instead decades of living with those practices.
August 21
On Monday, 21 August 2023 at 19:27:57 UTC, Walter Bright wrote:

>
> Druntime was written by many people, and does not exhibit consistent best practices.

"best practices" is undefined
August 21
On Monday, August 21, 2023 12:46:47 PM MDT Basile B. via Digitalmars-d wrote:
> On Monday, 21 August 2023 at 18:01:20 UTC, Walter Bright wrote:
> > On 8/21/2023 9:26 AM, Basile B. wrote:
> >> On Monday, 21 August 2023 at 16:19:25 UTC, Walter Bright wrote:
> >>> On 8/21/2023 8:39 AM, Basile B. wrote:
> >>>> Like you pretend that `enum DEFAULTS` is not a workaround the limitations.
> >>>
> >>> I would not use the DEFAULTS, but would spell it out for each system. Then it looks like a table, with rows and columns, and makes it easy to see which setting is for which system.
> >>
> >> you have to read top down to see what DEFAULTS do.
> >
> > That's why I wouldn't use the DEFAULTS approach. Just make a table.
>
> However that approach was used. It really looks like an alternative to a version OrOr. There are plenty of other examples in drutime sources.
>
> Sure at some point there is also the problem of the unix standards...Every distribution can choose its own value for the flag of this func or that one...which creates complexity in C `define`s, but should not in D. There is a problem that is not solved.

The way that version statements try to enforce a lack of boolean logic reflects the way that Walter believes (rightly or wrongly) that versioning code should work based on his experience, but it does not actually prevent you from writing code that uses boolean logic for versioning. It just makes it harder, and given how much most programmers hate code duplication (whereas the way that Walter wants versioning done typically introduces quite a lot of code duplication, even if it's for a good cause), plenty of D programmers routinely work around how version works in order to introduce boolean logic into how they version code. D runtime is not immune to this any more than any other D code, particularly since Walter wrote very little of it. If anything, it probably follows what Walter wants more than most D code, because it's official D stuff, but the way that Walter wants versioning done (while arguably a good idea) strongly goes against how programmers typically function, so it's pretty natural that stuff like this would creep into druntime.

Arguably, stuff like this should be removed from druntime to reflect how Walter wants versioning to be done, but clearly, no one who has spent much time working on druntime has felt strongly enough about it to spend the time to fix the problem, and whoever reviewed the code in question when it was first introduced didn't insist on it being fixed.

Utimately, the fact that people routinely try to work around how version statements work in D doesn't really say anything about whether the reasons for them working the way that they do are good or not. It just shows that (for better or worse) most programmers haven't been brought around to Walter's way of thinking with regards to versioning. In reality, I expect that most of the programmers versioning code in D aren't even aware of why it works the way that it works. They just want to version code the way that comes naturally to them, so they end up fighting how version works rather than adjusting how they function to match.

Personally, I think that Walter is probably right about how versioning should be done, but at the same time, I find it irritating, because it introduces so much code duplication. The code duplication is there to reduce the complexity and reduce the risk of other kinds of problems that typically come with having different versions of the same code, so it is arguably a good a tradeoff, but it often just feels wrong even if it isn't.

That being said, fortunately, most D code doesn't have to worry about version statements much, because druntime hides most of that mess. There are other libraries that wrap C code and/or are more low-level in nature which have to do a fair bit of versioning with code, but most D code is able to be version-agnostic, which fortunately keeps the issues with how how version statements work to a minimum.

- Jonathan M Davis



August 21

On Monday, 21 August 2023 at 19:27:57 UTC, Walter Bright wrote:

>

On 8/21/2023 11:46 AM, Basile B. wrote:

>

However that approach was used. It really looks like an alternative to a version OrOr. There are plenty of other examples in drutime sources.

Druntime was written by many people, and does not exhibit consistent best practices.

>

Sure at some point there is also the problem of the unix standards...Every distribution can choose its own value for the flag of this func or that one...which creates complexity in C defines, but should not in D. There is a problem that is not solved.

I've dealt with enough professional C .h files to conclude that #ifdef algebra is the worst solution. This includes the ones I have written.

The objectives of minimizing keystrokes and maximizing clarity are only rarely aligned.

I understand that many of D's design decisions are out of step with conventional wisdom. They aren't the result of reading about best practices, but instead decades of living with those practices.

I had the same opinion as the OP before, but one thing Walter is correct is that it is better for you to define version presets.

One thing I can't agree is the static assert approach, if you have a really big library, partially porting it makes it quite unfeasible, having ways to just test is a really nice feature.

Also, for not being that verbose, like if(a) b = true; if(c) b = true, I would rather just put the defaults and only change the cases which are different.

One thing that also works even better IMO is using:

version(MICROBLAZE) version = UseDefault;
else version (SH) version = UseDefault;
else version (ARM_Any) version = UseDefault;
else version (IBMZ_Any) version = UseDefault;
else version (IA64) version = UseDefault;

    version(UseDefault)
      private enum DEFAULTS = true;

This pattern has been work really well for me and it makes easier read than only thinking about the "table approach"(unless we really had a table). This also makes your code a lot more consistent. You can even save your version combination as a static if thing (and try to use it as if it were a version).

« First   ‹ Prev
1 2 3 4 5