On 12/21/2016 07:59 PM, Jon Degenhardt wrote:
> construct the 'opts' parameter from
> definitions stored in two or more files. The reason for doing this is to
> create a customization mechanism where-by there are a number of default
> capabilities built-in to the main code base, but someone can
On Wednesday, 21 December 2016 at 17:49:22 UTC, kinke wrote:
Basic stuff such as this is appropriately tested. The named
return value optimization is enforced by D (incl. unoptimized
builds), so behavior doesn't change by this optimization. It's
you who changed the behavior by removing the if.
I'd like to find a way to define programming constructs in one
file and reference them in a getopt call defined in another file.
getopt uses variadic template argument, so the argument list must
be known at compile time. The std.getopt.getopt signature:
GetoptResult getopt(T...)(ref
On 12/21/2016 02:59 PM, Nordlöw wrote:
On Wednesday, 21 December 2016 at 21:02:17 UTC, Ali Çehreli wrote:
void f(Rs...)(Rs ranges)
{
import std.functional: forward;
g(forward!ranges);
Interesting. How does this differ from std.algorithm.mutation.move()
when R.length is 1?
Why do we
On Wednesday, 21 December 2016 at 23:11:02 UTC, Nordlöw wrote:
Given that ref isn't involved, assuming that nothing else
after the call to g references ranges, the compiler should
move the values in ranges when it calls g
Yes, DMD should automatically convert the last reference of a
value
On Wednesday, 21 December 2016 at 21:09:41 UTC, Jonathan M Davis
wrote:
Given that ref isn't involved, assuming that nothing else after
the call to g references ranges, the compiler should move the
values in ranges when it calls g, so I would have hoped that
the compiler would then allow you
On Wednesday, 21 December 2016 at 21:02:17 UTC, Ali Çehreli wrote:
void f(Rs...)(Rs ranges)
{
import std.functional: forward;
g(forward!ranges);
Interesting. How does this differ from
std.algorithm.mutation.move() when R.length is 1?
Why do we have both `move` and `forward`, then?
On Wednesday, December 21, 2016 20:27:47 Nordlöw via Digitalmars-d-learn
wrote:
> If I have a variadic function
>
> f(Rs...)(Rs ranges)
> {
> g(ranges);
> }
>
> that calls
>
> g(Rs...)(Rs ranges)
> {
> // use ranges
> }
>
> and all or some of the elements in `ranges` are non-copyable
On 12/21/2016 12:27 PM, Nordlöw wrote:
If I have a variadic function
f(Rs...)(Rs ranges)
{
g(ranges);
}
that calls
g(Rs...)(Rs ranges)
{
// use ranges
}
and all or some of the elements in `ranges` are non-copyable can I
somehow move them at the call of `g` inside of `f`.
I've tried
If I have a variadic function
f(Rs...)(Rs ranges)
{
g(ranges);
}
that calls
g(Rs...)(Rs ranges)
{
// use ranges
}
and all or some of the elements in `ranges` are non-copyable can
I somehow move them at the call of `g` inside of `f`.
I've tried
f(Rs...)(Rs ranges)
{
import
On 2016-12-21 19:07, Nordlöw wrote:
Is there a way to specify in dub.json (or any other file) that only a
subset of the sources compiled and linked to a library or app should
have they're unittests enabled?
You can use the "unittest" configuration in Dub to add or remove files,
but I don't
On 12/21/2016 07:01 AM, Eugene Wissner wrote:
> Isn't an optimization that changes the behavior bad? I had a crash in
> the code where the destructor did something meaningfull, freed the
> memory (the same pointer) twice.
Sounds like you ended up with two objects that owned the same resource.
On Wednesday, 21 December 2016 at 18:02:54 UTC, bauss wrote:
It removes an unnecessary allocation for the returning copy of
the struct, as the return value is never used. Hence why it's
pointless that it would be compiled anyway.
That's incorrect, it doesn't have anything to do with the
Is there a way to specify in dub.json (or any other file) that
only a subset of the sources compiled and linked to a library or
app should have they're unittests enabled?
On Wednesday, 21 December 2016 at 15:01:20 UTC, Eugene Wissner
wrote:
On Wednesday, 21 December 2016 at 14:15:06 UTC, John C wrote:
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
This prints 3 times "Destruct" with dmd 0.072.1. If I remove
the if block, it prints
On Wednesday, 21 December 2016 at 15:01:20 UTC, Eugene Wissner
wrote:
On Wednesday, 21 December 2016 at 14:15:06 UTC, John C wrote:
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
This prints 3 times "Destruct" with dmd 0.072.1. If I remove
the if block, it prints
On Wednesday, 21 December 2016 at 14:15:06 UTC, John C wrote:
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
This prints 3 times "Destruct" with dmd 0.072.1. If I remove
the if block, it prints "Destruct" only 2 times - the behavior
I'm expecting. Why?
Possibly to do
On Wednesday, 21 December 2016 at 14:15:06 UTC, John C wrote:
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
This prints 3 times "Destruct" with dmd 0.072.1. If I remove
the if block, it prints "Destruct" only 2 times - the behavior
I'm expecting. Why?
Possibly to do
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
This prints 3 times "Destruct" with dmd 0.072.1. If I remove
the if block, it prints "Destruct" only 2 times - the behavior
I'm expecting. Why?
Possibly to do with named return value optimisation.
On Wednesday, 21 December 2016 at 12:32:51 UTC, Nicholas Wilson
wrote:
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
Consider we have a function that returns a struct. So for
example:
import std.stdio;
struct A {
~this() {
writeln("Destruct");
}
}
A
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
Consider we have a function that returns a struct. So for
example:
import std.stdio;
struct A {
~this() {
writeln("Destruct");
}
}
A myFunc() {
auto a = A(), b = A();
if (false) {
return a;
On Wednesday, 21 December 2016 at 12:00:57 UTC, Ezneh wrote:
On Wednesday, 21 December 2016 at 11:49:06 UTC, Ilya Yaroshenko
wrote:
[...]
Thanks, I'll check that solution to see if it fits my needs.
As an off-topic question, is there any plan in Mir to implement
the Tiny Mersenne Twister[1]
On Wednesday, 21 December 2016 at 11:49:06 UTC, Ilya Yaroshenko
wrote:
On Wednesday, 21 December 2016 at 09:08:51 UTC, Ezneh wrote:
Hi, in one of my projects I have to get a slice from a
BitArray.
I am trying to achieve that like this :
void foo(BitArray ba)
{
auto slice = ba[0..3]; //
On Wednesday, 21 December 2016 at 09:08:51 UTC, Ezneh wrote:
Hi, in one of my projects I have to get a slice from a BitArray.
I am trying to achieve that like this :
void foo(BitArray ba)
{
auto slice = ba[0..3]; // Assuming it has more than 4
elements
}
The problem is that I get an
Consider we have a function that returns a struct. So for example:
import std.stdio;
struct A {
~this() {
writeln("Destruct");
}
}
A myFunc() {
auto a = A(), b = A();
if (false) {
return a;
}
return b;
}
void main() {
myFunc();
}
This prints 3
On Wednesday, 21 December 2016 at 09:14:04 UTC, Eugene Wissner
wrote:
The problem is BitArray keeps multiple elements in one byte.
You can't return just three bits but in the best case one byte
with 8 elements.
What could be done some internal range could be returned that
gives access to
On Monday, 19 December 2016 at 20:26:26 UTC, Ali Çehreli wrote:
On 12/19/2016 06:09 AM, RazvanN wrote:
> [...]
wrote:
>> [...]
InputRanges.
>> [...]
following
> [...]
char[]
> [...]
function, so
> [...]
http://dlang.org/phobos/std_algorithm_mutation.html#bringToFront
[...]
No need to mention
On Wednesday, 21 December 2016 at 09:08:51 UTC, Ezneh wrote:
Hi, in one of my projects I have to get a slice from a BitArray.
I am trying to achieve that like this :
void foo(BitArray ba)
{
auto slice = ba[0..3]; // Assuming it has more than 4
elements
}
The problem is that I get an
Hi, in one of my projects I have to get a slice from a BitArray.
I am trying to achieve that like this :
void foo(BitArray ba)
{
auto slice = ba[0..3]; // Assuming it has more than 4 elements
}
The problem is that I get an error :
"no operator [] overload for type BitArray".
Is there any
29 matches
Mail list logo
