Re: GC: memory collected but destructors not called

On 10/11/14 16:19, Steven Schveighoffer wrote: Only classes call dtors from the GC. Structs do not. There are many hairy issues with structs calling dtors from GC. Most struct dtors expect to be called synchronously, and are not expecting to deal with multithreading issues. Note that structs

Re: GC: memory collected but destructors not called

On 11/11/14 22:41, Steven Schveighoffer wrote: At this point, I am not super-concerned about this. I cannot think of any bullet-proof way to ensure that struct dtors for structs that were meant only for stack variables can be called correctly from the GC. Isn't structs meant only for stack

Re: GC: memory collected but destructors not called

On 12/11/14 11:29, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: Supposedly, a struct destructor will only access resources that the struct itself manages. As long as that's the case, it will be safe. In practice, there's still a lot that can go wrong. Either a struct's destructor can

Bug in compiler?

Please consider the following program: import std.exception; void main() { struct A { int a; @disable this(this); @disable ref A opAssign(const ref A); ref A opOpAssign(string op: ~)(int data) { a += data; return this; }

Make int[12] convertible to int[]

The subject pretty much says it all. If I have a function: void function(int[] arr); I'd like to be able to call it with: int[12] a; function(a); I know I can do: function(a[]); It just seems like extra unneeded superfluous unnecessary redundancy. I don't see any static typing

Re: Make int[12] convertible to int[]

On 17/12/14 17:02, Adam D. Ruppe wrote: On Wednesday, 17 December 2014 at 13:13:43 UTC, Shachar Shemesh wrote: It just seems like extra unneeded superfluous unnecessary redundancy. It is somewhat important because storing a slice to a static array is a big problem: Any time you pass by

version(assert) defined variables

Hi all, Please consider the following program: int main() { version(assert) int var; assert(var == 0); return 0; } When compiled with dmd test.d, it passes without a problem. When compiled with dmd test.d -release, it produces the following error: test.d(5): Error: undefined

Trying to avoid the GC

I have a standard processing that needs to be done over and over again, with an inner function that is different between invocations. Here is a small sample that illustrates the need: import std.stdio; alias dtype = void delegate(int i); void func(T)( T d ) { foreach(i; 0 .. 10) {

Re: Trying to avoid the GC

On 31/12/14 15:52, Adam D. Ruppe wrote: Try writing that: void func(scope dtype d) Yep. That's exactly what I was looking for. On GDC it even allows for complete compile time evaluation of the entire loop. Thanks, Shachar

Re: Trying to avoid the GC

On 31/12/14 23:48, ketmar via Digitalmars-d wrote: On Wed, 31 Dec 2014 13:52:02 + Adam D. Ruppe via Digitalmars-d digitalmars-d@puremagic.com wrote: Try writing that: void func(scope dtype d) an it's so well hidden that not many people know about it. being a not very careful reader

Re: What is going on here?

On 07/03/15 23:44, w0rp wrote: Why not handle the scope(failure) cases in the constructor itself? Because this breaks encapsulation. struct SomeStruct { SomeOtherStruct a; MoreStruct b; this(int c) { this.a = SomeOtherStruct(c); this.b

Re: What is going on here?

On 07/03/15 07:09, Steven Schveighoffer wrote: That's pretty horrible. So now I need to keep track of the implementation of my members to figure out whether it is okay to skip the destructor or not. Why does it matter? If the member is constructed, insert a scope(failure) destroy, otherwise

Re: What is going on here?

On 04/03/15 17:43, Steven Schveighoffer wrote: On 3/4/15 8:43 AM, Shachar Shemesh wrote: I'd expect A's destructor to run, which does not seem to be the case. I believe destructors are not run when you throw inside a constructor. So plan to deallocate if the ctor throws: a = A(var + 1);

Re: What is going on here?

On 05/03/15 04:09, deadalnix wrote: On Wednesday, 4 March 2015 at 19:36:20 UTC, Ali Çehreli wrote: Even C++ gets this right. Ali Nop, I do think C++ destroy uninitialized fields. I'm sorry, but you are wrong. In C++, a destructor is run for fully constructed objects. Fully constructed is

What is going on here?

import std.stdio; struct A { int a = 3; this( int var ) { a += var; } ~this() { writeln(A down , a); } } struct B { A a; this( int var ) { a = A(var+1); throw new Exception(An exception); } } void main() { try {

Re: What is going on here?

On 08/03/15 15:56, w0rp wrote: So if you want something to work as of right now, do that. I realize that. What I'm saying is that this is unacceptable. This violates D's own standard. From http://dlang.org/exception-safe.html: The RAII (Resource Acquisition Is Initialization) idiom and

Re: Today's programming challenge - How's your Range-Fu ?

On 19/04/15 10:51, Abdulhaq wrote: MiOn Sunday, 19 April 2015 at 02:20:01 UTC, Shachar Shemesh wrote: On 18/04/15 21:40, Walter Bright wrote: Also, notice that some letters can only be achieved using multiple code points. Hebrew diacritics, for example, do not, typically, have a composite

Re: DMD Copyright string

On 22/04/15 04:42, Daniel Murphy wrote: Colin wrote in message news:sbafvqyzjweacrhwd...@forum.dlang.org... I notice when you run dmd with no args, it will print: DMD64 D Compiler v2.067.0 Copyright (c) 1999-2014 by Digital Mars written by Walter Bright Surely that's meant to be 2015? Walter

Re: Today's programming challenge - How's your Range-Fu ?

On 19/04/15 22:58, ketmar wrote: On Sun, 19 Apr 2015 07:54:36 +, John Colvin wrote: it's not crazy, it's just broken in all possible ways: http://file.bestmx.net/ee/articles/uni_vs_code.pdf This is not a very accurate depiction of Unicode. For example: And, moreover, BOM is meaningless

false positive escaping reference to local array

Hi all, Please consider the following program: void main() { int array[13]; int[] internalFunc() { return array; } } This code does not compile (dmd 2.066.1), claiming: test.d(5): Error: escaping reference to local array The way I see it, the array in question is in scope

Re: false positive escaping reference to local array

On 06/05/15 10:28, Shachar Shemesh wrote: Hi all, Please consider the following program: void main() { int array[13]; int[] internalFunc() { return array; } } This code does not compile (dmd 2.066.1), claiming: test.d(5): Error: escaping reference to local array The

Re: D casually mentioned and dismissed + a suggestion

On 13/05/15 12:29, Maxim Fomin wrote: Giving how D is similar to C/C++ I am surprised that non-familiriarity with D is a big problem. D is a fairly complex language (far too complex, IMHO, relative to its age). Its complexities are both different than C++, and also of a different kind. I

Re: D casually mentioned and dismissed + a suggestion

On 12/05/15 21:35, FujiBar wrote: Walter would probably violently disagree with the no decent development tools assessment. But I got to say that people used to Visual Studio and XCode (like myself) not being impressed by D's 1980s-style bare basic command line tools is not surprising. I don't

Re: D casually mentioned and dismissed + a suggestion

On 13/05/15 08:48, Walter Bright wrote: On 5/12/2015 10:13 PM, Shachar Shemesh wrote: And this is before mentioning stability. I've lost count of the number of times my compilation failed with an assert thrown by dmd, and just last week I've had to refactor the code around a consistent

Re: Today's programming challenge - How's your Range-Fu ?

On 18/04/15 21:40, Walter Bright wrote: I'm not arguing against the existence of the Unicode standard, I'm saying I can't figure any justification for standardizing different encodings of the same thing. A lot of areas in Unicode are due to pre-Unicode legacy. I'm guessing here, but looking

Re: Today's programming challenge - How's your Range-Fu ?

On 17/04/15 19:59, H. S. Teoh via Digitalmars-d wrote: There's also the question of what to do with bidi markings: how do you handle counting the columns in that case? Which BiDi marking are you referring to? LRM/RLM and friends? If so, don't worry: the interface, as described, is incapable

Re: Which D IDE do you use?(survey)

On 08/04/15 02:58, Idan Arye wrote: On Tuesday, 7 April 2015 at 22:58:44 UTC, weaselcat wrote: Hi, I hope nobody minds but I'm just curious as to the popularity amongst D IDEs for a blog post. Sorry if I forgot your favorite $editor. http://goo.gl/forms/MmsuInzDL0 thanks : ) Vim. The only

Re: dmd makes D appear slow

On 01/06/15 18:40, Steven Schveighoffer wrote: On 5/30/15 2:38 PM, Shachar Shemesh wrote: So given that a compiler actually *works* (i.e. produces valid binaries), is speed of compilation better than speed of execution of the resulting binary? There is no answer to that question. During

Re: [OT] Modules dropped out of C++17

On 09/06/15 10:21, Paulo Pinto wrote: It is no different than extension methods in .NET, Ceylon, Kotlin, multi-methods in CLOS or implicits in Scala. I never could understand that line of reasoning: Argument: So and so is bad because A Answer: X, Y, and Z also do so and so How is the answer

Re: [OT] Modules dropped out of C++17

On 09/06/15 11:17, Kagamin wrote: Not sure what you compare it to. Even finding declaration was never an easy job in C, and definition can be anywhere in the source tree. In D symbols are at least tied to modules, so you can look only in the respective module, this never worked for C though.

Re: [OT] Modules dropped out of C++17

On 09/06/15 11:35, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: I agree, I have conventions in my C++ code where member functions and free functions shouldn't mix. But given C++ templates lack of type safety, I'm not surprised that BS pushes it. It also

Re: [OT] Modules dropped out of C++17

On 08/06/15 22:24, Walter Bright wrote: Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. Dear god, I hope this doesn't pass. It is one of the

Re: [OT] Modules dropped out of C++17

On 09/06/15 10:27, Joakim wrote: Perhaps Dscanner's declaration finder (the -d flag) or DCD would make your life easier. I use Dscanner all the time and miss it when I'm stuck with grep for C nowadays: https://github.com/Hackerpilot/Dscanner https://github.com/Hackerpilot/DCD I use DCD, and

Re: Constructor inheritance? Why not?

On 08/06/15 06:35, Jonathan M Davis wrote: They're not polymorphic, and it doesn't make sense to call a base class constructor on a derived class. I think that I heard somewhere that C++11 added some sort of constructor inheritance No, it didn't. What C++11 added was the ability to use the

Re: dmd makes D appear slow

On 02/06/15 21:56, weaselcat wrote: On Monday, 1 June 2015 at 15:40:55 UTC, Steven Schveighoffer wrote: My original statement was obviously exaggerated, I would not put up with days-long compile times, I'd find another way to do development. But compile time is not as important to me as it is

Re: [OT] Modules dropped out of C++17

On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx();

Re: [OT] Modules dropped out of C++17

On 09/06/15 22:39, Walter Bright wrote: I usually try to select identifiers that are easy to grep. So unless one has a penchant for naming functions f(), in practice it isn't a significant issue. The difference between theory and practice is that, in theory, there is no difference between

Re: [OT] Modules dropped out of C++17

On 10/06/15 17:05, Kagamin wrote: On Wednesday, 10 June 2015 at 13:43:45 UTC, Shachar Shemesh wrote: On 10/06/15 15:37, Kagamin wrote: On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote: On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local

Re: [OT] Modules dropped out of C++17

On 10/06/15 15:37, Kagamin wrote: On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote: On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx();

Re: [OT] Modules dropped out of C++17

On 10/06/15 00:29, Walter Bright wrote: First off, D does not allow shadowing local variable declarations. Secondly, if you've got a lot of global variables, you've got a program design problem anyway. And lastly, naming everything diskIdx is a problem of your own creation. The first one is

Re: [OT] Modules dropped out of C++17

On 10/06/15 09:14, deadalnix wrote: I do think you think at it the wrong way. people are not telling you it is bad code. You are telling us it is bad code (because you mention having problem that people using other style do not have). It is not a problem in C++. It is not a problem with no

Re: Lets talk about fibers

On 05/06/15 16:44, Dmitry Olshansky wrote: * You seem to assume the same. Fine assumption given that OS usually tries to keep the same cores working on the same threads, for the similar reasons I believe. I see that people already raised the point that the OS does allow you to pin a thread

Re: Martin Nowak is officially MIA

On 20/06/15 12:37, Martin Nowak wrote: Which also comes with the usual e-mail benefit, people think a lot more before hitting send. You talk like someone who's never seen a flame war. Shachar

Re: DMD memory management

On 14/06/15 20:01, bitwise wrote: On Sun, 14 Jun 2015 12:52:47 -0400, ketmar ket...@ketmar.no-ip.org wrote: so it's by design. Ok, makes sense ;) Bit Well, sortof. It makes sense, until you try to compile a program that needs more memory than your computer has. Then, all of a

Re: dmd makes D appear slow

On 30/05/15 21:44, Iain Buclaw via Digitalmars-d wrote: Got any bug reports to back that up? I should probably run the testsuite with optimisations turned on sometime. The latest one (the one that stung my code) is http://bugzilla.gdcproject.org/show_bug.cgi?id=188. In general, the bugs

Re: dmd makes D appear slow

On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote: When he says Windows, he means MSVC, gcc backend will never support interfacing that ABI (at least I see no motivation as of writing). I thought that's what MINGW was. A gcc backend that interfaces with the Windows ABI. Isn't it?

Re: dmd makes D appear slow

On 30/05/15 03:57, Steven Schveighoffer wrote: I saw the slide from Liran that shows your compiler requirements :) I can see why it's important to you. Then you misunderstood Liran's slides. Our compile resources problem isn't with GDC. It's with DMD. Single object compilation requires more

Re: dmd makes D appear slow

On 31/05/15 02:08, Manu via Digitalmars-d wrote: On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d digitalmars-d@puremagic.com wrote: On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote: When he says Windows, he means MSVC, gcc backend will never support interfacing that ABI

Re: [OT] Sharp Regrets: Top 10 Worst C# Features

On 19/08/15 15:01, Kagamin wrote: Just switch your editor to RTL mode, haha. OT: (so this is an off topic reply to an off topic thread) I actually tried to write a good RTL text editor (you can see the half baked result at http://bidiedit.lingnu.com). I know your comment was meant as a

Re: Matrix API support - start with formats?

On 14/08/15 17:57, Andrei Alexandrescu wrote: I stumbled upon https://software.intel.com/en-us/node/471374 which gives good detail on Intel's Math Kernel Library's data formats for sparse matrices. No doubt other popular linear algebra libraries have similar documentation. I was thinking we

Difference between input range and forward range

Please consider the following program: import std.stdio; import std.range; struct Range { int a; @disable this(this); public: int front() { return a; } void popFront() { a--; } bool empty() { return a<=0; } } void main() {

Re: Go, D, and the GC

On 07/10/15 12:58, Timon Gehr wrote: Shachar struct S{ @disable this(); @disable enum init=0; } void main(){ S s; // error auto d=S.init; // error } An honest question. Would that also cover all cases where init is being used implicitly by the compiler? I will need

Re: Go, D, and the GC

On 08/10/15 18:58, Marco Leise wrote: Am Mon, 05 Oct 2015 13:42:50 + schrieb Adam D. Ruppe : On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote: Not on the heap. There are many cases where the destructor won't run and it is allowed by spec. We should do

Re: Difference between __gshared and shared.

On 08/07/15 15:08, Jonathan M Davis wrote: I know that there are a number of people who get frustrated with shared and using __gshared instead, but unless you fully understand what you're doing and how the language works, and you're _really_ careful, you're going to shoot yourself in the foot it

Re: Implement the unum representation in D ?

On 11/07/15 06:02, Nick B wrote: On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote: Hi everyone. John Gustafson Will be presenting a Keynote on Thursday 27th February at 11:00 am The abstract is here: http://openparallel.com/multicore-world-2014/speakers/john-gustafson/ There

Re: dmd codegen improvements

On 23/08/15 22:12, Walter Bright wrote: On 8/23/2015 11:42 AM, deadalnix wrote: No, x32 is basically amd64 with 32 bits pointers. You can use all other functions of amd64, like the extended number of registers. Makes sense. At least right now, it sounds more useful than it actually is.

Re: Go, D, and the GC

On 04/10/15 19:14, welkam wrote: On Sunday, 4 October 2015 at 12:40:00 UTC, rsw0x wrote: these tools are not very good and they don't help when the standard library(...or builtin language features...) use the GC and tie your hands IMO tools for memory management in D are way better than that

Re: Go, D, and the GC

On 05/10/15 10:01, Dmitry Olshansky wrote: When D structs has a destructor that is guaranteed to run for any instance that finished construction, no matter what is the use case, then we can have that discussion. Supposed to be the case for structs except for any bugs. Check this one out

Re: Go, D, and the GC

On 05/10/15 10:40, deadalnix wrote: Guaranteed construct/destruction is actually a desirable feature IMO. You get all kind of extra case int he dtor to care for when you can't ensure proper construction, and it is not always possible to have a meaningful .init value, leading to many useless

Re: Go, D, and the GC

On 05/10/15 10:49, Dmitry Olshansky wrote: Yes and no, if your type is movable in C++ you have to have a T.init equivalent to leave something behind after move (oops!). No, under C++ you can choose whether it makes sense for your type to be movable or not. No oops at all. C++ does not make

Re: Go, D, and the GC

On 05/10/15 13:39, Marc Schütz wrote: On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh wrote: What's more, init is used even if you @disable this(). The following compile and does what you'd expect (but not what you want): struct S { int d; @disable this(); this( int d ) {

Re: Andrei's list of barriers to D adoption

On 06/06/16 07:17, Adam D. Ruppe wrote: On Monday, 6 June 2016 at 02:30:55 UTC, Pie? wrote: Duh! The claim is made that D can work without the GC... but that's a red herring... If you take about the GC what do you have? Like 90% of the language, still generally nicer than most the

Re: Andrei's list of barriers to D adoption

On 06/06/16 07:38, Jack Stouffer wrote: I never understood the large amount of people on /r/programming complaining about the GC when the vast majority of software is written in one of the following languages: C#, Java, PHP, Python, JavaScript. With the *possible* exception of C#, none of

Re: Andrei's list of barriers to D adoption

On 06/06/16 10:02, Jack Stouffer wrote: On Monday, 6 June 2016 at 06:32:15 UTC, Andrei Alexandrescu wrote: These are only a part of our competition. -- Andrei Sure, I was just remarking on the fact that the amount of complaining about GCs is disproportionate to the number of people not using

Re: Parsing D Maybe Not Such a Good Idea <_<;

On 15/06/16 08:27, H. S. Teoh via Digitalmars-d wrote: IMHO, you're thinking about this at the wrong level of abstraction. I tend to agree. The first order of business, before you even think about parsing, should be to tokenize (or lex) the input. This is the stage where you break up the

inout and opApply

Please consider the following program: struct V(T) { int opApply(scope int delegate(ref T value) dg) { return 0; } int opApply(scope int delegate(ref const T value) dg) const { return 0; } } struct V1(T) { int opApply(scope int delegate(ref inout T value) dg)

Re: inout and opApply

On 24/06/16 01:22, Steven Schveighoffer wrote: Considering the possible use cases for something like this, I think we are better off having this limitation than not being able to use opApply with inout. -Steve I am not sure I followed the discussion correctly. If I did, however, it seems to

Re: Should % ever "overflow"?

What deadalnix (how did you choose a nickname that is more difficult to write than your given name anyway?) said was that the definition of % only makes sense if, for every n and every m: (n/m)+(n%m)=n What this means is that, if n/m is rounded up for negative numbers, n%m must be negative.

D's equivalent to C++'s std::move?

Hi all, I have a non-copyable struct with move semantics. In other words, a struct with @disable this(this), but with working overloads for the this(copy) and opAssign. Now I have an instance of that struct. I would like to be able to voluntarily give up ownership for the sake of another

Re: This feels wrong

On 02/02/16 21:24, Ali Çehreli wrote: On 02/02/2016 07:21 AM, Shachar Shemesh wrote: > it is a potential pitfall when implementing that I don't think is > documented. Good catch! Please either open a documentation bug for this or fork the repo and fix it yourself. :) (Hopefully, there is an

Re: This feels wrong

On 02/02/16 17:00, Steven Schveighoffer wrote: Just put try around the opApply specific parts you want to monitor. Don't guard the call to dg. The call to dg is, obviously, part of a loop. That whole loop body is inside a try/catch. What I ended up doing, instead, was to put a flag, and the

This feels wrong

Please consider the following program: import std.stdio; struct A { int opApply( scope int delegate(int) dg ) { foreach(int i; 0 .. 50) { try { int res = dg(i); if( res!=0 ) { writefln("Delegate returned %s", res);

Re: C++17

On 26/01/16 11:33, deadalnix wrote: On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim Grøstad wrote: Would it be possible to make a fully compatible unique_ptr/shared_ptr solution that acts as the default memory management scheme in D within 6 months? Now if one want to use that, D is

Re: C++17

On 27/01/16 16:24, Minas Mina wrote: On Wednesday, 27 January 2016 at 14:22:18 UTC, Shachar Shemesh wrote: On 26/01/16 11:33, deadalnix wrote: On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim Grøstad wrote: [...] Now if one want to use that, D is very capable of doing it already.

Re: Head Const

On 16/02/16 12:31, Guillaume Piolat wrote: I'm trying to say it politely. D2 const story is more complicated than its competitors. Both D1 "final" and C++ const always felt more useful and practical to me that the whole D2 immutable/const/inout thing. The current scheme seems to have marginal

Re: Head Const

On 17/02/16 14:03, Jakob Ovrum wrote: On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head const will do for us: 1. make it easy

Re: Why is this not a warning?

On 16/03/16 23:50, tsbockman wrote: On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh wrote: ... People who are marginally familiar with integer promotion will not be surprised to know that the program prints "256". What is surprising to me is that this produced neither error nor

Why is this not a warning?

Please consider the following program, which is a reduced version of a problem I've spent the entire of today trying to debug: import std.stdio; void main() { enum ulong MAX_VAL = 256; long value = -500; if( value>MAX_VAL ) value = MAX_VAL; writeln(value); } People

Re: Mindset of the D team vs the Rust team

On 29/03/16 07:36, Walter Bright wrote: On 3/28/2016 8:00 PM, Nick Sabalausky wrote: We have better things to deal with than endless Fire and Motion: http://www.joelonsoftware.com/articles/fog000339.html It's 7:40am here, and I just got to work. I stopped reading half way through,

Re: A very interesting slide deck comparing sync and async IO

On 03/03/16 19:31, Andrei Alexandrescu wrote: https://www.mailinator.com/tymaPaulMultithreaded.pdf Andrei You just stepped on a pet peeve of mine. NIO isn't async IO. It's non-blocking IO. Many people (including Microsoft's MSDN) confuse the two, but they are completely and utterly

Re: A very interesting slide deck comparing sync and async IO

On 05/03/16 20:50, Sean Kelly wrote: On Friday, 4 March 2016 at 06:55:29 UTC, Shachar Shemesh wrote: On 03/03/16 19:31, Andrei Alexandrescu wrote: https://www.mailinator.com/tymaPaulMultithreaded.pdf On a completely different note, me and a colleague started a proof of concept to disprove

Re: A very interesting slide deck comparing sync and async IO

For switching between threads, this seems wrong. On 04/03/16 20:29, deadalnix wrote: The minimal cost of a context switch is one TLB miss (~300), one cache miss (~300) Why do you claim the first two? Again, assuming threads of the same process, where the address space (minus the TLS) is the

Re: Checking if an Integer is an Exact Binary Power

On 23/04/16 16:04, Nordlöw wrote: Wanted: CT-trait and run-time predicate for checking whether its single integer parameter is an exact power of two. I guess https://dlang.org/phobos/std_math.html#.truncPow2 or https://dlang.org/phobos/std_math.html#.nextPow2 could be reused, but I bet

Re: So, to print or not to print?

On 26/04/16 07:54, rikki cattermole wrote: On 26/04/2016 8:41 AM, Brad Roberts via Digitalmars-d wrote: Something that's been bouncing around in the back of my head for a while. I can't decide if it's a good idea or a really bad one. Consider a series of small modules that are essentially

scope(exit) and scope(failure) on Errors

There is a problem with scope(exit) and scope(failure) running when Error types exceptions are thrown. It throws the program into code paths that are really not healthy. Imagine, for example, code handling linked lists. We do manipulations on linked lists, and put a scope(exit) that clears

Re: [OT] Swift removing minor features to piss me off

On 29/04/16 04:36, Walter Bright wrote: On 4/28/2016 2:32 PM, Daniel Kozak via Digitalmars-d wrote: Wierd, I am almost sure it does not work for me last time when I tried :) That's because in dmd there's the line: if (strcmp(user, "Daniel") == 0) setScoping(false); It's a feature!

Re: Walter's Famous German Language Essentials Guide

On 28/04/16 09:43, Iain Buclaw via Digitalmars-d wrote: Ha! There is no logical at all behind whether a word is masculine, feminine or neutral in German. In Hebrew, there is no such thing as a neutral noun, (though there are nouns that can be either male of female). When you go from one

Re: Overflows in Phobos

On 27/07/16 00:56, Walter Bright wrote: What the assert(0) actually does is insert a HALT instruction, even when -release is used. The spec is poorly worded. Does that mean D isn't meant to be used to develop code that will run in Ring-0? Or do we treat it as a feature that kernel mode

Re: Overflows in Phobos

On 27/07/16 08:03, deadalnix wrote: On Wednesday, 27 July 2016 at 03:31:07 UTC, Adam D. Ruppe wrote: On Wednesday, 27 July 2016 at 03:13:38 UTC, Shachar Shemesh wrote: Does that mean D isn't meant to be used to develop code that will run in Ring-0? assert(0) is never supposed to actually

Re: Overflows in Phobos

On 27/07/16 08:50, Walter Bright wrote: On 7/26/2016 10:24 PM, Shachar Shemesh wrote: Most D programmers, however, expect the program not to continue executing past an assert(false). They might see it as a bug. Hence my question whether that means D is not meant for programming in privileged

Re: Overflows in Phobos

On 27/07/16 10:14, Walter Bright wrote: Thank you. I'd prefer it to say something along the lines that it stops execution at the assert(0) in an implementation-defined manner. This leaves whether messages are printed or not, etc., up to the implementation. I don't think the spec should require

Re: Vision for the D language - stabilizing complexity?

On 12/07/16 08:33, Andrei Alexandrescu wrote: On 07/12/2016 01:15 AM, Shachar Shemesh wrote: The topic was reference counting's interaction with immutable (see deadalnix's comment, to which I completely agree, about inter-features interactions). Amaury failed to produce an example to support

Re: UB in D

On 10/07/16 02:44, H. S. Teoh via Digitalmars-d wrote: I find this rather disturbing, actually. There is a fine line between taking advantage of assert's to elide stuff that the programmer promises will not happen, and eliding something that's defined to be UB and thereby resulting in memory

Re: asd

On 25/07/16 12:10, ahahah wrote: haro And people say chivalry has disappeared from the world

Re: Why D is not popular enough?

On 14/08/16 03:26, Andrei Alexandrescu wrote: On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote: I'm also tempted to argue that making shared virtually unusable without casting it away would be a good idea It's a bad idea, no two ways about it. The bummer here is that this is

Re: Why D is not popular enough?

On 14/08/16 17:07, Andrei Alexandrescu wrote: > On 08/14/2016 01:18 AM, Shachar Shemesh wrote: >>> So that is slide 4. Could you please give a bit of detail? >> >> http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html >> > > OK. One thing we can't stress enough is

Re: Why D is not popular enough?

On 14/08/16 21:35, Andrei Alexandrescu wrote: I should add that as long as the .di does not import the .d, the slowdown due to the computed table will not occur. So the worry is not warranted. I'm not sure the above is true in cases of imports that are not circular for the optimal dis, but

Re: Why D is not popular enough?

On 12/08/16 12:38, Guillaume Piolat wrote: From the best of my knowledge you cannot do these things in in C++: https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through-CTFE I maintain an open source program called fakeroot-ng. It is written in C++. Just today, while doing

Re: Why D is not popular enough?

On 11/08/16 18:41, Edward Diener wrote: 2) While I greatly respect the programming abilities of Mr. Bright and Mr. Alexandrescu and their hard work in creating and improving D, having followed both from the C++ world, the arrogance by which D was initially and repeatedly compared against C/C++

Re: Why D is not popular enough?

On 12/08/16 22:55, Walter Bright wrote: > > I'm surprised that I've never seen anyone else use such a technique. > It's so unusual I've seen it be unrepresentable in some 'make' > replacements. > > I suppose it's like unittest and ddoc. Sure, you can do it with some > contortions and/or some

  1   2   3   4   >