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.
