Re: Help me decide D or C
On Fri, 2019-08-02 at 13:45 +, Alexandre via Digitalmars-d-learn wrote: > […] > Could you elaborate more about C being a burden? I have read so > many people saying C gives a great foundation and should be > everyone's first language. Now I am confused. C is a programming language created in the early 1970s to make writing UNIX easier. Early versions of UNIX (and Multics before it) were written in assembly language. Dennis Ritchie et al. wanted to use a programming language that had a higher level of abstraction than assembly language so as to make writing UNIX easier. BCPL gave many of the ideas for B which led to C, effectively a portable assembly language but with special eyes on the PDP-8, PDP-11, and later VAX-11 machine codes. C was hugely successful for writing operating systems because it was "close to the metal" and yet with better abstractions than assembly language. I spent many happy (and many unhappy) hours in the early 1980s writing device drivers for UNIX 6, UNIX 7, and BSD 4.0. C was the right tool for the job at hand at that time. Many tools associated with UNIX were written in C, including the C compiler, since the only other option at the time in the UNIX context was assembly language. Already though there was the question: was C the right tool for the job of writing applications – as opposed to hardware controlling software. One could argue that "buffer overruns" was clear evidence that C was the wrong tool for the job. Unfortunately the obsession with C, even if it was not the right tool for the job at hand, had taken hold: if you didn't write your application in C you were somehow a second or third rate human being, let alone programmer. Then came C++ (or then C with Classes) and the beginning of the rift between the C camp and the "we need a programming language with higher levels of abstraction" camp. I am sure many can write lots on the 1990s and 2000s and the various language wars, but here we are in 2010s entering the 2020s and we have D, Rust, Go, Java, Kotlin, Python, Ruby, C++, Lisp, Prolog, Erlang, etc. all of which have their problems, but all of which have their "sweet spots" for being the right tool for the job at hand. C is no longer the de facto standard language for writing all software. People are increasingly recognising that it is as if C were specifically created for writing software that controls hardware. C still has a role in the world of programming, and it definitely has a status as one of the most important programming languages ever. Moral of this story is that, for me, in 2019, if you are writing applications software or software tools, C is not the right tool for the job. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Help me decide D or C
On Friday, 2 August 2019 at 14:05:20 UTC, SashaGreat wrote: On Friday, 2 August 2019 at 12:28:45 UTC, berni wrote: On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote: Should I go for C and then when I become a better programmer change to D? Should I start with D right now? In my oppinion C should have been deprecated about 50 years ago ... I stopped there. How could you have deprecated a language 50 years ago since was first released in '72 (47 years ago). Yes, that was intentional. What I wanted to say is, that I think, that it would have been better, if C was never invented at all... In that case, there would have been space for an other language for writing operating systems, without that much bugs in its design. (But one never knows afterwards...)
Re: Help me decide D or C
On Friday, 2 August 2019 at 13:57:44 UTC, Bastiaan Veelo wrote: On Thursday, 1 August 2019 at 20:02:08 UTC, Aurélien Plazzotta wrote: [...] But don't fool yourself, D is not for beginners. Ali Çehreli is a very skilled programmer, ergo, he can't reason like a new/starting programmer anymore, regardless of his patience and kindness. I am sorry, but this is very strange reasoning. Would you recommend a book on programming written by someone who is not a skilled programmer himself in any language? I certainly would not. Even stranger when you consider the earlier recommendation to take pleasure in learning F*. It is a pure functional programming language based on logical-mathematical thought
Re: Help me decide D or C
On Thursday, 1 August 2019 at 22:36:06 UTC, Russel Winder wrote: On Thu, 2019-08-01 at 14:49 +, bachmeier via Digitalmars-d-learn wrote: […] There's nothing wrong with Haskell if you want to take a deep dive into pure functional programming. I personally find Haskell to be more of a religion than a programming language. You can learn the same perspective from functional-first languages like Clojure, Scala, Ocaml, and F#. […] Whilst I agree that most "this is the one true programming language" people are quasi-religious, programming languages are not: Haskell is a just a lazy, pure functional programming language, some adherents show quasi-religious fervour, just as some adherents of C++, Java, C, Go, Rust, D, etc. do. I am not sure about F# (I do not know anything of it), but Clojure, Scala, and OCaml are very different from Haskell for various reasons, cf. lazy vs. eager, pure vs. impure. Haskell is a programming language worth learning for all programmers,along with Lisp, Prolog, and Erlang. I'll bet (but I have no experimental data, just a hypothesis) that any D programmer that knows Haskell writes better D than a D programmer who doesn't know Haskell. This is getting somewhat off the topic of this thread, so all I'll say is that I agree with the recommendation to learn Haskell, but I don't think a beginner would get enough exposure to various approaches to programming. I did not personally see large benefits from Haskell, but perhaps I should have stuck with it longer.
Re: Help me decide D or C
On Friday, 2 August 2019 at 15:51:25 UTC, Russel Winder wrote: On Fri, 2019-08-02 at 13:45 +, Alexandre via Digitalmars-d-learn wrote: […] Could you elaborate more about C being a burden? I have read so many people saying C gives a great foundation and should be everyone's first language. Now I am confused. C is a programming language created in the early 1970s to make writing UNIX easier. Early versions of UNIX (and Multics before it) were written in assembly language. Dennis Ritchie et al. wanted to use a programming language that had a higher level of abstraction than assembly language so as to make writing UNIX easier. BCPL gave many of the ideas for B which led to C, effectively a portable assembly language but with special eyes on the PDP-8, PDP-11, and later VAX-11 machine codes. C was hugely successful for writing operating systems because it was "close to the metal" and yet with better abstractions than assembly language. I spent many happy (and many unhappy) hours in the early 1980s writing device drivers for UNIX 6, UNIX 7, and BSD 4.0. C was the right tool for the job at hand at that time. Many tools associated with UNIX were written in C, including the C compiler, since the only other option at the time in the UNIX context was assembly language. Already though there was the question: was C the right tool for the job of writing applications – as opposed to hardware controlling software. One could argue that "buffer overruns" was clear evidence that C was the wrong tool for the job. Unfortunately the obsession with C, even if it was not the right tool for the job at hand, had taken hold: if you didn't write your application in C you were somehow a second or third rate human being, let alone programmer. Then came C++ (or then C with Classes) and the beginning of the rift between the C camp and the "we need a programming language with higher levels of abstraction" camp. I am sure many can write lots on the 1990s and 2000s and the various language wars, but here we are in 2010s entering the 2020s and we have D, Rust, Go, Java, Kotlin, Python, Ruby, C++, Lisp, Prolog, Erlang, etc. all of which have their problems, but all of which have their "sweet spots" for being the right tool for the job at hand. C is no longer the de facto standard language for writing all software. People are increasingly recognising that it is as if C were specifically created for writing software that controls hardware. C still has a role in the world of programming, and it definitely has a status as one of the most important programming languages ever. Moral of this story is that, for me, in 2019, if you are writing applications software or software tools, C is not the right tool for the job. Do you thing D would be the right tool for the job at this point for me? Assuming I have 2 goals in mind: 1) become a better programmer and 2) want to make fun writing software for myself and if possible show something I might be proud of. I thought C would be a better choice for the 1), because everyone says it's great to see whats behind the hood and things like that. My experience with C btw is CS50 course, plus around 200/300 pages of some books, still reading and a few toy projects. So, basically 0 knowledge. haha. But after reading your opinion, I guess C might not be the right tool for me, since I wont be doing any kind of thing related to hardware (I think). I have receive so many good opinions so far. I realize there is no consensus what so ever. As I was suggested Haskell, Python, D, C etc. It's a good thing, but hard to make a decision.
Re: Why does choose not work here
On Thursday, 1 August 2019 at 21:26:10 UTC, Matt wrote:
Anyone have any other thoughts?
I tried to simplify your example a little bit:
import std.stdio;
import std.range;
import std.algorithm;
auto myFilter(R1, R2)(R1 a, R2 b)
{
return a.filter!(c => c==b.front);
}
struct A
{
int[] starts;
auto intervalRange() @property
{
return starts;
}
}
auto uniqIntervalsA(A primary, A* previous) @property
{
return choose(previous is null,
primary.intervalRange,
primary.intervalRange.filter!(a =>
a==previous.intervalRange.front));
}
auto uniqIntervalsB(A primary, A* previous) @property
{
return choose(previous is null,
primary.intervalRange,
primary.intervalRange.myFilter(previous.intervalRange));
}
unittest
{
auto a1 = A([1]);
writeln(uniqIntervalsA(a1,));
writeln(uniqIntervalsA(a1,null));
writeln(uniqIntervalsB(a1,));
writeln(uniqIntervalsB(a1,null));
}
The strange thing is, that even if you replace "return
a.filter!(c => c==b.front);" by "return a.filter!(c => true);"
the problem remains (but now you can use lazy). As I'm not an
expert myself, I'm not sure how to analyze this. But I think,
both parameters to "choose" are evaluated (that is they are not
lazy), but "myFilter" uses it's parameter immediately to give "b"
a value, while "filter" just hands in an anonymous function
without using it ever.
Hope, this helps to get further down the way to a solution...
[OT] Re: Using Haskell for teaching [was: Help me decide D or C]
On Fri, 2019-08-02 at 10:25 -0600, Jonathan M Davis via Digitalmars-d-learn wrote: > […] > My feeling is that functional languages are likely to be a very poor place > for most folks to start learning, much as I think that they're great for > someone to learn and work with at some point. I have heard of beginning > programming classes using functional languages and having it go very well, > but it seems hard to believe to me. Imperative programming can already be a > lot for beginners, but most people really don't think even vaguely in a > functional manner. Even simple recursion tends to be a bit of a mind-bender > for people at first. […] At UCL in the late 1980s and early 1990s, we used a functional programming language in the first term and C++ in the second term for teaching programming. Initially Scheme was the functional programming language but we then switched to Miranda (which was a pre-cursor to Haskell). This deep immersion in two totally different programming paradigms worked very well. The mid/late 1990s mad rush to Java everywhere in teaching (of which I was a part) was in hindsight madness (of a global sort). The move by many institutions to using Python first and then Java rebalances somewhat but is missing the point – it's about the paradigms. I have retrenched as a believer in the Haskell/C++, or Prolog/Java, or some such. In the new era with new undergraduates already knowing Scratch and Python, universities should really go the whole hog in getting programming paradigms and programming as a skill as well as knowledge, with all the tools,fair and square into the first year curriculum. Of course I have been out of academia for 20 years, and am now out of employment, so my views have no impact. :-) -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Help me decide D or C
On Friday, 2 August 2019 at 12:28:45 UTC, berni wrote: On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote: Should I go for C and then when I become a better programmer change to D? Should I start with D right now? In my oppinion C should have been deprecated about 50 years ago ... I stopped there. How could you have deprecated a language 50 years ago since was first released in '72 (47 years ago). C like it or not is still highly used today (Kernel, LIB, Embedded Systems). If it was so terrible as you and others are saying it would be damned a long time ago. It has flaws? Sure, but like C++, D, Java, Go, Python has it owns flaws too and they all came later. Sasha.
Re: Help me decide D or C
On Friday, 2 August 2019 at 13:45:17 UTC, Alexandre wrote: On Friday, 2 August 2019 at 12:30:44 UTC, berni wrote: On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote: [...] In my oppinion C should have been deprecated about 50 years ago and it's not worth while to learn it if you are not interested in the history of programming or you have to learn it, because you need to maintain software which is allready written in C. But that's my oppinion; others may have a different sight. [...] Could you elaborate more about C being a burden? I have read so many people saying C gives a great foundation and should be everyone's first language. Now I am confused. One example is this recent post: https://forum.dlang.org/post/yjgkatpbkdyyksldg...@forum.dlang.org “[...] recently all the problems I am having with D are because D is actually superior to C and some assumptions I still have because of C should be uninstalled from my brain.” If you plan on ending up with D anyway, I think that learning C first is an unnecessary detour and can be counter productive in some ways. And if your objective is to have fun, I would recommend against C (except for a masochistic kind of fun). Don’t take the detour, take the D tour! :-) Bastiaan.
Re: Help me decide D or C
On Friday, August 2, 2019 10:13:04 AM MDT bachmeier via Digitalmars-d-learn wrote: > On Thursday, 1 August 2019 at 22:36:06 UTC, Russel Winder wrote: > > On Thu, 2019-08-01 at 14:49 +, bachmeier via > > Digitalmars-d-learn wrote: […] > > > >> There's nothing wrong with Haskell if you want to take a deep > >> dive into pure functional programming. I personally find > >> Haskell to be more of a religion than a programming language. > >> You can learn the same perspective from functional-first > >> languages like Clojure, Scala, Ocaml, and F#. > > > > […] > > > > Whilst I agree that most "this is the one true programming > > language" people are quasi-religious, programming languages are > > not: Haskell is a just a lazy, pure functional programming > > language, some adherents show quasi-religious fervour, just as > > some adherents of C++, Java, C, Go, Rust, D, etc. do. > > > > I am not sure about F# (I do not know anything of it), but > > Clojure, Scala, and OCaml are very different from Haskell for > > various reasons, cf. lazy vs. eager, pure vs. impure. Haskell > > is a programming language worth learning for all > > programmers,along with Lisp, Prolog, and Erlang. > > > > I'll bet (but I have no experimental data, just a hypothesis) > > that any D programmer that knows Haskell writes better D than a > > D programmer who doesn't know Haskell. > > This is getting somewhat off the topic of this thread, so all > I'll say is that I agree with the recommendation to learn > Haskell, but I don't think a beginner would get enough exposure > to various approaches to programming. I did not personally see > large benefits from Haskell, but perhaps I should have stuck with > it longer. Using Haskell or other similar functional languages can be extremely beneficial towards improving how good you are at recursion, and it can make you much better at functional programming paradigms, because you really don't have much choice when using a language like Haskell. For a couple of years, Haskell was my go-to language for all of my side projects, and I got much better at the functional side of things (e.g. when I first used D templates, I had no problem with their functional nature to the point that I didn't realize that they were functional in nature until I read an article that compared Haskell to C++ templates). That being said, I'd _hate_ to use Haskell for anything serious or for any large projects. It's just too restrictive. My feeling is that functional languages are likely to be a very poor place for most folks to start learning, much as I think that they're great for someone to learn and work with at some point. I have heard of beginning programming classes using functional languages and having it go very well, but it seems hard to believe to me. Imperative programming can already be a lot for beginners, but most people really don't think even vaguely in a functional manner. Even simple recursion tends to be a bit of a mind-bender for people at first. - Jonathan M Davis
Re: [OT] Re: Using Haskell for teaching [was: Help me decide D or C]
On Friday, August 2, 2019 11:05:13 AM MDT Russel Winder via Digitalmars-d- learn wrote: > On Fri, 2019-08-02 at 10:25 -0600, Jonathan M Davis via > Digitalmars-d-learn wrote: > > […] > > > My feeling is that functional languages are likely to be a very poor > > place for most folks to start learning, much as I think that they're > > great for someone to learn and work with at some point. I have heard of > > beginning programming classes using functional languages and having it > > go very well, but it seems hard to believe to me. Imperative > > programming can already be a lot for beginners, but most people really > > don't think even vaguely in a functional manner. Even simple recursion > > tends to be a bit of a mind-bender for people at first. > > […] > > At UCL in the late 1980s and early 1990s, we used a functional programming > language in the first term and C++ in the second term for teaching > programming. Initially Scheme was the functional programming language but > we then switched to Miranda (which was a pre-cursor to Haskell). > > This deep immersion in two totally different programming paradigms worked > very well. The mid/late 1990s mad rush to Java everywhere in teaching (of > which I was a part) was in hindsight madness (of a global sort). The move > by many institutions to using Python first and then Java rebalances > somewhat but is missing the point – it's about the paradigms. I have > retrenched as a believer in the Haskell/C++, or Prolog/Java, or some > such. In the new era with new undergraduates already knowing Scratch and > Python, universities should really go the whole hog in getting > programming paradigms and programming as a skill as well as knowledge, > with all the tools,fair and square into the first year curriculum. > > Of course I have been out of academia for 20 years, and am now out of > employment, so my views have no impact. :-) The university I went to had an undergrad class on programming paradigms that I _think_ was required (maybe two even), but it was definitely just the focus of a small number of classes, whereas my experience is that you get a lot more out of it when you actually use a language with a different paradigm for a while rather than just doing one group of assignments in it - and when the class covers multiple programming paradigms, that also dilutes how much you get out of each. On some level, as with many things, a lot of it depends on how much the students decide to put into it on their own. I still find it funny that the class that got me started with Haskell was the grad version of the programming paradigms course, and we used Haskell only because the teacher was always using Scheme (in fact, he was a developer for Dr. Scheme IIRC) and felt like doing something different. So, while I'd used Scheme some in an undergrad course, I ended up using Haskell in the course with the teacher who was majorly into Scheme. It seemed a bit like if one of the major D contributors decided to use Rust for a bit just to try something different. Of course, I haven't done anywhere near as good a job at learning new languages for a while now, because I've been focused enough on D that I haven't really wanted to spend time writing programs in something else. And I don't think that it works very well to really learn a language if you don't use it as your go-to language for a while (at least if you want to be good at more than the basics). There's no question though that I'm better at D thanks to the time I spent on languages such as Haskell. - Jonathan M Davis
Re: Can I remove an element from a global associative array from within a class destructor?
On Friday, August 2, 2019 5:13:10 PM MDT realhet via Digitalmars-d-learn
wrote:
> Hi,
>
> I tried to make some resource statistict for my OpenGL Buffer
> objects:
>
>
> //here are the things that hold the statistics.
> private __gshared{ size_t[int] textureSizeMap, bufferSizeMap; }
>
> struct GLCounters{
>int programs, shaders, textures, buffers;
>size_t textureSize, bufferSize;
> }
> __gshared GLCounters glCounters;
>
> ...
>
> //And this is the buffer creation.
> int genBuffer(size_t size){
>int res; glGenBuffers (1, ); glChk;
>glCounters.buffers ++;
>glCounters.bufferSize += size;
>bufferSizeMap [res] = size;
>writefln("buffer allocated %d %d", res, size);
>return res;
> }
>
> //Finally, this is the deallocation. If it is called from the GC
> (when it destroys a class), it has a big chance to throw an
> Invalid Memory Operation exception.
>
> void deleteBuffer (int handle){
>if(!handle) return;
>glDeleteBuffers (1, ); glChk;
>glCounters.buffers --;
>glCounters.bufferSize -= bufferSizeMap [handle];
>writefln("buffer deallocated %d %d", handle, bufferSizeMap
> [handle]);
>bufferSizeMap.remove(handle); <- this is the problematic part.
> }
>
>
> Today I read the documentation about structs, unions and classes,
> but I haven't find any restrictions for the ~this() destructors.
>
> Is there some extra rules regarding the GC and what I must not do
> in the destructors?
>
> I think the destructor always called in the same thread where the
> instance was created. This can't be the case.
> But what I can guess is: The GC makes a collection and calls my
> destructor and inside I do something and the GC calls a
> collection again recursively. But it seems a bit crazy, so I
> think it's not the case :D
>
> Please help me solve this!
>
> *I'm using LDC 1.6.0 Win64
As I understand it, you can't do much of anything that involves the GC
inside a destructor that's being run as a finalizer by the GC (as is almost
always the case with classes). Structs or classes on the stack (which for
classes requires something like scope) don't have that problem, because
they're not being run by the GC. But if a struct or class is on the GC heap,
then attempting to allocate or deallocate GC resources doesn't work, because
the destructor/finalizer runs when the GC is doing a collection. Even trying
to use other objects that are on the GC heap from a finalizer is not a
allowed, because there is no guarantee about the order that the objects are
collected (otherwise, cyclical references would be a big problem), meaning
that references in the finalizer could refer to objects that have already
been destroyed and their memory freed.
https://dlang.org/spec/class.html#destructors
Basically, destructors/finalizers for anything on the GC heap are just for
cleaning up non-GC-allocated resources.
- Jonathan M Davis
1 new
When I navigate to https://forum.dlang.org/ I have a message that says "1 new reply" to "your posts." Normally, I click on that "1 new reply" and find the post that's new, go to it, and the message disappears. However, it doesn't seem to go away anymore. I tried looking at many different old posts without luck. At one point it was up to "2 new replies," but I viewed that other post and it went back down to "1 new reply." Does anyone else have this?
Re: Help me decide D or C
On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote: Should I go for C and then when I become a better programmer change to D? Should I start with D right now? In my view, the most important thing is the decision you've already made - to pick a programming language and learn it in a reasonable bit of depth. Which programming language you choose is less important. No matter which choice you make you'll have the opportunity to learn skills that will transfer to other programming languages. As you can tell from the other responses, the pros and cons of a learning a specific language depend quite a bit on what you hope to get out of it, and are to a fair extent subjective. But both C and D provide meaningful opportunities to gain worthwhile experience. A couple reasons for considering learning D over C are its support for functional programming and templates. These were also mentioned by a few other people. These are not really "beginner" topics, but as one moves past the beginner stage they are really quite valuable techniques to start mastering. For both D is the far better option, and it's not necessary to use either when starting out. --Jon
Re: Function called twice
On Friday, 2 August 2019 at 21:44:28 UTC, Jordan Wilson wrote:
Hello,
I don't quite understand why isEven is called twice in the 2nd
example?
auto isEven(int n) {
n.writeln;
return (n % 2) == 0;
}
void main() {
auto z = [1,2,3];
// outputs 1 2 3
z.map!(a => tuple!("number")(a))
.filter!(a => a.number.isEven)
.array;
// outputs 1 2 2 3
z.map!(a => tuple!("number","iseven")(a, a.isEven))
.filter!(a => a.iseven)
.array;
return;
}
Thanks,
Jordan
The way map is designed is to call its predicate on each front
call and filter calls it twice with the number 2.
https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d#L604
You can use "cache" to avoid the double front call on any range.
z.map!(a => tuple!("number","iseven")(a, a.isEven))
.cache
.filter!(a => a.iseven)
.array;
Function called twice
Hello,
I don't quite understand why isEven is called twice in the 2nd
example?
auto isEven(int n) {
n.writeln;
return (n % 2) == 0;
}
void main() {
auto z = [1,2,3];
// outputs 1 2 3
z.map!(a => tuple!("number")(a))
.filter!(a => a.number.isEven)
.array;
// outputs 1 2 2 3
z.map!(a => tuple!("number","iseven")(a, a.isEven))
.filter!(a => a.iseven)
.array;
return;
}
Thanks,
Jordan
Re: Function called twice
On Friday, 2 August 2019 at 21:44:28 UTC, Jordan Wilson wrote:
// outputs 1 2 2 3
z.map!(a => tuple!("number","iseven")(a, a.isEven))
.filter!(a => a.iseven)
.array;
I *think* what's happening here is first it calls map() first
going into the filter... then it gets called again when it is
being evaluated for the array.
So like basically consider if you had:
if(filter(a())
array ~= a();
that kind of thing. I think anyway, I'm not entirely sure but it
fits what I can see happening here.
but idk why it is actually doing this in the phobos implementation
Can I remove an element from a global associative array from within a class destructor?
Hi,
I tried to make some resource statistict for my OpenGL Buffer
objects:
//here are the things that hold the statistics.
private __gshared{ size_t[int] textureSizeMap, bufferSizeMap; }
struct GLCounters{
int programs, shaders, textures, buffers;
size_t textureSize, bufferSize;
}
__gshared GLCounters glCounters;
...
//And this is the buffer creation.
int genBuffer(size_t size){
int res; glGenBuffers (1, ); glChk;
glCounters.buffers ++;
glCounters.bufferSize += size;
bufferSizeMap [res] = size;
writefln("buffer allocated %d %d", res, size);
return res;
}
//Finally, this is the deallocation. If it is called from the GC
(when it destroys a class), it has a big chance to throw an
Invalid Memory Operation exception.
void deleteBuffer (int handle){
if(!handle) return;
glDeleteBuffers (1, ); glChk;
glCounters.buffers --;
glCounters.bufferSize -= bufferSizeMap [handle];
writefln("buffer deallocated %d %d", handle, bufferSizeMap
[handle]);
bufferSizeMap.remove(handle); <- this is the problematic part.
}
Today I read the documentation about structs, unions and classes,
but I haven't find any restrictions for the ~this() destructors.
Is there some extra rules regarding the GC and what I must not do
in the destructors?
I think the destructor always called in the same thread where the
instance was created. This can't be the case.
But what I can guess is: The GC makes a collection and calls my
destructor and inside I do something and the GC calls a
collection again recursively. But it seems a bit crazy, so I
think it's not the case :D
Please help me solve this!
*I'm using LDC 1.6.0 Win64
Re: How do I use mixin types?
On Friday, 2 August 2019 at 21:10:08 UTC, Andrej wrote: The D spec mentions something called mixin types: This is brand new to the spec and hasn't yet been released in a compiler. You can get a nightly build here https://dlang.org/changelog/pending.html to maybe try, but I don't think it will be in a proper release until ... my guess is Sept 1.
Re: Function called twice
On Friday, 2 August 2019 at 21:44:28 UTC, Jordan Wilson wrote:
Hello,
I don't quite understand why isEven is called twice in the 2nd
example?
auto isEven(int n) {
n.writeln;
return (n % 2) == 0;
}
void main() {
auto z = [1,2,3];
// outputs 1 2 3
z.map!(a => tuple!("number")(a))
.filter!(a => a.number.isEven)
.array;
// outputs 1 2 2 3
z.map!(a => tuple!("number","iseven")(a, a.isEven))
.filter!(a => a.iseven)
.array;
return;
}
map doesn't memoize its front value
(https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d#L604), so every time someone looks at it the mapping function needs to be called again. So in the second case, for each item first filter calls map.front which calls isEven, then if it matches the filter (so only the 2), array calls filter.front, which calls map.front, which calls isEven.
You can avoid this by eagerly iterating to an array:
z.map!(a => tuple!("number","iseven")(a, a.isEven))
.array // new!
.filter!(a => a.iseven)
.array;
I was also gonna suggest using std.functional.memoize to memoize
the function in map, but apparently it doesn't like lambdas
(https://issues.dlang.org/show_bug.cgi?id=20099).
--
Simen
How do I use mixin types?
The D spec mentions something called mixin types:
https://dlang.org/spec/grammar.html#MixinType
https://dlang.org/spec/type.html#mixin_types
If I'm understanding the grammar right, it means you can use a
string mixin anywhere a Type would normally go, for example:
int func(mixin("int") x)
{
return x;
}
However, when I try to compile that fragment (using dmd 2.086.1),
it fails with the following error:
.\mixintype.d(1): Error: basic type expected, not `mixin`
...and then a few more cascading errors as a result of it not
understanding the mixin.
I've tried placing the mixin on the right hand side of an alias
declaration, but that didn't work either.
I've found literally nothing about this feature online except for
the official spec so I'm starting to question whether this is an
actual language feature or not...
I'd really like it to exist, otherwise I'd need to use a regular
mixin declaration to define the entire function.
Re: Function called twice
On Friday, 2 August 2019 at 22:35:53 UTC, Adam D. Ruppe wrote:
On Friday, 2 August 2019 at 21:44:28 UTC, Jordan Wilson wrote:
// outputs 1 2 2 3
z.map!(a => tuple!("number","iseven")(a, a.isEven))
.filter!(a => a.iseven)
.array;
I *think* what's happening here is first it calls map() first
going into the filter... then it gets called again when it is
being evaluated for the array.
So like basically consider if you had:
if(filter(a())
array ~= a();
that kind of thing. I think anyway, I'm not entirely sure but
it fits what I can see happening here.
but idk why it is actually doing this in the phobos
implementation
In my real-world case "isEven" is a long running function. I'll
put an .array after the map and see if it makes a difference.
Thanks,
Jordan
Re: Help me decide D or C
On Friday, 2 August 2019 at 12:30:44 UTC, berni wrote: On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote: [...] In my oppinion C should have been deprecated about 50 years ago and it's not worth while to learn it if you are not interested in the history of programming or you have to learn it, because you need to maintain software which is allready written in C. But that's my oppinion; others may have a different sight. [...] Could you elaborate more about C being a burden? I have read so many people saying C gives a great foundation and should be everyone's first language. Now I am confused.
Re: Help me decide D or C
On Thursday, 1 August 2019 at 20:02:08 UTC, Aurélien Plazzotta wrote: [...] But don't fool yourself, D is not for beginners. Ali Çehreli is a very skilled programmer, ergo, he can't reason like a new/starting programmer anymore, regardless of his patience and kindness. I am sorry, but this is very strange reasoning. Would you recommend a book on programming written by someone who is not a skilled programmer himself in any language? I certainly would not. Besides, the OP has already expressed his appreciation for Ali’s writing. Bastiaan.
Re: Help me decide D or C
On Wednesday, 31 July 2019 at 22:30:52 UTC, Alexandre wrote: My goals: 1) Improve as a programmer 2) Have fun doing programs That's it basically. I am planning to study all "free" time I have. I am doing basically this since last year. Are you only considering D and C or just mentioning them in this forum? The interpreted dynamically-typed languages like Python are considered easier to use and have the largest amount of functionality in their libraries. If it is just down to D or C, then definitely D. C would be at or near the bottom in terms of a language to have fun doing general programming and learning.
Blog Post #0058: Cairo Rectangles
Continuing on with Cairo, this is a look at the variations and permutations of drawing rectangles and you'll find it here: https://gtkdcoding.com/2019/08/02/0058-cairo-ii-rectangles.html
Re: Help me decide D or C
On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote: Should I go for C and then when I become a better programmer change to D? Should I start with D right now? D and C++ (and probably other languages) inherit features of C such as operator precendence, integer promotion, and a few things. So learning these specific points of C will pay dividends. However, I don't see any other reason - apart from platform support maybe - to bother with C when D is available.
Re: Help me decide D or C
On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote: Hi everyone, I would like an honest opinion. I have a beginner level (able to do very small programs) in a few languages such as python, go, C, guile(scheme) and common lisp. I want to pick a language and go deep with it and focus on only one for at least the next 2 years or so. Should I go for C and then when I become a better programmer change to D? Should I start with D right now? The reason I am considering starting with C: since I am a beginner, obvious I will need lots of books, tutorials, videos etc. And I believe C would have more resources and maybe a low level to help with programming in general. And, when I need a more powerful language, I would than learn D. Since you know the good and the ugly of the D programming language I wonder, what you would think would be the best to do right now? Thank you for your help! It depends what you want to do. C is a good language for low level, embedded programming. For "higher" level programming like web clients/servers, text processing, programs with graphical user interface then C is just awful because it has fewer built in primitives and libraries. Also with more complicated program C in general requires more boiler plate. Then we have C++ but in general it has the same problems as I mentioned with C but programming is slightly more convenient as it has classes, exceptions and some more powerful libraries due to templates, operator overloading such things. D is somewhere in the middle between Java and C++. Syntax is much better and intuitive than C++. Thanks to that it is more inspired by Java, the libraries are in general more convenient to use and cleaner. I'd say D is a good choice for learning programming as it sits in the high seat of low level and high level. No, other language combines that as good as D I think. Also if you start with D you can easily go to C++ or Java. I'd say start with D and then learn C++ because it would be interesting to hear from a person who learn D first, thinks of C++.
Re: Help me decide D or C
On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote: Should I go for C and then when I become a better programmer change to D? Should I start with D right now? In my oppinion C should have been deprecated about 50 years ago and it's not worth while to learn it if you are not interested in the history of programming or you have to learn it, because you need to maintain software which is allready written in C. But that's my oppinion; others may have a different sight. I would recommend to start immediately with D (using the book of Ali, which has allready been mentioned). When you've got mastered D you will not have any problems switching to an other language. And you don't need to know everything about D to write programs. For example you do not need to use templates in the beginning. You might find out a strange looking syntax for type conversion "to!string(17)" with this exclamation mark in between, which you can just accept and us as is, without having to understand what it's good for. I would even go further and state, that learning C first will become a burden instead of a help.
Re: Help me decide D or C
On Fri, Aug 2, 2019 at 2:30 PM berni via Digitalmars-d-learn wrote: > ... > I would even go further and state, that learning C first will > become a burden instead of a help. > Yes, I agree with this. It is same as with C++. Many people starts with C and then learn C++. Which is really not a good idea.
Re: Help me decide D or C
On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote: Should I go for C and then when I become a better programmer change to D? Should I start with D right now? In my oppinion C should have been deprecated about 50 years ago and it's not worth while to learn it if you are not interested in the history of programming or you have to learn it, because you need to maintain software which is allready written in C. But that's my oppinion; others may have a different sight. I would recommend to start immediately with D (using the book of Ali, which has allready been mentioned). When you've got mastered D you will not have any problems switching to an other language. And you don't need to know everything about D to write programs. For example you do not need to use templates in the beginning. You might find out a strange looking syntax for type conversion "to!string(17)" with this exclamation mark in between, which you can just accept and us as is, without having to understand what it's good for. I would even go further and state, that learning C first will become a burden instead of a help.
