Help needed to learn templates
Hi all,
I am trying to learn D templates with Philippe Sigaud's "D
Templates: A Tutorial". So far so good. I have completed first 19
pages and in the 20th page, I found an obstacle. This is the code.
```d
module rank1;
template rank(T)
{
static if (is(T t == U[], U)) // is T an array of U, for some
type U?
enum size_t rank = 1 + rank!(U); // then let’s recurse
down.
else
enum size_t rank = 0; // Base case, ending the recursion.
}
module using_rank1;
import rank1;
static assert(rank!(int) == 0);
static assert(rank!(int[]) == 1);
static assert(rank!(int[][]) == 2);
static assert(rank!(int[][][]) == 3);
```
Question 1 - `U` is appearing in the first static if statement.
But we had to write `U` on the template line, right? Like -
`template rank(T, U)`
Question 2 - The statif if test is - `T t == U[ ]` What does that
mean ?
Question 3 - if `T t == U[ ]` is the test, then I think when we
pass
```d
rank!(int[ ][ ][ ])
```
The test will be `int[ ][ ][ ] == U[ ]`, Right ?
Re: Nested Classes with inheritance
On Saturday, 19 March 2022 at 00:16:48 UTC, user1234 wrote: That crashes because of the creation of `Bar b` member, which itself has a Bar b member, which itself... Mhmm... So There's Foo with Bar b, which has Bar b which has Bar b which... just keeps going over and over again. It appears to me that it only crashes when you fully run out of memory then. Much like a function calling itself and you exhaust all your stack space. I'd suggest avoiding self-inheritance. No one wants to be their own Grandpa
Re: Nested Classes with inheritance
On Saturday, 19 March 2022 at 00:05:54 UTC, Salih Dincer wrote:
Greetings to all...
There are nested classes as below. But beware, there's also
inheritance, extra! If you construct ```Bar b``` from main(),
it's okay. But if declare the constructor in Foo(), the program
crashes with a segmentation error.
Is this not legal? Like two mirrors are facing each other, that
I do?
```d
class Foo
{
Bar b;
int i;
this(int n)
{
this.i = n;
//this.b = new Bar(this.i); // compiles but crashes
}
class Bar : Foo
{
int i;
this(int n)
{
this.i = n;
super(this.i);
}
}
}
void main()
{
auto foo = new Foo(1);
auto bar = foo.new Bar(1);
foo.b = bar;
assert(foo.i == foo.b.i);
}
```
SDB@79
That crashes because of the creation of `Bar b` member, which
itself has a Bar b member, which itself...
One solution is to create the member depending on some condition,
example:
```d
if (typeid(this) !is typeid(Bar))
this.b = new Bar(this.i);
```
Nested Classes with inheritance
Greetings to all...
There are nested classes as below. But beware, there's also
inheritance, extra! If you construct ```Bar b``` from main(),
it's okay. But if declare the constructor in Foo(), the program
crashes with a segmentation error.
Is this not legal? Like two mirrors are facing each other, that I
do?
```d
class Foo
{
Bar b;
int i;
this(int n)
{
this.i = n;
//this.b = new Bar(this.i); // compiles but crashes
}
class Bar : Foo
{
int i;
this(int n)
{
this.i = n;
super(this.i);
}
}
}
void main()
{
auto foo = new Foo(1);
auto bar = foo.new Bar(1);
foo.b = bar;
assert(foo.i == foo.b.i);
}
```
SDB@79
Re: Basic question about size_t and ulong
On 3/18/22 14:54, WhatMeWorry wrote: > size_t is an alias to one of the unsigned integral basic types, and > represents a type that is large enough to represent an offset into all > addressable memory. In practice, that general description means "size_t is either ulong or uint" depending on your platform (or build e.g. -m32 as Adam said). > size_t huge = uint.max; // compiles That means size_t is uint on that build. Ali P.S. On a related note, I used to make the mistake of using size_t for file offsets as well. That is a mistake because even on a 32-bit system (or build), file sizes can be larger than uint.max. So, the correct type is long for seek() so that we can seek() to an earlier place and ulong for tell().
Re: Basic question about size_t and ulong
On Friday, 18 March 2022 at 21:54:55 UTC, WhatMeWorry wrote: Isn't ulong an integer? And isn't memory addresses 64 bits long? Only if you are doing a 64 bit build. Try using -m64
Basic question about size_t and ulong
Quoting the D documentation: size_t is an alias to one of the unsigned integral basic types, and represents a type that is large enough to represent an offset into all addressable memory. And I have a line of code: size_t huge = ulong.max; dmd GC.d GC.d(29): Error: cannot implicitly convert expression `18446744073709551615LU` of type 'ulong` to `uint Isn't ulong an integer? And isn't memory addresses 64 bits long? size_t huge = uint.max; // compiles works but now I'm just curious. I was just seeing what is the largest dynamic array I could create.
Re: I like dlang but i don't like dub
On Fri, Mar 18, 2022 at 11:16:51AM -0700, Ali Çehreli via Digitalmars-d-learn wrote: > tldr; I am talking on a soap box with a big question mind hovering > over on my head: Why can't I accept pulling in dependencies > automatically? Because it's a bad idea for your code to depend on some external resource owned by some anonymous personality somewhere out there on the 'Net that isn't under your control. > On 3/18/22 07:48, H. S. Teoh wrote: > > > As a package manager, dub is OK, it does its job. > > As a long-time part of the D community, I am ashamed to admit that I > don't use dub. I am ashamed because there is no particular reason, or > my reasons may not be rational. I have only used dub once -- for an experimental vibe.d project -- and that only using a dummy empty project the sole purpose of which was to pull in vibe.d (the real code is compiled by a different build system). And I'm not even ashamed to admit it. :-P > > As a build system > > I have seen and used a number of build systems that were started after > make's shortcomings and they ended up with their own shortcomings. > Some of them were actually program code that teams would write to > build their system. As in steps "compile these, then do these". What? > My mind must have been tainted by the beauty of make that writing > build steps in a build tool strikes me as unbelievable... But it > happened. I don't remember its name but it was in Python. You would > modify Python code to build your programs. (?) Maybe you're referring to SCons? I love SCons... not because it's Python, but because it's mostly declarative (the Python calls don't actually build anything immediately -- they register build actions with the build engine and are executed later by an opaque scheduler). The procedural part is really for things like creating lists of files and such (though for the most common tasks there are already basically-declarative functions available for use), or for those occasions where the system simply doesn't have the means to express what you want to do, and you need to invent your own build recipe and plug it in. > I am well aware of make's many shortcomings but love it's declarative > style where things happen automatically. That's one smart program > there. A colleague loves Bazel and is playing with it. Fingers > crossed... Make in its most basic incarnation was on the right path. What came after, however, was a gigantic mess. The macro system, for example, which leads to spaghetti code of the C #ifdef-hell kind. Just look at dmd/druntime/phobos' makefiles sometime, and see if you can figure out what exactly it's trying to do, and how. There's also implementational issues, the worst of which is non-reproducibility: running `make` after making some changes has ZERO guarantees about the consistency of what happens afterwards. It *may* just work, or it may silently link in stale binaries from previous builds that silently replace some symbols with obsolete versions, leading to heisenbugs that exist in your executable but do not exist in your code. (I'm not making this up; I have seen this with my own eyes in my day job on multiple occasions.) The usual bludgeon-solution to this is `make clean; make`, which defeats the whole purpose of having a build system in the first place (just write a shell script to recompile everything from scratch, every time). Not to mention that `clean` isn't a built-in rule, and I've encountered far too many projects where `make clean` doesn't *really* clean everything thoroughly. Lately I've been resorting to `git clean -dfx` as a nuke-an-ant solution to this persistent problem. (Warning: do NOT run the above git command unless you know what you're doing. :-P) > > I much rather prefer Adam's arsd libs[1], where you can literally > > just copy the module into your own workspace (they are almost all > > standalone single-file modules > > That sounds great but aren't there common needs of those modules to > share code from common modules? Yes and no. The dependencies aren't zero, to be sure. But Adam also doesn't take code reuse to the extreme, in that if some utility function can be written in 2-3 lines, there's really no harm repeating it across modules. Introducing a new module just to reuse 2-3 lines of code is the kind of emperor's-clothes philosophy that leads to Dependency Hell. Unfortunately, since the late 70's/early 80's code reuse has become the sacred cow of computer science curriculums, and just about everybody has been so indoctrinated that they would not dare copy-n-paste a 2-3 line function for fear that the Reuse Cops would come knocking on their door at night. > It is ironic that packages being as small as possible reduces the > chance of dependencies of those modules and at the same time it > increases the total number of dependencies. IMNSHO, when the global dependency graph becomes non-trivial (e.g., NP-complete Dependency Hell), that's a sign that you've partitioned
Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote: If ```import std.regex;``` is commented out or if ```-checkaction=context``` is removed from the cmd line the unittest passes. Can anybody reproduce this? https://run.dlang.io/is/GYDUBz File an issue, I'd say. The worst thing that can happen is that someone flags it as a duplicate.
Re: I like dlang but i don't like dub
tldr; I am talking on a soap box with a big question mind hovering over on my head: Why can't I accept pulling in dependencies automatically? On 3/18/22 07:48, H. S. Teoh wrote: > As a package manager, dub is OK, it does its job. As a long-time part of the D community, I am ashamed to admit that I don't use dub. I am ashamed because there is no particular reason, or my reasons may not be rational. > As a build system I have seen and used a number of build systems that were started after make's shortcomings and they ended up with their own shortcomings. Some of them were actually program code that teams would write to build their system. As in steps "compile these, then do these". What? My mind must have been tainted by the beauty of make that writing build steps in a build tool strikes me as unbelievable... But it happened. I don't remember its name but it was in Python. You would modify Python code to build your programs. (?) I am well aware of make's many shortcomings but love it's declarative style where things happen automatically. That's one smart program there. A colleague loves Bazel and is playing with it. Fingers crossed... > I much rather prefer Adam's arsd libs[1], where you can literally just > copy the module into your own workspace (they are almost all standalone > single-file modules That sounds great but aren't there common needs of those modules to share code from common modules? It is ironic that packages being as small as possible reduces the chance of dependencies of those modules and at the same time it increases the total number of dependencies. > The dependency graph of a project > should not be more than 2 levels deep (preferably just 1). I am fortunate that my programs are commond line tools and libraries that so far depended only on system libraries. The only outside dependency is cmake-d to plug into our build system. (I don't understand or agree with all of cmake-d but things are in an acceptable balance at the moment.) The only system tool I lately started using is ssh. (It's a topic for another time but my program copies itself to the remote host over ssh to work as a pair of client and server.) > You shouldn't have to download half the world The first time I learned about pulling in dependencies terrified me. (This is the part I realize I am very different from most other programmers.) I am still terrified that my dependency system will pull in a tree of code that I have no idea doing. Has it been modified to be malicious overnight? I thought it was possible. The following story is an example of what I was exactly terrified about: https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 Despite such risks many projects just pull in code. (?) What am I missing? I heard about a team at a very high-profile company actually reviewing such dependencies before accepting them to the code base. But reviewing them only at acceptance time! Once the dependency is accepted, the projects would automatically pull in all unreviewed changes and run potentially malicious code on your computer. I am still trying to understand where I went wrong. I simply cannot understand this. (I want to believe they changed their policy and they don't pull in automatically anymore.) When I (had to) used Go for a year about 4 years ago, it was the same: The project failed to build one morning because tere was an API change on one of the dependencies. O... K... They fixed it in a couple of hours but still... Yes, the project should probably have depended on a particular version but then weren't we interested in bug fixes or added functionality? Why should we have decided to hold on to version 1.2.3 instead of 1.3.4? Should teams follow their many dependencies before updating? Maybe that's the part I am missing... Thanks for listening... Boo hoo... Why am I like this? :) Ali
Re: I like dlang but i don't like dub
On Fri, Mar 18, 2022 at 04:13:36AM +, Alain De Vos via Digitalmars-d-learn wrote: > Dlang includes some good ideas. > But dub pulls in so much stuff. Too much for me. > I like things which are clean,lean,little,small. > But when i use dub it links with so many libraries. > Are they really needed ? [...] As a package manager, dub is OK, it does its job. As a build system, I find dub simply isn't good enough for my use cases. Its build model is far too simplistic, and does not integrate well with external build systems (esp in projects involving multiple programming languages). I rather prefer SCons for my general build needs. As far as dub pulling in too many libraries: IMNSHO this is a malaise of modern software in general. (No) thanks to the code reuse mantra, nobody seems satisfied until they refactor every common function into its own package, and everything depends on everything else, so doing something trivial like displaying a static webpage with vibe.d pulls in 25 packages just so it can be built. I much rather prefer Adam's arsd libs[1], where you can literally just copy the module into your own workspace (they are almost all standalone single-file modules, except for a small number of exceptions) and just build away. No hairy recursive dependencies to worry about, everything you need is encapsulated in a single file. That's the kind of dependency philosophy I subscribe to. The dependency graph of a project should not be more than 2 levels deep (preferably just 1). You shouldn't have to download half the world just to build a hello world program. And you definitely shouldn't need to solve an NP-complete problem[2] just so you can build your code. [1] https://github.com/adamdruppe/arsd/ [2] https://research.swtch.com/version-sat - Dependency hell is NP-complete. T -- It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton
Re: How to use ImportC?
On Friday, 4 March 2022 at 17:17:17 UTC, MoonlightSentinel wrote: On Friday, 4 March 2022 at 01:30:00 UTC, Leonardo wrote: Thanks but not worked here. ``` [leonardo@leonardo-pc dimportc]$ dmd --version DMD64 D Compiler v2.098.1 ``` Please retry with the [beta](https://dlang.org/download.html#dmd_beta) or [nightly build](https://github.com/dlang/dmd/releases/tag/nightly). I think your bug was already fixed since 2.098.1. Thank you all. In v2.099.0 it works.
Re: How to exclude function from being imported in D language?
On Friday, 18 March 2022 at 03:24:10 UTC, Era Scarecrow wrote: On Tuesday, 8 March 2022 at 22:28:27 UTC, bauss wrote: What D just needs is a way to specify the entry point, in which it just defaults to the first main function found, but could be any function given. Which is similar to what Java does. When i was first learning Java in a company i would make main() and have it run all the unittests of that particular module, then have a different file that actually combined all the tools together to run the program. Though when making the jar I'd specify which one actually was needed. But this was... 10 years ago. Yeah, it's similar to most other languages that allows it too. It doesn't make much sense to force an entry point anyway, especially not in D where there is no real entry point anyway, but the compiler already emits a couple of different ones that are platform dependent.
Re: I like dlang but i don't like dub
On Friday, 18 March 2022 at 04:13:36 UTC, Alain De Vos wrote: Dlang includes some good ideas. But dub pulls in so much stuff. Too much for me. I like things which are clean,lean,little,small. But when i use dub it links with so many libraries. Are they really needed ? And how do you compare to pythons pip. Feel free to elaborate. Dub is fantastic at some places, e.g. if you need to just execute something from code.dlang.org via `dub run`, or single file packages (https://dub.pm/advanced_usage) are great to write small cmdline utilities with dependencies. I don't like it as a build system and it is notoriously hard to integrate into existing build systems. You can look at meson (which had some D related bug fixes recently) or reggae for that. Or just do `dmd -i` as long as compile times are low enough.
Re: I like dlang but i don't like dub
On Friday, 18 March 2022 at 04:13:36 UTC, Alain De Vos wrote: Dlang includes some good ideas. But dub pulls in so much stuff. Too much for me. I like things which are clean,lean,little,small. But when i use dub it links with so many libraries. Are they really needed ? And how do you compare to pythons pip. Feel free to elaborate. Long story short, dub isn't needed. If you prefer pulling dependencies and compiling them by hand nothing is stopping you. As for comparison to pip, I'd say that dub compares favourably actually. Yes, it does do more than pip, and that used to annoy me. But if you look at it from the stance of a user it makes sense: when you pull dependencies or a package using pip you expect to be able to run them immediately. Python isn't a compiled language, but D is and to get these packages and dependencies to be run immediately it needs to do more than pip: download dependencies, manages their version and compile them. This last part is the reason for most of the added complexity to dub IMHO.
