Re: __TIMESTAMP_UNIXEPOCH__ instead of useless __TIMESTAMP__?

On Wednesday, January 24, 2018 18:25:21 Timothee Cour via Digitalmars-d wrote: > On Wed, Jan 24, 2018 at 5:50 PM, rikki cattermole via Digitalmars-d > > wrote: > > On 24/01/2018 7:18 PM, Timothee Cour wrote: > >> __TIMESTAMP__ is pretty useless: > >> `string literal

Re: The most confusing error message

On Wednesday, January 24, 2018 14:22:59 Meta via Digitalmars-d wrote: > IMO the error message is not too bad once you understand what's > going on (which probably means it's really not a good error > message). It's not that uncommon for me to see a question in D.Learn where someone is asking a

Re: Shouldn't invalid references like this fail at compile time?

On Wednesday, January 24, 2018 18:46:38 Walter Bright via Digitalmars-d wrote: > On 1/23/2018 7:22 PM, Jonathan M Davis wrote: > > We need to do that anyway for the overly large > > objects (and unfortunately don't last I heard). > > I put a limit in at one time for struct/class sizes to prevent

Re: Shouldn't invalid references like this fail at compile time?

On 1/24/2018 9:04 PM, Mike Franklin wrote: On Thursday, 25 January 2018 at 04:59:55 UTC, Mike Franklin wrote: Yes, ROM is at address 0.  Address 0 contains the initial stack pointer.  So you read address 0, dereference it, and then do your damage. This is from the "what were they thinking"

Re: Shouldn't invalid references like this fail at compile time?

On Thursday, 25 January 2018 at 04:59:55 UTC, Mike Franklin wrote: Yes, ROM is at address 0. Address 0 contains the initial stack pointer. So you read address 0, dereference it, and then do your damage. Keep in mind too that the ROM, on these devices, is actually reprogrammable from the

Re: Shouldn't invalid references like this fail at compile time?

On Thursday, 25 January 2018 at 04:45:34 UTC, Walter Bright wrote: This implies a ROM must be located there. Else how do initial values get there? Yes, ROM is at address 0. Address 0 contains the initial stack pointer. So you read address 0, dereference it, and then do your damage. Mike

Re: Shouldn't invalid references like this fail at compile time?

On Thursday, 25 January 2018 at 04:45:34 UTC, Walter Bright wrote: This implies a ROM must be located there. Else how do initial values get there? I'm not sure what you mean. When you upload your firmware to the MCU, it writes the initial stack pointer to address 0x00 and the address of

Re: Shouldn't invalid references like this fail at compile time?

On 1/24/2018 8:31 PM, Mike Franklin wrote: On Thursday, 25 January 2018 at 04:01:47 UTC, Mike Franklin wrote: "The initial stack pointer and the address of the reset handler must be located at 0x0 and 0x4 respectively."

[Issue 16510] Request: RSA digital signature validation in phobos

https://issues.dlang.org/show_bug.cgi?id=16510 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net ---

Re: Shouldn't invalid references like this fail at compile time?

On Thursday, 25 January 2018 at 04:01:47 UTC, Mike Franklin wrote: "The initial stack pointer and the address of the reset handler must be located at 0x0 and 0x4 respectively." (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/CHDBIJJE.html) Sorry! Wrong link. Try this

The Eve programming language project is winding down

https://news.ycombinator.com/item?id=16227130

Re: Shouldn't invalid references like this fail at compile time?

On Thursday, 25 January 2018 at 02:41:53 UTC, Walter Bright wrote: Ok, but are these devices with 0 being a valid address? It seems weird to me that any sane modern CPU design that can access megabytes of memory would have 0 be a valid address. Yes, 0 is a valid address and typically

Re: Shouldn't invalid references like this fail at compile time?

On 1/23/2018 7:22 PM, Jonathan M Davis wrote: We need to do that anyway for the overly large objects (and unfortunately don't last I heard). I put a limit in at one time for struct/class sizes to prevent this issue, but got a lot of pushback on it and it was reverted. Perhaps we can revisit

Re: Shouldn't invalid references like this fail at compile time?

On 1/23/2018 6:28 PM, Mike Franklin wrote: I think you need to get involved in programming microcontrollers again because the landscape has changed drastically.  The microcontrollers I use now are more powerful than PCs of the 90's. Ok, but are these devices with 0 being a valid address? It

Re: __TIMESTAMP_UNIXEPOCH__ instead of useless __TIMESTAMP__?

On Wed, Jan 24, 2018 at 5:50 PM, rikki cattermole via Digitalmars-d wrote: > On 24/01/2018 7:18 PM, Timothee Cour wrote: >> >> __TIMESTAMP__ is pretty useless: >> `string literal of the date and time of compilation "www mmm dd hh:mm:ss >> "` >> eg:Wed Jan 24

Re: Class instance memory overhead lower than 3 words?

On Wednesday, January 24, 2018 17:50:35 Ali Çehreli via Digitalmars-d-learn wrote: > On 01/24/2018 05:43 PM, Jonathan M Davis wrote: > > On Thursday, January 25, 2018 00:10:32 Nicholas Wilson via > > Digitalmars-d- > > > > learn wrote: > >> One pointer for the vtbl, one for the monitor, not sure

Re: __TIMESTAMP_UNIXEPOCH__ instead of useless __TIMESTAMP__?

On 24/01/2018 7:18 PM, Timothee Cour wrote: __TIMESTAMP__ is pretty useless: `string literal of the date and time of compilation "www mmm dd hh:mm:ss "` eg:Wed Jan 24 11:03:56 2018 which is a weird non-standard format not understood by std.datetime. __DATE__ and __TIME__ are also pretty

Re: Class instance memory overhead lower than 3 words?

On 01/24/2018 05:43 PM, Jonathan M Davis wrote: On Thursday, January 25, 2018 00:10:32 Nicholas Wilson via Digitalmars-d- learn wrote: One pointer for the vtbl, one for the monitor, not sure what the other one is. The TypeInfo maybe? I'm not sure where that lives. - Jonathan M Davis

Re: Class instance memory overhead lower than 3 words?

On Thursday, January 25, 2018 00:10:32 Nicholas Wilson via Digitalmars-d- learn wrote: > One pointer for the vtbl, one for the monitor, not sure what the > other one is. The TypeInfo maybe? I'm not sure where that lives. - Jonathan M Davis

Re: The most confusing error message

On Wednesday, January 24, 2018 16:21:39 Nick Treleaven via Digitalmars-d wrote: > On Wednesday, 24 January 2018 at 14:22:59 UTC, Meta wrote: > > One way we could probably improve the error message is to > > change it to "template struct test.A(int var = 3) is used as a > > type. It must be

[Issue 18294] std.path.dirName needs better documentation

https://issues.dlang.org/show_bug.cgi?id=18294 Jonathan M Davis changed: What|Removed |Added CC|

Re: Channeling memory model experts...

On Wednesday, 24 January 2018 at 18:37:54 UTC, Andrei Alexandrescu wrote: ... to review https://github.com/dlang/druntime/pull/2057/. Thanks! -- Andrei This isn't really about the memory model is it ? I'd like to see a description of what that change is supposed a achieve. On the first glance

Re: Class instance memory overhead lower than 3 words?

On Wednesday, 24 January 2018 at 22:27:40 UTC, Nordlöw wrote: On Wednesday, 24 January 2018 at 21:47:26 UTC, H. S. Teoh wrote: On Wed, Jan 24, 2018 at 09:48:21PM +, Nordlöw via Digitalmars-d-learn wrote: Why is the memory overhead for a class instance as high as 3 words (24 bytes on 64-bit

Re: Class instance memory overhead lower than 3 words?

On Wednesday, 24 January 2018 at 21:48:21 UTC, Nordlöw wrote: Why is the memory overhead for a class instance as high as 3 words (24 bytes on 64-bit systems? I find that annoyingly much for my knowledge database application. I'm aware of extern(C++), having one word overhead, but such

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 14:55:39 UTC, Simen Kjærås wrote: auto map(alias fn, R)(R r) if (isInputRange!(HeadMutable!R)) { // Pass head-mutable versions to MapResult. return MapResult!(fn, HeadMutable!R)(headMutable(r)); } Another thing that I didn't think of when writing the

[Issue 18296] [Reg2.078.1] invalid code with coverage and copy construction

https://issues.dlang.org/show_bug.cgi?id=18296 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/2d45fcbbd7a734bb6ecf8ba3d60897e8fefc4d44 use more specific workaround for Issue 18296 --

Re: Shouldn't invalid references like this fail at compile time?

On Wednesday, January 24, 2018 21:24:16 Seb via Digitalmars-d wrote: > On Wednesday, 24 January 2018 at 19:12:50 UTC, Steven > > Schveighoffer wrote: > > While I understand your argument, the truth is that avoiding > > null dereferencing *statically* has to be built into the > > language from the

Re: Class instance memory overhead lower than 3 words?

On Wednesday, 24 January 2018 at 21:47:26 UTC, H. S. Teoh wrote: On Wed, Jan 24, 2018 at 09:48:21PM +, Nordlöw via Digitalmars-d-learn wrote: Why is the memory overhead for a class instance as high as 3 words (24 bytes on 64-bit systems? I find that annoyingly much for my knowledge

Re: Channeling memory model experts...

On Wednesday, 24 January 2018 at 18:37:54 UTC, Andrei Alexandrescu wrote: ... to review https://github.com/dlang/druntime/pull/2057/. Thanks! -- Andrei Which memory model would that be? D's?

Re: Class instance memory overhead lower than 3 words?

On Wed, Jan 24, 2018 at 09:48:21PM +, Nordlöw via Digitalmars-d-learn wrote: > Why is the memory overhead for a class instance as high as 3 words (24 > bytes on 64-bit systems? I find that annoyingly much for my knowledge > database application. [...] There's been an attempt to get rid of the

[Issue 18267] Linker errors compiling std_data_json dub package with dmd 2.078.0

https://issues.dlang.org/show_bug.cgi?id=18267 John Colvin changed: What|Removed |Added CC|

Class instance memory overhead lower than 3 words?

Why is the memory overhead for a class instance as high as 3 words (24 bytes on 64-bit systems? I find that annoyingly much for my knowledge database application. I'm aware of extern(C++), having one word overhead, but such extern(C++)-classes cannot use all of D; I get compilation errors such

Re: [dlang library documentation] Why there are dlang.org/library and dlang.org/phobos?

On Tuesday, 23 January 2018 at 19:05:21 UTC, Seb wrote: On Monday, 22 January 2018 at 19:38:45 UTC, John Gabriele wrote: On Monday, 22 January 2018 at 15:32:29 UTC, Adam D. Ruppe wrote: On Monday, 22 January 2018 at 15:18:38 UTC, Johann wrote: Maybe it's due to historical reasons. It's

[Issue 18296] [Reg2.078.1] invalid code with coverage and copy construction

https://issues.dlang.org/show_bug.cgi?id=18296 Seb changed: What|Removed |Added CC||greensunn...@gmail.com ---

[Issue 18296] [Reg2.078.1] invalid code with coverage and copy construction

https://issues.dlang.org/show_bug.cgi?id=18296 --- Comment #1 from Martin Nowak --- Only occurs with PIC enabled, guess this happens as a result of https://github.com/dlang/dmd/pull/7654 whereby coverage symbols no longer have local linkage. --

[Issue 14767] Support CTFE of BigInt under x86

https://issues.dlang.org/show_bug.cgi?id=14767 --- Comment #8 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/f2c5ee3bf17707ea16c2d7c269b3537a46d11032 fix issue 14767 - Support CTFE of BigInt under x86

[Issue 14767] Support CTFE of BigInt under x86

https://issues.dlang.org/show_bug.cgi?id=14767 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 18296] New: [Reg2.078.1] invalid code with coverage and copy construction

https://issues.dlang.org/show_bug.cgi?id=18296 Issue ID: 18296 Summary: [Reg2.078.1] invalid code with coverage and copy construction Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW

Re: Shouldn't invalid references like this fail at compile time?

On Wednesday, 24 January 2018 at 19:12:50 UTC, Steven Schveighoffer wrote: While I understand your argument, the truth is that avoiding null dereferencing *statically* has to be built into the language from the beginning. As D is already too far along to retrofit this, your 2 options are: a)

[Issue 18295] [Scope][dip1000] `scope class` check too conservative under -dip1000

https://issues.dlang.org/show_bug.cgi?id=18295 Mike Franklin changed: What|Removed |Added Keywords||pull, rejects-valid --

[Issue 18295] [Scope][dip1000] `scope class` check too conservative under -dip1000

https://issues.dlang.org/show_bug.cgi?id=18295 --- Comment #1 from Mike Franklin --- Potential Fix: https://github.com/dlang/dmd/pull/7771 --

[Issue 18295] New: [Scope][dip1000] `scope class` check too conservative under -dip1000

https://issues.dlang.org/show_bug.cgi?id=18295 Issue ID: 18295 Summary: [Scope][dip1000] `scope class` check too conservative under -dip1000 Product: D Version: D2 Hardware: All OS: All Status:

Re: Release D 2.078.1

On Wednesday, 24 January 2018 at 20:05:42 UTC, Martin Nowak wrote: On Wednesday, 24 January 2018 at 13:30:42 UTC, Radu wrote: Just want to bring to your attention a major regression introduced in 2.078, and still present on current master, re. the new __equals template.

[Issue 18294] New: std.path.dirName needs better documentation

https://issues.dlang.org/show_bug.cgi?id=18294 Issue ID: 18294 Summary: std.path.dirName needs better documentation Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: trivial

Re: Release D 2.078.1

On Wednesday, 24 January 2018 at 13:30:42 UTC, Radu wrote: Just want to bring to your attention a major regression introduced in 2.078, and still present on current master, re. the new __equals template. https://issues.dlang.org/show_bug.cgi?id=18252 Comparing arrays of associative arrays is

[Issue 18269] Inconsistent string representation of delegate @system attribute

https://issues.dlang.org/show_bug.cgi?id=18269 --- Comment #2 from hst...@quickfur.ath.cx --- Reduced further: --- void one(T)(T t, size_t ln = 0) { pragma(msg, "one: ", T.stringof); two(t); } void two(T)(T t) { pragma(msg, "two: ", T.stringof); } alias T = void delegate();

[Issue 18252] [Reg 2.078] comparison of arrays of associative arrays no longer compiles

https://issues.dlang.org/show_bug.cgi?id=18252 Martin Nowak changed: What|Removed |Added Keywords||pull --- Comment #4 from

[Issue 18252] [Reg 2.078] comparison of arrays of associative arrays no longer compiles

https://issues.dlang.org/show_bug.cgi?id=18252 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu

Re: D at Netflix

On Tuesday, 11 April 2017 at 20:41:47 UTC, Vasudev Ram wrote: On the reddit or Hacker News thread (congratulations on getting approval from Symantec - v exciting) there was a guy from Netflix who said he was using D there, I think for data science. That person may be referring to VectorFlow,

__TIMESTAMP_UNIXEPOCH__ instead of useless __TIMESTAMP__?

__TIMESTAMP__ is pretty useless: `string literal of the date and time of compilation "www mmm dd hh:mm:ss "` eg:Wed Jan 24 11:03:56 2018 which is a weird non-standard format not understood by std.datetime. __DATE__ and __TIME__ are also pretty useless. Could we have __TIMESTAMP_UNIXEPOCH__

Re: Shouldn't invalid references like this fail at compile time?

On 1/23/18 9:28 PM, Mike Franklin wrote: On Wednesday, 24 January 2018 at 01:44:51 UTC, Walter Bright wrote: Microcontroller code tends to be small and so it's unlikely that you'll need to worry about it. I think you need to get involved in programming microcontrollers again because the

[Issue 18293] bugzilla search does not work (misses word that's right there in issue title)

https://issues.dlang.org/show_bug.cgi?id=18293 ag0ae...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Issue 18293] New: bugzilla search does not work (misses word that's right there in issue title)

https://issues.dlang.org/show_bug.cgi?id=18293 Issue ID: 18293 Summary: bugzilla search does not work (misses word that's right there in issue title) Product: D Version: D2 Hardware: All OS: Mac OS X

Channeling memory model experts...

... to review https://github.com/dlang/druntime/pull/2057/. Thanks! -- Andrei

Re: The most confusing error message

On 01/24/2018 05:36 AM, Jonathan M Davis wrote: > It's probably > a result of whatever code generating the error message being shared between > explicit templates and other sorts of templates where the template keyword > isn't used, and it doesn't handle the non-explicit templates very well.

[Issue 18280] std.algorithm.comparison.cmp for non-strings should call opCmp only once per item pair

https://issues.dlang.org/show_bug.cgi?id=18280 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 18280] std.algorithm.comparison.cmp for non-strings should call opCmp only once per item pair

https://issues.dlang.org/show_bug.cgi?id=18280 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/7f59e5ad526ee4bf856e8235e3042bb5cd442ad4 Fix Issue 18280 - std.algorithm.comparison.cmp for

[Issue 18292] New: Version=GC shouldn't segfault

https://issues.dlang.org/show_bug.cgi?id=18292 Issue ID: 18292 Summary: Version=GC shouldn't segfault Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1

Re: getting member functions of a struct and Error: identifier expected following ., not this

On Wednesday, 24 January 2018 at 07:55:01 UTC, thedeemon wrote: On Tuesday, 23 January 2018 at 00:00:38 UTC, aliak wrote: [...] The struct defined inside a scope can mention variables defined in that scope (e.g. use them in its methods), so it needs a pointer to the place where those closed

[Issue 18252] no property 'tupleof' for type 'string[int]'

https://issues.dlang.org/show_bug.cgi?id=18252 Jack Stouffer changed: What|Removed |Added CC||j...@jackstouffer.com

Re: The most confusing error message

On Wednesday, 24 January 2018 at 14:22:59 UTC, Meta wrote: One way we could probably improve the error message is to change it to "template struct test.A(int var = 3) is used as a type. It must be instantiated", or something along those lines, to make it clear why you can't use A as a type.

[Issue 10128] import statement in base class members should be private by default

https://issues.dlang.org/show_bug.cgi?id=10128 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 16057] [TDPL] synchronized (a, b) compiles and runs with wrong semantics

https://issues.dlang.org/show_bug.cgi?id=16057 yebblies changed: What|Removed |Added CC||simen.kja...@gmail.com ---

[Issue 18277] synchronized statement with comma operator ignores first arguments

https://issues.dlang.org/show_bug.cgi?id=18277 yebblies changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Issue 18252] no property 'tupleof' for type 'string[int]'

https://issues.dlang.org/show_bug.cgi?id=18252 Seb changed: What|Removed |Added CC||greensunn...@gmail.com ---

Re: `Alias this` to a mixed in property

On Wednesday, 24 January 2018 at 14:21:42 UTC, ag0aep6g wrote: The spec says that you cannot make an overload set just by mixing in multiple functions/methods with the same name. Instead, you have to do it like this: mixin getter g; mixin setter!int s; alias p = g.p; alias p = s.p;

Re: How does rt_finalized function work exactly? (Fixing bugs regarding Destroy).

On Friday, 19 January 2018 at 20:21:44 UTC, Steven Schveighoffer wrote: On 1/19/18 2:48 PM, 12345swordy wrote: [...] Here are the improvements that Lucia is doing/has done, which is a lot of good stuff: [...] I found out that this fix does require a DIP. (Thanks Walker!)

Re: The most confusing error message

On Wednesday, 24 January 2018 at 07:21:09 UTC, Shachar Shemesh wrote: test.d(6): Error: struct test.A(int var = 3) is used as a type Of course it is. That's how structs are used. Program causing this: struct A(int var = 3) { int a; } void main() { A a; } To resolve, you need to

Re: `Alias this` to a mixed in property

On 01/24/2018 02:24 PM, Bastiaan Veelo wrote: `Alias this` to mixed in properties does not seem to work, see below. If you think it should, I'll file an issue. Otherwise: can this be made to work somehow? Not supposed to work as it is. The spec says that you cannot make an overload set just

Re: The most confusing error message

On Wednesday, January 24, 2018 15:15:30 Shachar Shemesh via Digitalmars-d wrote: > On 24/01/18 10:01, Jonathan M Davis wrote: > > On Wednesday, January 24, 2018 09:21:09 Shachar Shemesh via > > Digitalmars-d > > > > wrote: > >> test.d(6): Error: struct test.A(int var = 3) is used as a type > >> >

`Alias this` to a mixed in property

Hi, `Alias this` to mixed in properties does not seem to work, see below. If you think it should, I'll file an issue. Otherwise: can this be made to work somehow? Interestingly, if you uncomment either the mixin getter or setter (row 36 or 37) and its corresponding use in `main`, then the

Re: The most confusing error message

On 24/01/18 10:01, Jonathan M Davis wrote: On Wednesday, January 24, 2018 09:21:09 Shachar Shemesh via Digitalmars-d wrote: test.d(6): Error: struct test.A(int var = 3) is used as a type Of course it is. That's how structs are used. Program causing this: struct A(int var = 3) { int a; }

[Issue 18252] no property 'tupleof' for type 'string[int]'

https://issues.dlang.org/show_bug.cgi?id=18252 Radu changed: What|Removed |Added Component|phobos |druntime --

[Issue 18252] no property 'tupleof' for type 'string[int]'

https://issues.dlang.org/show_bug.cgi?id=18252 --- Comment #1 from Radu --- This is a regression introduced in 2.078 --

[Issue 18252] no property 'tupleof' for type 'string[int]'

https://issues.dlang.org/show_bug.cgi?id=18252 Radu changed: What|Removed |Added CC||radu.raca...@gmail.com

[Issue 18291] New: getcwd is deprecated for Windows - the ISO C++ conformant _getcwd should be used instead

https://issues.dlang.org/show_bug.cgi?id=18291 Issue ID: 18291 Summary: getcwd is deprecated for Windows - the ISO C++ conformant _getcwd should be used instead Product: D Version: D2 Hardware: All OS:

Re: Implementing tail-const in D

On Wednesday, 24 January 2018 at 11:21:59 UTC, Nick Treleaven wrote: On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Unqual is the standard way today to get a head-mutable version of something. For dynamic arrays, static arrays, pointers and value types, including structs

[Issue 18014] DMD test suite fails to link on Linux distros where PIC/PIE is enforced

https://issues.dlang.org/show_bug.cgi?id=18014 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/252ab44d00f3427d6ed35d7823cd0844ba5f909a Allow to run the DMD testsuite on hardened systems (#7420) *

[Issue 14147] Compiler crash on identical functions in a single module

https://issues.dlang.org/show_bug.cgi?id=14147 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/ab47b8b0cf18d14c1ffbc97df6c8fb299971170a Issue 14147 - Compiler crash on identical functions in a

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Unqual is the standard way today to get a head-mutable version of something. For dynamic arrays, static arrays, pointers and value types, including structs without aliasing, thi works. For AAs, classes, and structs with aliasing,

[Issue 18281] Compiler rejects safe code in @safe

https://issues.dlang.org/show_bug.cgi?id=18281 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org

Re: Shouldn't invalid references like this fail at compile time?

On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote: The last memory corruption issue we had in non-critcal was 4yrs ago, in older C++ code. Memory corruption really is becoming a thing of the past in modern C++. If you write everything from scratch with safety-oriented design?

Re: Shouldn't invalid references like this fail at compile time?

On Wednesday, 24 January 2018 at 04:15:27 UTC, Mike Franklin wrote: On Wednesday, 24 January 2018 at 03:46:41 UTC, lobo wrote: Well if your embedded device has all that on it you should be sitting on an OS with proper memory management support. I don't see how the OS can help if the

Re: wut: std.datetime.systime.Clock.currStdTime is offset from Jan 1st, 1 AD

On Wednesday, 24 January 2018 at 08:12:55 UTC, Jonathan M Davis wrote: Thanks. I did it because I was sick of time-related bugs at work, and I wanted the language I wanted D to get it right. By no means do I claim that std.datetime is perfect, but IMHO, it's way better than what most languages

Re: Implementing tail-const in D

On 2018-01-24 00:10, sarn wrote: Have you seen Rebindable in Phobos?  I know it's not the same thing as what you're talking about, but it's relevant. https://dlang.org/library/std/typecons/rebindable.html I'm pretty sure he has since it's use in the implementation [1] ;) [1]

[Issue 16037] assigning delegate to a scope variable shouldn't allocate closure

https://issues.dlang.org/show_bug.cgi?id=16037 anonymous4 changed: What|Removed |Added Keywords||safe --

[Issue 16037] assigning delegate to a scope variable shouldn't allocate closure

https://issues.dlang.org/show_bug.cgi?id=16037 anonymous4 changed: What|Removed |Added Keywords|safe|performance

Re: wut: std.datetime.systime.Clock.currStdTime is offset from Jan 1st, 1 AD

On Wednesday, January 24, 2018 10:50:55 drug via Digitalmars-d wrote: > 24.01.2018 10:25, Jonathan M Davis пишет: > > If you need to interact with time_t, there's SysTime.toUnixTime, > > SysTime.fromUnixTime, stdTimeToUnixTime, and unixTimeToStdTime - > > assuming of course that time_t is unix

Re: The most confusing error message

On Wednesday, January 24, 2018 09:21:09 Shachar Shemesh via Digitalmars-d wrote: > test.d(6): Error: struct test.A(int var = 3) is used as a type > > Of course it is. That's how structs are used. > > Program causing this: > struct A(int var = 3) { > int a; > } > > void main() { > A a; >