I remember reading that guaranteed RVO was part of the D
standard, but I am completely unable to find anything on it in
the specification.
I'm also unable to find anything in it that explicitly states the
lifetime of returning a stack-local struct from a function.
However, it does state
On Monday, 4 May 2015 at 02:47:24 UTC, WhatMeWorry wrote:
This following code works fine. A triangle is displayed.
GLfloat[6] verts = [ 0.0, 1.0,
-1.0, -1.0,
1.0, -1.0 ];
glGenBuffers(1, vbo);
On Monday, 4 May 2015 at 03:57:04 UTC, bitwise wrote:
I'll probably go with in ref. I think escape proof is
probably a good default. Not to mention, easier to type ;)
FYI I'm unsure how well `scope` storage class is currently
implemented because it's in a state of flux at the moment as far
On Monday, 4 May 2015 at 01:58:12 UTC, bitwise wrote:
If I have a large struct that needs to be passed around, like a
4x4 matrix for example, how do I do that efficiently in D?
In std.datetime, in is used for most struct parameters, but
I'm confused by the docs for function parameter storage
On Tuesday, 5 May 2015 at 02:47:03 UTC, bitwise wrote:
On Mon, 04 May 2015 00:16:03 -0400, Jonathan M Davis via
Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
D will move the argument if it can rather than copying it
(e.g. if a
temporary is being passed in), which reduces the need
On Tuesday, 5 May 2015 at 14:14:51 UTC, bitwise wrote:
On Tue, 05 May 2015 00:20:15 -0400, rsw0x
anonym...@anonymous.com wrote:
it does, auto ref can bind to both lvalues and rvalues. Create
the function with an empty template like so,
import std.stdio;
struct S{
}
void Foo()(auto ref S s){
On Tuesday, 19 May 2015 at 21:07:52 UTC, bitwise wrote:
On Tue, 19 May 2015 15:36:21 -0400, rsw0x
anonym...@anonymous.com wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May
On Tuesday, 19 May 2015 at 19:45:38 UTC, Namespace wrote:
On Tuesday, 19 May 2015 at 19:36:23 UTC, rsw0x wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC,
On Friday, 19 June 2015 at 19:10:11 UTC, Shachar Shemesh wrote:
On 14/06/15 04:31, Adam D. Ruppe wrote:
On Sunday, 14 June 2015 at 00:52:20 UTC, FujiBar wrote:
I have read that in D structs are always allocated on the
stack while
classes are always allocated on the heap.
That's not true; it
On Friday, 26 June 2015 at 19:26:57 UTC, Jack Stouffer wrote:
Thanks for the reply! I understand the reasoning now.
On Friday, 26 June 2015 at 18:46:03 UTC, Adam D. Ruppe wrote:
2) interfaces have an associated runtime cost, which ranges
wanted to avoid. They come with hidden function pointers
On Friday, 26 June 2015 at 18:37:51 UTC, Jack Stouffer wrote:
I have been learning D over the past three weeks and I came to
the chapter in Programming in D on Ranges. And I am a little
confused on the choice to make Ranges based on the methods you
have in the struct, but not use a interface.
On Wednesday, 1 July 2015 at 18:09:19 UTC, Mathias Lang wrote:
On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote:
[...]
In your dub.json, can you use the following:
subConfigurations: {
vibe-d: libasync
},
dependencies: {
vibe-d: ~0.7.24-beta.3
},
On Friday, 3 July 2015 at 19:17:28 UTC, Marko Grdinic wrote:
[...]
Have you tried using LDC? I'm unsure of GDC's support on Windows.
LDC is D's LLVM compiler, and GDC/LDC generally produce binaries
with similar performance.
You can find a download link here:
On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote:
Just creating a bunch (10k) of sleeping (for 100 msecs)
goroutines/tasks.
Compilers
go: go version go1.4.2 linux/amd64
vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23
Code
go: http://pastebin.com/2zBnGBpt
On Saturday, 27 June 2015 at 21:53:33 UTC, ketmar wrote:
is it safe to call `GC.removeRange` in dtor? i believe it
should be safe, so one can perform various cleanups, but
documentation says nothing about guarantees
It's not documented. Afaik parts of the standard library depend
on this
There's very little writing about D's core.atomics(TDPL seems to
very barely cover them, I assume it's because it's aging compared
to the library.)
Is it safe to assume that they behave similarly to C++11's
atomics?
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced memory dead at the
same
Sample code:
class C{}
struct S{}
void main(){
import std.stdio;
auto c = new shared C();
auto s = new shared S();
writeln(typeid(c)); //modulename.C
writeln(typeid(s)); //shared(modulename.S)*
writeln(typeid(c).next); //null
writeln(typeid(s).next);
On Thursday, 13 August 2015 at 03:46:19 UTC, rsw0x wrote:
Sample code:
class C{}
struct S{}
void main(){
import std.stdio;
auto c = new shared C();
auto s = new shared S();
writeln(typeid(c)); //modulename.C
writeln(typeid(s)); //shared(modulename.S)*
On Friday, 14 August 2015 at 15:39:39 UTC, Timon Gehr wrote:
I don't understand. It is evidently fixable. E.g. if TypeInfo
was just a template without the mostly redundant additional
compiler support, this would be a trivial fix.
It appears that this was suggested already after a bit of
On Saturday, 22 August 2015 at 09:16:32 UTC, Russel Winder wrote:
On Sat, 2015-08-22 at 07:30 +, rsw0x via
Digitalmars-d-learn wrote:
[...]
Not entirely true. Go is a general purpose language, it is a
successor to C as envisioned by Rob Pike, Russ Cox, and others
(I am not sure how much
On Saturday, 22 August 2015 at 06:48:48 UTC, Russel Winder wrote:
On Fri, 2015-08-21 at 10:47 +, via Digitalmars-d-learn
wrote:
Yes, Go has sacrificed some compute performance in favour of
latency and convenience. They have also released GC
improvement plans for 1.6:
On Saturday, 22 August 2015 at 10:47:55 UTC, Laeeth Isharc wrote:
On Saturday, 22 August 2015 at 09:16:32 UTC, Russel Winder
wrote:
[...]
I didn't mean to start again the whole GC and Go vs D thing.
Just that one ought to know the lay of the land as it develops.
Out of curiosity, how much
On Sunday, 23 August 2015 at 11:06:20 UTC, Russel Winder wrote:
On Sat, 2015-08-22 at 09:27 +, rsw0x via
Digitalmars-d-learn wrote:
[…]
The performance decrease has been there since 1.4 and there is
no way to remove it - write barriers are the cost you pay for
concurrent collection. Go
On Thursday, 20 August 2015 at 17:13:33 UTC, Ilya Yaroshenko
wrote:
Hi All!
Does GC scan manually allocated memory?
I want to use huge manually allocated hash tables and I don't
want to GC scan them because performance reasons.
Best regards,
Ilya
GC does not scan memory allocated with
On Wednesday, 22 July 2015 at 17:17:17 UTC, Frank Pagliughi wrote:
On Wednesday, 22 July 2015 at 09:04:49 UTC, Marc Schütz wrote:
But as long as the original pointer is still on the stack,
that one _will_ keep the object alive. It is only a problem if
all pointers to a GC managed object are
On Sunday, 19 July 2015 at 17:12:07 UTC, rsw0x wrote:
On Sunday, 19 July 2015 at 17:04:07 UTC, Frank Pagliughi wrote:
[...]
Oh, yes, pointer. Ha! I didn't even think of that. Thanks.
I'm not familiar with how garbage collection works in D. If
the initial reference goes out of scope, and you
On Tuesday, 21 July 2015 at 21:44:07 UTC, rsw0x wrote:
On Sunday, 19 July 2015 at 17:12:07 UTC, rsw0x wrote:
[...]
wow, I don't even remember posting this.
This is (mostly) wrong, but I'm unsure if a pointer to another
pointer on the stack would correctly keep its object alive(but,
I
On Wednesday, 22 July 2015 at 09:04:49 UTC, Marc Schütz wrote:
On Tuesday, 21 July 2015 at 21:50:35 UTC, rsw0x wrote:
On Tuesday, 21 July 2015 at 21:44:07 UTC, rsw0x wrote:
[...]
addendum:
http://dlang.org/garbage.html
[...]
[...]
I believe this implies that it would *not* keep the
I can't find anything on this in the spec.
On Sunday, 19 July 2015 at 17:04:07 UTC, Frank Pagliughi wrote:
[...]
Oh, yes, pointer. Ha! I didn't even think of that. Thanks.
I'm not familiar with how garbage collection works in D. If the
initial reference goes out of scope, and you just have a
pointer - in another thread, no less -
On Monday, 24 August 2015 at 21:20:39 UTC, Russel Winder wrote:
For Python and native code, D is a great fit, perhaps more so
that Rust, except that Rust is getting more mind share,
probably because it is new.
I'm of the opinion that Rust's popularity will quickly die when
people realize
On Saturday, 24 October 2015 at 13:18:26 UTC, Shriramana Sharma
wrote:
Hello. I had first expected that dynamic arrays (slices) would
provide a `.clear()` method but they don't seem to. Obviously I
can always effectively clear an array by assigning an empty
array to it, but this has unwanted
On Sunday, 8 November 2015 at 11:57:16 UTC, J.Frank wrote:
On Sunday, 8 November 2015 at 11:47:41 UTC, Rikki Cattermole
wrote:
opApply if you want 0 .. N iterations during for a foreach
statement and having it reset each time.
No, that won't help. I want to be able to iterate over a data
set
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
On 09/11/15 4:57 PM, TheFlyingFiddle wrote:
[...]
Nope.
[...]
As far as I'm aware, you are stuck using e.g. structs to
emulate AA behavior.
I have a VERY basic implementation here:
On Monday, 9 November 2015 at 21:33:09 UTC, TheFlyingFiddle wrote:
On Monday, 9 November 2015 at 04:52:37 UTC, rsw0x wrote:
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
Fwiw, EMSI provides high quality containers backed by
std.experimental.allocator.
On Thursday, 5 November 2015 at 23:37:45 UTC, TheFlyingFiddle
wrote:
On Thursday, 5 November 2015 at 21:24:03 UTC, TheFlyingFiddle
wrote:
[...]
I reduced it further:
[...]
these run at the exact same speed for me and produce identical
assembly output from a quick glance
dmd 2.069, -O
On Friday, 6 November 2015 at 01:17:20 UTC, TheFlyingFiddle wrote:
On Friday, 6 November 2015 at 00:43:49 UTC, rsw0x wrote:
On Thursday, 5 November 2015 at 23:37:45 UTC, TheFlyingFiddle
wrote:
On Thursday, 5 November 2015 at 21:24:03 UTC, TheFlyingFiddle
wrote:
[...]
I reduced it further:
On Friday, 6 November 2015 at 08:48:38 UTC, user123456789abcABC
wrote:
Template parameter deduction in partially specialized template
fails:
---
enum Bar{b,a,r}
void foo(Bar bar, T)(T t){}
alias foob(T) = foo!(Bar.b, T);
void main()
{
foo!(Bar.b)(8);
foob(8); // autsch
}
---
It looks
On Friday, 6 November 2015 at 17:55:47 UTC, arGus wrote:
I did some testing on Linux and Windows.
I ran the code with ten times the iterations, and found the
results consistent with what has previously been observed in
this thread.
The code seems to run just fine on Linux, but is slowed down
On Saturday, 31 October 2015 at 23:07:46 UTC, rumbu wrote:
On Saturday, 31 October 2015 at 20:55:33 UTC, David Nadlinger
wrote:
On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote:
My opinion is that a decimal data type must be builtin in any
modern language, not implemented as a
On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote:
On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:
I'm writing a talk for codemesh on the use of D in finance.
Any other thoughts?
For finance stuff - missing a floating point decimal data type.
Things like 1.1 + 2.2 =
On Wednesday, 26 August 2015 at 17:30:29 UTC, Alex Parrill wrote:
On Wednesday, 26 August 2015 at 15:49:23 UTC, Junichi Nakata
wrote:
Hi, all.
I have a question.
When 'testdic' file does' t exist, something wrong.
---
import std.mmFile;
int main() {
auto x = new
On Tuesday, 25 August 2015 at 07:18:24 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 25 August 2015 at 05:09:56 UTC, Laeeth Isharc wrote:
On Monday, 24 August 2015 at 21:57:41 UTC, rsw0x wrote:
[...]
Horses for courses ? Eg for Andy Smith's problem of
processing trade information of tens of
On Monday, 31 August 2015 at 01:32:01 UTC, Yuxuan Shui wrote:
Why is reduce defined as 'auto reduce(S, R)(S seed, R r)',
instead of reduce(R r, S seed)? I can't chain it.
Maybe provide both?
You might be interested in this PR
https://github.com/D-Programming-Language/phobos/pull/1955
It's a
On Tuesday, 25 August 2015 at 22:35:57 UTC, Jim Hewes wrote:
Although C++ can be ugly, one reason I keep going back to it
rather then commit more time to reference-based languages like
C# is because I like deterministic destruction so much. My
question is whether D can REALLY handle this or
On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote:
Just translating some simple C++/glm/opengl tutorial code to
D/gl3n/opengl and I'm coming across more friction than I
expected. I've got a square centered at my window which is
rotated by 45 degrees (counter clockwise) and then
On Tuesday, 22 December 2015 at 21:38:22 UTC, ZombineDev wrote:
On Tuesday, 22 December 2015 at 17:49:34 UTC, Jakob Jenkov
wrote:
On Tuesday, 22 December 2015 at 03:30:32 UTC, ShinraTensei
wrote:
I recently noticed massive increase in new languages for a
person to jump into(Nim, Rust,
On Thursday, 24 December 2015 at 06:10:55 UTC, H. S. Teoh wrote:
On Thu, Dec 24, 2015 at 12:16:16AM +, rsw0x via
Digitalmars-d-learn wrote: [...]
D, as I expected, has a massive following in Japan. I'm still
not quite sure why.
Maybe because one of the most prolific contributors to D, esp
On Friday, 27 November 2015 at 08:38:29 UTC, drug wrote:
I need to store a struct like a reference type. Now I use
pointer for this, is it the best D way? This pointer is private
and access to it is safe, but it's just unusual for me to see
pointers in D code.
if you own the resource,
On Wednesday, 18 November 2015 at 20:57:08 UTC, Spacen Jasset
wrote:
Should this be allowed? What is it's purpose? It could compare
two arrays, but surely not that each element of type char is
null?
char[] buffer;
if (buffer == null) {}
slices aren't arrays
On Sunday, 22 November 2015 at 10:01:48 UTC, Kagamin wrote:
As an idiomatic option there can be `finally(exit)`,
`finally(success)` and `finally(failure)` that would mirror
semantics of scope guards.
how does this differ from just putting a scope(failure) inside
the try block?
it only
On Saturday, 21 November 2015 at 05:45:37 UTC, Shriramana Sharma
wrote:
Hello. In Python one has the syntax try..except..else.. where
code in the else clause will only be executed if an exception
does not occur. (Ref:
http://stackoverflow.com/a/22579805/1503120)
In D, is there such an
On Saturday, 21 November 2015 at 05:55:53 UTC, Shriramana Sharma
wrote:
rsw0x wrote:
scope(failure) can be used to run code when an exception is
thrown inside the scope, and scope(success) only triggers if
the
scope exited successfully
http://ddili.org/ders/d.en/scope.html
Thanks but I
Why is there no way to specify the desired memory order with
these?
What memory order am I supposed to assume? The documentation is
sparse.
On Tuesday, 12 January 2016 at 01:00:30 UTC, Mike Parker wrote:
On Sunday, 10 January 2016 at 05:47:01 UTC, WhatMeWorry wrote:
Thanks. Bummer. I really like gl3n, but glm/opengl is used
almost exclusively in all the modern opengl code (tutorials)
I've seen, so this might be a deal breaker.
On Sunday, 10 January 2016 at 21:30:32 UTC, Jason Jeffory wrote:
Seems like it is a very nice way to get into openGL from D.
http://glad.dav1d.de/
I generated the bindings for all the latest versions of the
various specifications.
Does anyone have any tutorials that use this library
On Saturday, 16 January 2016 at 21:22:15 UTC, data pulverizer
wrote:
Is it possible to create a function that returns Type like
typeof() does? Something such as:
Type returnInt(){
return int;
}
Functions return values, not types. You would use a template to
"return" a type.
More to
On Sunday, 17 January 2016 at 06:27:41 UTC, Jon D wrote:
My underlying question is how to compose functions taking
functions as arguments, while allowing the caller the
flexibility to pass either a function or delegate.
[...]
Templates are an easy way.
---
auto call(F, Args...)(F fun, auto
Returning a struct with a destructor and not binding it to a
variable appears to make the destructor run immediately instead
of at the end of the scope.
Is this intended?
example:
http://dpaste.dzfl.pl/dd285200ba2b
On Saturday, 6 February 2016 at 17:46:48 UTC, rsw0x wrote:
On Saturday, 6 February 2016 at 17:46:00 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote:
Can't be done with the root class because classes never
trigger RAII outside of (deprecated) scope
On Saturday, 6 February 2016 at 17:46:00 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote:
Can't be done with the root class because classes never
trigger RAII outside of (deprecated) scope allocations.
Not sure what you mean. The class instance
On Saturday, 6 February 2016 at 17:36:28 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 6 February 2016 at 17:22:03 UTC, Adam D. Ruppe
wrote:
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim
Grøstad wrote:
Nothing prevents you from creating your own reference
counting mechanism.
A
I was playing around with alias templates and came across this, I
reduced it to:
---
struct A(alias C c){
auto foo(){
return c.i;
}
}
struct B{
C c;
A!c a;
}
struct C{
int i;
}
---
It gives me a "need 'this' for 'i' of type 'int'" error.
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 6 February 2016 at 11:09:28 UTC, NX wrote:
On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim
Grøstad wrote:
What makes it impossible to have ref counted classes?
Nothing.
Then why do we need DIP74
On Sunday, 7 February 2016 at 19:27:19 UTC, Charles Hixson wrote:
If I define a shared ulong variable, is increment an atomic
operation?
E.g.
shared ulong t;
...
t++;
It seems as if it ought to be, but it could be split into read,
increment, store.
I started off defining a shared struct,
On Sunday, 7 February 2016 at 20:25:44 UTC, Minas Mina wrote:
On Sunday, 7 February 2016 at 19:43:23 UTC, rsw0x wrote:
On Sunday, 7 February 2016 at 19:39:27 UTC, rsw0x wrote:
On Sunday, 7 February 2016 at 19:27:19 UTC, Charles Hixson
wrote:
[...]
On Sunday, 7 February 2016 at 19:39:27 UTC, rsw0x wrote:
On Sunday, 7 February 2016 at 19:27:19 UTC, Charles Hixson
wrote:
If I define a shared ulong variable, is increment an atomic
operation?
E.g.
shared ulong t;
...
t++;
It seems as if it ought to be, but it could be split into
read,
On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:
I see... By any chance, can we solve this issue with GC
managed pointers?
Maybe we could. But it's never going to happen. Even if
Walter weren't fundamentally opposed to
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 call to
call. It could potentially differ based on the type
On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer
wrote:
but I'm unaware of such an optimization, and it definitely
isn't triggered specifically by 'in'. 'in' is literally
replaced with 'scope const' when it is a storage class.
-Steve
I'd imagine GCC or LLVM may be able to
On Friday, 12 February 2016 at 17:29:54 UTC, Matt Elkins wrote:
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
72 matches
Mail list logo
