Re: Silicon Valley D Meetup January 28, 2016
On 01/28/2016 08:37 PM, Adam D. Ruppe wrote: > I've been listening in on this Why didn't you say hi? :) This has been the first time that we didn't have the attendance list open, so we didn't even know whether others were connected. Come to think of it, I think we were seeing just two connections: Luís and us. Perhaps it was showing just the attendees who had video enabled? Anyway... > and the talk about @nogc on constructors highlights the need to me > of having more attribute inference. Is there a reason why only auto functions have attribute inference? Why not infer all attributes unless they are overridden by explicit attributes? > Yes, it works on templates, but not all methods are templates. Agreed. Ali
[Issue 15621] std.file.rename does not allow moving files to a different drive
https://issues.dlang.org/show_bug.cgi?id=15621 yebblieschanged: What|Removed |Added Keywords||pull Assignee|nob...@puremagic.com|yebbl...@gmail.com --- Comment #1 from yebblies --- Windows rename: https://msdn.microsoft.com/en-us/library/zw5t957f.aspx MoveFileExW: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365240(v=vs.85).aspx https://github.com/D-Programming-Language/phobos/pull/3960 --
Re: `alias this` pointers and typeof(null)
On Friday, 29 January 2016 at 13:38:20 UTC, Tomer Filiba wrote: I can change all such invocations into ``func(FooPtr(null))`` but it's tedious and basically requires me to compile tens of times before I'd cover everything. Is there some workaround to make null implicitly convertible to my alias-this type? I mean, it's Foo* would accept `typeof(null)` so why can't FooPtr with an alias-this to Foo* do so too? -tomer What about this: http://dpaste.dzfl.pl/3305cdf8b7b4 ? Andrea
Re: Overriding opEquals in classes, for comparison with things that aren't Objects
On Friday, 29 January 2016 at 15:00:59 UTC, pineapple wrote: With this bit of code, the first method seems to work fine - things go as expected. But I get a compile error with the second method, and I'm not sure how else to write this. override bool opEquals(Object value) const{ return this.equals(cast(typeof(this)) value); } override bool opEquals(T)(T value) const if(isNumeric!(T)){ return this.equals(value); } The compile errors I get look like this: C:\path\to\file.d(477): Error: function units.quantity.opEquals!int.opEquals cannot override a non-virtual function C:\path\to\file.d(519): Error: template instance units.quantity.opEquals!int error instantiating How can I revise this so that I can override comparison operators for things other than class instances? The first implementation is fine because you're overriding the implementation in the base class (Object). However, the second one fails because it's a template. Templates are non-virtual and cannot override anything. Even if you could, there is no such implementation in Object and, therefore, nothing to override. Templated functions can be used as overloads, though, but I'm not sure off the top of my head if the compiler accepts templated opEquals on classes at all. My guess is no, but you can find out by removing the override from the template declaration. If not, you should be able to implement non-templated overloads for the types you're interested in (without the override keyword, mind you, since they won't be overriding anything).
Re: Why is it a memory ERRO.
On Friday, 29 January 2016 at 13:22:07 UTC, Mike Parker wrote: Your problem is probably that you are calling GC.free in the destructor. Don't do this. You don't need to call GC.free at all. The GC will collect both your object instance and the memory you allocated with new. Never, ever, manipulate GC memory in the destructor of a GC-managed object. Here's a modified version of your program. Every time it prints, you know the garbage collector has just run a collection cycle. Every class instance and every 'by' that is allocated will eventually be free. Not all destructors are guaranteed to run during the program's lifetime, though. Some will be run after main exits and the GC shuts down. import core.thread; import std.stdio; class MyClass { this(){ by = new ubyte[1]; id = i; ++i; } ~this() { writeln("freed #", id); } private: ubyte[] by; int id; static int i; }; void main() { while(true) { auto obj = new MyClass; Thread.sleep(5.msecs); if(MyClass.i == 2000) break; } }
`alias this` pointers and typeof(null)
I had a struct (Foo) that was passed by pointer (i.e., Foo*) throughout my code. To prevent dangling pointers, I created a `FooPtr` struct with an `alias this` that does some checks before returning me the underlying pointer. This is sort-of what I have: struct FooPtr { Foo* ptr; this(Foo* p) {ptr = p;} @property auto get() {return ptr;} alias get this; } I changed all `Foo*` into `FooPtr` and it's great, but I have numerous places where `null` is used literally, and its type is `typeof(null)`. So void func(FooPtr x) {} func(null); fails with ``Error: function func (FooPtr x) is not callable using argument types (typeof(null))`` I can change all such invocations into ``func(FooPtr(null))`` but it's tedious and basically requires me to compile tens of times before I'd cover everything. Is there some workaround to make null implicitly convertible to my alias-this type? I mean, it's Foo* would accept `typeof(null)` so why can't FooPtr with an alias-this to Foo* do so too? -tomer
Re: Movable resource handles
On Thursday, 28 January 2016 at 06:13:32 UTC, Era Scarecrow wrote: On Thursday, 28 January 2016 at 05:39:55 UTC, Era Scarecrow wrote: It really comes down to that an array qualifies as an Lvalue operator; But I _think_ this is a bug in the language since you should be able to assign a new Rvalue to a new array element just being created/added. We'll have to get input from Walter or Andrei. Alright, closest bug match i could find is https://issues.dlang.org/show_bug.cgi?id=7032 which is sorta the same thing, but not quite... Ah, ok. A bug is better than a language design limitation -- it might get fixed at some point! I'll figure out a workaround for my use case. Thanks for all the time you spent, I appreciate the help.
Re: reduce -> fold?
On Friday, 29 January 2016 at 13:56:48 UTC, Dragos Carp wrote: But not in python, where "accumulate"[1] is the generic equivalent of C++ "partial_sum"[2]. I like "fold" more. BTW this week, a colleague of mine implemented a python "accumulate" in D. Is there any interest to contribute it to Phobos? How should this be named? [1] https://docs.python.org/3/library/itertools.html#itertools.accumulate [2] http://en.cppreference.com/w/cpp/algorithm/partial_sum Fair enough. Yes, that is indeed a useful algorithm, so please do contribute. I won't bikeshed on that other name, heh.
Re: reduce -> fold?
On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote: Just to bikeshed a little, I remember that when I first started using std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite often. D competes with C++ directly, so do consider that name :-) But not in python, where "accumulate"[1] is the generic equivalent of C++ "partial_sum"[2]. I like "fold" more. BTW this week, a colleague of mine implemented a python "accumulate" in D. Is there any interest to contribute it to Phobos? How should this be named? [1] https://docs.python.org/3/library/itertools.html#itertools.accumulate [2] http://en.cppreference.com/w/cpp/algorithm/partial_sum
Overriding opEquals in classes, for comparison with things that aren't Objects
With this bit of code, the first method seems to work fine - things go as expected. But I get a compile error with the second method, and I'm not sure how else to write this. override bool opEquals(Object value) const{ return this.equals(cast(typeof(this)) value); } override bool opEquals(T)(T value) const if(isNumeric!(T)){ return this.equals(value); } The compile errors I get look like this: C:\path\to\file.d(477): Error: function units.quantity.opEquals!int.opEquals cannot override a non-virtual function C:\path\to\file.d(519): Error: template instance units.quantity.opEquals!int error instantiating How can I revise this so that I can override comparison operators for things other than class instances?
Re: Overriding opEquals in classes, for comparison with things that aren't Objects
It also occurred to me to do something like this, but it isn't accepted either. override bool opEquals(T)(T value){ return this.equals(value); }
Re: Why is it a memory ERRO.
On Friday, 29 January 2016 at 12:43:53 UTC, Dsby wrote: the Code: ~this(){ GC.free(by.ptr); by = null; writeln("free"); } Your problem is probably that you are calling GC.free in the destructor. Don't do this. You don't need to call GC.free at all. The GC will collect both your object instance and the memory you allocated with new. Never, ever, manipulate GC memory in the destructor of a GC-managed object.
Re: `alias this` pointers and typeof(null)
On Friday, 29 January 2016 at 13:59:15 UTC, Andrea Fontana wrote: What about this: http://dpaste.dzfl.pl/3305cdf8b7b4 ? Andrea Thanks Andrea, I thought about it but it requires duplicating all function signatures (and not in an automatic manner). Btw, you can also write ``void func(typeof(null) x) {}`` instead.
Re: D vs Rust
On Friday, 29 January 2016 at 07:01:07 UTC, Sönke Ludwig wrote: Am 29.01.2016 um 00:18 schrieb Ola Foaheim Grøstad: D is closer to C++ style templating and OO, and currently focus on enabling binding to non-template C++ libraries. Small correction: Should be "binding to template based C++ libraries" - non-template libraries have worked more or less for a while now. I was thinking of Walter's work on supporting C++ exceptions as completing the effort to bind to non-templated libraries; exceptions being the "return value" for failure. Is there an effort to support templated libraries? They are often fully inlined and header-only?
Re: D vs Rust
On Thursday, 28 January 2016 at 22:30:51 UTC, nbro wrote: Apart from [syntax], what are the real advantages of D over Rust? D is a broader language and is applicable in more situations. In many cases you don't care and don't want to care about memory management. Use D and its garbage collector and be done with it. Rust forces you to think about memory management all the time, because it type checks life times. If you hit some performance wall during development, then Ds toolbox allows you to work around the GC in specific places. So, convenience first and performance where necessary. No premature optimization. If you need more programmers, D is easier to learn, due to its syntax. Simple C, Java and even C++ programs can be very directly ported to D. For example, the D compiler frontend was converted from C++ to D algorithmically. This does not work with Rust, where the type checker will complain a lot. D is more mature than Rust at the moment. Less backwards incompatible changes. More reliability and stability. D has three different backends with different strengths. With dmd you have really fast compilation, which is great for development. With the LLVM and GCC backends you get better performance for release builds. With GCC you can compile for many architectures (although you might need to port the runtime).
Re: What are the real GUI toolkits for D?
On Friday, 29 January 2016 at 10:18:31 UTC, interessted wrote: On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon wrote: On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote: Except for GtkD and DWT, D does not seem to be supported by a really nice GUI toolkit. For Windows DFL is quite nice and working well (I've used it in several projects). where can one find a working DFL version - compilable with the last compiler? sorry forgot - and running for win64, since nobody i know still uses/creates x32.
Re: C++17
https://www.reddit.com/r/cpp/comments/41uflq/bjarne_stroustrup_doing_an_ama/ Mentions D.
Re: reduce -> fold?
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote: As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders. So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Thoughts? YES! There was a topic on this [1] and some implementation proposed. I'm not sure if it was the only one. [1] http://forum.dlang.org/post/sqbizjwcyavbrxwag...@forum.dlang.org
Re: reduce -> fold?
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote: So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Just to bikeshed a little, I remember that when I first started using std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite often. D competes with C++ directly, so do consider that name :-)
Re: What are the real advantages that D offers in multithreading?
On Thursday, 28 January 2016 at 22:59:58 UTC, cym13 wrote: On Thursday, 28 January 2016 at 11:53:48 UTC, Russel Winder wrote: It should be pointed out that anyone using the synchronized keyword anywhere in Java code is doing concurrent and parallel programming wrong. If they are using synchronized in single threaded programming well, then… [...] I have seen you talk about this before and I too would love you to elaborate on the subject. One of the most obvious problems with using `synchronized` on methods, or using `synchronized(this)`, is that an object has no control over its monitor. All code that can see a particular instance can choose to synchronize on that instance, which creates opportunities for deadlocks. This problem can be avoided by controlling access to the monitor you use. One of the easiest ways to control access to your monitor is by having a private object to synchronize on (e.g. `private final Object lock = new Object();`) instead of synchronizing on `this`. Further improvements can be made by explicitly using one of the classes found in java.util.concurrent.locks: this allows you to be more explicit by, for instance, choosing a ReadWriteLock, and it provides access to proper conditions. Another problem with `synchronized` in Java is that it requires all objects to contain an implicit monitor, while the vast majority of objects will never get synchronized on: for all those objects this is useless overhead. Sadly backwards compatibility implies that Java will likely never be able to entirely get rid of this overhead.
reduce -> fold?
As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders. So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Thoughts? Andrei
Re: D vs Rust
On Friday, 29 January 2016 at 07:01:07 UTC, Sönke Ludwig wrote: Small correction: Should be "binding to template based C++ libraries" - non-template libraries have worked more or less for a while now. Actually less. Without RAII you can't bind any realistic C++ library like Qt.
[Issue 15619] [REG 2.068] Floating-point x86_64 codegen regression, when involving array ops
https://issues.dlang.org/show_bug.cgi?id=15619 poncechanged: What|Removed |Added Summary|[REG 2.068] Floating-point |[REG 2.068] Floating-point |x86_64 codegen regression |x86_64 codegen regression, ||when involving array ops --
Re: What are the real GUI toolkits for D?
On Friday, 29 January 2016 at 11:30:41 UTC, Suliman wrote: On Friday, 29 January 2016 at 10:41:03 UTC, interessted wrote: On Friday, 29 January 2016 at 10:18:31 UTC, interessted wrote: On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon wrote: On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote: Except for GtkD and DWT, D does not seem to be supported by a really nice GUI toolkit. For Windows DFL is quite nice and working well (I've used it in several projects). where can one find a working DFL version - compilable with the last compiler? sorry forgot - and running for win64, since nobody i know still uses/creates x32. http://code.dlang.org/packages/dformlib thank you. but trying to compile i get - ex.: Error Error: function dfl.control.ControlSuperClass.wndProc does not override any function C:\proggies\D\dfl\src\dfl\control.d 6510 or SeverityCodeDescription Project FileLineSuppression State Error Error: overlapping default initialization for field droptarget and ldlgcode C:\proggies\D\dfl\src\dfl\control.d 603 anything i do wrong?
Re: C++17
On Friday, 29 January 2016 at 10:43:08 UTC, Ola Fosheim Grøstad wrote: https://www.reddit.com/r/cpp/comments/41uflq/bjarne_stroustrup_doing_an_ama/ Mentions D. Since it is in danish, let me quickly translate the informative sections: Bjarne Stroustrup (translated from danish): The safety rules is part of the more extensive guidelines (https://github.com/isocpp/CppCoreGuidelines ) and supported by a small library (https://github.com/microsoft/gsl ) . We have "annotations" which can be used to neutralize the rules (as an "unsafe" annotation). We minimize their usage. Our goal is 100% safety and I assume that we will get as close to that goals as any language that can work directly with hardware. We already have 100% resource safety, and that is better than languages like Java and C#. I think all languages will become better in these areas.» On garbage collection: Bjarne Stroustrup (translated from danish): Yes, programming language creators and researchers have always been fascinated by garbage collection. I think that is a mistake: GC is not general - it cannot deal with non-memory resources - and is not ideal - it introduces a central facility in (otherwise) distributed systems. The good solution is to not produce garbage: http://www.stroustrup.com/resource-model.pdf . RAII is central in my ideas about programming. He also acknowledges scandinavian contributions to programming languages, the OO languages Simula and Beta.
math libraries
are you handling this in the math libs? http://milesmathis.com/pi2.html http://milesmathis.com/pi4.html
Re: What are the real GUI toolkits for D?
On Friday, 29 January 2016 at 12:12:40 UTC, interessted wrote: On Friday, 29 January 2016 at 11:30:41 UTC, Suliman wrote: On Friday, 29 January 2016 at 10:41:03 UTC, interessted wrote: On Friday, 29 January 2016 at 10:18:31 UTC, interessted wrote: On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon wrote: On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote: Except for GtkD and DWT, D does not seem to be supported by a really nice GUI toolkit. For Windows DFL is quite nice and working well (I've used it in several projects). where can one find a working DFL version - compilable with the last compiler? sorry forgot - and running for win64, since nobody i know still uses/creates x32. http://code.dlang.org/packages/dformlib thank you. but trying to compile i get - ex.: fixing some imports etc this remains: SeverityCodeDescription Project FileLineSuppression State Error Error: static assert (136LU == 152LU) is false C:\xxx\D\dfl\src\dfl\filedialog.d 409
[Issue 15622] New: Order of execution of module destructors is not always correct
https://issues.dlang.org/show_bug.cgi?id=15622 Issue ID: 15622 Summary: Order of execution of module destructors is not always correct Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: yazan.dab...@gmail.com import core.stdc.stdio; import std.parallelism; static ~this() { printf("%.*s\n", __FUNCTION__.length, __FUNCTION__.ptr); } shared static ~this() { printf("%.*s\n", __FUNCTION__.length, __FUNCTION__.ptr); } void main() { auto t = new TaskPool(); t.isDaemon = true; } -- The previous code prints: main._staticDtor1 main._sharedStaticDtor2 main._staticDtor1 main._staticDtor1 main._staticDtor1 -- Per http://dlang.org/spec/module.html#staticorder, shared static destructors are defined to run after all other static destructors but in this case that is not happening. Original bug report: https://github.com/rejectedsoftware/vibe.d/issues/1374 --
d plugin for Intelij Idea debuging support
Hello! Is there any debuging support for Intelij Idea's D plugin? Thanks!
Why is it a memory ERRO.
the Code: class MyClass { this(){ by = new ubyte[1]; ++i; } ~this(){ GC.free(by.ptr); by = null; writeln("free"); } void show(){ writeln(i); }; private: ubyte[] by; static i = 0; }; void main() { bool start = true; int i = 0; while(start){ auto obj = new MyClass(); obj.show(); Thread.sleep(5.msecs); //obj.destroy; //GC.free(cast(void *)obj); ++i; if (i > 2) break; } } the code will be : 341 core.exception.InvalidMemoryOperationError@src/core/exception.d(679): Invalid memory operation core.exception.InvalidMemoryOperationError@src/core/exception.d(679): Invalid memory operation .why is it? if < obj.destroy; > is exec. the code will not errno.
Re: What are the real GUI toolkits for D?
On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon wrote: On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote: Except for GtkD and DWT, D does not seem to be supported by a really nice GUI toolkit. For Windows DFL is quite nice and working well (I've used it in several projects). Some one should update the DFL web page and forums. There is a few post asking if DFL is dead, when there is at least 3 forks or updates to D2 on http://code.dlang.org/search?q=dfl
Re: What are the real GUI toolkits for D?
On Friday, 29 January 2016 at 10:41:03 UTC, interessted wrote: On Friday, 29 January 2016 at 10:18:31 UTC, interessted wrote: On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon wrote: On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote: Except for GtkD and DWT, D does not seem to be supported by a really nice GUI toolkit. For Windows DFL is quite nice and working well (I've used it in several projects). where can one find a working DFL version - compilable with the last compiler? sorry forgot - and running for win64, since nobody i know still uses/creates x32. http://code.dlang.org/packages/dformlib
Re: Why is it a memory ERRO.
On Friday, 29 January 2016 at 12:43:53 UTC, Dsby wrote: the Code: class MyClass { this(){ by = new ubyte[1]; ++i; } ~this(){ GC.free(by.ptr); by = null; writeln("free"); } void show(){ writeln(i); }; private: ubyte[] by; static i = 0; }; void main() { bool start = true; int i = 0; while(start){ auto obj = new MyClass(); obj.show(); Thread.sleep(5.msecs); //obj.destroy; //GC.free(cast(void *)obj); ++i; if (i > 2) break; } } the code will be : 341 core.exception.InvalidMemoryOperationError@src/core/exception.d(679): Invalid memory operation core.exception.InvalidMemoryOperationError@src/core/exception.d(679): Invalid memory operation .why is it? if < obj.destroy; > is exec. the code will not errno. I am in 2.069, on opensuse leap 42.1 X86_64 dmd -v DMD64 D Compiler v2.069 Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
Re: What are the real GUI toolkits for D?
I think what to make "pure" GUI for D there is a waste of time and forces. More effectively and faster to develop "wrapper" for Qt. For myself I have made library QtE which possibilities suffice me much. The main feature that addition of a new method or property from Qt in QtE occupies only five minutes. By the current moment in QtE is 340 of functions Qt 4.8 "are wrapped up". For beginning studying of programming language D, library QtE is the best decision. QtE is checked up in Windows 32/64 and Linux 32/64 and depends from Qt 4.8.x. In the near future I plan to transfer it on MAC OS X 10.9 (64). https://github.com/MGWL/QtE-Qt_for_Dlang_and_Forth Some screenshots Screen Windows http://qte.ucoz.ru/QtE_win_2.png Screen Linux http://qte.ucoz.ru/QtE_linux_2.png simple example: Hello.d import qte; import core.runtime;// parametr start int main(string[] args) { bool fDebug; foreach (arg; args) if (arg=="--debug") fDebug = true; int rez = LoadQt( dll.Core | dll.Gui | dll.QtE, fDebug); if (rez==1) return 1; // Error load QtE QApplication app = new QApplication(, Runtime.cArgs.argv, 1); QLabel label = new QLabel(null); label.setText(“ --- Hello from QtE ---”); label.setAlignment(QtE.AlignmentFlag.AlignCenter); label.resize(300, 130); label.show(); return app.exec(); } Compile and execute: rdmd Hello qte
Re: merging map/filter/reduce/... in D
Thanks. I am glad be wrong on that one. I had a look at map & filter in the source code ; pleased to see they're lazily implemented! map https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L425 filter https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L924 I had to look for FilterResult! https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L979 Small remark: One could make the laziness of filter a bit more clear in the doc though - at least for newbies like me. http://dlang.org/phobos/std_algorithm_iteration.html Best regards, Guillaume
Re: D vs Rust
On Friday, 29 January 2016 at 08:26:01 UTC, John Colvin wrote: It depends what you mean by templated. I believe the interoperability work is for the results of instantiated templates, not on the templates themselves. Hmm, not sure how important that is. At least in my C++ class templates most member functions tend to be inline, so they shouldn't end up in an object file.
Re: What are the real GUI toolkits for D?
On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon wrote: On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote: Except for GtkD and DWT, D does not seem to be supported by a really nice GUI toolkit. For Windows DFL is quite nice and working well (I've used it in several projects). where can one find a working DFL version - compilable with the last compiler?
[Issue 15621] New: std.file.rename does not allow moving files to a different drive
https://issues.dlang.org/show_bug.cgi?id=15621 Issue ID: 15621 Summary: std.file.rename does not allow moving files to a different drive Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: yebbl...@gmail.com On windows std.file.rename calls MoveFileExW, which will not move files from once device to another unless the MOVEFILE_COPY_ALLOWED flag is set. Since the cstdio function with the same name doesn't have this limitation, and it's not documented, it seems accidental. --
Re: D vs Rust
On Friday, 29 January 2016 at 08:23:38 UTC, Ola Fosheim Grøstad wrote: On Friday, 29 January 2016 at 07:01:07 UTC, Sönke Ludwig wrote: Am 29.01.2016 um 00:18 schrieb Ola Foaheim Grøstad: D is closer to C++ style templating and OO, and currently focus on enabling binding to non-template C++ libraries. Small correction: Should be "binding to template based C++ libraries" - non-template libraries have worked more or less for a while now. I was thinking of Walter's work on supporting C++ exceptions as completing the effort to bind to non-templated libraries; exceptions being the "return value" for failure. Is there an effort to support templated libraries? They are often fully inlined and header-only? It depends what you mean by templated. I believe the interoperability work is for the results of instantiated templates, not on the templates themselves.
Re: merging map/filter/reduce/... in D
On Friday, 29 January 2016 at 08:06:14 UTC, glathoud wrote: Thanks. I am glad be wrong on that one. I had a look at map & filter in the source code ; pleased to see they're lazily implemented! map https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L425 filter https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L924 I had to look for FilterResult! https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L979 Small remark: One could make the laziness of filter a bit more clear in the doc though - at least for newbies like me. http://dlang.org/phobos/std_algorithm_iteration.html Best regards, Guillaume While it's not entirely true because one can implement a non-lazy range, any time you see the word "range" in the documentation you should think that it is lazy. Ranges are an important concept in D so we usually don't bother explaining it in the doc. You can read about it here if you need to: http://ddili.org/ders/d.en/ranges.html and http://dlang.org/phobos/std_range.html
Re: Overriding opEquals in classes, for comparison with things that aren't Objects
On Friday, 29 January 2016 at 15:13:45 UTC, Mike Parker wrote: The first implementation is fine because you're overriding the implementation in the base class (Object). However, the second one fails because it's a template. Templates are non-virtual and cannot override anything. Even if you could, there is no such implementation in Object and, therefore, nothing to override. Templated functions can be used as overloads, though, but I'm not sure off the top of my head if the compiler accepts templated opEquals on classes at all. My guess is no, but you can find out by removing the override from the template declaration. If not, you should be able to implement non-templated overloads for the types you're interested in (without the override keyword, mind you, since they won't be overriding anything). Hm, I should've thought to try that. I was able to get things working as I wanted them to by doing this: override bool opEquals(Object value) const{ return this.equals(cast(typeof(this)) value); } bool opEquals(T)(T value){ return this.equals(value); }
Re: is(some template instantiation) is true, but the actual instantiation fails
On Friday, 29 January 2016 at 15:28:29 UTC, Adrian Matoga wrote: How can I reliably test if CallsFoo can be instantiated? You can use a constraint to prevent invalid instantiation: struct HasFoo { void foo() {} } struct NoFoo {} struct CallsFoo(T) if (__traits(hasMember, T, "foo")) { T t; void bar() { t.foo(); } } static assert(is(CallsFoo!HasFoo)); static assert(!is(CallsFoo!NoFoo));
Re: Vision for the first semester of 2016
On Thursday, 28 January 2016 at 12:40:56 UTC, Ola Fosheim Grøstad wrote: I think that Sonke received too much "negative motivation" for his contributions recently, if I had been in his shoes I'd probably found working on vibe.d more fun. IRRC Ruppe also have voiced that he want to work on libraries which he has more freedom with. Yeah, I think getting in Phobos is a waste of time and likely a net negative on the library due to how much harder it is to change phobos vs changing your own file. In my perfect world, quality third party apps - as determined just by usage stats or something - would be automatically downloadable and their documentation searchable as if it was standard. When you do `import std.string;` you expect it to just work, and you find std.string's docs easily from dmd. I'd love it if you could do `import thirdparty.independent;` and it magically works too - without even need for a configuration file or an install command. And the docs are right there and tutorials are written however the author feels like writing them. Then the line between "standard library" and other library basically disappears. While that isn't likely to happen, we could at least start promoting third party stuff more equally. An frankly, as APIs have to be vetted on large applications in maintenance mode a lot of the effort put into arguing the design "perfect Phobos libraries" most likely will be in vain. This is a reason why I tend to only write libs that I actually use myself - at least then I know every function has one happy user.
[Issue 15623] New: is(M!N) evaluates to true for M!N that fails to instantiate.
https://issues.dlang.org/show_bug.cgi?id=15623 Issue ID: 15623 Summary: is(M!N) evaluates to true for M!N that fails to instantiate. Product: D Version: D2 Hardware: x86_64 OS: All Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: e...@atari8.info struct HasFoo { void foo() {} } struct NoFoo {} struct CallsFoo(T) { T t; void bar() { t.foo(); } } static assert(is(CallsFoo!HasFoo)); static assert(is(typeof({ alias Baz = CallsFoo!HasFoo; return Baz.init; }(; static assert(__traits(compiles, { alias Baz = CallsFoo!HasFoo; return Baz.init; }())); alias Bar = CallsFoo!HasFoo; // this should fail: static assert(is(CallsFoo!NoFoo)); // this should fail too: static assert(is(typeof({ alias Baz = CallsFoo!NoFoo; return Baz.init; }(; // this too: static assert(__traits(compiles, { alias Baz = CallsFoo!NoFoo; return Baz.init; }())); // only this fails: //alias Baz = CallsFoo!NoFoo; // (1) --
Re: `alias this` pointers and typeof(null)
On Friday, 29 January 2016 at 13:38:20 UTC, Tomer Filiba wrote: I can change all such invocations into ``func(FooPtr(null))`` but it's tedious and basically requires me to compile tens of times before I'd cover everything. Is there some workaround to make null implicitly convertible to my alias-this type? I mean, it's Foo* would accept `typeof(null)` so why can't FooPtr with an alias-this to Foo* do so too? -tomer Unfortunately D is strictly against implict conversion, so there is no way to do this. I also hit this issue a couple of times already. But implicitly calling a constructor in C++ is considered error prone and therefor not supported in D. Kind Regards Benjamin Thaut
Re: What are the real GUI toolkits for D?
On Friday, 29 January 2016 at 10:41:03 UTC, interessted wrote: where can one find a working DFL version - compilable with the last compiler? The last compiler is just 1 day old, don't expect all libs updated this soon. ;) Usually I took DFL here: https://github.com/Rayerd/dfl/ There are many forks and branches now: https://github.com/Rayerd/dfl/network sorry forgot - and running for win64, since nobody i know still uses/creates x32. This rep seems quite active, includes 64-bit versions too: https://github.com/qchikara/dfl/branches The last version I personally used (32-bit) : https://github.com/thedeemon/dfl (includes some my own fixes)
Re: Assert failure on 2.070.0 without stack trace
On Thursday, 28 January 2016 at 18:33:19 UTC, Nordlöw wrote: Thanks, I'm aware of these tools. But it's easier to use the stacktrace...if I only get one. The function where the assert() is called is, in turn, called in hundreds of places. Which platform are you on? Are all your binaries compiled with debug symbols? If one or multiple functions on the stack are within phobos or druntime you might not have debug symbols for phobos or druntime. Using inline asm might also destroy your stack frames.
Re: D vs Rust
qznc: On Friday, 29 January 2016 at 09:00:52 UTC, qznc wrote: D is a broader language and is applicable in more situations. In many cases you don't care and don't want to care about memory management. Learning to manage memory in Rust takes lot of time and practice, it's a bit painful. I am sometimes able to write working D code almost as quickly as Python code, but writing similar code in Rust takes me much more time. So I think for both small script-like programs, and general application code (where code safety is not the most important thing), D wins over Rust. D is also more flexible (higher order templates, better CTFE, unrestricted UFCS, etc), and you can port Python or C code to D faster than to Rust. So I think Rust targets a smaller number of coding purposes compared to D. Rust could also replace the code you want to write in OcaML, like compiler-like programs (thanks to Rust enums and pattern matching). Safety and correctness of the code are very important for me. Regarding safety & correctness I think there's this ordering: Rust > D > C++14 > C If you talk about correctness you think about Ada too. Rust code seems usually more succinct compared to Ada code. Ada is more mature and it has lot of small features missing from Rust/D, that help make the code more correct (like integer subsets, static invariants, stronger typing for array indexing, SPARK annotations to manage global mutables safely, and so on). I don't know if such safety features will be added to Rust, I am dubious. In the C/Ada world you have language subsets like MISRA/SPARK that people use in high integrity system. I think Rust still lacks something like that. Bye, bearophile
Re: reduce -> fold?
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote: As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders. So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Thoughts? Andrei Absolutely yes!
Re: reduce -> fold?
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote: As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders. So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Thoughts? Andrei Yes yes yes please!
Re: reduce -> fold?
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote: As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders. So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Thoughts? Andrei I think yes. Took me ages to realise the difference with reduce.
Re: reduce -> fold?
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote: As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders. So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Thoughts? Andrei +1 Let's make sure to write the half dozen other names for it in the documentation so people coming to D from other languages can easily find it. And just for completeness, here is monarchdodra's valiant but ultimately unsuccessful pull request which attempted fix reduce: https://github.com/D-Programming-Language/phobos/pull/861#issuecomment-20760448
Re: is(some template instantiation) is true, but the actual instantiation fails
On 1/29/16 10:28 AM, Adrian Matoga wrote: Code: struct HasFoo { void foo() {} } struct NoFoo {} struct CallsFoo(T) { T t; void bar() { t.foo(); } } static assert(is(CallsFoo!HasFoo)); alias Bar = CallsFoo!HasFoo; static assert(is(CallsFoo!NoFoo)); // (1) //alias Baz = CallsFoo!NoFoo; // (2) This compiles, although I expected that (1) should fail. Now try uncommenting (2) and it can't be compiled. Why does `is(CallsFoo!NoFoo)` evaluate to true if `is(CallsFoo!NoFoo)` can't be instantiated? Am I missing something about `is(T)` or is it a bug? How can I reliably test if CallsFoo can be instantiated? is(T) is supposed to be false if T is not a valid type. I would agree with you that the static assert should fail. -Steve
is(some template instantiation) is true, but the actual instantiation fails
Code: struct HasFoo { void foo() {} } struct NoFoo {} struct CallsFoo(T) { T t; void bar() { t.foo(); } } static assert(is(CallsFoo!HasFoo)); alias Bar = CallsFoo!HasFoo; static assert(is(CallsFoo!NoFoo)); // (1) //alias Baz = CallsFoo!NoFoo; // (2) This compiles, although I expected that (1) should fail. Now try uncommenting (2) and it can't be compiled. Why does `is(CallsFoo!NoFoo)` evaluate to true if `is(CallsFoo!NoFoo)` can't be instantiated? Am I missing something about `is(T)` or is it a bug? How can I reliably test if CallsFoo can be instantiated?
InSituRegion + allocatorObject compile time error
Getting this error, could someone explain why? void main(string[] args) { InSituRegion!(1024) stackAlloc; IAllocator alloc = allocatorObject(stackAlloc); } ..\src\phobos\std\conv.d(5055): Error: static assert "Don't know how to initialize an object of type CAllocatorImpl!(InSituRegion!(1024u, 8u), cast(Flag)false) with arguments (InSituRegion!(1024u, 8u))" ..\src\phobos\std\experimental\allocator\package.d(1175): instantiated from here: emplace!(CAllocatorImpl!(InSituRegion!(1024u, 8u), cast(Flag)false), InSituRegion!(1024u, 8u)) main.d(15): instantiated from here: allocatorObject!(InSituRegion!(1024u, 8u)) Thank you
RC vibe.d 0.7.27-rc.2
Am 22.01.2016 um 12:14 schrieb Sönke Ludwig: I've finally managed to tag a first beta for vibe.d. It contains numerous optimizations in the network and HTTP code, so it's especially important to thoroughly test this before release. 0.7.26 (except for the win32 driver) still compiles fine on DMD 2.070.0, so a fully synchronized release is fortunately not essential this time. http://code.dlang.org/packages/vibe-d/0.7.27-beta.1 Changelog: https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md A release candidate is now up for testing. If now further issues come up, this will be tagged as 0.7.27 next week. http://code.dlang.org/packages/vibe-d/0.7.27-rc.2
Re: reduce -> fold?
On Friday, 29 January 2016 at 16:38:23 UTC, Brad Anderson wrote: And just for completeness, here is monarchdodra's valiant but ultimately unsuccessful pull request which attempted fix reduce: https://github.com/D-Programming-Language/phobos/pull/861#issuecomment-20760448 Interestingly, that pull request links to another pull request which introduces fold, so we can just merge that one :) ? https://github.com/D-Programming-Language/phobos/pull/2033
Re: Release D 2.070.0
On Friday, 29 January 2016 at 17:49:58 UTC, Nick Sabalausky wrote: I don't recall: Does that parse the source for comments on its own or does it still use dmd's json (or html) output? Does it on its own. (Well, except the search results page, it still uses the json, but I'm fixing that soon and the main body pages already do their own thing.) Brian Schott's libdparse does the bulk of the work, independently of dmd. A big reason for this is that doing changes on dmd is a pain in the butt, and another one is that dmd is optimized toward compiling code (as it should be!) which isn't always ideal for doc generation (like version(Windows) docs being left out if you happen to be on a Linux box.) So doing it myself frees me from dmd's design constraints as well as dmd's development process.
Re: Vision for the first semester of 2016
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote: Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei Just out of curiosity, is getting the different compilers in sync still a priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066.
Re: is(some template instantiation) is true, but the actual instantiation fails
On Friday, 29 January 2016 at 16:36:01 UTC, Steven Schveighoffer wrote: On 1/29/16 10:28 AM, Adrian Matoga wrote: Code: struct HasFoo { void foo() {} } struct NoFoo {} struct CallsFoo(T) { T t; void bar() { t.foo(); } } static assert(is(CallsFoo!HasFoo)); alias Bar = CallsFoo!HasFoo; static assert(is(CallsFoo!NoFoo)); // (1) //alias Baz = CallsFoo!NoFoo; // (2) This compiles, although I expected that (1) should fail. Now try uncommenting (2) and it can't be compiled. Why does `is(CallsFoo!NoFoo)` evaluate to true if `is(CallsFoo!NoFoo)` can't be instantiated? Am I missing something about `is(T)` or is it a bug? How can I reliably test if CallsFoo can be instantiated? is(T) is supposed to be false if T is not a valid type. I would agree with you that the static assert should fail. -Steve Oh, there's more: // this should fail: static assert(is(CallsFoo!NoFoo)); // this should fail too: static assert(is(typeof({ alias Baz = CallsFoo!NoFoo; return Baz.init; }(; // and this: static assert(__traits(compiles, { alias Baz = CallsFoo!NoFoo; return Baz.init; }())); // but only this fails: alias Baz = CallsFoo!NoFoo; https://issues.dlang.org/show_bug.cgi?id=15623
opApply @safety
I want to create an opApply for a type. I've marked my code @safe, because everything I wrote was @safe. The body of opApply is @safe, but it calls a delegate that may or may not be @safe. How do I make it so I can iterate through this type safely and systemly? I want to support iteration like: foreach (string key, string value; collection) {} foreach (size_t i, string key, string value; collection) {}
Re: D vs Rust
On Friday, 29 January 2016 at 15:39:53 UTC, bearophile wrote: D is also more flexible (higher order templates, better CTFE, unrestricted UFCS, etc), and you can port Python or C code to D faster than to Rust. So I think Rust targets a smaller number of coding purposes compared to D. Which purposes and why?
Re: D vs Rust
On Friday, 29 January 2016 at 12:05:08 UTC, Kagamin wrote: Actually less. Without RAII you can't bind any realistic C++ library like Qt. My understanding is that D has a lot of options for behavior similar to RAII, but it does not have the full capability. What would be the most important thing for D to change to improve the experience of binding to C++?
Re: Vision for the first semester of 2016
On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote: >> >> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei > > > Just out of curiosity, is getting the different compilers in sync still a priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066. If anyone wants to help out... I have to also juggle working on GCC and GDB. :-) When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect it to stay there for a while...
Re: Release D 2.070.0
On 01/29/2016 11:09 AM, Adam D. Ruppe wrote: On Thursday, 28 January 2016 at 19:46:48 UTC, Nick Sabalausky wrote: Use dpldocs.info. We have good docs. That's orthogonal to this. It is just another example of why I feel it is necessary to take a different direction than dmd. I see. Good point. You've probably answered this elsewhere, but I don't recall: Does that parse the source for comments on its own or does it still use dmd's json (or html) output? Unless it does the parsing 100% on its own, then it would still suffer from the issue that PR addresses.
DMD 2.070.0 - The package is of bad quality
I get the following downloading and installing the Ubuntu x86_64 deb file. The package is of bad quality The installation of a package which violates the quality standards isn't allowed. This could cause serious problems on your computer. Please contact the person or organisation who provided this package file and include the details beneath. Lintian check results for /home/gary/Desktop/dmd_2.070.0-0_amd64.deb: Can't close(GLOB(0xddf540)) filehandle: '' at /usr/share/lintian/helpers/coll/objdump-info-helper line 192 command failed with error code 123 at /usr/share/lintian/collection/objdump-info line 79. warning: collect info objdump-info about package dmd failed warning: skipping check of binary package dmd
Re: Vision for the first semester of 2016
On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote: In my perfect world, quality third party apps - as determined just by usage stats or something - would be automatically downloadable and their documentation searchable as if it was standard. I've noticed that curated lists of libraries are popping up on github for various languages: https://github.com/search?utf8=%E2%9C%93=awesome If D gets more users maybe there would be a market for a commercial IDE with a reviewed repository with globally searchable reference documentation and cookbook recipes. For popular languages stack overflow is pretty ok, but over time it is getting more chaotic. Imagine an intelligent IDE that looks at the probability of a match between a cookbook recipe and what you type. A.I. templating of sorts. Then the line between "standard library" and other library basically disappears. I usually prefer to download from github for commercial code and put it in my project archive. I want to check out if the library programmers are maintaining it and have enough people as well. Then I lock that version until I find a reason to upgrade. For me automatic downloading (dub etc) fits more with hobby projects and experiments. While that isn't likely to happen, we could at least start promoting third party stuff more equally. Yep, a curated list like those awesome-lists found on github would be a start. Then write tutorials that only use libraries from that list. This is a reason why I tend to only write libs that I actually use myself - at least then I know every function has one happy user. Yeah, I find myself constantly wanting to improve on even the simplest libraries for better interaction with the kind of code the functions/objects seem to be most used with. More of a discovery process of usability than "mathematical deduction".
Re: is(some template instantiation) is true, but the actual instantiation fails
On 1/29/16 6:44 PM, Basile B. wrote: Haven't you seen my answer about constraint ? If you put a constraint on your function template then invalid instantiations are rejected. I mean... this language feature is not just ornamental... What do you think constraints are used for otherwise ^^ A constraint should not be necessary here. Constraints are useful when you have multiple templates that may match (without specializations), or you want to affect the way the compiler reports errors. Iff a template instantiation T compiles, then is(T) should evaluate to true. At least, that's my understanding. -Steve
Re: D vs Rust
On Friday, 29 January 2016 at 18:43:19 UTC, Walter Bright wrote: On 1/29/2016 7:39 AM, bearophile wrote: [...] Nice to see you back, bearophile! Having not been around here much myself recently, I didn't even realize he was away, but ... agree :-)
Re: is(some template instantiation) is true, but the actual instantiation fails
On Friday, 29 January 2016 at 17:01:46 UTC, Adrian Matoga wrote: On Friday, 29 January 2016 at 16:36:01 UTC, Steven Schveighoffer wrote: On 1/29/16 10:28 AM, Adrian Matoga wrote: [...] is(T) is supposed to be false if T is not a valid type. I would agree with you that the static assert should fail. -Steve Oh, there's more: // this should fail: static assert(is(CallsFoo!NoFoo)); // this should fail too: static assert(is(typeof({ alias Baz = CallsFoo!NoFoo; return Baz.init; }(; // and this: static assert(__traits(compiles, { alias Baz = CallsFoo!NoFoo; return Baz.init; }())); // but only this fails: alias Baz = CallsFoo!NoFoo; https://issues.dlang.org/show_bug.cgi?id=15623 Haven't you seen my answer about constraint ? If you put a constraint on your function template then invalid instantiations are rejected. I mean... this language feature is not just ornamental... What do you think constraints are used for otherwise ^^
Re: UTF-16 endianess
On 1/29/16 6:03 PM, Marek Janukowicz wrote: On Fri, 29 Jan 2016 17:43:26 -0500, Steven Schveighoffer wrote: Is there anything I should know about UTF endianess? It's not any different from other endianness. In other words, a UTF16 code unit is expected to be in the endianness of the platform you are running on. If you are on x86 or x86_64 (very likely), then it should be little endian. If your source of data is big-endian (or opposite from your native endianness), To be precise - my case is IMAP UTF7 folder name encoding and I finally found out it's indeed big endian, which explains my problem (as I'm indeed on x86_64). it will have to be converted before treating as a wchar[]. Is there any clever way to do the conversion? Or do I need to swap the bytes manually? No clever way, just the straightforward way ;) Swapping endianness of 32-bits can be done with core.bitop.bswap. Doing it with 16 bits I believe you have to do bit shifting. Something like: foreach(ref elem; wcharArr) elem = ((elem << 8) & 0xff00) | ((elem >> 8) & 0x00ff); Or you can do it with the bytes directly before casting Note the version identifiers BigEndian and LittleEndian can be used to compile the correct code. This solution is of no use to me as I don't want to change the endianess in general. What I mean is that you can annotate your code with version statements like: version(LittleEndian) { // perform the byteswap ... } so your code is portable to BigEndian systems (where you would not want to byte swap). -Steve
Re: Relocatable objects and internal pointers
On Sat, Jan 30, 2016 at 01:21:27AM +, Matt Elkins via Digitalmars-d-learn wrote: > On Saturday, 30 January 2016 at 01:18:33 UTC, Ali Çehreli wrote: > >Definitely so. Rvalues are moved around all the time. The following > >program has two rvalue moves without calling post-blits or > >destructors. > > Oi, that makes life tough. Ok, I'll figure something else out, then... [...] Keep in mind that D structs are conceptually different from C++ structs (even if they are similarly implemented). D structs are supposed to be value types with POD-like semantics; so when passing structs around they are bit-copied into the destination and then the postblit method (this(this)) is called to "patch up" the copy. This is unlike in C++ where you have copy ctors and dtors and operator=() to manage copying. Because there are no copy ctors, having internal pointers can be dangerous, since structs can move around in memory without any warning (e.g., returning a struct from a function generally involves copying it from the callee's stack frame into a local variable in the caller's stack frame). If you need something with internal pointers, you might want to consider classes instead. Either that, or be sure to allocate your structs on the heap instead, and work with pointers instead of the struct values directly. (Note that this is still risky, since somebody might dereference the pointer and get a stack copy of the struct, which will cause problems when it then gets passed around.) T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Re: Relocatable objects and internal pointers
On Saturday, 30 January 2016 at 01:28:54 UTC, H. S. Teoh wrote: On Sat, Jan 30, 2016 at 01:21:27AM +, Matt Elkins via Digitalmars-d-learn wrote: On Saturday, 30 January 2016 at 01:18:33 UTC, Ali Çehreli wrote: >Definitely so. Rvalues are moved around all the time. The >following program has two rvalue moves without calling >post-blits or destructors. Oi, that makes life tough. Ok, I'll figure something else out, then... [...] Keep in mind that D structs are conceptually different from C++ structs (even if they are similarly implemented). D structs are supposed to be value types with POD-like semantics; so when passing structs around they are bit-copied into the destination and then the postblit method (this(this)) is called to "patch up" the copy. This is unlike in C++ where you have copy ctors and dtors and operator=() to manage copying. Because there are no copy ctors, having internal pointers can be dangerous, since structs can move around in memory without any warning (e.g., returning a struct from a function generally involves copying it from the callee's stack frame into a local variable in the caller's stack frame). If you need something with internal pointers, you might want to consider classes instead. Either that, or be sure to allocate your structs on the heap instead, and work with pointers instead of the struct values directly. (Note that this is still risky, since somebody might dereference the pointer and get a stack copy of the struct, which will cause problems when it then gets passed around.) T Yeah, but the whole point of what I am doing is to avoid using the heap; I can think of several ways to implement this if I relax that restriction :). I'm basically trying to make C++'s std::unique_ptr for resource handles, a thin wrapper which ensures resource cleanup and allows moving the handle. Since I'm putting it in my lowest-level/most-generic library with no visibility on how it gets used, I want it very lightweight (ideally zero-cost, like I can do in C++11, or at least low-cost [sans heap] like I could do in C++98) so that I can use it with the broadest range of higher-level applications.
Re: Relocatable objects and internal pointers
On 1/29/16 8:07 PM, Matt Elkins wrote: [snip] on D and came across a section in TDPL which said internal pointers are verboten because objects must be relocatable. Does this mean my example is invalid (e.g., the invariant will not hold in all circumstances)? If it is invalid, does that mean there are circumstances under which the post-blit constructor can be elided when performing a copy or copy-like operation (such as a move)? I've been treating it like a sort of copy-constructor that lacks visibility on the copied-from object, but maybe that's a mistake... No, you cannot have internal pointers. But... I figured out a way to have them. You just have to guarantee you don't copy the actual "pointer" out of the struct: https://forum.dlang.org/post/mk5k4l$s5r$1...@digitalmars.com -Steve
Re: reduce -> fold?
On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote: On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote: So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Just to bikeshed a little, I remember that when I first started using std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite often. D competes with C++ directly, so do consider that name :-) I'm not sure what the problem was, but the documentation for "reduce" already mentions "accumulate": https://dlang.org/library/std/algorithm/iteration/reduce.html
UTF-16 endianess
I have trouble understanding how endianess works for UTF-16. For example UTF-16 code for 'ł' character is 0x0142. But this program shows otherwise: import std.stdio; public void main () { ubyte[] properOrder = [0x01, 0x42]; ubyte[] reverseOrder = [0x42, 0x01]; writefln( "proper: %s, reverse: %s", cast(wchar[])properOrder, cast(wchar[])reverseOrder ); } output: proper: 䈁, reverse: ł Is there anything I should know about UTF endianess? -- Marek Janukowicz
Trouble complinig DMD 2.070 on windows
I'm trying to compile a 64-bit DMD.exe on windows (as my project has enough CTFE and Template work that it bumps up against the 4gb limit). with the pre-DDMD setup I was just able to load the thing up in visual studio 2013 and build, but I've been having some difficulty with 2.070's projects. Namely, it seems that no matter what type of bulid I do, I get a bunch of errors in elfobj.c and one in filename.d Error 1 error C3861: 'assert': identifier not found D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3512 1 dmd_backend Error 2 error C3861: 'assert': identifier not found D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3527 1 dmd_backend Error 3 error C2352: 'Obj::reftoident' : illegal call of non-static member function D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3528 1 dmd_backend Error 4 error C2065: 'symtab_strings' : undeclared identifier D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3531 1 dmd_backend Error 5 error C2227: left of '->size' must point to class/struct/union/generic type D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3531 1 dmd_backend Error 6 error C2065: 'symtab_strings' : undeclared identifier D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3532 1 dmd_backend Error 7 error C2227: left of '->writeString' must point to class/struct/union/generic type D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3532 1 dmd_backend Error 8 error C2065: 'symtab_strings' : undeclared identifier D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3533 1 dmd_backend Error 9 error C2227: left of '->setsize' must point to class/struct/union/generic type D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3533 1 dmd_backend Error 10 error C2227: left of '->size' must point to class/struct/union/generic type D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3533 1 dmd_backend Error 11 error C2065: 'symtab_strings' : undeclared identifier D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3534 1 dmd_backend Error 12 error C2227: left of '->writeString' must point to class/struct/union/generic type D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3534 1 dmd_backend Error 13 error C3861: 'elf_addsym': identifier not found D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3536 1 dmd_backend Error 14 error C3861: 'MAP_SEG2SECIDX': identifier not found D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3536 1 dmd_backend Error 15 error C2352: 'Obj::reftoident' : illegal call of non-static member function D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3542 1 dmd_backend Error 16 Error: function ddmd.root.filename.GetFullPathNameA (const(wchar)* lpFileName, uint nBufferLength, wchar* lpBuffer, wchar** lpFilePart) is not callable using argument types (const(char)*, int, typeof(null), typeof(null)) D:\programs\dmd\dmd2\src\dmd\root\filename.d 645 17 IntelliSense: identifier "assert" is undefined d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3512 5 dmd_backend 18 IntelliSense: a nonstatic member reference must be relative to a specific object d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3528 13 dmd_backend 19 IntelliSense: identifier "symtab_strings" is undefined d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3531 29 dmd_backend 20 IntelliSense: identifier "elf_addsym" is undefined d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3536 30 dmd_backend 21 IntelliSense: identifier "MAP_SEG2SECIDX" is undefined d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3536 79 dmd_backend 22 IntelliSense: a nonstatic member reference must be relative to a specific object d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3542 9 dmd_backend (If this is an actual issue with the code or projects I'll file a bug, but I wanted to make sure it wasn't just me doing something wrong first)
Re: opApply @safety
On Friday, 29 January 2016 at 17:44:34 UTC, Chris Wright wrote: I want to create an opApply for a type. I've marked my code @safe, because everything I wrote was @safe. The body of opApply is @safe, but it calls a delegate that may or may not be @safe. How do I make it so I can iterate through this type safely and systemly? I want to support iteration like: foreach (string key, string value; collection) {} foreach (size_t i, string key, string value; collection) {} You can implement an input range and annotate all the primitives as @safe. Then if there's only an input range in your agregate, DMD will auto-detect that it must use it in foreach(): http://dlang.org/spec/statement.html#foreach-with-ranges in the worst case (range not implementable directly but only as a getter in .range() or .opSlice() you'll have to change the style a bit and consume the range explicitly in a typical "while (!stuff.empty) {...}"
Re: UTF-16 endianess
Am Fri, 29 Jan 2016 18:58:17 -0500 schrieb Steven Schveighoffer: > On 1/29/16 6:03 PM, Marek Janukowicz wrote: > > On Fri, 29 Jan 2016 17:43:26 -0500, Steven Schveighoffer wrote: > >>> Is there anything I should know about UTF endianess? > >> > >> It's not any different from other endianness. > >> > >> In other words, a UTF16 code unit is expected to be in the > >> endianness of the platform you are running on. > >> > >> If you are on x86 or x86_64 (very likely), then it should be > >> little endian. > >> > >> If your source of data is big-endian (or opposite from your native > >> endianness), > > > > To be precise - my case is IMAP UTF7 folder name encoding and I > > finally found out it's indeed big endian, which explains my problem > > (as I'm indeed on x86_64). > >> it will have to be converted before treating as a wchar[]. > > > > Is there any clever way to do the conversion? Or do I need to swap > > the bytes manually? > > No clever way, just the straightforward way ;) > > Swapping endianness of 32-bits can be done with core.bitop.bswap. > Doing it with 16 bits I believe you have to do bit shifting. > Something like: > > foreach(ref elem; wcharArr) elem = ((elem << 8) & 0xff00) | ((elem >> > 8) & 0x00ff); > > Or you can do it with the bytes directly before casting There's also a phobos solution: bigEndianToNative in std.bitmanip.
[Issue 15623] is(M!N) evaluates to true for M!N that fails to instantiate.
https://issues.dlang.org/show_bug.cgi?id=15623 Ali Cehrelichanged: What|Removed |Added CC||acehr...@yahoo.com --- Comment #1 from Ali Cehreli --- Interestingly, they all fail when moved inside a function. So, they seem to be broken only at module scope. --
Re: Relocatable objects and internal pointers
On 01/29/2016 05:07 PM, Matt Elkins wrote: > this(/* arguments to populate stuff */) > { > m_this = > /* ... populate stuff ... */ > } > a section in TDPL which said internal pointers are > verboten because objects must be relocatable. Does this mean my example > is invalid Yes, D explicitly bans internal pointers. > does that mean there are circumstances under which the > post-blit constructor can be elided when performing a copy or copy-like > operation (such as a move)? Definitely so. Rvalues are moved around all the time. The following program has two rvalue moves without calling post-blits or destructors. struct Foo { this(this) { assert(false);// not expected to be called in this program } } Foo makeFoo() { return Foo(); } void takesFoo(Foo foo) { } void main() { Foo foo; foo = makeFoo();// post-blit not called takesFoo(Foo());// post-blit not called } Ali
Re: Dub packages: Best practices for windows support
On Friday, 29 January 2016 at 19:46:40 UTC, Johannes Pfau wrote: Now on windows, things are more complicated. First of all, I can't seem to simply use "libs": ["foo"] as the linker won't find the C import .lib file. Then apparently there's no way to add a library search path with the MSVC linker? So I have to use the full path: "libs": [$PACKAGE_DIR\\path\\foo]. Without $PACKAGE_DIR paths are incorrect for applications using the library because of a dub problem. And then I'll have to use different import libraries and paths for -m32, -m64 and -m32mscoff. Now you know my motivation for creating Derelict. All this leads to the following questions: * Should cairoD copy the DLLs for all applications using cairoD? This way simply adding a dependency will work. However, if users want to use a self compiled cairo DLL with fewer dependencies there's no easy way to disable the file copying? * Should cairoD link in the .lib DLL import file? This might be useful even when not copying the DLLs. But if users want to link a custom import library that would be difficult. OTOH not copying DLLs and/or not linking the import library will make dub.json much more complicated for simple applications, especially if these applications want to support -m32, -m32mscoff and -m64. IMO, no to both of these (for now). Including all of these dependencies is going to mean that all of your users, no matter the platform, will pull the down with every new version of gtkd. I recommend you provide all of the precompiled DLLs and import libraries as a separate download and let the user do the configuration needed to get it to link. Most Windows developers are used to it. You can provide instructions for those who aren't. Hopefully one day dub will have the ability to pull down library dependencies on demand, or based on the current platform and architecture by default, then this problem goes away. * What's the best way to support all of -m32, -m32mscoff and -m64? I've got working import libraries and DLLs for all configurations, but how to support this in dub.json? I think the best way would be to have -ms32coff as a special architecture or flag for dub, but I can't seem to find any documentation about that. -m64 can be detected by x86_64 in platforms, but how to detect -m32 vs -m32mscoff? Alternatively I could simply let users choose the configurations manually. But adding dflags: ["-m32mscoff"] does not build the Derelict dependencies with the m32mscoff flag so linking will fail... DFLAGS="-m32mscoff" doesn't work with dub test as the dub test command ignores the DFLAGS variable. I'd have to check whether it works for applications, but then there's still no way to use the correct cairo import library in cairoDs dub.json There's an issue for this at [1]. Until support for -m32mscoff is baked in, distributing any libraries with a dub project will be problematic.
Re: Dub packages: Best practices for windows support
On Saturday, 30 January 2016 at 01:17:13 UTC, Mike Parker wrote: There's an issue for this at [1]. Until support for -m32mscoff is baked in, distributing any libraries with a dub project will be problematic. [1] https://github.com/D-Programming-Language/dub/issues/628
Re: Dub packages: Best practices for windows support
On Saturday, 30 January 2016 at 01:17:13 UTC, Mike Parker wrote: Hopefully one day dub will have the ability to pull down library dependencies on demand, or based on the current platform and architecture by default, then this problem goes away. I should say "precompiled library dependencies".
Re: reduce -> fold?
On Friday, 29 January 2016 at 23:45:04 UTC, Ola Fosheim Grøstad wrote: So D is adding currying and builtin tuples? :^) Yes. Come back in 10 years it'll be ready for you.
Re: Autocompletion not working on Xamarin Studio for D
On Friday, 29 January 2016 at 21:31:35 UTC, Pradeep Gowda wrote: On Friday, 29 January 2016 at 21:05:00 UTC, nbro wrote: Hi! I am trying to write some code in D using Xamarin Studio, but it's not autocompleting the code as I would expect. For example, it does not even gives you autocompletion for libraries, but apparently only for the language's primitives, i.e. keywords, etc. Is this the expected behaviour or is there's something wrong with my settings? Thanks! I wrote this up https://www.btbytes.com/posts/xamarind.html (Xamarin Studio with auto completion etc., for D on Mac) HTH. Yes, I was forgetting to include the link the libraries. I hadn't use Xamarin for a while and I remembered I had to set up Xamarin for D, but meanwhile I removed the D compiler, updated Xamarin, etc, and it might be that these settings were reset.
Re: UTF-16 endianess
On Friday, 29 January 2016 at 22:36:37 UTC, Marek Janukowicz wrote: I have trouble understanding how endianess works for UTF-16. UTF-16 (as well as UTF-32) comes in both little-endian and big-endian variants. A byte-order marker in the file can help you detect which one it is in. See t his t able: http://www.unicode.org/faq/utf_bom.html#gen6
The Quick Mom Algorithm
http://dpaste.dzfl.pl/05a82699acc8 So over the past few days I've been in the zone working on a smooth implementation of "Median of Medians" (https://en.wikipedia.org/wiki/Median_of_medians). Its performance is much better compared to the straightforward implementation. However, in practice it's very hard to get it to beat simple heuristics (such as median of five, random pivot etc). These heuristics run `n` comparisons for an input of length `n`, whereas the MoM needs over twice as many comparisons. Also it does a bunch of swapping around the data. Overall I got it within 2.5x of the heuristic-based topN for most data sizes up to tens of millions. While thinking of MoM and the core reasons of its being slow (adds nice structure to its input and then "forgets" most of it when recursing), I stumbled upon a different algorithm. It's much simpler, also deterministic and faster than MoM for many (most?) inputs. But it's not guaranteed to be linear. After having pounded at this for many hours, it is clear that I am in need of some serious due destruction. I call it a "quick median of medians" or in short "quick mom". Consider the algorithm defined as follows over a range `r` of length `n`. It returns an index to an element likely to be in the second tertile of r. (A tertile is a third of the range. So the expectation is that the returned index x is such that e<=r[x] for at least one third of the range, and r[x]<=e again for at least one third of the range.) 0. If n<=3, compute median by rote and return its index. 1. Divide r in three equal adjacent subranges r0 = r[0 .. $/3], r1 = r[$/3 .. $*2/3], r2 = r[$*2/3 .. $]. 2. Recurse to get the median of these three, call them m0, m1, m2. 3. Return the median of m0, m1, m2. Note that no data has been written yet; we only have an estimate of a pivot. On random inputs it's expected that the median thus gotten is greater than 1/6 + 1/6 = 1/3 elements, and less than the same fraction. The algorithm completes in linear time. However, the pivot obtained is just an approximation. In the worst case it's possible that e.g. all recursions return the leftmost of the allowed index, so the bound deteriorates by 1/3 for each recursion depth, or generally to (1/3)^^log3(n). Not good! That's where the quick mom pays attention. After it partitions the data using the pivot obtained by the quick mom method, the partitioning stage checks whether the resulting pivot falls within bounds. If not, it runs a precise selection method (such as proper median of medians - "thorough mom") to bring the pivot where it needs to be. The data patterns that cause the quick mom to fail systematically are rather odd but worst case is what it is. Overall the partitioning either succeeds with the quick mom pivot in linear time, or does one more linear pass if "unlucky". So overall partition is linear. (Micro-optimization: not all data needs to be repartitioned, only that outside the not-so-good pivot.) Unlike the quick mom, the partition guarantees a pivot in the mid tertile. After partitioning the classic quickselect algorithm may be implemented. There's one more _really_ juicy detail. In fact, the quick mom may finish without looking at all data. Look at the implementation - there are two overloads of quickMom. The second gets the bounds and works as follows: if you've already computed two elements of a median, the third may be chosen only if in between the two. Otherwise, you only care whether it's larger or smaller than the other two. This allows the algorithm to finish certain recursion branches early. Destroy! Andrei
Re: reduce -> fold?
On Friday, 29 January 2016 at 23:20:38 UTC, Walter Bright wrote: On 1/29/2016 5:11 AM, Luís Marques wrote: Just to bikeshed a little, I remember that when I first started using std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite often. D competes with C++ directly, so do consider that name :-) For algorithms and FP in general, we may be better off drawing inspiration from Haskell, as C++ does not have FP in its DNA. So D is adding currying and builtin tuples? :^)
To cast a uint to float to compute k/n, use to! or cast()?
I want to compute the points of a regular polygon in a loop: float r = 1.0; for (uint k=0; k < numVerts; k++) { vertlist ~= Vec2D(r * cos(k/n * 2 * PI), ...) } How do I make sure k/n is a float or double?
Re: is(some template instantiation) is true, but the actual instantiation fails
On 01/29/2016 09:01 AM, Adrian Matoga wrote: > Oh, there's more: > // this should fail: > static assert(is(CallsFoo!NoFoo)); > // this should fail too: > static assert(is(typeof({ alias Baz = CallsFoo!NoFoo; return Baz.init; > }(; > // and this: > static assert(__traits(compiles, { alias Baz = CallsFoo!NoFoo; return > Baz.init; }())); > // but only this fails: > alias Baz = CallsFoo!NoFoo; > > https://issues.dlang.org/show_bug.cgi?id=15623 As I noted on the bug report, they are work when moved from module scope to inside a function (e.g. main()). At least there's that workaround... Ali
Re: opApply @safety
On 1/29/16 3:08 PM, Chris Wright wrote: On Fri, 29 Jan 2016 14:00:08 -0500, Steven Schveighoffer wrote: On 1/29/16 12:44 PM, Chris Wright wrote: I want to create an opApply for a type. I've marked my code @safe, because everything I wrote was @safe. The body of opApply is @safe, but it calls a delegate that may or may not be @safe. How do I make it so I can iterate through this type safely and systemly? Likely an overload. Tag the delegate as being @safe or not. -Steve That's handy. It works. I can make it so someone can call: foo.opApply((i, k, v) @safe => 0); foo.opApply((i, k, v) @system => 0); And that works. However, if you have: @safe void bar() { foreach(i, k, v; foo) { } } the compiler complains: opapplysafe.d(12): Error: foo.opApply matches more than one declaration: opapplysafe.d(2): @safe int(int delegate(int, string, string) @safe dg) and: opapplysafe.d(5): @system int(int delegate(int, string, string) @system dg) Guess I'll file a bug. Definitely seems like a bug. As a workaround, you can name the opApply functions: struct S { int opApply(int delegate(int, string, string) @safe dg) @safe {...} int unsafeApply(int delegate(int, string, string) dg) {...} } foreach(i, k, v; foo.unsafeApply) {...} though that's... ugly. -Steve
Re: opApply @safety
On Fri, 29 Jan 2016 23:35:35 +, Basile B. wrote: > You can implement an input range and annotate all the primitives as > @safe. I hadn't realized that if front() returns a tuple, it's automatically expanded. Works for me.
Re: DMD 2.070.0 - The package is of bad quality
On Friday, 29 January 2016 at 17:38:18 UTC, Gary Willoughby wrote: I get the following downloading and installing the Ubuntu x86_64 deb file. The package is of bad quality The installation of a package which violates the quality standards isn't allowed. This could cause serious problems on your computer. Please contact the person or organisation who provided this package file and include the details beneath. Lintian check results for /home/gary/Desktop/dmd_2.070.0-0_amd64.deb: Can't close(GLOB(0xddf540)) filehandle: '' at /usr/share/lintian/helpers/coll/objdump-info-helper line 192 command failed with error code 123 at /usr/share/lintian/collection/objdump-info line 79. warning: collect info objdump-info about package dmd failed warning: skipping check of binary package dmd Not much help but I downloaded it last night and it worked fine with Linux Mint.
Re: To cast a uint to float to compute k/n, use to! or cast()?
On 1/29/16 6:48 PM, Enjoys Math wrote: I want to compute the points of a regular polygon in a loop: float r = 1.0; for (uint k=0; k < numVerts; k++) { vertlist ~= Vec2D(r * cos(k/n * 2 * PI), ...) } How do I make sure k/n is a float or double? uint is promoted to float/double with a binary math operation. You could simply reverse the order of your expression: 2 * PI * k/n But if you want to force a type change with simple conversions such as these, just use a constructor: float(k) / n * 2 * PI There is no need to cast or use `to` (though both of those would be equivalent to simple conversion). -Steve
Re: UTF-16 endianess
On 1/29/16 5:36 PM, Marek Janukowicz wrote: I have trouble understanding how endianess works for UTF-16. For example UTF-16 code for 'ł' character is 0x0142. But this program shows otherwise: import std.stdio; public void main () { ubyte[] properOrder = [0x01, 0x42]; ubyte[] reverseOrder = [0x42, 0x01]; writefln( "proper: %s, reverse: %s", cast(wchar[])properOrder, cast(wchar[])reverseOrder ); } output: proper: 䈁, reverse: ł Is there anything I should know about UTF endianess? It's not any different from other endianness. In other words, a UTF16 code unit is expected to be in the endianness of the platform you are running on. If you are on x86 or x86_64 (very likely), then it should be little endian. If your source of data is big-endian (or opposite from your native endianness), it will have to be converted before treating as a wchar[]. Note the version identifiers BigEndian and LittleEndian can be used to compile the correct code. -Steve
Re: reduce -> fold?
On 1/29/2016 5:11 AM, Luís Marques wrote: Just to bikeshed a little, I remember that when I first started using std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite often. D competes with C++ directly, so do consider that name :-) For algorithms and FP in general, we may be better off drawing inspiration from Haskell, as C++ does not have FP in its DNA.
Relocatable objects and internal pointers
Hi all, I'm a C++ programmer trying to decide whether to switch my main focus to D, and so I'm working on a pet project using it. So far I really like some of the practical aspects of the language (built-in contracts are great, the metaprogramming is very accessible, and I can't enough of these compile speeds!), but I keep finding myself frustrated by what seem like expressiveness limitations (unless, as I hope, they are just examples of my newbieness shining through). Case in point: In an attempt to work around one apparent limitation (previously asked about here http://forum.dlang.org/thread/eizmagtimvetogana...@forum.dlang.org) I came up with an idea which would require storing internal points in a struct. A very stripped-down but illustrative example would be something like this: [code] struct Foo { invariant { assert(m_this == ); } @disable(this); this(/* arguments to populate stuff */) { m_this = /* ... populate stuff ... */ } this(this) { m_this = /* ... do more stuff ... */ } private: Foo* m_this; /* ... stuff ... */ } [/code] This is just a piece of what I am doing, if you are wondering why I am bothering to save a pointer to this. However, I was doing some reading on D and came across a section in TDPL which said internal pointers are verboten because objects must be relocatable. Does this mean my example is invalid (e.g., the invariant will not hold in all circumstances)? If it is invalid, does that mean there are circumstances under which the post-blit constructor can be elided when performing a copy or copy-like operation (such as a move)? I've been treating it like a sort of copy-constructor that lacks visibility on the copied-from object, but maybe that's a mistake...
Re: Vision for the first semester of 2016
On Friday, 29 January 2016 at 23:41:47 UTC, Ola Fosheim Grøstad wrote: Yep, a curated list like those awesome-lists found on github would be a start. I've got one before there were many awesome-lists: https://github.com/zhaopuming/awesome-d
Re: Relocatable objects and internal pointers
On 1/29/16 9:35 PM, Matt Elkins wrote: On Saturday, 30 January 2016 at 02:09:55 UTC, Steven Schveighoffer wrote: I figured out a way to have them. You just have to guarantee you don't copy the actual "pointer" out of the struct: https://forum.dlang.org/post/mk5k4l$s5r$1...@digitalmars.com Unfortunately, that won't work for what I was trying to do. The stuff I elided in the comments were more pointers to other Foo instances, used to create a linked-list (of stack-allocated objects); these would still break under the conditions Ali described. I was only storing the this pointer so that blitted objects could deduce where they came from (trying to turn the post-blit constructor into a copy-constructor). Ah, so you were actually counting on the postblit to have an *invalid* pointer to begin with :) Yeah, that isn't going to work. In D, it's legal to do something like memcpy struct data (with no postblit), and this is done quite often in many places because of that. Thanks, though. I'm thinking that maybe D just can't express these semantics without substantial overhead. While somewhat disappointing (I came into D with stars in my eyes :)), it's not enough by itself to make me go back to C++, at least not just yet. Not when I can just use a few static ifs to do what previously required careful template crafting that I wouldn't understand 3 months later. On the other hand, I'm falling behind on my library books since I no longer have any time for reading during compilations ;). There are some really smart people who frequent these forums, if you post your actual use case, you may get an answer that you hadn't thought of. I saw you were trying to implement something like std::unique_ptr? There is http://dlang.org/phobos/std_typecons.html#.Unique Not sure if it helps. -Steve