Re: weird behave of Array?
On Monday, 29 July 2019 at 05:58:21 UTC, dmm wrote:
So, d try to be smart, only make thing worse?
D is behaving exactly as it should here. You simply have a wrong
model of what an array is in D.
In C++, an array owns its memory. In D, an array is a thin
wrapper around GC managed memory. As such, for instance, you can
take a reference to an array field, then resize the array, and
the original reference will still be valid and at its original
value.
To do what you want, use std.array.Appender, which owns its
memory.
import std.algorithm;
import std.array;
import std.range;
import std.stdio;
void main() {
Appender!(int[]) app;
10.iota.each!(a => app.put(a));
writefln!"%s, %s"(app.data.ptr, app.data);
app.shrinkTo(0);
10.iota.each!(a => app.put(a));
writefln!"%s, %s"(app.data.ptr, app.data);
}
Re: Calling / running / executing .d script from another .d script
On Sunday, 28 July 2019 at 12:56:12 UTC, BoQsc wrote: Right now, I'm thinking what is correct way to run another .d script from a .d script. Do you have any suggestions? You mean something like execute(["rdmd", "another.d"]); ?
There is anything like nodiscard attribute in D?
I have an Expected/Result struct, but without an attribute similar to nodiscard (https://en.cppreference.com/w/cpp/language/attributes/nodiscard) is not very useful. There is anything like that in D? If not, there is any plan to add it?
Question on Password Encryption, using stdlib or third party lib
On a project I was asked to a- Compute SHA-256 of a password b- Do a BigInteger, convert to Hex String c- Encrypt the key using a public key with the following parameters Entropy: I'm given some numbers Modulus: also given long numbers [encrypt using RSA algorithm] So far I'm familiar with a and b in Dlang. how do I go about c) In Dlang ? Thanks
Re: Question on Password Encryption, using stdlib or third party lib
On Monday, 29 July 2019 at 14:37:54 UTC, 0x wrote: On a project I was asked to a- Compute SHA-256 of a password b- Do a BigInteger, convert to Hex String c- Encrypt the key using a public key with the following parameters Entropy: I'm given some numbers Modulus: also given long numbers [encrypt using RSA algorithm] So far I'm familiar with a and b in Dlang. how do I go about c) In Dlang ? Thanks I hope it's for a school project since I wouldn't recommend doing that in production. However you can do c) either by implementing RSA (it's rather easy to badly implement RSA which could be enough at school level) or by using a library (I recommend the library). There are several cryptographic libraries on https://code.dlang.org that implement RSA, botan and crypto for example. I'd trust botan more at the moment though I don't think any D library has received a proper cryptographic audit at the moment.
Re: There is anything like nodiscard attribute in D?
On Monday, July 29, 2019 8:23:43 AM MDT victoroak via Digitalmars-d-learn wrote: > I have an Expected/Result struct, but without an attribute > similar to nodiscard > (https://en.cppreference.com/w/cpp/language/attributes/nodiscard) > is not very useful. > > There is anything like that in D? If not, there is any plan to > add it? No, D does not currently have a feature like that, and there are not currently any plans to add such a feature. If someone writes a DIP (D Improvement Proposal) for such a feature and provides good enough arguments for why it's worth adding that the DIP ends up being accepted, then such a feature would be added, but AFAIK, no one has written such a proposal. The closest that D has to such a feature is that if a function is pure, then IIRC in at lesat some cases, the compiler will warn if the return value is ignored, because there isn't normally any point to a pure function if you ignore everything that it does, but that probably requires that the function be "strongly" pure (meaning that all of its parameters are immutable or implicitly convertible to immutable), since if it's possible for any effects to escape via the function arguments (e.g. because they're pointers or ref), then ignoring the return value isn't necessarily a problem. However, that's the only time that D complains about a function's return value being ignored. - Jonathan M Davis
Re: Question on Password Encryption, using stdlib or third party lib
On Monday, 29 July 2019 at 14:37:54 UTC, 0x wrote: On a project I was asked to a- Compute SHA-256 of a password b- Do a BigInteger, convert to Hex String c- Encrypt the key using a public key with the following parameters Entropy: I'm given some numbers Modulus: also given long numbers [encrypt using RSA algorithm] So far I'm familiar with a and b in Dlang. how do I go about c) In Dlang ? Thanks It is exponent not entropy
Building GDC with auto-generated header files
Cheers, everybody I'm working on this as part of my GSoC project [0]. I'm working on building gdc with the auto-generated `frontend.h` [1], but I'm having some issues There are functions in dmd that don't have an `extern (C)` or `extern (C++)` but they are used by gdc (are exposed in `.h` files) An example of such a function is `checkNonAssignmentArrayOp`[2] from `dmd/arrayop.d` which is can be found in `gcc/d/dmd/expression.h` [3] How does the linker find the right match in dmd? Since the function is `extern (D)`, isn't it mangled differently than C++? [0] - https://forum.dlang.org/thread/djurwumzfrrttvtdg...@forum.dlang.org [1] - https://github.com/dlang/dmd/pull/9971 [2] - https://github.com/dlang/dmd/blob/master/src/dmd/arrayop.d#L85 [3] - https://github.com/gcc-mirror/gcc/blob/master/gcc/d/dmd/expression.h#L84
Why in Phobos is empty() sometimes const and sometimes not
I've noticed that for some ranges in Phobos empty is marked const (e.g. iota) but for other ranges (e.g. multiwayMerge) it is not const. Is there a reason why? Isn't empty guaranteed not to alter the data of the range and so should be const? This is causing me considerable headaches as I try to write my own ranges that accept other ranges and have it all work for the general case. Any advice would be welcome.
Re: Why in Phobos is empty() sometimes const and sometimes not
On Monday, 29 July 2019 at 17:32:58 UTC, Matt wrote: I've noticed that for some ranges in Phobos empty is marked const (e.g. iota) but for other ranges (e.g. multiwayMerge) it is not const. Is there a reason why? Isn't empty guaranteed not to alter the data of the range and so should be const? This is causing me considerable headaches as I try to write my own ranges that accept other ranges and have it all work for the general case. Any advice would be welcome. You could use introspection (a static i) to check if the type defines a const/non-const version and write the appropriate empty declaration. As for why it’s like this I’ll have to look at the code in Phobos, but I’m currently away from my pc (on the phone). Cheers, Edi
Re: Why in Phobos is empty() sometimes const and sometimes not
On Mon, Jul 29, 2019 at 05:32:58PM +, Matt via Digitalmars-d-learn wrote:
> I've noticed that for some ranges in Phobos empty is marked const
> (e.g. iota) but for other ranges (e.g. multiwayMerge) it is not
> const. Is there a reason why? Isn't empty guaranteed not to alter the
> data of the range and so should be const?
Although .empty should be *logically* const, some ranges do non-const
work in .empty for various reasons (e.g., caching, lazy evaluation,
etc.). Since D doesn't have logical const, it can't be used in every
case.
> This is causing me considerable headaches as I try to write my own
> ranges that accept other ranges and have it all work for the general
> case. Any advice would be welcome.
Generally, the idiom is to let the compiler do attribute inference by
templatizing your code and not writing any explicit attributes, then use
unittests to ensure that instantiations of the range that ought to have
certain attributes actually have those attributes. For example, instead
of writing:
struct MyRange(R) {
...
@property bool empty() const { ... }
...
}
write instead:
struct MyRange(R) {
...
// No attributes: compiler does inference
@property bool empty() { ... }
...
}
// unittest ensures .empty is callable with const object.
unittest {
const rr = MyRange!(const(Range))(...);
assert(rr.empty); // will fail compilation if .empty is
non-const
}
The unittest tests that a specific instantiation of MyRange has const
.empty. It's still possible to use MyRange with a range that has
non-const .empty, but this unittest ensures that the non-const-ness
wasn't introduced by the implementation of MyRange itself, but only
comes from the template argument.
T
--
"Holy war is an oxymoron." -- Lazarus Long
Re: Why in Phobos is empty() sometimes const and sometimes not
On Monday, July 29, 2019 11:32:58 AM MDT Matt via Digitalmars-d-learn wrote: > I've noticed that for some ranges in Phobos empty is marked const > (e.g. iota) but for other ranges (e.g. multiwayMerge) it is not > const. Is there a reason why? Isn't empty guaranteed not to alter > the data of the range and so should be const? > > This is causing me considerable headaches as I try to write my > own ranges that accept other ranges and have it all work for the > general case. Any advice would be welcome. empty is most definitely _not_ guaranteed to not mutate the range. No, it must not change whether the range is actually empty or not, consume elements, etc., but stuff like caching or delayed calculation can affect what empty does in ways that would require mutation. For instance, filter avoids doing any real work in its constructor, but that means that in order for empty to work if it's called before front or popFront (as would be typical), it has to do the work to get the range to its starting point so that it's known whether it's actually empty or not. So, filter's empty can't be const. In general, generic code can't assume that a range-based function is const, because that varies wildly across ranges, because they're frequently wrapping other ranges. Even if a range that's being wrapped could theoretically be const, it's frequently the case that it isn't, because there isn't much point. Ranges are pretty much useless if they're const. The best that you'd be able to do with any range API functions would be to call empty, front, back (if it's a bidirectional range), opIndex (if it's a random-access range), and maybe opSlice (if it has slicing). But pretty much the only range types that will give you a tail-const slice if you slice them is dynamic arrays, because the compiler understands them and knows that it's safe to const(T)[] instead of const(T[]), whereas with templated types, not only is there no way for it to know what the tail-const equivalent of const(R) or const(R!E) would be, but with how templates work, there's no guarantee that a different instantiation of the same template would be equivalent even if the only difference is const. Stuff like static if could be used to make them completely different. So, once you have a const range, your essentially stuck and can't mutate it or get a tail-const copy to mutate. Because const ranges are basically useless, there really isn't much point in putting const on any range functions even if it would work for that particular range, and if a range is a wrapper range, the only way that it could do it would be if it used static if to make the code differ depending on whether the range it's wrapping will work if that function is const, which essentially means duplicating a bunch of code for little to no benefit. - Jonathan M Davis
Re: Why in Phobos is empty() sometimes const and sometimes not
On Monday, July 29, 2019 1:35:18 PM MDT H. S. Teoh via Digitalmars-d-learn
wrote:
> Generally, the idiom is to let the compiler do attribute inference by
> templatizing your code and not writing any explicit attributes, then use
> unittests to ensure that instantiations of the range that ought to have
> certain attributes actually have those attributes. For example, instead
> of writing:
>
> struct MyRange(R) {
> ...
> @property bool empty() const { ... }
> ...
> }
>
> write instead:
>
> struct MyRange(R) {
> ...
> // No attributes: compiler does inference
> @property bool empty() { ... }
> ...
> }
>
> // unittest ensures .empty is callable with const object.
> unittest {
> const rr = MyRange!(const(Range))(...);
> assert(rr.empty); // will fail compilation if .empty is non-const
> }
>
> The unittest tests that a specific instantiation of MyRange has const
> .empty. It's still possible to use MyRange with a range that has
> non-const .empty, but this unittest ensures that the non-const-ness
> wasn't introduced by the implementation of MyRange itself, but only
> comes from the template argument.
Since when does const have anything to do with attribute inference? Unless
something has changed recently, const is _never_ inferred for functions.
Your unittest here should never compile regardless of whether empty could
have been marked as const or not. If you want empty to be const or not based
on the range being wrapped, you'd need to use two separate function
definitions (one const and one not) and use static if to choose which got
compiled in based on whether it could be const or not with the range type
that it's wrapping.
- Jonathan M Davis
Re: Why in Phobos is empty() sometimes const and sometimes not
On 29.07.19 21:35, H. S. Teoh wrote:
Generally, the idiom is to let the compiler do attribute inference by
templatizing your code and not writing any explicit attributes, then use
unittests to ensure that instantiations of the range that ought to have
certain attributes actually have those attributes. For example, instead
of writing:
struct MyRange(R) {
...
@property bool empty() const { ... }
...
}
write instead:
struct MyRange(R) {
...
// No attributes: compiler does inference
@property bool empty() { ... }
...
}
// unittest ensures .empty is callable with const object.
unittest {
const rr = MyRange!(const(Range))(...);
assert(rr.empty); // will fail compilation if .empty is
non-const
}
The unittest tests that a specific instantiation of MyRange has const
.empty. It's still possible to use MyRange with a range that has
non-const .empty, but this unittest ensures that the non-const-ness
wasn't introduced by the implementation of MyRange itself, but only
comes from the template argument.
But const isn't inferred.
struct MyRange()
{
@property bool empty() { return true; }
}
void main()
{
pragma(msg, typeof(&MyRange!().empty));
/* Prints: "bool function() pure nothrow @nogc @property @safe"
Note: no const. */
const MyRange!() r;
assert(r.empty); /* fails compilation */
}
Re: Why in Phobos is empty() sometimes const and sometimes not
On Monday, 29 July 2019 at 19:38:34 UTC, Jonathan M Davis wrote: On Monday, July 29, 2019 11:32:58 AM MDT Matt via Digitalmars-d-learn wrote: Because const ranges are basically useless, there really isn't much point in putting const on any range functions even if it would work for that particular range, and if a range is a wrapper range, the only way that it could do it would be if it used static if to make the code differ depending on whether the range it's wrapping will work if that function is const, which essentially means duplicating a bunch of code for little to no benefit. - Jonathan M Davis This was super helpful, thanks so much. I thought it was good practice to label member functions const if they didn't/couldn't modify any data. Now I see the reality is different for ranges. Not worrying about const for these seems simpler than code repetition. Thanks again.
How do I display unicode characters in D on standard (english) Windows 10 console window?
This is a very stupid question but from Ali's book, I took this
segment:
writeln("Résumé preparation: 10.25€");
writeln("\x52\ésum\u00e9 preparation: 10.25\€");
and after running it all I get is the following:
Résumé preparation: 10.25€
Résumé preparation: 10.25€
I was expecting the symbol "£" or something like that. What am I
missing?
Re: How do I display unicode characters in D on standard (english) Windows 10 console window?
On Monday, 29 July 2019 at 22:17:55 UTC, WhatMeWorry wrote: What am I missing? Switching the console code page to UTF-8, and then restoring the original one before termination. See https://github.com/ldc-developers/ldc/pull/3086/commits/5915534530fa095e7e5d58bcfb4ad100d249bbca#diff-c59e7716a40a08ce42f141c738f2c311. You may have to set a non-raster console font (e.g., Consolas).
Re: Building GDC with auto-generated header files
On 30/07/2019 4:11 AM, Eduard Staniloiu wrote: Cheers, everybody I'm working on this as part of my GSoC project [0]. I'm working on building gdc with the auto-generated `frontend.h` [1], but I'm having some issues There are functions in dmd that don't have an `extern (C)` or `extern (C++)` but they are used by gdc (are exposed in `.h` files) An example of such a function is `checkNonAssignmentArrayOp`[2] from `dmd/arrayop.d` which is can be found in `gcc/d/dmd/expression.h` [3] It may have previously been extern(C) or its a gdc specific patch. Either way PR please.
Re: Why in Phobos is empty() sometimes const and sometimes not
On Monday, July 29, 2019 3:11:45 PM MDT Matt via Digitalmars-d-learn wrote: > On Monday, 29 July 2019 at 19:38:34 UTC, Jonathan M Davis wrote: > > On Monday, July 29, 2019 11:32:58 AM MDT Matt via > > Digitalmars-d-learn wrote: > > > > > > > > Because const ranges are basically useless, there really isn't > > much point in putting const on any range functions even if it > > would work for that particular range, and if a range is a > > wrapper range, the only way that it could do it would be if it > > used static if to make the code differ depending on whether the > > range it's wrapping will work if that function is const, which > > essentially means duplicating a bunch of code for little to no > > benefit. > > > > - Jonathan M Davis > > This was super helpful, thanks so much. I thought it was good > practice to label member functions const if they didn't/couldn't > modify any data. Now I see the reality is different for ranges. > Not worrying about const for these seems simpler than code > repetition. > > Thanks again. In principle, it's good to use const when you know that data isn't going to change, but that gets far more complicated when you're dealing with generic code or even with classes, since as soon as you use const, everything used with that template then needs to work with const, or in the case of classes, every derived class has to use const for their override of that function. Sometimes, that's fine, but that's usually when you're either requiring that const always work, or you're in control all of the code involved, so you know that you're not going to have to deal with issues like caching. It's issues like this that led us to decide a while ago that putting functions on Object was a mistake, since it locked all classes into a particular set of attributes (and even if we changed which attributes those were, it would still cause problems). The ProtoObject DIP (which would add a base class for Object that didn't have anything on it) will hopefully fix that, but that still hasn't been finalized yet. In the case of ranges, on top of the general issues with const and generic code, their API just isn't designed with const in mind. Fundamentally, you need to be able to mutate a range to iterate through it. It would be different if we'd gone with more of a functional-style, head/tail solution where you have a function like head to get the first element, and a function like tail to return a range with the first element popped off, but for better or worse, that's not the direction we went. However, even if we had, issues like caching or delayed calculation would still come into play, and if you require that const work on something like empty, that prevents certain classes of solutions. Of course, on the flip side, without const, you don't know for sure that unwanted mutation isn't happening, but what would really be needed would be some kind of "logical" const rather than the full-on const we currently have, and that would be very difficult to implement. C++'s const _sort_ of allows that, because it has so many loopholes, but on the flip side, you lose most of the guarantees, and it mostly just becomes documentation of intent rather than actually enforcing logical constness. In practice, I find that D's const tends to not be terribly useful in generic code, but it's far more of a problem with libraries that are publicly available than with code where you control everything and can change stuff when you need to. This article I wrote goes into further detail about the issues with const in general: http://jmdavisprog.com/articles/why-const-sucks.html The situation with ranges would be improved if we had some kind of const or inout inference for templated code like we do with other attributes, but I don't know quite how that would work or what the downsides would be. - Jonathan M Davis
Re: Building GDC with auto-generated header files
Am Tue, 30 Jul 2019 15:19:44 +1200 schrieb rikki cattermole: > On 30/07/2019 4:11 AM, Eduard Staniloiu wrote: >> Cheers, everybody >> >> I'm working on this as part of my GSoC project [0]. >> >> I'm working on building gdc with the auto-generated `frontend.h` [1], >> but I'm having some issues >> >> There are functions in dmd that don't have an `extern (C)` or `extern >> (C++)` but they are used by gdc (are exposed in `.h` files) >> >> An example of such a function is `checkNonAssignmentArrayOp`[2] from >> `dmd/arrayop.d` which is can be found in `gcc/d/dmd/expression.h` [3] > > It may have previously been extern(C) or its a gdc specific patch. > Either way PR please. Actually the code at https://github.com/gcc-mirror/gcc/blob/master/gcc/d/ dmd is still the C++ frontend. The DMD frontend in upstream master (https://github.com/dlang/dmd/blob/master/) and in GCC master are very different versions, so mismatches are expected. The latest DDMD GDC is here: https://github.com/gcc-mirror/gcc/commits/ ibuclaw/gdc However, it's still not a good idea to mix and match files from DMD upstream master and that GDC branch, as they will not be 100% in sync. It's best to simply use only files from the gcc/d repo, as that's what's used when compiling GDC. You could also have a look at the gcc/d/dmd/MERGE file, which will tell you what upstream DMD commit has been used in the respective GDC tree. -- Johannes
