Re: Converting multiple inheritance code into C ++ for D language
On Friday, 17 February 2017 at 23:24:57 UTC, Nicholas Wilson wrote: Something like this would be a goods use for struct multiple alias this, except that we haven't implemented that yet unfortunately. What's the deal with that? It seems someone made progress on this issue 2 years ago and then vanished. It's a fairly significant feature that's never been implemented!
Re: DStyle: Braces on same line
On Sunday, 13 July 2014 at 17:24:40 UTC, Timon Gehr wrote: On 07/13/2014 06:45 PM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: Wrong. There are things which are simply bad ideas. E.g. in this case, Egyptian-style braces definitely make your code more compact, I.e. you see where everything is. Yes, the same argument for books and slides is also applicable to all other media. This style has also caught on amongst the other curly braced languages that I use, so that most of the code I read (and write) has adopted it (C/C++/Java/Javascript code, that is). The Phobos style is incredibly wasteful IMO, but that's what D has adopted, so if you intend to contribute to Phobos, you had better get used to it. The Rust community appears to have made the right choice with Egyptian for everything. but separate-line opening braces definitely make it easier to see where scopes begin and end. All of this is subjective, of course, but I definitely don't find that the Phobos style provides this advantage. This is the only argument I have heard in favour of doing this, but it is not actually valid. This critique might apply to Lisp style. Not sure I follow you here. Most of the Lisp I've read is indented like Python, the idea being that you learn not to not see all of the parens and rely on tools like paredit to do the trivial balancing. I'd hate to read Lisp with separate lines for parens that open scopes. I'm sure that's not what you mean!
Re: Ensuring template argument is descendant of class
On Friday, 13 December 2013 at 05:55:09 UTC, H. S. Teoh wrote: On Fri, Dec 13, 2013 at 06:42:26AM +0100, Brian Rogoff wrote: I'm sympathetic to this POV, or something similar. For example, a multiyear plan to deprecate the 'is' syntax and replace it with something better, in the current D. I'm not a fan of gratuitous changes which make the language unstable, but if there were a pleasing design to replace 'is' I'd like to think that D users could change the relevant sources given a long enough deprecation window. I vote for this. Good luck convincing Walter, though. Step 1 is to come up with a set of better design alternatives, and a transition plan, etc. I'm pretty sure I've read posts from Walter on this forum that agree with the current 'is' is far from ideal, so maybe convincing him is not as hard as you think, though I imagine he has bigger fish to fry these days. Still, it would be encouraging if the D community could address the general issue of *not* being forced to keep bad designs forever. -- Brian
Re: Ensuring template argument is descendant of class
On Friday, 13 December 2013 at 05:22:26 UTC, Ross Hays wrote: Yeah, is-expression syntax is one of the dark, ugly corners of D that unfortunately we're stuck with, because changing it now will totally break a LOT of code for merely cosmetic reasons. I honestly wish that one day this mess could be cleared up, though I'm not holding my breath for it. T I know this is probably obvious, but if D were allowed to just make one big breaking change for D3 or something, and fix every dark corner it has. Would that really be so bad? I know it would break things but... I kind of long for it. I'm sympathetic to this POV, or something similar. For example, a multiyear plan to deprecate the 'is' syntax and replace it with something better, in the current D. I'm not a fan of gratuitous changes which make the language unstable, but if there were a pleasing design to replace 'is' I'd like to think that D users could change the relevant sources given a long enough deprecation window. Changing every dark corner and every poor choice is too much. For instance, a lot of people think that immutability and 'nothrow' should have been the default, but changing that would be dramatic and probably will have to wait for a D3 or new language. -- Brian
Re: matrix business in D
On Friday, 18 October 2013 at 13:04:51 UTC, bearophile wrote: Julia is a very new language, quite newer than D. I don't think it's a good idea to recommend it for real work. I don't think that the simple rule comparing age of the languages in question for risk assessment is very useful. Given all of the other variables, I'd be more likely to recommend Julia for numerical linear algebra today than D for the same role. That's not a slam on D, which I mostly like better than it's competition (C++, Rust, C, ...) but rather an observation that the Julia community is entirely focused on this domain. A really risk averse programmer who wouldn't consider Julia in this domain wouldn't consider D either -- Brian
Re: Question about garbage collector
On Wednesday, 28 August 2013 at 21:28:11 UTC, bioinfornatics wrote: Hi everyone, yesterday i read an article into a french linux journal that in some years garbage collector will disapear. Why ? he explain in very very short as: -- - Moore's law will be not anymore true so only memory will continue to increase ( static and volatil ) - Garbage Collector are not efficient in big memory for some technical reason - Data to manage will continue to grow big data ant full memory stategy will the rule I've had similar thoughts myself for some time. So Develloper will move to a language where they are no garbage collector. There are many different kinds of software and developer, you need to qualify that assertion. GCed languages will not go away. -- In bioinformatic we work with big data or full memory stategy often and that will not stop. So what think D garbage cllector's dev about this ? I hope that D can go either way on this, and allows developers to 'opt out' of GC if they need to, but I don't think it is that easy now. Is there a skeletal 'no GC D' project out there? What is given up (AAs, slices, classes, exceptions, ...) and how easy is it to use? If not, Rust, Ada, and of course, C++ will be there. There are surprisingly few languages being designed to be used without GC these days. -- Brian
Re: Ping qznc: Re: A little of coordination for Rosettacode
On Saturday, 22 June 2013 at 21:27:01 UTC, bearophile wrote: Ali Çehreli: The code compiles under 32-bit (e.g. with the -m32 compiler switch) where size_t is an alias of uint. Thanks, Ali! I'm always compiling on 64 bit systems; I'll add the 32 bit switch to my diagnostic approach now. Oh, I see. I compile most of the code on a 32 bit system. I asked Walter to warn d programmers against such mistakes, and Walter closed it down. Someone else has opened the ER again... In general, I think implicit conversions of any kind are a misfeature, but better error messages would be enough for me here. At least in Scala, you need to bring the conversion into scope yourself, or have it accidentally imported... Thanks for your help. -- Brian
Re: Ping qznc: Re: A little of coordination for Rosettacode
On Saturday, 16 February 2013 at 11:30:00 UTC, Jos van Uden wrote:
On 16-2-2013 8:58, qznc wrote:
On Saturday, 16 February 2013 at 06:58:01 UTC, qznc wrote:
On Saturday, 16 February 2013 at 02:23:42 UTC, Jos van Uden
wrote:
On 5-2-2013 20:45, Jos van Uden wrote:
By the way, I think 'Qznc' may want to have a look at 'The
dining
philosophers':
http://rosettacode.org/wiki/Dining_philosophers
I should find the time to solve it this weekend.
Wow, my kid let me do some hacking right now and it was
simpler than expected.
Posted a solution already.
Wow, that was quick. Thanks!
The current D code for Dining philosophers does not compile with
dmd v2.063.2, the error message being
dining.d(34): Error: cannot uniquely infer foreach argument types
The code looks OK to me (but I'm a D newbie) so I wonder if
someone could explain the inference issue. Where should an
annotation be added to allow this to compile?
1 import std.stdio, std.algorithm, std.string,
std.parallelism,
2core.sync.mutex;
3
4 void eat(in uint i, in string name, Mutex[] forks) {
5writeln(name, is hungry.);
6
7immutable j = (i + 1) % forks.length;
8
9 // Take forks i and j. The lower one first to prevent
deadlock.
10auto fork1 = forks[min(i, j)];
11auto fork2 = forks[max(i, j)];
12
13fork1.lock();
14scope(exit) fork1.unlock();
15
16fork2.lock();
17scope(exit) fork2.unlock();
18
19writeln(name, is eating.);
20writeln(name, is full.);
21 }
22
23 void think(in string name) {
24writeln(name, is thinking.);
25 }
26
27 void main() {
28 const philosophers = Aristotle Kant Spinoza Marx
Russell.split();
29Mutex[philosophers.length] forks;
30foreach (ref fork; forks)
31 fork = new Mutex();
32
33defaultPoolThreads = forks.length;
34 foreach (uint i, philo; taskPool.parallel(philosophers))
{
35 foreach (_; 0 .. 100) {
36eat(i, philo, forks);
37think(philo);
38 }
39}
40 }
BTW, I like the coding style being used in the rosetta examples
and TDPL much better than the library style.
-- Brian
