On Sunday, 28 February 2016 at 22:16:39 UTC, Rene Zwanenburg
wrote:
On Sunday, 28 February 2016 at 19:02:21 UTC, Matt Elkins wrote:
Any suggestions?
I don't know how to fix that error, but 2.070.1 has been
released and contains a fix for your issue:
http://dlang.org/changelog/2.070.1.html
I'm attempting to use the DMD nightly build (because this fix
matters a lot to my project:
https://issues.dlang.org/show_bug.cgi?id=15661), but the build
fails at the link step. Here is my full output:
[output]
"C:\Program Files (x86)\dub\dub.exe" run --force --build debug
--build-mode separa
On Thursday, 18 February 2016 at 01:14:00 UTC, ZombineDev wrote:
https://issues.dlang.org/show_bug.cgi?id=15661. I suggest
testing this code again with a newer compiler (see my answer in
the other thread -
http://forum.dlang.org/post/omfyqfulgyzbrxlzr...@forum.dlang.org).
Thanks -- I might ge
On Friday, 19 February 2016 at 01:30:13 UTC, H. S. Teoh wrote:
Suppose the array gets moved sometime after i=500 because it
ran out of space in the current memory location. Since there
is another slice middleSlice pointing at the old data, it's not
just a matter of *moving* the elements over t
So in a different thread someone mentioned that when arrays are
grown an implicit copy could be called on all the elements, as
they might need to be copied over to a new, larger block of
memory. This makes sense, and is expected. However, it got me
concerned: what if the post-blit was disabled
On Wednesday, 17 February 2016 at 07:10:15 UTC, ZombineDev wrote:
The downside is that it really indicates that I didn't reduce
my buggy program properly. I'll hold out for the
live-object-destructor-call fix to see whether that corrects
my problem; I can just leak resources until then :).
So
On Wednesday, 17 February 2016 at 02:23:52 UTC, Ali Çehreli wrote:
Since a static array must consist of .init values to begin
with, every move into its members must also trigger its
destructor if the type has elaborate destructor.
Oof. This strikes me as a "gotcha", that this happens even with
After some more time spent on (the non-reduced version of) this,
I think there is a decent chance I am really just experiencing
another manifestation of a bug I reported a little bit ago:
https://issues.dlang.org/show_bug.cgi?id=15661
The good news is that this is now marked as resolved, so
h
On Tuesday, 16 February 2016 at 10:45:09 UTC, Marc Schütz wrote:
On Tuesday, 16 February 2016 at 04:00:27 UTC, Mike Parker wrote:
On Tuesday, 16 February 2016 at 03:39:00 UTC, Matt Elkins
wrote:
On Tuesday, 16 February 2016 at 03:31:51 UTC, maik klein
wrote:
In D you can always call Foo.init e
On Tuesday, 16 February 2016 at 08:18:51 UTC, Ali Çehreli wrote:
When a temporary Foo object is moved into the array, the
temporary object is set to Foo.init. This temporary object
lives on the stack. In fact, all temporary Foo objects of
Foo.this(int) live at the same location.
After Foo(8)
On Tuesday, 16 February 2016 at 03:31:51 UTC, maik klein wrote:
In D you can always call Foo.init even with @disable this(),
Foo.init can be called implicitly (not just explicitly)? If so,
why even have @disable this(), if it offers no guarantees?
The first 3 destructor calls are from the 3
I've been bitten again by my lack of understanding of the D
struct lifecycle :-/. I managed to reduce my buggy program to the
following example:
[code]
import std.stdio;
struct Foo
{
@disable this();
@disable this(this);
this(int valueIn) {value = valueIn;}
~this() {writeln("F
On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote:
On Friday, 12 February 2016 at 15:12:19 UTC, Steven
Schveighoffer wrote:
On 2/12/16 9:37 AM, Matt Elkins wrote:
[...]
Pass by reference and pass by value means different treatment
inside the function itself, so it can't differ from ca
On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer
wrote:
It could potentially differ based on the type being passed,
Yes, that's what I meant.
but I'm unaware of such an optimization,
Hm. Unfortunate.
and it definitely isn't triggered specifically by 'in'. 'in' is
literall
On Friday, 12 February 2016 at 14:03:05 UTC, Steven Schveighoffer
wrote:
On 2/10/16 11:51 PM, Matt Elkins wrote:
* The in keyword. This is nice syntactic sugar over having a
special
trait in C++ which deduces whether to pass by value or
const-reference.
"foo(in bar)" is way more readable than
On Thursday, 11 February 2016 at 05:05:22 UTC, tsbockman wrote:
On Thursday, 11 February 2016 at 04:51:39 UTC, Matt Elkins
wrote:
- Syntactic sugars (associtive arrays, powerful foreach,
slices...)
I'm still adjusting to the idea of AAs as part of the language
rather than library. Not sure I
On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote:
There are several reasons I want to use D rather than C# / Go /
something else:
I will focus on comparing against C++, because that has been my
favorite general purpose language for a long time. While I often
have to use C, Java, C#, etc.
On Thursday, 11 February 2016 at 03:47:09 UTC, Steven
Schveighoffer wrote:
Misunderstanding.
An AA under the hood is simply a pointer. Initialized to null.
When you pass it around, you are passing a pointer. AA assign
checks for null and allocates a new AA impl to hold the data.
But this does
Consider the following definition of Foo and an accompanying
unittest:
[code]
struct Foo
{
@property int[int] aa() {return m_aa;}
@property ref int[int] aaRef() {return m_aa;}
int[int] m_aa;
}
unittest
{
Foo foo;
assert(5 !in foo.m_aa); // Sanity-check to start off
foo.a
On Monday, 8 February 2016 at 07:31:07 UTC, Daniel Kozak wrote:
Seems to me too, please report it on issues.dlang.org
Reported: https://issues.dlang.org/show_bug.cgi?id=15661
Some environment information:
DMD 2.070 32-bit
Windows 7 (64-bit)
On Sunday, 7 February 2016 at 23:11:34 UTC, anonymous wrote:
On 07.02.2016 23:49, Matt Elkins wrote:
Oi. Yes, I can, but it is quite a lot of code even if you
don't count
that it is dependent on OpenGL, GLFW, and gl3n to run to this
point.
This is why I was disappointed that simpler reproducing
On Sunday, 7 February 2016 at 22:04:27 UTC, anonymous wrote:
On 07.02.2016 22:49, Matt Elkins wrote:
From this non-reduced situation, does anything jump out? Am I
missing
something about struct lifetimes? This is the only place I
instantiate a
TileView.
Looks weird. I presume this doesn't h
On Sunday, 7 February 2016 at 22:35:57 UTC, anonymous wrote:
On 07.02.2016 23:07, Márcio Martins wrote:
The destructor you are seeing is from the assignment:
m_tileView = TileView(...);
This creates a temporary TileView, copies it to m_tileView,
and then
destroys it. I suppose you want to mov
I've been experiencing some odd behavior, where it would appear
that a struct's destructor is being called before the object's
lifetime expires. More likely I am misunderstanding something
about the lifetime rules for structs. I haven't been able to
reproduce with a particularly minimal example
On Sunday, 31 January 2016 at 20:20:52 UTC, Steven Schveighoffer
wrote:
Oh, nevermind. This is actually simpler.
You can't do memory operations inside a destructor during
collection. I forgot about that.
But the rule I stated is still in force.
-Steve
So this implies that the UniquePtr imp
On Sunday, 31 January 2016 at 20:11:07 UTC, Matt Elkins wrote:
On Sunday, 31 January 2016 at 20:10:03 UTC, Matt Elkins wrote:
On Sunday, 31 January 2016 at 20:07:26 UTC, Steven
Schveighoffer wrote:
What is likely happening is that ptr is already collected,
and you are invalidly attempting to re
On Sunday, 31 January 2016 at 20:10:03 UTC, Matt Elkins wrote:
On Sunday, 31 January 2016 at 20:07:26 UTC, Steven
Schveighoffer wrote:
What is likely happening is that ptr is already collected, and
you are invalidly attempting to re-free it.
The GC can collect this memory even though there is
On Sunday, 31 January 2016 at 20:07:26 UTC, Steven Schveighoffer
wrote:
What is likely happening is that ptr is already collected, and
you are invalidly attempting to re-free it.
The GC can collect this memory even though there is still an
outstanding root-reachable pointer to it?
On Sunday, 31 January 2016 at 19:34:43 UTC, maik klein wrote:
I recently asked a question about ownership semantics in D
https://stackoverflow.com/questions/35115702/how-do-i-express-ownership-semantics-in-d
But a few minutes ago I found an answer on SO that could
potentially explain a lot.
On Sunday, 31 January 2016 at 18:02:19 UTC, Matt Elkins wrote:
Here is the one I am using right now:
Actually, here is the whole module in case you are interested in
the unittests/usage:
[code]
import std.algorithm;
import std.traits;
struct ResourceHandle(T, alias Deleter, T Default = T.in
On Sunday, 31 January 2016 at 17:55:53 UTC, Matt Elkins wrote:
Errr, ignore the makeFoo() line. Left that in by accident, has
no bearing on the issue.
Ok, I think I understand why this doesn't work, at least. The Foo
passed into bar() is, of course, an lvalue itself.
So I can achieve this wi
On Sunday, 31 January 2016 at 17:48:53 UTC, maik klein wrote:
The problem is that x will be copied afaik which is not what
you want if you want to deal with ownership.
I think that can be solved by wrapping the resource in a struct
that deals with passing the ownership. Here is the one I am us
Errr, ignore the makeFoo() line. Left that in by accident, has no
bearing on the issue.
On Sunday, 31 January 2016 at 17:42:19 UTC, anonymous wrote:
I don't know if this works in all cases, but it passes that
simple test:
@disable void foo(ref int x);
void foo(int x) {}
void main()
{
foo(5); /* works */
int y = 5;
foo(y); /* error */
}
My fault, I should h
I know I can mark an argument ref to require lvalues, so I'm
wondering whether there is an equivalent for rvalues; that is, is
there a way to specify that an argument to a function MUST be an
rvalue?
For example, in C++ I can do this:
[code]
void foo(int && x) {...}
foo(5); // Works fine
int
On Saturday, 30 January 2016 at 13:37:43 UTC, Kagamin wrote:
Alias templates require stack pointer, init probably has it set
to null.
Try this:
FooType foo = FooType();
Yes, that fixed it. Interesting.
On Saturday, 30 January 2016 at 05:57:34 UTC, H. S. Teoh wrote:
A common idiom that we use is to write an attributed unittest
to verify that the function itself is @safe/etc.. This way, if
instantiated with safe/etc. types, the template will also be
safe/etc., but if instantiated with an unsafe
On Saturday, 30 January 2016 at 05:18:08 UTC, Steven
Schveighoffer wrote:
https://issues.dlang.org/enter_bug.cgi
-Steve
Added!
https://issues.dlang.org/show_bug.cgi?id=15627
Thanks for the help.
On Saturday, 30 January 2016 at 05:25:49 UTC, Rikki Cattermole
wrote:
On 30/01/16 6:17 PM, Matt Elkins wrote:
[...]
templated functions have attribute inference. Meaning if it can
be nothrow it will be.
Regarding your real use case, again struct if templated so it
should be inferred.
Conve
Is there any way to specify that a generic function is
conditionally nothrow (or other function decorators), based on
whether the template instantiation is nothrow? I'm looking for
something akin to C++'s noexcept(noexcept()), e.g.:
template void foo() noexcept(noexcept(T())) {}
I don't see
Title says it; I get an access violation in code marked @safe.
Here's a minimal example:
[code]
@safe:
struct Foo(alias Callback)
{
~this() {Callback();}
}
unittest
{
uint stackVar;
alias FooType = Foo!((){++stackVar;});
FooType[1] foos;
foos[0] = FooType.init;
}
[/code]
On Saturday, 30 January 2016 at 03:00:11 UTC, Steven
Schveighoffer wrote:
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.
Yeah, I tried that first (on the general forum, since at the time
I didn'
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
On Friday, 29 January 2016 at 12:00:25 UTC, Pavel wrote:
Hello!
Is there any debuging support for Intelij Idea's D plugin?
Thanks!
I can't say for certain, but the website
(https://github.com/kingsleyh/DLanguage) lists this as an
upcoming feature by the end of 2016, so I think there probabl
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 p
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...
Thanks for the
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
48 matches
Mail list logo
