Re: Best practices of using const
Am I mistaken in saying that we are conflating: "anything that is logically const should be declared const" // makes perfect sense // e.g. the lowest 2, and some branches of the 3rd and 4th, levels // of members (and a subset of the overall methods) in a 5-deep type hierarchy are const with: "most code/data should be declared const" // no! isn't efficient code all about mutation? // no grounds for, e.g.: "ideally, no more than 40% of code should be doing mutation" On Wednesday, 13 February 2019 at 16:40:18 UTC, H. S. Teoh wrote: On Wed, Feb 13, 2019 at 11:32:46AM +, envoid via Digitalmars-d-learn wrote: Unfortunately, that guarantee also excludes a lot of otherwise useful idioms, like objects that cache data -- a const object cannot cache data because that means it's being mutated, or lazily-initialized objects -- because once the ctor has run, the object can no longer be mutated. Most notably, D's powerful range idiom is pretty much unusable with const because iteration over a range requires mutating the range (though having const *elements* in a range is fine). This doesn't seem as bad at first glance, but it wreaks havoc on generic code, another thing that D is purportedly good at. It's very hard (and often impossible) to write generic code that works with both const and mutable objects. So ironically, the iron-clad semantics of D's const system turns out to be also its own downfall. T The point about generic code (reiterated by many) is intriguing on its own; until now, I hadn't explicitly thought about const even for my C++ template library code (whatever little I have of those). Any pointers to other posts or articles elaborating this a little bit? I believe the other points probably matter when interacting with every other feature (I would have to write some of my "real" code in D to see if I hit it on my own), but there doesn't seem to be anything unusable about them on their own. The inability to have a const caching object seems correct. The way around would be to have a wrapper that caches (meh). If that is not possible, then maybe caching objects just aren't meant to be const by their nature? Isn't memoize a standard library feature? I should look at it, but I wouldn't expect it to be const. On Monday, 18 February 2019 at 06:50:32 UTC, Marco de Wild wrote: I agree that const by nature unfortunately kills lazy initialization. Lazy initialization - is this the same as post-blit? At the cost of copying (justifiable? maybe), doesn't D have a way to copy-construct a const/immutable struct object from a mutable one? If there is a way (or will be - there is a recent posting and a Dconf talk about copy constructors), does the copying negate the benefits of lazy initialization? However, I don't really understand why const is a problem with ranges. Const elements are not a problem. Iterating over a range consumes it (if I understand correctly). It does not make sense to be able to consume a const object, so from my point of view it's perfectly logical to disallow iterating const ranges. If I'm missing something, please correct me. ... +1. Or I haven't understood why ranges would ever ever need to be const. After all, in C++, what use is: std::vector::const_iterator const iter = sequence.begin(); About the only kind of use would be: std::vector::const_iterator iter = sequence.begin(); std::vector::const_iterator const iterEnd = sequence.end(); What are ranges if not an encapsulation of the above functionality?
Options for unit testing in D?
If you never herd about Meson before: 🤔. https://mesonbuild.com/ I am wondering as to what options are available for a Meson build user when unit testing? What I am trying todo is simply rewrite my C17 project reference templates to D versions so I may show other developers the basic structure of my project if I have a question about something or to influence the idea of Meson with D projects. Excuse the Conan file. As reference: C17 https://github.com/squidfarts/c-example.git https://github.com/squidfarts/c-project.git Dlang https://github.com/squidfarts/d-example.git
Re: Range violation error when reading from a file
On Tuesday, 18 June 2019 at 09:42:41 UTC, aliak wrote: On Tuesday, 18 June 2019 at 01:15:54 UTC, Samir wrote: On Monday, 17 June 2019 at 03:46:11 UTC, Norm wrote: That's because you're using write*ln*. So even though line is empty, you still output a new line. Curious. I am going to have to think about that for a bit as I don't quite understand. I mean this: $ dmd -run readfile.d 1) file.eof() == false line = "> line 1" writeln("lines 1" + \n); 2) file.eof() == false line = line 2 writeln("line 2" + \n); ...snip... 6) file.eof() == false line = "" // empty since there're no lines left in file writeln("" + \n); <-- this is your blank line 7) file.eof() == true Got it! Now I see what you were saying. Thanks for taking the time to provide a detailed explanation!
Re: Transform a function's body into a string for mixing in
On Thursday, 20 June 2019 at 19:09:11 UTC, Emmanuelle wrote: Is there any trait or Phobos function for transforming a function/delegate/lambda/whatever's body into a string suitable for `mixin(...)`? For example: See: https://forum.dlang.org/post/kozwskltzidfnatbp...@forum.dlang.org If not, is there any way to do this _without_ using strings? Depends on what you are trying to achieve with mixing in function body code. If you just want to execute the function code, you can just call it (obviously), so I assume you want dynamic scoping (that global variables are overridden by local variables from the caller) or something?
Re: Transform a function's body into a string for mixing in
On Thursday, 20 June 2019 at 19:09:11 UTC, Emmanuelle wrote: Hello! Is there any trait or Phobos function for transforming a function/delegate/lambda/whatever's body into a string suitable for `mixin(...)`? For example: --- __traits(getBody, (int a, int b) => a + b); // returns "(int a, int b) => a + b" // or maybe just "a + b" --- If not, is there any way to do this _without_ using strings? They are very inconvenient and could hide errors. Thanks! We don't have anything AST-macro ish or a trait as described. The trait isn't impossible to implement but I could imagine it being a nightmare for compile times
Transform a function's body into a string for mixing in
Hello! Is there any trait or Phobos function for transforming a function/delegate/lambda/whatever's body into a string suitable for `mixin(...)`? For example: --- __traits(getBody, (int a, int b) => a + b); // returns "(int a, int b) => a + b" // or maybe just "a + b" --- If not, is there any way to do this _without_ using strings? They are very inconvenient and could hide errors. Thanks!
Re: make C is scriptable like D
On Thursday, 20 June 2019 at 06:20:17 UTC, dangbinghoo wrote: hi there, a funny thing: $ cat rgcc #!/bin/sh cf=$@ mycf=__`echo $cf|xargs basename` cat $cf | sed '1d' > ${mycf} gcc ${mycf} -o a.out rm ${mycf} ./a.out $ cat test.c #!/home/user/rgcc #include int main() { printf("hello\n"); } And then, chmod +x test.c ./test.c output hello. is rdmd implemented similarly? thanks! binghoo rdmd adds a few different features as well, but the bigger thing it does is cache the results in a global temporary directory. So If you run rdmd on the same file with the same options twice, the second time it won't compile anything, it will detect that it was already compiled and just run it.
Re: make C is scriptable like D
On Thursday, 20 June 2019 at 06:20:17 UTC, dangbinghoo wrote: hi there, a funny thing: $ cat rgcc #!/bin/sh cf=$@ mycf=__`echo $cf|xargs basename` cat $cf | sed '1d' > ${mycf} gcc ${mycf} -o a.out rm ${mycf} ./a.out $ cat test.c #!/home/user/rgcc #include int main() { printf("hello\n"); } And then, chmod +x test.c ./test.c output hello. is rdmd implemented similarly? thanks! binghoo Basically, yeah.
Re: DIP 1016 and const ref parameters
On Wednesday, 19 June 2019 at 19:25:59 UTC, Jonathan M Davis wrote: Aside from looking through the newsgroup/forum for discussions on DIPs, that's pretty much all you're going to find on that. Andrei's talk is the most up-to-date information that we have about this particular DIP. The preliminary implementation is the most practicable up to date info there: https://github.com/dlang/dmd/pull/9817
Re: create and initialise array
Thanks Matheus, thats what i needed. I added a PR to mention this function in the language documentation about arrays.
Re: Where can find fix length array memory layout document
On Tuesday, 18 June 2019 at 12:26:14 UTC, lili wrote: Hi guys: Is the Dlang fix-length array alloc on stack? when a test writeln([1]).sizeof //16 writeln([2]).sizeof //16 Why, What is the fix-length array memory layout. You are quite confused... [...] is an array literal, not a static array. Those aren't the same thing. When you pass a array literal anywhere in your code, it will in principle be referred as a slice variable. This will not reallocate the contents. However the slice reference is another variable that takes up two words of space (see code below). This slice type is the same variable type that stores dynamic arrays -- be they allocated or null. Array literals are not necessarily allocated. The compiler is free to embed them into the program machine code itself. If you want a static array, you can just declare it directly e.g. int[n] arr. Of course you can also generate is out of an array literal with the staticArray std library function. PS the layout of D arrays is of course linear and contiguous. Both static or dynamic, just like C/C++ static arrays or std::vectors respectively. Hopefully this code makes things clear: /*/ enum lenInts = int.sizeof; static assert(lenInts == 4); int[1] arrStatic; static assert(lenInts == arrStatic.sizeof); auto slice = arrStatic[]; alias sliceType = typeof(slice); static assert(is(sliceType == int[])); enum lenPointers = size_t.sizeof; // fyi (unsinged) pointers static assert(ptrdiff_t.sizeof == lenPointers); // fyi signed pointer diff static assert(sliceType.sizeof == 2 * lenPointers); // because a D array reference remembers a pointer (like C) plus the length (stored in a word-length integer)
Re: create and initialise array
On Thursday, 20 June 2019 at 01:32:04 UTC, matheus wrote: import std.stdio; import std.array; void main(){ auto s = uninitializedArray!(float[])(100); s[] = 0.0f; writeln(s[0]); } another version: auto arr = new double[ 10 ]; writeln( arr[5] ); // NaN arr.length += 10; writeln( arr[15] ); // NaN imo NaN is useless, weird and unusual coz integrals and pointers are "all bits zeroes" but float and chars are "all bits ones". WTF? its strange that bool.init is false in such case. .init = "all zeroes" can be faster initialize any block of memory. for example array of structs coz u dont need copy struct.init to each element and just fill memory with AVX2 zeroed register (or another fastest hack). with "all zeroes" u can continue work without reinitialization first as arr[15] += 3.14; probably should be added option to compiler. and again module behavior will be different due to this option. NaN/#FF was worst decision. The road to hell is paved with good intentions. or do a poll for the last decision for several months and leave it as it is forever or recompile new versions with zeros. and of course there must be the possibility of increasing the length of the array with a given value.