On Sunday, 30 April 2017 at 19:05:18 UTC, bauss wrote:
On Sunday, 30 April 2017 at 16:15:41 UTC, Xinok wrote:
On Sunday, 30 April 2017 at 15:31:39 UTC, Jolly James wrote:
Is there a String Comparison Operator in D?
Yeah, just the usual comparison operators:
"abc" == "abc"
"abc" != "ABC"
~
On Sunday, 30 April 2017 at 15:31:39 UTC, Jolly James wrote:
Is there a String Comparison Operator in D?
Yeah, just the usual comparison operators:
"abc" == "abc"
"abc" != "ABC"
~ is for string concatenation, i.e.:
"abc" ~ "def" == "abcdef"
On Saturday, 19 November 2016 at 03:52:02 UTC, Ryan wrote:
Why do I see double `not` operators sometimes in D code? An
example it the last post of this thread.
http://forum.dlang.org/thread/ktlpnikvdwgbvfaam...@forum.dlang.org
import core.sys.windows.windows : GetConsoleCP;
bool hasConsole =
On Sunday, 1 May 2016 at 05:42:00 UTC, Ali Çehreli wrote:
On 04/30/2016 10:05 PM, Joel wrote:
> This has no effect:
> _bars.each!(a => { a._plots.fillColor = Color(255, 180, 0);
});
This is a common issue especially for people who know lambdas
from other languages. :)
Your lambda does not do
On Friday, 8 April 2016 at 10:15:10 UTC, Dicebot wrote:
On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote:
Semantically, array literals are always allocated on the
heap. In this case, the optimizer can obviously place the
array on the stack or even make it static/global.
So @nogc
On Friday, 8 April 2016 at 01:36:18 UTC, rcorre wrote:
@nogc unittest {
int[2] a = [1, 2];
assert(a == [1, 2]); // OK
immutable(int)[2] b = [1, 2];
assert(b == [1, 2]); // fail: array literal may cause
allocation
}
Is there any logic behind allowing the comparison with `a` but
On Wednesday, 9 March 2016 at 15:39:55 UTC, rcorre wrote:
Still curious as to why it fails; maybe the range is getting
copied at some point? I guess I need to step through it.
That's my suspicion as well. It seems that OnlyResult is
pass-by-value so every time it gets passed to another functio
On Saturday, 13 February 2016 at 03:16:09 UTC, cym13 wrote:
On Saturday, 13 February 2016 at 02:17:17 UTC, Xinok wrote:
On Friday, 12 February 2016 at 20:43:24 UTC, Taylor Hillegeist
wrote:
So I have this code and I have to add the element
.each!(a => a.each!("a"));
to the end in order for it t
On Friday, 12 February 2016 at 20:43:24 UTC, Taylor Hillegeist
wrote:
So I have this code and I have to add the element
.each!(a => a.each!("a"));
to the end in order for it to evaluate the range completely and
act like I expect it too. Is there a better thing to put in
the place of
.each!(a
On Saturday, 13 February 2016 at 01:11:53 UTC, Nicholas Wilson
wrote:
...
If you just want the range evaluated use walkLength
It might work in this case, but in general this won't work for
any range which defines .length as a member. In that case,
walkLength will simply return .length of tha
On Friday, 22 January 2016 at 12:07:11 UTC, abad wrote:
Let's say I have an array like this:
int[][][] array;
And I want to generate a linear int[] based on its data. Is
there a standard library method for achieving this, or must I
iterate over the array manually?
What I'm thinking of is so
On Tuesday, 15 December 2015 at 01:29:39 UTC, Jakob Ovrum wrote:
Thanks, that makes sense.
String manipulation in D without regex is pretty nice anyway,
so it's not a big loss.
There is a library named Pegged which can match against balanced
parens:
https://github.com/PhilippeSigaud/Pegged
On Sunday, 13 December 2015 at 20:29:47 UTC, Pederator wrote:
Hi. Does anybody who is familair with D consider to make a
comprehensive D programming video tutorial / training / course?
This could be encouraging and helpful for people to start with
D. It could also help in promoting D programmin
On Saturday, 12 December 2015 at 23:36:43 UTC, cym13 wrote:
...
So, in your example:
int product(const ref int[] arr) {
import std.array: array;
import std.algorithm: reduce;
arr = arr.reduce!((p, i) => p*i).array;
}
A good post overall but you got reduce wrong. In D, reduce
On Saturday, 26 September 2015 at 17:08:00 UTC, Nordlöw wrote:
Why is the following code not pure:
float x = 3.14;
import std.conv : to;
auto y = x.to!string;
???
Is there a reason for it not being pure? If not, this is a
serious problem as this is such a fundamental function.
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an ea
On Wednesday, 12 August 2015 at 15:47:37 UTC, Adam D. Ruppe wrote:
Example with them:
...
That's the idea I had except I would use a struct instead because
using a class requires a second allocation.
is there a trait in D or Phobos which will tell you if a type can
be used as a key for an associative array? For example, where T
is some type:
static assert(isKeyType!T)
int[T] hashTable = ...
On Sunday, 28 June 2015 at 15:55:51 UTC, jmh530 wrote:
My understanding of pure is that a function labeled pure can
only include pure functions. I've been confused by the fact
that a function calling map (like below) can be labeled pure
without any problems. The only way I can rationalize it is
On Tuesday, 19 May 2015 at 00:31:50 UTC, Freddy wrote:
Sorry mis-phrased my question,
Who do you allocate a pointer to an associative
array(int[string]*).
Ignoring the why for a moment, one trick is to place it in an
array literal so it's heap allocated. This requires writing an
associative
On Tuesday, 10 March 2015 at 22:00:29 UTC, safety0ff wrote:
On Tuesday, 10 March 2015 at 21:56:39 UTC, Xinok wrote:
I'm inclined to believe this is a bug.
https://issues.dlang.org/show_bug.cgi?id=11048
Thanks for the link, and I didn't mean to post this in D.learn.
>.<
The following code fails to compile because unpredictableSeed is
impure:
void main()
{
foreach(i; 0..10) writeln(pureRandom);
}
pure uint pureRandom()
{
auto r = Random(unpredictableSeed);
return r.front;
}
However, make unpredictableSeed a defau
On Wednesday, 3 December 2014 at 21:02:05 UTC, Nordlöw wrote:
Have anybody written a generic automatically sorted range
wrapper for RandomAccessRanges?
I guess
http://dlang.org/library/std/range/assumeSorted.html
should play a key role.
I see two typical variants:
- Direct: Always sorts on
On Saturday, 29 November 2014 at 20:47:09 UTC, Paul wrote:
On Saturday, 29 November 2014 at 20:22:40 UTC, bearophile wrote:
This works:
enum MAPSIZE = 3;
void main() {
ubyte[MAPSIZE][MAPSIZE] map2 = 1;
}
This doesn't work:
enum MAPSIZE = 3;
ubyte[MAPSIZE][MAPSIZE] map1 = ubyte(1);
void ma
Given that we have GDC with the GCC backend and LDC with the LLVM
backend, what are the benefits of keeping the DMD compiler
backend? It seems to me that GCC and LLVM are far more developed
and better supported by their respective communities. They have
superior optimizers and are better equipp
On Sunday, 2 November 2014 at 20:19:12 UTC, bearophile wrote:
Xinok:
My concern is that SortedRange only accepts a range which is
random-access and limits its functionality to those
primitives. Concatenation is not required for random-access
ranges, so should we expect SortedRange to overload
On Sunday, 2 November 2014 at 20:06:51 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 2 November 2014 at 19:54:38 UTC, Xinok wrote:
D got it right. C++ returns an iterator which can be a bit
confusing. D returns a slice so it's meaning is much clearer.
No, according to docs D has defined the low
On Sunday, 2 November 2014 at 15:13:37 UTC, bearophile wrote:
I have often arrays that are sorted, and sometimes I'd like to
append items to them. So I'd like to write something like:
SortedRange!(Foo[], q{ a.x < b.x }) data;
data ~= Foo(5);
immutable n = data.upperBound(Foo(2)).length;
This
On Sunday, 2 November 2014 at 17:21:04 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 2 November 2014 at 16:59:30 UTC, bearophile wrote:
Ola Fosheim Grøstad:
Shouldn't sorted range maintain the invariant automatically
in order to remain typesafe?
Yes, of course.
If SortedRange is fixed, please
This is the full compiler output:
combsort.d(90): Error: template D main.pred cannot deduce
function from argument
types !()(uint, uint), candidates are:
benchsort.d(37):benchsort.main.pred(T)(T a, T b)
benchsort.d(81): Error: template instance
combsort.combSortLinear!(pred, uint[])
e
I'm currently receiving several errors when trying to compile
this code with DMD 2.066 (beginning with RC1):
https://github.com/Xinok/XSort
The compiler throws an error because it's unable to deduce a type
for the predicate in a few places. This repository compiles just
fine in DMD 2.065 and
31 matches
Mail list logo
