Re: Templates are slow.

On Friday, 9 September 2016 at 01:38:40 UTC, deadalnix wrote: On Thursday, 8 September 2016 at 20:10:01 UTC, Stefan Koch wrote: generating separate object files for each template instanciation is and then only re-generating on change will only be effective if they do not change much. From one

Re: Templates are slow.

On Thursday, 8 September 2016 at 20:10:01 UTC, Stefan Koch wrote: generating separate object files for each template instanciation is and then only re-generating on change will only be effective if they do not change much. From one build to the next. You'd have tens of thousands of file and

Re: Fully-qualified symbol disambiguation is deprecated???

On Thursday, September 08, 2016 18:26:40 Nick Sabalausky via Digitalmars-d- learn wrote: > On 09/08/2016 06:22 PM, Nick Sabalausky wrote: > > On 09/08/2016 06:13 PM, Steven Schveighoffer wrote: > >> And > >> there are still some straggling bugs which cause this message to be > >> erroneously

Re: D1: zlib string to decode

On Thursday, 8 September 2016 at 16:19:44 UTC, jicman wrote: I have a zlib string that I want to decode. Anybody has any idea how to do that? I am trying to figure out what to send with a POST to create a new internal log and the person that created the form is no longer available, but I

[Issue 16478] New: Confusing internal error message with std.variant.visit

https://issues.dlang.org/show_bug.cgi?id=16478 Issue ID: 16478 Summary: Confusing internal error message with std.variant.visit Product: D Version: D2 Hardware: All OS: All Status: NEW

Re: [GSoC] Precise GC

On Wednesday, 7 September 2016 at 02:15:30 UTC, Dsby wrote: On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote: Hi everyone, I know I'm super late to the party for this, and sorry for that. While my work on the precise GC didn't go as planned, it is closer than it was to be

Re: Simplifying conversion and formatting code in Phobos

On 9/8/2016 5:10 AM, Andrei Alexandrescu wrote: Consider the pattern of overloads: template foo(T) if (condition!T) { } template foo(T) if (!condition!T) { } It makes condition!T a user-facing constraint, which it should not be. This looks like a nice guideline. Good work. Pushing the

Re: Templates are slow.

On Thursday, 8 September 2016 at 22:57:07 UTC, Stefan Koch wrote: The front-end spends most of it's time comparing strings of unique type-names :) (Waits for Walter to say, "Use a pool Luke!")

Re: Struct default constructor - need some kind of solution for C++ interop

On 9/8/2016 4:26 AM, Ethan Watson wrote: On Thursday, 8 September 2016 at 11:18:12 UTC, Walter Bright wrote: The thing is, the 'destroy()' function is going to swamp any extra clock cycle, as will a virtual lookup and dereference. Assume destroy() is a more trivial function then. The point is

Re: Fully-qualified symbol disambiguation is deprecated???

On 09/08/2016 03:22 PM, Nick Sabalausky wrote: On 09/08/2016 06:13 PM, Steven Schveighoffer wrote: On 9/8/16 6:02 PM, Nick Sabalausky wrote: I'm getting deprecation messages ("Package...not accessible here, perhaps add static import") when simply trying to use fully-qualified symbol names to

Re: Templates are slow.

Hi Guys, I have some more data. In the binderoo example the main time is spent in the backend. generating code and writing objects files. The front-end spends most of it's time comparing strings of unique type-names :) One particular outlier in the backend code is the function ecom which

Re: Fully-qualified symbol disambiguation is deprecated???

On 09/08/2016 06:22 PM, Nick Sabalausky wrote: On 09/08/2016 06:13 PM, Steven Schveighoffer wrote: And there are still some straggling bugs which cause this message to be erroneously printed. I'm pretty sure I've hit one of those :( Can't be certain though until I examine my specific case

Re: Fully-qualified symbol disambiguation is deprecated???

On 09/08/2016 06:13 PM, Steven Schveighoffer wrote: On 9/8/16 6:02 PM, Nick Sabalausky wrote: I'm getting deprecation messages ("Package...not accessible here, perhaps add static import") when simply trying to use fully-qualified symbol names to disambiguate a symbol. Is this really intended?

Re: Fully-qualified symbol disambiguation is deprecated???

On 9/8/16 6:13 PM, Steven Schveighoffer wrote: On 9/8/16 6:02 PM, Nick Sabalausky wrote: I'm getting deprecation messages ("Package...not accessible here, perhaps add static import") when simply trying to use fully-qualified symbol names to disambiguate a symbol. Is this really intended? Yes.

Re: Fully-qualified symbol disambiguation is deprecated???

On 9/8/16 6:02 PM, Nick Sabalausky wrote: I'm getting deprecation messages ("Package...not accessible here, perhaps add static import") when simply trying to use fully-qualified symbol names to disambiguate a symbol. Is this really intended? Yes. It's difficult to attribute the message

Re: Fully-qualified symbol disambiguation is deprecated???

On 09/08/2016 03:02 PM, Nick Sabalausky wrote: I'm getting deprecation messages ("Package...not accessible here, perhaps add static import") when simply trying to use fully-qualified symbol names to disambiguate a symbol. Is this really intended? Sounds like the recent changes in 2.071:

Fully-qualified symbol disambiguation is deprecated???

I'm getting deprecation messages ("Package...not accessible here, perhaps add static import") when simply trying to use fully-qualified symbol names to disambiguate a symbol. Is this really intended?

Re: Struct default constructor - need some kind of solution for C++ interop

On Thursday, 8 September 2016 at 11:18:12 UTC, Walter Bright wrote: http://www.agner.org/optimize/microarchitecture.pdf section 3.13 has a bit more info on the branch predictor. Desktop Intel CPUs tend to hide performance problems like this thanks to their far-higher-quality branch

mysql-native v0.1.6

Another small update, v0.1.6, to fix this: Linker error when using dub to import *just* vibe-d:core, but not all of vibe.d. At least once code.dlang.org notices the new tag.

Re: VisualD core.exception.RangeError@pipedmd(286): Range violation

On Thursday, 8 September 2016 at 19:56:45 UTC, Rainer Schuetze wrote: I think I fixed both issues in this build: https://ci.appveyor.com/project/rainers/visuald/build/1.0.76/job/kq0a5bqpy7anou46/artifacts Well that was fast :) It does appear to be fixed on my machine, thanks a lot for the

Re: [GSoC] Precise GC

On Saturday, 3 September 2016 at 12:22:25 UTC, thedeemon wrote: On Friday, 2 September 2016 at 14:55:26 UTC, jmh530 wrote: Anyway, with @safe unions, my thinking is that it would mean that the garbage collector can be made precise in @safe code in a way that it can't in @system code (assuming

Re: [OT] LLVM 3.9 released - you can try the release already with LDC!

On Tuesday, 6 September 2016 at 10:51:16 UTC, eugene wrote: On Tuesday, 6 September 2016 at 09:42:11 UTC, Lodovico Giaretta wrote: There are lot of projects using LLVM [1]. The fact that LDC if often cited in the release notes means that it's one of the best. This is free advertisement, as

Re: Generate unique members with recursive mixins or another solution?

On 09/08/2016 02:55 AM, ilariel wrote: Is it possible to generate unique fields and members with recursive template mixins? I don't fully understand the question but my answer is yes, D can do this as well. :p Ali

Re: Templates are slow.

On Thursday, 8 September 2016 at 19:17:42 UTC, Lewis wrote: Am I crazy in wondering about caching template instantiations? I understand that an incremental build would kind of accomplish this goal, but that comes with its own set of problems. Not as good as what you propose, but: LDC 1.1.0

Re: Templates are slow.

On Thursday, 8 September 2016 at 19:49:38 UTC, Ethan Watson wrote: On Thursday, 8 September 2016 at 19:17:42 UTC, Lewis wrote: I can't help but wonder if there were some way to automatically cache templates instantiations between runs of dmd? I'm running with Visual D, which has a "COMPILE

Re: VisualD core.exception.RangeError@pipedmd(286): Range violation

On 08.09.2016 20:15, Rainer Schuetze wrote: On 08.09.2016 19:35, Tofu Ninja wrote: On Thursday, 8 September 2016 at 07:45:56 UTC, Rainer Schuetze wrote: Fixed it again. You can find a prebuilt binary of pipedmd.exe here:

Re: Templates are slow.

On Thursday, 8 September 2016 at 19:17:42 UTC, Lewis wrote: I can't help but wonder if there were some way to automatically cache templates instantiations between runs of dmd? I'm running with Visual D, which has a "COMPILE ALL THE THINGS" mentality as the default. As part of the rapid

Re: Struct default constructor - need some kind of solution for C++ interop

On Thursday, 8 September 2016 at 10:06:16 UTC, John Colvin wrote: I think it's too late for this stuff now for D anyway. There are workarounds that make life acceptable without default constructors, I can't see how we could add them without getting into a real mess. The kind of flow analysis

Re: Templates are slow.

It's true that templates are inherently slow, and there isn't a ton we can do about that. However, almost every time I compile the project (hundreds of times per day), the overwhelming majority of the time, the same templates are being re-instantiated in exactly the same way. I can't help but

Re: Templates are slow.

I recently went through the process of optimizing the build time on one of my projects. I started at ~3.08s, and got it down to ~1.6s. The project is around 7000 non-comment-non-whitespace LOC. I timed the build in a pretty non-rigourous fashion (I just timed the python script that kicks off a

Re: Battle-plan for CTFE

On Thursday, 8 September 2016 at 13:11:23 UTC, Stefan Koch wrote: On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :) I think I have taken care of the incorrect

Re: VisualD core.exception.RangeError@pipedmd(286): Range violation

On 08.09.2016 19:35, Tofu Ninja wrote: On Thursday, 8 September 2016 at 07:45:56 UTC, Rainer Schuetze wrote: Fixed it again. You can find a prebuilt binary of pipedmd.exe here: https://ci.appveyor.com/project/rainers/visuald/build/1.0.75/job/n9tf67jxcir6kpmg/artifacts Thanks for the

Re: CompileTime performance measurement

On Thursday, 8 September 2016 at 17:15:54 UTC, safety0ff wrote: On Thursday, 8 September 2016 at 17:03:30 UTC, Stefan Koch wrote: I thought of the same thing a while back. However I have had the time to decipher the gprof data-format yet. Is there another profile-format for decent

Re: VisualD core.exception.RangeError@pipedmd(286): Range violation

On Thursday, 8 September 2016 at 07:45:56 UTC, Rainer Schuetze wrote: Fixed it again. You can find a prebuilt binary of pipedmd.exe here: https://ci.appveyor.com/project/rainers/visuald/build/1.0.75/job/n9tf67jxcir6kpmg/artifacts Thanks for the response, I think there is more going on than

Re: We need to enhance the standard library!

On Thursday, 8 September 2016 at 16:43:09 UTC, Brian wrote: What's important is that no one goes to plan or organize what is needed. I'm honestly not sure how you can say that. The Vision documents are pretty clear about priorities and plans.

Re: Use of StackOverflow

On Thursday, 8 September 2016 at 16:57:46 UTC, Johan Engelen wrote: IMHO, it is much more pleasant to lookup questions on SO because the answer is easily found, instead of being buried in a forum thread 3 pages down. So, against effectiveness, I'd advice people to ask questions on SO, for my

Re: CompileTime performance measurement

On Thursday, 8 September 2016 at 17:03:30 UTC, Stefan Koch wrote: I thought of the same thing a while back. However I have had the time to decipher the gprof data-format yet. Is there another profile-format for decent visualization tools exist ? I was just using that as an example of what

Re: Templates are slow.

On Thu, Sep 08, 2016 at 04:37:36PM +, Stefan Koch via Digitalmars-d wrote: [...] > Also we need to special case ranges in general. > And try harder to inline calls to range functions. > Maybe even early in the frontend. [...] Yeah, dmd's inliner is really pessimistic. It gives up too easily,

Re: CompileTime performance measurement

On Thursday, 8 September 2016 at 16:52:47 UTC, safety0ff wrote: On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote: ... I have now implemented another pseudo function called __ctfeTicksMs. [Snip] This does allow meaningful compiletime performance tests to be written. spanning

Re: Use of StackOverflow

On Thursday, 8 September 2016 at 13:22:15 UTC, Jonathan M Davis wrote: On Thursday, September 08, 2016 09:54:16 Russel Winder via Digitalmars-d wrote: Do people operate on StackOverflow for D questions and answers? Yes. D is about the only reason that I pay attention to SO anymore. There are

Re: CompileTime performance measurement

On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote: ... I have now implemented another pseudo function called __ctfeTicksMs. [Snip] This does allow meaningful compiletime performance tests to be written. spanning both CTFE and template-incitations timeings. Please tell me what

Re: We need to enhance the standard library!

On Thursday, 8 September 2016 at 07:43:02 UTC, Jack Stouffer wrote: On Wednesday, 7 September 2016 at 19:01:23 UTC, Piotrek wrote: Almost every "standard" evolves (e.g. USB, 3GPP, etc) and are subject to change in subsequent releases. Stopping the progress is not a case in good standardization

Re: Templates are slow.

On Thursday, 8 September 2016 at 15:45:53 UTC, Jonathan M Davis wrote: It's critical that we do what we can to make templates fast. And if we can't make them fast enough, we'll definitely have to come up with techniques/guidelines for reducing their usage when they're not really needed. -

D1: zlib string to decode

Hi. I have a zlib string that I want to decode. Anybody has any idea how to do that? I am trying to figure out what to send with a POST to create a new internal log and the person that created the form is no longer available, but I need to find what are the pieces and data that I need to

Re: workspace-d 2.7.2 & code-d 0.10.14

On Thursday, 8 September 2016 at 06:50:58 UTC, Suliman wrote: It's possible to integrate workspace-d with Sublime? Yes, as long as you can start a process and read its output & write to its input in binary, you can do it. Message format is available here:

mysql-native v0.1.5

Tagged a new release of mysql-native: A client driver for MySQL/MariaDB written natively in D from scratch via the published protocol specs, with no dependency on the C MySQL client library. Supports either Phobos or Vide.d sockets (works with or without Vibe.d). Despite the seemingly low

Re: Use of StackOverflow

On Thursday, 8 September 2016 at 09:04:27 UTC, cym13 wrote: On Thursday, 8 September 2016 at 08:54:16 UTC, Russel Winder wrote: Do people operate on StackOverflow for D questions and answers? Yes, from my experience most questions get answered quickly (within an hour) thanks to the IRC bot

Re: Templates problem

On Thursday, 8 September 2016 at 10:20:42 UTC, Russel Winder wrote: On Wed, 2016-09-07 at 20:29 +, deXtoRious via Digitalmars-d-learn wrote: […] More to the general point of the discussion, I find that most scientifically minded users of Python already appreciate some of the inherent

Re: Templates are slow.

On Thursday, September 08, 2016 07:43:10 Ethan Watson via Digitalmars-d wrote: > On Thursday, 8 September 2016 at 05:02:38 UTC, Stefan Koch wrote: > > I have just hit a barrier trying to optimize the compile-time > > in binderoo. > > I did a double take when Stefan told me the representative

Re: Battle-plan for CTFE

On Thursday, 8 September 2016 at 14:48:25 UTC, Rory McGuire wrote: On Thu, Sep 8, 2016 at 3:11 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no

Re: UFCS not working with alias

On Thursday, 8 September 2016 at 13:38:54 UTC, Steven Schveighoffer wrote: There is a workaround, identified by Vladimir Panteleev (https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/): import std.algorithm; bool fulfillsKeyPredicate(string s, string t)

Re: We need to enhance the standard library!

On Thu, 08 Sep 2016 07:43:02 +, Jack Stouffer wrote: > On Wednesday, 7 September 2016 at 19:01:23 UTC, Piotrek wrote: >> Almost every "standard" evolves (e.g. USB, 3GPP, etc) and are subject >> to change in subsequent releases. Stopping the progress is not a case >> in good standardization

Re: Functions, nothrow and assert

On Thu, Sep 08, 2016 at 12:07:43PM +, Lodovico Giaretta via Digitalmars-d-learn wrote: [...] > To expand on the previous correct answers, nothrow is about not > throwing Exceptions. Exceptions are part of the normal flow of the > program: they are used to signal recoverable errors, much like

Re: Return type deduction

On Thursday, 8 September 2016 at 13:28:15 UTC, Steven Schveighoffer wrote: Right, but there is a problem here. The connection of the simple return type to the simple template parameter is not necessarily guaranteed. That is, there is no guarantee simple!int is going to return int (for any

Re: Battle-plan for CTFE

On Thu, Sep 8, 2016 at 3:11 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: > >> compiling parts of phobos does no longer crash the new engine. >> However it still produces incorrect

Re: Struct default constructor - need some kind of solution for C++ interop

On Tuesday, 6 September 2016 at 13:44:37 UTC, Ethan Watson wrote: So now I'm in a bind. This is one struct I need to construct uniquely every time. And I also need to keep the usability up to not require calling some other function since this is matching a C++ class's functionality, including

Re: Templates problem

On Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder wrote: I am certainly hoping that Chapel will be the language to displace NumPy for serious computation in the Python-sphere. Given it's foundation in the PGAS model, it has all the parallelism needs, both cluster and local, built

Re: We need to enhance the standard library!

On Thursday, 8 September 2016 at 07:43:02 UTC, Jack Stouffer wrote: On Wednesday, 7 September 2016 at 19:01:23 UTC, Piotrek wrote: Almost every "standard" evolves (e.g. USB, 3GPP, etc) and are subject to change in subsequent releases. Stopping the progress is not a case in good standardization

Re: Struct default constructor - need some kind of solution for C++ interop

On Thursday, 8 September 2016 at 12:32:44 UTC, Andrei Alexandrescu wrote: One thing we could look at is allow only CTFEable default constructors. Wouldn't work in my case where I need to call a dynamically imported extern( C++ ) function to correctly construct an object.

Re: [GtkD] How to connect to notify::active signal?

On Saturday, 4 May 2013 at 09:59:12 UTC, Mike Wey wrote: On 05/04/2013 05:20 AM, Alexandr Druzhinin wrote: 04.05.2013 1:18, Mike Wey пишет: On 05/03/2013 06:30 PM, Alexandr Druzhinin wrote: I need to connect to "notify::active" signal for Switch widget to process changing of its state. The

Re: UFCS not working with alias

On 9/7/16 4:26 AM, Andre Pany wrote: On Wednesday, 7 September 2016 at 08:08:34 UTC, rikki cattermole wrote: On 07/09/2016 8:06 PM, Andre Pany wrote: Should I open an enhancement request? No. It works outside of the function (part of lookup rules). I simplified my example too much. Yes in

Re: Templates are slow.

On Thursday, 8 September 2016 at 05:02:38 UTC, Stefan Koch wrote: If you are instantiating a template inside another template think very hard about the reason, often you can "inline" the template body of the inner template and get an instant speed win right there. (Don't do this

Re: Return type deduction

On 9/7/16 3:19 AM, Andrea Fontana wrote: On Tuesday, 6 September 2016 at 14:21:26 UTC, Steven Schveighoffer wrote: On 9/5/16 5:59 AM, Andrea Fontana wrote: I asked this some time (years?) ago. Time for a second try :) Consider this: --- T simple(T)() { return T.init; } void main() {

Re: Classes new'd inside for loop are all the same instance?

On Thursday, 8 September 2016 at 12:36:29 UTC, drug wrote: is address of the variable c, that is allocated on the stack and has the same address on every iteration cast(void*)c return the value of variable c that is address of a class instance and is different for every iteration in other

Re: Use of StackOverflow

On 09/09/2016 1:22 AM, Jonathan M Davis via Digitalmars-d wrote: On Thursday, September 08, 2016 09:54:16 Russel Winder via Digitalmars-d wrote: Do people operate on StackOverflow for D questions and answers? Yes. D is about the only reason that I pay attention to SO anymore. There are

Re: Stdio.write/writeln and flushing

On 9/8/16 4:53 AM, Somebody wrote: If i write something like: writeln("what to do?"); switch(readln[0 .. $ - 1]) { //.. } writeln("bye"); that works just as it should at Windows, started from a command prompt. However, if I run it from GNU Emacs, I have to manually flush the output after

Re: Use of StackOverflow

On Thursday, September 08, 2016 09:54:16 Russel Winder via Digitalmars-d wrote: > Do people operate on StackOverflow for D questions and answers? Yes. D is about the only reason that I pay attention to SO anymore. There are several folks who post here who answer D questions on SO, and there are

Re: Battle-plan for CTFE

On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :) I think I have taken care of the incorrect bytecode. It was not an issue with the engine itself but rather with the

Re: Templates problem

On Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder wrote: I am certainly hoping that Chapel will be the language to displace NumPy for serious computation in the Python-sphere. Given it's foundation in the PGAS model, it has all the parallelism needs, both cluster and local, built

Re: Templates are slow.

On Thursday, 8 September 2016 at 12:23:35 UTC, Andrei Alexandrescu wrote: Are there any situations that we can special-case away? Raising the roof. -- Andrei The rangefying functions in std.array come to mind. That will give a huge boost to everyone. (everyone who uses arrays anyway :))

Re: Classes new'd inside for loop are all the same instance?

08.09.2016 15:24, lobo пишет: I am confused, which is normal, but I'd appreciate some help :-) If I create N classes in a for loop they are all the same instance. I would expect each to be a unique instance of the class. See the code below --- class C {} void main() { import std.stdio;

Re: Classes new'd inside for loop are all the same instance?

On Thursday, 8 September 2016 at 12:36:29 UTC, drug wrote: 08.09.2016 15:24, lobo пишет: [...] is address of the variable c, that is allocated on the stack and has the same address on every iteration cast(void*)c return the value of variable c that is address of a class instance and is

Re: Classes new'd inside for loop are all the same instance?

On Thursday, 8 September 2016 at 12:28:55 UTC, Meta wrote: On Thursday, 8 September 2016 at 12:24:48 UTC, lobo wrote: [...] I don't have time to explain at the moment, but change the `` to `cast(void*)c` and you will see what you expect. I will post an explanation soon. Thanks for the

Re: Struct default constructor - need some kind of solution for C++ interop

On 9/8/16 12:06 PM, John Colvin wrote: I think it's too late for this stuff now for D anyway. There are workarounds that make life acceptable without default constructors, I can't see how we could add them without getting into a real mess. A good point. I should mention, however, that the lack

Re: Classes new'd inside for loop are all the same instance?

On 09/09/2016 12:24 AM, lobo wrote: I am confused, which is normal, but I'd appreciate some help :-) If I create N classes in a for loop they are all the same instance. I would expect each to be a unique instance of the class. See the code below --- class C {} void main() { import

Re: Classes new'd inside for loop are all the same instance?

On Thursday, 8 September 2016 at 12:24:48 UTC, lobo wrote: I am confused, which is normal, but I'd appreciate some help :-) If I create N classes in a for loop they are all the same instance. I would expect each to be a unique instance of the class. See the code below --- class C {} void

Re: Struct default constructor - need some kind of solution for C++ interop

On 9/8/16 1:37 AM, Walter Bright wrote: On 9/7/2016 4:05 PM, deadalnix wrote: Consider reference counting for instance. Andrei's scheme for RC doesn't have that issue. Default constructors would help RC design. Raising the roof. -- Andrei

Re: Templates are slow.

On 9/8/16 7:02 AM, Stefan Koch wrote: I will write an article about why templates are slow. The gist will be however : "Templates being slow is an inherent property of templates." (We are only talking about templates as defined by (C++ and D)). That would be a great article. Are there any

Classes new'd inside for loop are all the same instance?

I am confused, which is normal, but I'd appreciate some help :-) If I create N classes in a for loop they are all the same instance. I would expect each to be a unique instance of the class. See the code below --- class C {} void main() { import std.stdio; auto c1 = new C();

Re: Simplifying conversion and formatting code in Phobos

On 9/7/16 9:49 PM, Walter Bright wrote: On 9/7/2016 8:46 AM, Jack Stouffer wrote: Yeah, this problem ultimately comes down to healthy use of DRY in Phobos in regards to string handling code. This was always the tradeoff with DRY: with small pieces of reused code being put into functions, it

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/7/16 9:21 PM, Ali Çehreli wrote: On 09/03/2016 03:13 PM, Ethan Watson wrote: On Saturday, 3 September 2016 at 21:54:24 UTC, Jacob Carlborg wrote: allMembers not returning all members makes introspection entirely useless when it comes to Binderoo. Same problem with Weka's code base...

Re: Functions, nothrow and assert

On Thursday, 8 September 2016 at 11:40:17 UTC, Russel Winder wrote: Is the fact that: void f() nothrow { assert(1 == 0); } int main() { f(); return 0; } compiles fine but at run time f does indeed throw an exception what should happen? If

Re: Functions, nothrow and assert

On Thursday, 8 September 2016 at 11:45:32 UTC, Basile B. wrote: f() is nothrow because assert() throws an "AssertError" not an "Exception". Since Error descendants are not recoverable the program usually crashes. The program is guaranteed to crash unless you catch the error (not

[Issue 16477] Template not properly instantiated / emitted

https://issues.dlang.org/show_bug.cgi?id=16477 Johannes Pfau changed: What|Removed |Added Summary|Template not properly |Template not

[Issue 16477] New: Template not properly instantiated

https://issues.dlang.org/show_bug.cgi?id=16477 Issue ID: 16477 Summary: Template not properly instantiated Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1

Re: Return type deduction

On Monday, 5 September 2016 at 09:59:16 UTC, Andrea Fontana wrote: I asked this some time (years?) ago. Time for a second try :) Consider this: --- T simple(T)() { return T.init; } void main() { int test = simple!int(); // it compiles int test2 = simple();// it doesn't }

Re: Functions, nothrow and assert

On Thursday, 8 September 2016 at 11:40:17 UTC, Russel Winder wrote: Is the fact that: void f() nothrow { assert(1 == 0); } int main() { f(); return 0; } compiles fine but at run time f does indeed throw an exception what should happen? If

Functions, nothrow and assert

Is the fact that: void f() nothrow { assert(1 == 0); } int main() { f(); return 0; } compiles fine but at run time f does indeed throw an exception what should happen? If it is what does nothrow actually mean? -- Russel.

Re: Struct default constructor - need some kind of solution for C++ interop

On Thursday, 8 September 2016 at 11:26:22 UTC, Ethan Watson wrote: Being D though. Destructors can be contracted, yeah? Tested. Confirmed.

Re: Struct default constructor - need some kind of solution for C++ interop

On Thursday, 8 September 2016 at 11:18:12 UTC, Walter Bright wrote: The thing is, the 'destroy()' function is going to swamp any extra clock cycle, as will a virtual lookup and dereference. Assume destroy() is a more trivial function then. The point is that if you put more than two branches

Re: Struct default constructor - need some kind of solution for C++ interop

On 9/8/2016 1:10 AM, Ethan Watson wrote: On Wednesday, 7 September 2016 at 22:52:04 UTC, Walter Bright wrote: Is: if (resource != null) resource.destroy(); v.s.: resource.destroy(); so onerous? It's one TST/JNE pair for a value loaded into a register anyway. This one has

Re: Struct default constructor - need some kind of solution for C++ interop

On Thursday, 8 September 2016 at 10:36:22 UTC, Dicebot wrote: As a workaround I sincerely believe explicit 'create' (with forged mangling if needed) is better. It provides exactly the same functionality without tricking the developet into expecting more by confusion of the syntax similarity.

Re: Battle-plan for CTFE

compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :)

Re: Struct default constructor - need some kind of solution for C++ interop

On Thursday, 8 September 2016 at 09:54:51 UTC, Ethan Watson wrote: On Thursday, 8 September 2016 at 09:33:01 UTC, Dicebot wrote: Instead, it would be much more constructive (pun unintended) to focus on language changes to extern(c++) class bindings to make them suitable for the task - those

Re: Templates problem

On Wed, 2016-09-07 at 16:21 +, Kagamin via Digitalmars-d-learn wrote: > On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder  > wrote: > > > > The real problem though is the terrifying error message. I am  > > having a hard time finding a way of pitching them to  > > Pythonistas. >

Re: Templates problem

On Wed, 2016-09-07 at 20:29 +, deXtoRious via Digitalmars-d-learn wrote: > […] > More to the general point of the discussion, I find that most  > scientifically minded users of Python already appreciate some of  > the inherent advantages of lower level statically typed languages  > and often

Re: Templates problem

On Wed, 2016-09-07 at 20:29 +, jmh530 via Digitalmars-d-learn wrote: > […] > Are you familiar with Chapel at all? The language allows the user  > to specify a domain with an array, facilitating sparsity or  > arrays distributed across different machines. For some reason I  > was reminded of

Re: Struct default constructor - need some kind of solution for C++ interop

On Wednesday, 7 September 2016 at 22:31:17 UTC, Walter Bright wrote: S is initialized to a valid state, meaning the fields are not filled with garbage, and are in a state expected by the member functions. We can write member functions that require a state other than the initial state. I

Generate unique members with recursive mixins or another solution?

Is it possible to generate unique fields and members with recursive template mixins? Each mixin has their own scope even if outer scope shadows their scope. So could it be possible to generate template methods that can access members in their own scopes? Assuming the members are dispatches

Re: Struct default constructor - need some kind of solution for C++ interop

On Thursday, 8 September 2016 at 09:33:01 UTC, Dicebot wrote: Instead, it would be much more constructive (pun unintended) to focus on language changes to extern(c++) class bindings to make them suitable for the task - those won't affect anyone but C++ interop users. I agree in principle,

  1   2   >