Re: is my code to get CTFE instantiated object valid D ?

On Friday, 27 May 2016 at 21:41:02 UTC, Kagamin wrote: On Friday, 27 May 2016 at 20:20:36 UTC, chmike wrote: Is this code valid D or is the behavior undefined due to the cast ? A mutable object can be synchronized on: synchronized(Category.instance){} This will create and store a mutex in the

Re: Our Sister

On Saturday, 28 May 2016 at 04:31:22 UTC, Manu wrote: On 27 May 2016 at 02:11, Andrei Alexandrescu via Digitalmars-d wrote: I've been working on RCStr (endearingly pronounced "Our Sister"), Ah, I totally skipped over this thread... Wow... this really doesn't

Re: Our Sister

On 27 May 2016 at 02:11, Andrei Alexandrescu via Digitalmars-d wrote: > I've been working on RCStr (endearingly pronounced "Our Sister"), Ah, I totally skipped over this thread... Wow... this really doesn't work in any accent I'm close to, but I can hear it if I

Re: Our Sister

On 27 May 2016 at 23:32, Andrei Alexandrescu via Digitalmars-d wrote: > On 5/27/16 7:07 AM, Marc Schütz wrote: >> >> On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote: >>> >>> RFC: what primitives should RCStr have? >> >> >> It should _safely_

Re: Our Sister

On 28 May 2016 at 10:16, Adam D. Ruppe via Digitalmars-d wrote: > On Friday, 27 May 2016 at 21:51:59 UTC, Seb wrote: >> >> not if [] would be ref-counted too ;-) > > > That would be kinda horrible. Right now, slicing is virtually free and > compatible with all kinds

[Issue 16077] [CodeView] no language information in MS-COFF debug information

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

[Issue 16077] [CodeView] no language information in MS-COFF debug information

https://issues.dlang.org/show_bug.cgi?id=16077 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/91869f79a1c4726e04480ab296d3d50973921ed1 fix issue 16077: add S_COMPILE record to MS-COFF debug info

[Issue 16084] Linker error with interface final function calling virtual function

https://issues.dlang.org/show_bug.cgi?id=16084 --- Comment #3 from Vladimir Panteleev --- (In reply to Jack Stouffer from comment #2) > (In reply to Vladimir Panteleev from comment #1) > > How can this code be valid? > > According to the spec ;) It may be

[Issue 16084] Linker error with interface final function calling virtual function

https://issues.dlang.org/show_bug.cgi?id=16084 --- Comment #2 from Jack Stouffer --- (In reply to Vladimir Panteleev from comment #1) > How can this code be valid? According to the spec ;) > You are declaring a templated function with no > implementation. Templated

Re: A ready to use Vulkan triangle example for D

On Friday, 27 May 2016 at 18:40:24 UTC, maik klein wrote: https://github.com/MaikKlein/VulkanTriangleD Another dependency is ErupteD which I have forked myself because there is currently an issue with xlib-d and xcb-d with their versioning. Nice work. As a person still trying to

Re: Request assistance binding to Windows dsound.{lib, dll}

On Friday, 27 May 2016 at 20:59:56 UTC, John wrote: Additionally, remove QueryInterface, AddRef and Release from the definition of IDirectSound. Also, interfaces are already references, so the definition of LPDIRECTSOUND should be: alias LPDIRECTSOUND = IDirectSound; Note there should be

Re: foo => "bar" key/value literals in D!

On Friday, 27 May 2016 at 18:10:59 UTC, Vladimir Panteleev wrote: On Monday, 23 May 2016 at 19:00:40 UTC, Adam D. Ruppe wrote: Have I gone completely mad?!?! Yes, though what does it have to do with this thread? :D This is by far the most appealing way to implement named arguments that I've

Re: Dynamic Bindings to libui (x-platform GUI)

you probably misunderstood my post. ;-) i absolutely don't want to install gtk+3, it's not "native" for my system, no other app is using it. that means "no GNU/Linux support" for me.

SR3C -- small sompression library

SR3C[1] is a small and simple MIT-licensed compression library (~28KB of source code, no external dependencies), which nevertheless can compress data with the quality of gzip -7. the drawbacks are: • it requires ~4.5MB of RAM for compression or decompression; • decompression speed is much

Re: Transient ranges

On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote: > So what about the convention to explicitely declare a > `.transient` enum member on a range, if the front element value > can change? Honestly, I don't think that supporting transient ranges is worth it. Every single range-based

Re: faster splitter

On 05/27/2016 06:19 PM, qznc wrote: manual find: 118 ±24 qznc find: 109 ±13 <--- using the sentinel trick Chris find: 142 ±27 It is normal that the numbers of the other tests change, since those are relative to the fastest one in each run. When qznc find 'wins' more often, the others get

Re: The Case Against Autodecode

On Fri, May 27, 2016 at 04:41:09PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 05/27/2016 03:43 PM, H. S. Teoh via Digitalmars-d wrote: > > That's what we've been trying to say all along! > > If that's the case things are pretty dire, autodecoding or not. -- > Andrei Like it or

Re: Our Sister

On 05/27/2016 06:09 PM, tsbockman wrote: On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote: On 05/27/2016 05:02 PM, Era Scarecrow wrote: With the current state of things, I'll just take your word on it. Reasoning is simple - yes we could safely convert to const(char)[] but

Re: Our Sister

On Friday, 27 May 2016 at 22:09:48 UTC, tsbockman wrote: But conversions to scope const(char)[] could be made safe, right? (If scope were ever fully implemented, that is.) Indeed, and I really think we should spend more effort on making this work. Not as much as Rust spends on it, but a lil

Re: Our Sister

On Friday, 27 May 2016 at 21:51:59 UTC, Seb wrote: not if [] would be ref-counted too ;-) That would be kinda horrible. Right now, slicing is virtually free and compatible with all kinds of backing schemes. If it became refcounted, it'd: 1) have to keep a pointer to the refcount structure

Transient ranges

A couple of weeks ago on the next/shift convenience wrapper discussion [1], there was a nice discussion about transient ranges. It didn't come to a conclusion, so let's revie it. I just cite the best three quotes from the thread as a summary: jmdavis: The reality of the matter is that ranges

Re: Battle-plan for CTFE

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. I will post more details as soon as I dive deeper into the code. Update : int bug6498(int x) { int n = 0; while (n < x) ++n; return

Re: The Case Against Autodecode

On 5/27/2016 11:27 AM, Andrei Alexandrescu wrote: On 5/27/16 1:11 PM, Walter Bright wrote: They mean code units. Always valid or potentially invalid as well? -- Andrei Some years ago I would have said always valid. Experience, however, says that Unicode is often dirty and code should be

Does this C callback call look correct?

// Specification from ALURE documentation ALURE_API ALboolean ALURE_APIENTRY alurePlaySourceStream( ALuint source, alureStream *stream, ALsizei numBufs, ALsizei loopcount, void(*eos_callback)(void *userdata, ALuint source), void*userdata ) // My D code, below

Re: The Case Against Autodecode

On Friday, 27 May 2016 at 22:12:57 UTC, Minas Mina wrote: Those should be the same though, i.e compare the same. In order to do that, there is normalization. What is does is to _expand_ the single codepoint Ä into A + ¨ Unless I'm mistaken, this depends on the form used. For example, in NFKC

Re: faster splitter

On Friday, 27 May 2016 at 18:21:06 UTC, Andrei Alexandrescu wrote: What you want to do here for indexed access is to match the last element first. If no match, continue etc. If there's a match, enter an inner loop where you don't need to check for the end of the haystack. -- Andrei Another

Re: The Case Against Autodecode

On Friday, 27 May 2016 at 20:42:13 UTC, Andrei Alexandrescu wrote: On 05/27/2016 03:39 PM, Dmitry Olshansky wrote: On 27-May-2016 21:11, Andrei Alexandrescu wrote: On 5/27/16 10:15 AM, Chris wrote: It has happened to me that characters like "é" return length == 2 Would normalization make

Re: Our Sister

On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote: On 05/27/2016 05:02 PM, Era Scarecrow wrote: With the current state of things, I'll just take your word on it. Reasoning is simple - yes we could safely convert to const(char)[] but that means effectively all refcounting is

Re: The Case Against Autodecode

On Friday, 27 May 2016 at 20:42:13 UTC, Andrei Alexandrescu wrote: On 05/27/2016 03:39 PM, Dmitry Olshansky wrote: No, this is not the point of normalization. What is? -- Andrei 1) A grapheme may include several combining characters (such as diacritics) whose order is not supposed to be

Re: The Case Against Autodecode

On Friday, 27 May 2016 at 20:42:13 UTC, Andrei Alexandrescu wrote: On 05/27/2016 03:39 PM, Dmitry Olshansky wrote: On 27-May-2016 21:11, Andrei Alexandrescu wrote: On 5/27/16 10:15 AM, Chris wrote: It has happened to me that characters like "é" return length == 2 Would normalization make

Re: Battle-plan for CTFE

On Saturday, 21 May 2016 at 21:20:54 UTC, Martin Nowak wrote: On 05/21/2016 11:18 PM, Martin Nowak wrote: The debugging metaphor would be comparing a program that only uses pointer arithmetic against one that is memory safe, the former can randomly write everywhere from anywhere, the latter

Re: is my code to get CTFE instantiated object valid D ?

On Friday, 27 May 2016 at 20:20:36 UTC, chmike wrote: The public interface of Category is designed so that the object's state can't be modified and thus remains immutable. Then... why cast away immutable? I suppose there's always a core set of variables that are what the object actually

Re: Our Sister

On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote: On 05/27/2016 05:02 PM, Era Scarecrow wrote: With the current state of things, I'll just take your word on it. Reasoning is simple - yes we could safely convert to const(char)[] but that means effectively all refcounting is

Re: is my code to get CTFE instantiated object valid D ?

On Friday, 27 May 2016 at 20:20:36 UTC, chmike wrote: Is this code valid D or is the behavior undefined due to the cast ? A mutable object can be synchronized on: synchronized(Category.instance){} This will create and store a mutex in the object (sad but true, design taken from java). If the

Re: faster splitter

On Friday, 27 May 2016 at 14:06:09 UTC, Chris wrote: I have to correct myself. A manual loop is faster, I couldn't believe it either, so I benchmarked the same function with `foreach` and `for`. Turns out that `for` is _way_ faster. Just about the only reason I could think of for this to

Re: Our Sister

On 05/27/2016 05:02 PM, Era Scarecrow wrote: With the current state of things, I'll just take your word on it. Reasoning is simple - yes we could safely convert to const(char)[] but that means effectively all refcounting is lost for that string. So we can convert but in an explicit manner,

Re: faster splitter

On Friday, 27 May 2016 at 20:50:52 UTC, Andrei Alexandrescu wrote: On 05/27/2016 04:39 PM, qznc wrote: Now added Chris' algo to the benchmark: std find:155 ±33 manual find: 112 ±19 qznc find: 122 ±18 <--- improved find Chris find: 133 ±20 <--- findStringS_ Does any of these feature

Re: Our Sister

On Friday, 27 May 2016 at 13:32:30 UTC, Andrei Alexandrescu wrote: On 5/27/16 7:07 AM, Marc Schütz wrote: On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote: RFC: what primitives should RCStr have? It should _safely_ convert to `const(char)[]`. That is not possible, sorry.

Re: Request assistance binding to Windows dsound.{lib, dll}

Additionally, remove QueryInterface, AddRef and Release from the definition of IDirectSound. Also, interfaces are already references, so the definition of LPDIRECTSOUND should be: alias LPDIRECTSOUND = IDirectSound; Note there should be no *. Regarding any linking errors, it's easier to

Re: is my code to get CTFE instantiated object valid D ?

On 5/27/16 4:20 PM, chmike wrote: I need to create an app wide singleton instance for my class. The singleton is immutable, but I want to allow mutable references to that singleton object so that I can do fast 'is' tests. I declared this class Category { protected static immutable

Re: faster splitter

On 05/27/2016 04:39 PM, qznc wrote: Now added Chris' algo to the benchmark: std find:155 ±33 manual find: 112 ±19 qznc find: 122 ±18 <--- improved find Chris find: 133 ±20 <--- findStringS_ Does any of these feature simultaneously: * check the last element first * consequently stop

Re: these are nOT the sisters you're looking for

On 05/27/2016 03:35 PM, Pete wrote: If anyone calls, Jack and I will be over at stack overflow gleefully closing down the derailers there. Thanks for that. Not sure what your moniker is there, but I noticed a good number of solid answers to D questions on SO. Regarding the title, it was

Re: The Case Against Autodecode

On 05/27/2016 03:39 PM, Dmitry Olshansky wrote: On 27-May-2016 21:11, Andrei Alexandrescu wrote: On 5/27/16 10:15 AM, Chris wrote: It has happened to me that characters like "é" return length == 2 Would normalization make length 1? -- Andrei No, this is not the point of normalization.

Re: The Case Against Autodecode

On 05/27/2016 03:43 PM, H. S. Teoh via Digitalmars-d wrote: That's what we've been trying to say all along! If that's the case things are pretty dire, autodecoding or not. -- Andrei

Re: faster splitter

Now added Chris' algo to the benchmark: std find:155 ±33 manual find: 112 ±19 qznc find: 122 ±18 <--- improved find Chris find: 133 ±20 <--- findStringS_

allocator expand should not "expand" the null array

https://github.com/dlang/phobos/pull/4372 What do you all think? Fortunately we're not breaking "any" code because well we're in experimental! :o) -- Andrei

Re: these are nOT the sisters you're looking for

On Friday, 27 May 2016 at 19:35:58 UTC, Pete wrote: read the subject line slowly Jack Sorry about that. I use the web interface and everything is grouped together even if it doesn't have the same subject line, so I didn't see that you changed it.

is my code to get CTFE instantiated object valid D ?

I need to create an app wide singleton instance for my class. The singleton is immutable, but I want to allow mutable references to that singleton object so that I can do fast 'is' tests. I declared this class Category { protected static immutable Category instance_ = new Category;

[Issue 16085] Imported name causes lookup deprecation warning even if masked by member name

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

Re: The Case Against Autodecode

On Fri, May 27, 2016 at 07:53:30PM +, Adam D. Ruppe via Digitalmars-d wrote: > On Friday, 27 May 2016 at 19:30:53 UTC, Andrei Alexandrescu wrote: > > It seems code points are kind of useless because they don't really > > mean anything, would that be accurate? -- Andrei > > It might help to

[Issue 16085] New: Imported name causes lookup deprecation warning even if masked by member name

https://issues.dlang.org/show_bug.cgi?id=16085 Issue ID: 16085 Summary: Imported name causes lookup deprecation warning even if masked by member name Product: D Version: D2 Hardware: x86_64 OS: Linux

[Issue 16085] Imported name causes lookup deprecation warning even if masked by member name

https://issues.dlang.org/show_bug.cgi?id=16085 --- Comment #1 from Andrei Alexandrescu --- https://github.com/dlang/phobos/pull/4371 --

Re: The Case Against Autodecode

On 5/27/16 3:30 PM, Andrei Alexandrescu wrote: On 5/27/16 3:10 PM, ag0aep6g wrote: I don't think there is value in distinguishing by language. The point of Unicode is that you shouldn't need to do that. It seems code points are kind of useless because they don't really mean anything, would

Re: faster splitter

On Friday, 27 May 2016 at 14:41:29 UTC, Chris wrote: The improved `std find` comes very close to the manual function above now, sometimes it's even faster or at least as fast. std findtook 12573666 manual find took 7418454 my std find took 6903854 <=== findStringS

Re: The Case Against Autodecode

On Friday, 27 May 2016 at 19:30:53 UTC, Andrei Alexandrescu wrote: It seems code points are kind of useless because they don't really mean anything, would that be accurate? -- Andrei It might help to think of code points as being a kind of byte code for a text-representing VM. It's not

Re: The Case Against Autodecode

On Fri, May 27, 2016 at 03:30:53PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 5/27/16 3:10 PM, ag0aep6g wrote: > > I don't think there is value in distinguishing by language. The > > point of Unicode is that you shouldn't need to do that. > > It seems code points are kind of

Re: The Case Against Autodecode

On Fri, May 27, 2016 at 02:42:27PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 5/27/16 12:40 PM, H. S. Teoh via Digitalmars-d wrote: > > Exactly. And we just keep getting stuck on this point. It seems that > > the message just isn't getting through. The unfounded assumption > >

Re: The Case Against Autodecode

On 05/27/2016 09:30 PM, Andrei Alexandrescu wrote: It seems code points are kind of useless because they don't really mean anything, would that be accurate? -- Andrei I think so, yeah. Due to combining characters, code points are similar to code units: a Unicode thing that you need to know

Re: The Case Against Autodecode

On 27-May-2016 21:11, Andrei Alexandrescu wrote: On 5/27/16 10:15 AM, Chris wrote: It has happened to me that characters like "é" return length == 2 Would normalization make length 1? -- Andrei No, this is not the point of normalization. -- Dmitry Olshansky

Re: these are nOT the sisters you're looking for

and tag it OT.<< read the subject line slowly Jack ..but I appreciate your witty use of the word derail. If anyone calls, Jack and I will be over at stack overflow gleefully closing down the derailers there. On Friday, 27 May 2016 at 17:37:20 UTC, Jack Stouffer wrote: On Friday, 27 May

Re: The Case Against Autodecode

On 5/27/16 1:11 PM, Walter Bright wrote: The std.string algorithms I wrote all work much better (i.e. faster) without autodecoding, while maintaining proper Unicode support. Violent agreement is occurring here. We have plenty of those and need more. -- Andrei

Re: Easier way to add libraries to visual d?

On Thursday, 26 May 2016 at 22:15:17 UTC, Basile B. wrote: gfm doesn't yield a .lib because of this: https://github.com/d-gamedev-team/gfm/blob/master/dub.json#L22 it should be "library" or staticLibrary or "sourceLibrary" thus it can't be registered. Bad luck here you've chosen the wrong

Re: faster splitter

On Friday, 27 May 2016 at 19:17:44 UTC, Chris wrote: Oops, I've been found out. :-) Thanks. You're right of course, and I've already noticed that bug as it fails on not found. I got the bounds wrong. I had the same "bug" when I wrote my search function on the project at work. I also found

Re: The Case Against Autodecode

On 5/27/16 3:10 PM, ag0aep6g wrote: I don't think there is value in distinguishing by language. The point of Unicode is that you shouldn't need to do that. It seems code points are kind of useless because they don't really mean anything, would that be accurate? -- Andrei

Re: First Boston D language meetup

On 5/27/16 1:35 PM, Steven Schveighoffer wrote: I added a meetup date for next Thursday. If any one is interested: http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/231443603/ I'll be there. Thanks! -- Andrei

Re: Request assistance binding to Windows dsound.{lib, dll}

On Friday, 27 May 2016 at 17:49:56 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 17:37:38 UTC, Andrew Edwards wrote: extern (C) class IDirectSound : IUnknown That should just be `interface IDirectSound : IUnknown` Thanks for the clarification. That actually compiles but results

Re: The D language online tour - tour.dlang.org

On Friday, 27 May 2016 at 19:18:11 UTC, Andrew Edwards wrote: On Monday, 16 May 2016 at 17:32:06 UTC, André wrote: [...] Hello André, Congratulations. Job well done on a much need resource for the community. I sent you an email almost two weeks ago via your website. Not sure if you

Re: faster splitter

Oops, I've been found out. :-) Thanks. You're right of course, and I've already noticed that bug as it fails on not found. I got the bounds wrong.

Re: The D language online tour - tour.dlang.org

On Monday, 16 May 2016 at 17:32:06 UTC, André wrote: Hi, after another round of polishing, bug fixing, very useful user contributions and suggestions, I'd like to present the new home of the D language online tour: http://tour.dlang.org/ Thank you very much to the D foundation for hosting

Re: The Case Against Autodecode

On 05/27/2016 08:42 PM, Andrei Alexandrescu wrote: Which languages are covered by code points, and which languages require graphemes consisting of multiple code points? How does normalization play into this? -- Andrei I don't think there is value in distinguishing by language. The point of

Re: Sociomantic's short DConf2016 video

On Wednesday, 25 May 2016 at 12:17:13 UTC, Steven Schveighoffer wrote: On 5/24/16 7:51 PM, Walter Bright wrote: On 5/24/2016 4:04 PM, Jonathan M Davis via Digitalmars-d-announce wrote: Well, I guess that that answers the question of what they were going to do with the interviews they were

Re: Why do some T.init evaluate to true while others to false?

On Friday, 27 May 2016 at 18:03:23 UTC, Steven Schveighoffer wrote: I didn't change the default. The default is to pick the first member and use that as the init value. I may not have even considered what foo.init might be when I was creating my enum. -Steve by default i ment this enum

Re: A technique to mock "static interfaces" (e.g. isInputRange)

On 2016-05-27 15:12, Atila Neves wrote: I get an SSL warning for that link. Hmm, here's the code inline: module red; import std.stdio; import core.sys.posix.sys.mman : mprotect, PROT_NONE, PROT_READ, PROT_WRITE, PROT_EXEC; import core.stdc.errno : errno; import core.stdc.string :

Re: The Case Against Autodecode

On 5/27/16 12:40 PM, H. S. Teoh via Digitalmars-d wrote: Exactly. And we just keep getting stuck on this point. It seems that the message just isn't getting through. The unfounded assumption continues to be made that iterating by code point is somehow "correct" by definition and nobody can

A ready to use Vulkan triangle example for D

https://github.com/MaikKlein/VulkanTriangleD Currently only Linux is supported but it should be fairly easy to also add Windows support. Only the surface extensions have to be changed. The example requires Vulkan ready hardware + driver + LunarG sdk with validation layer + sdl2. Another

Re: faster splitter

On Friday, 27 May 2016 at 14:41:29 UTC, Chris wrote: On Friday, 27 May 2016 at 14:06:09 UTC, Chris wrote: This outperforms both `manual_find` and the improved `std find` string findStringS_Manual(string haystack, string needle) { if (needle.length > haystack.length)

Re: The Case Against Autodecode

On 5/27/16 1:11 PM, Walter Bright wrote: They mean code units. Always valid or potentially invalid as well? -- Andrei

Re: DIP 88: Simple form of named parameters

On Sunday, 24 January 2016 at 02:51:43 UTC, Jonathan M Davis wrote: Regardless, I for one, hope that we never have named arguments. Whops. https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d :D

Re: faster splitter

On 5/27/16 10:41 AM, Chris wrote: The improved `std find` comes very close to the manual function above now, sometimes it's even faster or at least as fast. What you want to do here for indexed access is to match the last element first. If no match, continue etc. If there's a match, enter an

Re: The Case Against Autodecode

On Friday, 27 May 2016 at 18:11:22 UTC, Andrei Alexandrescu wrote: Would normalization make length 1? -- Andrei In some, but not all cases.

Re: The Case Against Autodecode

On 5/27/16 10:15 AM, Chris wrote: It has happened to me that characters like "é" return length == 2 Would normalization make length 1? -- Andrei

Re: foo => "bar" key/value literals in D!

On Monday, 23 May 2016 at 19:00:40 UTC, Adam D. Ruppe wrote: Have I gone completely mad?!?! Yes, though what does it have to do with this thread? :D This is by far the most appealing way to implement named arguments that I've seen so far:

Re: Why do some T.init evaluate to true while others to false?

On 5/27/16 1:42 PM, ArturG wrote: On Friday, 27 May 2016 at 16:56:21 UTC, Steven Schveighoffer wrote: Why are you expecting it to be? Won't work for enums with first elements that are non-zero either: enum foo : int { bar = 1; } foo f; if(f) writeln("this will output too"); but by

Re: Request assistance binding to Windows dsound.{lib, dll}

On Friday, 27 May 2016 at 17:37:38 UTC, Andrew Edwards wrote: extern (C) class IDirectSound : IUnknown That should just be `interface IDirectSound : IUnknown`

Re: IDE - Coedit 2, update 6 released

On Thursday, 26 May 2016 at 23:44:21 UTC, Basile B. wrote: Mostly because an important feature of the library manager was not compatible with DUB > v0.9.24. Otherwise almost nothing. See https://github.com/BBasile/Coedit/releases/tag/2_update_6 for the changelog and the binaries. Is there

Re: Why do some T.init evaluate to true while others to false?

On Friday, 27 May 2016 at 16:56:21 UTC, Steven Schveighoffer wrote: Why are you expecting it to be? Won't work for enums with first elements that are non-zero either: enum foo : int { bar = 1; } foo f; if(f) writeln("this will output too"); -Steve but by default it works you just

Re: these are nOT the sisters you're looking for

On Friday, 27 May 2016 at 17:08:33 UTC, Pete wrote: ... Please don't derail this conversation. If you have a complaint please make it in a separate thread and tag it OT.

Re: Request assistance binding to Windows dsound.{lib, dll}

On Friday, 27 May 2016 at 16:08:27 UTC, Kagamin wrote: On Friday, 27 May 2016 at 15:28:42 UTC, Andrew Edwards wrote: Have you tried with extern(C) yet? extern(C) is for undecorated symbold extern(Windows) adds the _ and @12 decorations (would be __stdcall on C/C++ side) The thought never

First Boston D language meetup

I added a meetup date for next Thursday. If any one is interested: http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/231443603/ -Steve

Re: faster splitter

On Friday, 27 May 2016 at 14:41:29 UTC, Chris wrote: The improved `std find` comes very close to the manual function above now, sometimes it's even faster or at least as fast. I think it really depends on the use case. The manual algorithm is really naive and std-find is slightly more

Re: faster splitter

On Friday, 27 May 2016 at 14:06:09 UTC, Chris wrote: I think it's clear that `std find` is vry slow. If anyone wants to test my function, please do so. I don't want to spread wrong data, but this is what I get at the moment (ldc latest version). If you want to see find (current or my

Re: The Case Against Autodecode

On 5/26/2016 9:00 AM, Andrei Alexandrescu wrote: My thesis: the D1 design decision to represent strings as char[] was disastrous and probably one of the largest weaknesses of D1. The decision in D2 to use immutable(char)[] for strings is a vast improvement but still has a number of issues. The

these are nOT the sisters you're looking for

I post this only as a warning to others. Imagine being the kind of person who isn't certain he could actually get Hello World past the D compiler -but (and?) sees the subject "Our Sister" and immediately thinks: "oh, Alexandrescu must be referring to his sister who is a doctor and did the

Re: Alias this member shadowed by imported function identifier?

On 5/27/16 9:33 AM, Johan Engelen wrote: The following code compiles with DMD 2.070, but not with 2.071: ``` module mod; import std.range; struct S { struct Inner { int unique_identifier_name; int tail; } Inner inner; alias inner this; auto

Re: Request for approval: deploying dlang.org on merge

On 5/27/16 11:35 AM, Joakim wrote: On Friday, 27 May 2016 at 14:34:03 UTC, Jesse Phillips wrote: On Thursday, 26 May 2016 at 15:53:34 UTC, Seb wrote: We already have http://wiki.dlang.org/User:Vladimir_Panteleev/Website_staging so it's not a matter of implementation, just everyone agreeing

Re: Why do some T.init evaluate to true while others to false?

On 5/27/16 11:49 AM, ArturG wrote: On Friday, 27 May 2016 at 15:24:18 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 15:19:50 UTC, ArturG wrote: yes but i have to check for that when some one does Why? This is no different than if they set any of the other four billion possible values.

Re: Benchmark Dlang vs Node vs Ruby

Why not to use distribute oprion? Dne 27. 5. 2016 17:35 napsal uživatel "yawniek via Digitalmars-d-learn" < digitalmars-d-learn@puremagic.com>: > On Friday, 27 May 2016 at 13:45:23 UTC, llaine wrote: > >> Hi guys, >> >> In my journey of learning about D I tried to benchmark D with Vibe.d vs >>

Re: The Case Against Autodecode

On Fri, May 27, 2016 at 03:47:32PM +0200, ag0aep6g via Digitalmars-d wrote: > On 05/27/2016 03:32 PM, Andrei Alexandrescu wrote: > > > > However the following do require autodecoding: > > > > > > > > s.walkLength > > > > s.count!(c => !"!()-;:,.?".canFind(c)) // non-punctuation > > > > s.count!(c

[Issue 11817] Structs with void initialized fields get initialized anyway

https://issues.dlang.org/show_bug.cgi?id=11817 --- Comment #4 from Sobirari Muhomori --- I use it as a hack to have a zero-initialized member, results in a more efficient initialization of the struct - when it can be simply wiped with zeros. --

Re: Alias this member shadowed by imported function identifier?

Hmm... I wouldn't expect this to work, but still worth to report in bugzilla.

  1   2   3   >