On Sunday, 15 February 2015 at 23:48:50 UTC, rumbu wrote:
This problem appears only if one of the parameters is an
interface. Without it or using any other type as a second
parameter instead of the interface, it compiles. Also it
compiles if the passed interface is null. The example below
us
while learning the map function, i've landed on this wikipedia
page(http://en.wikipedia.org/wiki/Map_(higher-order_function)).
For each language there is a column about handing multiple list,
i thought it could be a good idea to see how D handle this:
is this the official way ?
---
auto fruit
Hi,
you can also take a look at my implementation:
https://github.com/Ingrater/druntime/blob/master/src/core/allocator.d
Look at AllocatorNew and AllocatorDelete
Especially important is, that you correctly handle the
constructor throwing an exception. You have to catch that
exception in your
Baz:
is this the official way ?
It seems a way to perform nested mapping in D.
---
auto fruits = ["apple", "banana", "orange"][];
auto vegies = ["grass", "salad"][];
Those trailing [] are unneded.
auto youreallygonna = map!( `map!(a => "eat " ~ a)(a)`
)([fruits, vegies]);
Better to u
On Sunday, 15 February 2015 at 22:38:20 UTC, anonymous wrote:
And more:
import std.stdio;
struct MapResult(alias fun)
{
@property int front() {return fun();}
@property auto save() {return typeof(this)();}
}
void main()
{
int ys_length = 4;
auto dg = {return MapResult!({return ys_
On Monday, 16 February 2015 at 07:33:54 UTC, Kagamin wrote:
It checks that you don't set both text and image, because the
button doesn't support it.
Yes, I get that. :-) I am talking about the
in
{
}
and also the
body
{
}
how are these interpreted by the compiler? They are both part of
the f
http://digitalmars.com/d/1.0/dbc.html
in is precondition, body is function body, which expects
precondition to pass.
On Monday, 16 February 2015 at 15:10:29 UTC, Kagamin wrote:
http://digitalmars.com/d/1.0/dbc.html
in is precondition, body is function body, which expects
precondition to pass.
Muchas gracias. (That is, "Thanks much", for the Spanish Speaking
Challenged Community. :-))
Is there a specific function in to empty a builtin D array or
should I just do
auto x = [1,2,3];
x = [];
I'm asking because std.container.Array has the member .clear()
and I would like my code to compatible with both builtin arrays
and std.container.Array. If not is there an con to us
On Monday, 16 February 2015 at 16:56:15 UTC, Per Nordlöw wrote:
Is there a specific function in to empty a builtin D array or
should I just do
auto x = [1,2,3];
x = [];
I'm asking because std.container.Array has the member .clear()
and I would like my code to compatible with both buil
On Monday, 16 February 2015 at 17:00:39 UTC, Tobias Pankrath
wrote:
You can set the length to zero for both.
Thanks.
I believe C++ programmers would find a tiny wrapper function, say
clear(), in std.algorithm or perhaps even D array builtin for
this nice from a portability point of view.
On Monday, 16 February 2015 at 17:55:42 UTC, Jonathan Marler
wrote:
Why is the 'in' operator nogc but the index operator is not?
void main() @nogc
{
int[int] a;
auto v = 0 in a; // OK
auto w = a[0]; // Error: indexing an associative
// array in @nogc function m
Am 16.02.2015 um 18:55 schrieb Jonathan Marler:
Why is the 'in' operator nogc but the index operator is not?
void main() @nogc
{
int[int] a;
auto v = 0 in a; // OK
auto w = a[0]; // Error: indexing an associative
// array in @nogc function main may
Why is the 'in' operator nogc but the index operator is not?
void main() @nogc
{
int[int] a;
auto v = 0 in a; // OK
auto w = a[0]; // Error: indexing an associative
// array in @nogc function main may
// cause GC allocation
}
On Monday, 16 February 2015 at 17:58:10 UTC, Benjamin Thaut wrote:
Because the index operator throws a OutOfRange exception and
throwing exceptions allocates, maybe?
Oh...I hadn't thought of that! Thanks for the quick response.
The question appear here
http://stackoverflow.com/questions/28546572/how-to-find-duplicates-in-array-of-strings-in-d
I can't understand, why uniq work for array of int but do not
work with array of strings.
int[] arr = [ 1, 2, 2, 2, 2, 3, 4, 4, 4, 5 ];
writeln(uniq(arr));
On Monday, 16 February 2015 at 18:28:13 UTC, Suliman wrote:
The question appear here
http://stackoverflow.com/questions/28546572/how-to-find-duplicates-in-array-of-strings-in-d
I can't understand, why uniq work for array of int but do not
work with array of strings.
int[] arr = [ 1, 2
Docs will get a lot better in the next release:
http://dlang.org/phobos-prerelease/std_algorithm_iteration.html#uniq
Iterates unique -> _consecutive_ <- elements of the given range
Could you explain what does it's mean? I do not understand what
is _consecutive_ mean in this content... and why it's not work
with strings...
Oh I understood. It's means that it work only of two or more
element's is placed one after one?
On Monday, 16 February 2015 at 18:45:17 UTC, Suliman wrote:
Oh I understood. It's means that it work only of two or more
element's is placed one after one?
Yes, uniq returns exactly the same range as its input, except
that elemens that are equal to their immediate predecessor are
dropped.
On Monday, 16 February 2015 at 18:45:17 UTC, Suliman wrote:
Oh I understood. It's means that it work only of two or more
element's is placed one after one?
That's why you'll usually want to sort before using uniq.
On 2015-02-16 at 18:58, Benjamin Thaut wrote:
Am 16.02.2015 um 18:55 schrieb Jonathan Marler:
Why is the 'in' operator nogc but the index operator is not?
void main() @nogc
{
int[int] a;
auto v = 0 in a; // OK
auto w = a[0]; // Error: indexing an associative
Hi.
And how to read Data from the input stream?
import std.stdio;
import std.bigint;
void main() {
BigInt n;
readf(" %?", &n);
writeln(n);
}
I'm trying to figure out how to implement a light-weight wrappr
realizing type-safe indexing á lá Ada. Here's my first try:
struct Ix(T = size_t)
{
@safe pure: @nogc nothrow:
this(T ix) { this._ix = ix; }
alias _ix this;
private T _ix = 0;
}
struct IndexedBy(R, I)
{
auto ref
On Monday, 16 February 2015 at 20:09:09 UTC, Nordlöw wrote:
I'm trying to figure out how to implement a light-weight wrappr
realizing type-safe indexing á lá Ada. Here's my first try:
See also:
https://github.com/nordlow/justd/blob/master/typecons_ex.d#L83
On Monday, 16 February 2015 at 20:09:09 UTC, Nordlöw wrote:
How can I prevent
jx[0] = 11;
from compiling?
Remove that `alias _r this;`. You don't want to forward opIndex,
so you can't use alias this which forwards everything that
doesn't compile. opDispatch may be an option to forward
On Monday, 16 February 2015 at 20:09:09 UTC, Nordlöw wrote:
I'm trying to figure out how to implement a light-weight wrappr
realizing type-safe indexing á lá Ada. Here's my first try:
struct Ix(T = size_t)
{
@safe pure: @nogc nothrow:
this(T ix) { this._ix = ix; }
alias _ix this;
On Monday, 16 February 2015 at 20:17:55 UTC, anonymous wrote:
Remove that `alias _r this;`. You don't want to forward
opIndex, so you can't use alias this which forwards everything
that doesn't compile. opDispatch may be an option to forward
everything but opIndex.
Thanks!
On Monday, 16 February 2015 at 20:48:29 UTC, Nordlöw wrote:
Thanks!
See also:
http://forum.dlang.org/thread/akibggljgcmmacsba...@forum.dlang.org
On Monday, 16 February 2015 at 19:12:45 UTC, FG wrote:
Range violation is an Error, but never mind that. The real
question is: given all the work related to @nogc, wouldn't it
be better for such common Errors to be preallocated and only
have file and line updated when they are thrown?
@nogc a
On Monday, 16 February 2015 at 20:17:55 UTC, anonymous wrote:
that doesn't compile. opDispatch may be an option to forward
everything but opIndex.
What about disable?
I'm looking to manage my current project with dub, but there is
one problem that has been getting in my way. I want to use
`-rpath=$ORIGIN`, which I can pass with `-L-rpath=\$ORIGIN` when
directly invoking the compiler, but when putting `-rpath=$ORIGIN`
or `-rpath=\$ORIGIN` in "lflags," dub com
On 2015-02-16 at 22:12, Jonathan Marler wrote:
On Monday, 16 February 2015 at 19:12:45 UTC, FG wrote:
Range violation is an Error, but never mind that. The real question is: given
all the work related to @nogc, wouldn't it be better for such common Errors to
be preallocated and only have file
On Tuesday, 17 February 2015 at 00:00:54 UTC, FG wrote:
Yes, they would be in TLS. I know exceptions in general are a
complex problem, therefore I limited the comment only to
errors, because forbidding the use of `aa[key]` in @nogc seemed
odd (although I do think that `aa.get(key, default)` and
We've got arbitrary precision integers, why not arbitrary
precision floating point?
On 2015-02-17 at 03:35, Jonathan Marler wrote:
On Tuesday, 17 February 2015 at 00:00:54 UTC, FG wrote:
Yes, they would be in TLS. I know exceptions in general are a complex problem,
therefore I limited the comment only to errors, because forbidding the use of
`aa[key]` in @nogc seemed odd (alt
On Monday, 16 February 2015 at 19:52:20 UTC, Dennis Ritchie wrote:
Hi.
And how to read Data from the input stream?
import std.stdio;
import std.bigint;
void main() {
BigInt n;
readf(" %?", &n);
writeln(n);
}
The readf function does not seem to support reading BigInt
38 matches
Mail list logo
