Re: Why are class variables public, when marked by the 'private' keyword?
On Saturday, 21 March 2020 at 04:58:32 UTC, Mike Parker wrote: In D, the unit of encapsulation is the module. So private means "private to the module", i.e., private members are accessible within the same module. If ID were in a different module from main, you would see an error. Indeed, I read something like this somewhere... It makes sense to me now! Thank you!
Re: Why are class variables public, when marked by the 'private' keyword?
On Saturday, 21 March 2020 at 04:45:29 UTC, Kirill wrote: I was playing around with visibility attributes in D. I created a class with private variables. Then I tried to access those variables through the class object. It compiled without any errors. However, ... Shouldn't the compiler output an error for trying to access private members of a class? Do I get something wrong? Here is the code: import std.stdio; class ID { public: int id = 3849493; private: string name = "Julia"; int age = 17; }; void main() { ID p = new ID(); writeln(p.name, " ", p.age, " ", p.id); } In D, the unit of encapsulation is the module. So private means "private to the module", i.e., private members are accessible within the same module. If ID were in a different module from main, you would see an error.
Why are class variables public, when marked by the 'private' keyword?
I was playing around with visibility attributes in D. I created a class with private variables. Then I tried to access those variables through the class object. It compiled without any errors. However, ... Shouldn't the compiler output an error for trying to access private members of a class? Do I get something wrong? Here is the code: import std.stdio; class ID { public: int id = 3849493; private: string name = "Julia"; int age = 17; }; void main() { ID p = new ID(); writeln(p.name, " ", p.age, " ", p.id); }
Strip Unused Symbols Ldc + Windows
Someone knows how to strip unused symbols on final binary using ldc on windows ? i found this about this topic: https://forum.dlang.org/post/yvmnkvzgoxhcfavja...@forum.dlang.org that uses --gc-sections and --version-script but this options are not avaliable in windows lld-link
Re: OR in version conditional compilation
On Saturday, 21 March 2020 at 00:12:20 UTC, Jonathan M Davis wrote: On Friday, March 20, 2020 4:33:58 PM MDT jxel via Digitalmars-d-learn wrote: On Friday, 20 March 2020 at 21:03:55 UTC, Jonathan M Davis wrote: > On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via > > Digitalmars-d-learn wrote: >> I have not seen any example where version has several OR >> matches. >> >> Example idiom: >> >> version(X86_64 || X86) >> { >> >> } >> else version(ARM || Thumb) >> { >> >> }... >> >> you get the idea. So is this possible at all or do you have >> to duplicate the code for each version identifier despite >> they are equal for many version identifiers? > > To add to what the others have said, the reasons that Walter > is against having boolean conditions in version statements > have to do with how using boolean conditions in #ifdefs in > C/C++ has historically been a big source of bugs. So, > disallowing it helps prevent certain classes of bugs. It's > why druntime duplicates most C declarations across platforms. What kind of bugs are those? There are a variety of issues that come from it, and it's been discussed at length in past threads (and much better than I'll explain here, I'm sure), but the main issues stem from the fact that when you're writing code that is platform-dependent but using it on multiple platforms, it can become really easy to break stuff as the code is altered over time. e.g. you can make a change that works perfectly fine on the platform that you're developing on without realizing that it won't work on the other platforms sharing the same #ifdef block, and while you should be testing such code on all supported platforms, it often doesn't happen, and even when it does happen, it's usually much further down the line after many more changes have been made. It would be highly abnormal for someone to test what they're working on on all of the relevant platforms as they're working on it. None of that is limited specifically to ifdefs. If you modify code not in an ifdef you can still cause bugs that only materialize on specific platforms. This is the nature of building for multiple platforms at the low level, hell you'll still have problems even in Java. The D test suite doesn't run unit tests for every platform for all libraries. There's also debug assert statements that fail, and at least last I checked for some platforms didn't run debug builds, so the tests don't catch this. And not everyone develops for those platforms so I guess no one does a debug build on their systems either. It also can get really tricky to avoid subtle bugs once you start having more complex boolean expressions and/or have nested #ifdefs. That's where things tend to get _really_ bad. Another big problem comes in when you just assume that the code from one platform will work with another and alter existing #ifdefs to be used on the new platform. Suddenly code that was only supposed to be used on one platform is being used on multiple, and it can cause big problems depending on what that code actualy does and what assumptions were made when writing it. By simply following the basic idiom of version(A) { } else version(B) { } else static assert(false, "Platform not supported"); you avoid problems that stem from code being used an a platform that it's not intended for, and you get compilation errors if you try to use code on a platform that it wasn't made to work on yet. It can result in more code duplication than many people like, but it's ultimately less error-prone. Either way, in general, it's far better to design your code such that as little of it as possible is platform-dependent and that those parts that are are well-encapsulated. - Jonathan M Davis Like I said in my other comment. This only works if you can assert out of it, and in C and C++ it is the same. There's a bigger problem that still isnt solved, if you need one version statement that doesn't assert to failure. Since a typo will just evaluate to false, the version statement may never be active under any circumstance and it would be difficult to fins such a bug. For example for conguration options, there's no other versions you would put in else versions, and it isnt intended to fail if that configuration version isnt there. The version feature inherited one of C's worst characteristics of the preprocessor for ifdef.
Re: dub and -lowmem: does nothing
On Friday, 20 March 2020 at 23:37:52 UTC, Anonymouse wrote: 4. If I run dub with -v on the lowmem configuration and copy/paste *the same command it ran*, unmodified, I suddenly get the more expected ~1183 Mb used. [...] -lowmem is visibly present in the dmd command listed with -v, but it seems to do nothing through dub. How? Why? Most likely because dub doesn't actually invoke the listed command, but uses a response file to work around cmdline length limits. -lowmem in response files is ignored by DMD (needs to be parsed and set before druntime initialization, but response file parsing needs druntime + GC). It works for LDC though.
Re: OR in version conditional compilation
On Friday, March 20, 2020 4:33:58 PM MDT jxel via Digitalmars-d-learn wrote: > On Friday, 20 March 2020 at 21:03:55 UTC, Jonathan M Davis wrote: > > On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via > > > > Digitalmars-d-learn wrote: > >> I have not seen any example where version has several OR > >> matches. > >> > >> Example idiom: > >> > >> version(X86_64 || X86) > >> { > >> > >> } > >> else version(ARM || Thumb) > >> { > >> > >> }... > >> > >> you get the idea. So is this possible at all or do you have to > >> duplicate the code for each version identifier despite they > >> are equal for many version identifiers? > > > > To add to what the others have said, the reasons that Walter is > > against having boolean conditions in version statements have to > > do with how using boolean conditions in #ifdefs in C/C++ has > > historically been a big source of bugs. So, disallowing it > > helps prevent certain classes of bugs. It's why druntime > > duplicates most C declarations across platforms. > > What kind of bugs are those? There are a variety of issues that come from it, and it's been discussed at length in past threads (and much better than I'll explain here, I'm sure), but the main issues stem from the fact that when you're writing code that is platform-dependent but using it on multiple platforms, it can become really easy to break stuff as the code is altered over time. e.g. you can make a change that works perfectly fine on the platform that you're developing on without realizing that it won't work on the other platforms sharing the same #ifdef block, and while you should be testing such code on all supported platforms, it often doesn't happen, and even when it does happen, it's usually much further down the line after many more changes have been made. It would be highly abnormal for someone to test what they're working on on all of the relevant platforms as they're working on it. It also can get really tricky to avoid subtle bugs once you start having more complex boolean expressions and/or have nested #ifdefs. That's where things tend to get _really_ bad. Another big problem comes in when you just assume that the code from one platform will work with another and alter existing #ifdefs to be used on the new platform. Suddenly code that was only supposed to be used on one platform is being used on multiple, and it can cause big problems depending on what that code actualy does and what assumptions were made when writing it. By simply following the basic idiom of version(A) { } else version(B) { } else static assert(false, "Platform not supported"); you avoid problems that stem from code being used an a platform that it's not intended for, and you get compilation errors if you try to use code on a platform that it wasn't made to work on yet. It can result in more code duplication than many people like, but it's ultimately less error-prone. Either way, in general, it's far better to design your code such that as little of it as possible is platform-dependent and that those parts that are are well-encapsulated. - Jonathan M Davis
dub and -lowmem: does nothing
Manjaro/Arch x86_64, dmd v2.091.0, dub 1.19.0. I have a project which dmd on Windows fails to compile, throwing an OutOfMemoryError[1]. Up until recently it could be worked around by using `--build-mode=singleFile`, but now that's no longer enough and errors out too (on AppVeyor). The obvious solution is to set `-lowmem` in dub.sdl, but it seems to do nothing, as measured *in Linux* by the amount of memory used with zsh's `time` shell built-in. If using zsh time, you may need the following environmental variable to get the required output: ``` TIMEFMT='%J %U user %S system %P cpu %*E total avg shared (code): %X KB avg unshared (data/stack): %D KB total (sum): %K KB max memory:%M MB page faults from disk: %F other page faults: %R' ``` A gutted test branch: (has two dependencies) git clone https://github.com/zorael/tests.git -b lowmem 1. `dub build` on a default configuration without -lowmem defined shows some ~2011 Mb used. 2. If I run dub with -v, then copy the dmd command it runs and execute it manually, I get the same ~2012 Mb used. Close enough, makes sense. 3. `dub build -c lowmem` for an identical configuration but with dflags "-lowmem" added, nothing changes and I still get ~2011 Mb used. 4. If I run dub with -v on the lowmem configuration and copy/paste *the same command it ran*, unmodified, I suddenly get the more expected ~1183 Mb used. Log: https://pastebin.com/raw/yDnCj1KJ -lowmem is visibly present in the dmd command listed with -v, but it seems to do nothing through dub. How? Why? dub remove lu --version="*" dub remove dialect --version="*" [1]: https://issues.dlang.org/show_bug.cgi?id=20562
Re: OR in version conditional compilation
On Friday, 20 March 2020 at 21:03:55 UTC, Jonathan M Davis wrote: On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via Digitalmars-d-learn wrote: I have not seen any example where version has several OR matches. Example idiom: version(X86_64 || X86) { } else version(ARM || Thumb) { }... you get the idea. So is this possible at all or do you have to duplicate the code for each version identifier despite they are equal for many version identifiers? To add to what the others have said, the reasons that Walter is against having boolean conditions in version statements have to do with how using boolean conditions in #ifdefs in C/C++ has historically been a big source of bugs. So, disallowing it helps prevent certain classes of bugs. It's why druntime duplicates most C declarations across platforms. What kind of bugs are those? In general, I think that Walter's approach here is probably the right one, but it can certainly be annoying in cases where you have to duplicate code that actually is the same rather than being subtly different, and a lot of people dislike it enough that they use workarounds like those discussed in this thread. Sadly it still shares probably the worst bug with the C preposser in that anything that isnt defined simply evaluates to false. If you have a typo then the code will still "work". His approach only works if you can put an assert in the else branch. Which is the case for C/C++ as well. That isnt always possible, as a result you still have the same problem with typos. And of course, some of the same bugs that come up with #ifdefs come up with static ifs in generic code (particularly with range-based code that changes what it's doing based on arange's type), but at least those can be found with thorough tests on a single platform, whereas version-related bugs tend to require that you run thorough tests on each platform. - Jonathan M Davis You still need to test your code on those platforms, so if you are supporting them you still have related problems.
Re: OR in version conditional compilation
On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via Digitalmars-d-learn wrote: > I have not seen any example where version has several OR matches. > > Example idiom: > > version(X86_64 || X86) > { > > } > else version(ARM || Thumb) > { > > }... > > you get the idea. So is this possible at all or do you have to > duplicate the code for each version identifier despite they are > equal for many version identifiers? To add to what the others have said, the reasons that Walter is against having boolean conditions in version statements have to do with how using boolean conditions in #ifdefs in C/C++ has historically been a big source of bugs. So, disallowing it helps prevent certain classes of bugs. It's why druntime duplicates most C declarations across platforms. In general, I think that Walter's approach here is probably the right one, but it can certainly be annoying in cases where you have to duplicate code that actually is the same rather than being subtly different, and a lot of people dislike it enough that they use workarounds like those discussed in this thread. And of course, some of the same bugs that come up with #ifdefs come up with static ifs in generic code (particularly with range-based code that changes what it's doing based on arange's type), but at least those can be found with thorough tests on a single platform, whereas version-related bugs tend to require that you run thorough tests on each platform. - Jonathan M Davis
Re: need help to get member function const address
On Thursday, 19 March 2020 at 23:46:01 UTC, Boris Carvajal wrote: https://issues.dlang.org/show_bug.cgi?id=20687 https://github.com/dlang/dmd/pull/10946 Thanks very much for such a quick fix.