On Thursday, 23 March 2017 at 03:02:54 UTC, Jonathan M Davis
wrote:
On Thursday, March 23, 2017 02:53:40 Soulsbane via
Digitalmars-d-learn wrote:
[...]
find just iterates to the first element that matches. It
doesn't affect the range beyond that. It works basically the
same way that find
On Wednesday, 22 March 2017 at 13:19:32 UTC, Nicholas Wilson
wrote:
On Wednesday, 22 March 2017 at 08:57:34 UTC, ANtlord wrote:
You still have the buffer (the class has to go somewhere!), but
it is implicit (you can't refer to it directly only through the
class reference) and so is the
On Thursday, March 23, 2017 02:53:40 Soulsbane via Digitalmars-d-learn
wrote:
> Thanks for the reply Jonathan! Yes, I was trying to find all the
> ids that match but couldn't get find to work. So I think I have
> missed something somewhere.
>
> As a quick example:
> import std.stdio;
> import
On Wednesday, 22 March 2017 at 07:30:48 UTC, Jonathan M Davis
wrote:
On Wednesday, March 22, 2017 07:06:47 Soulsbane via
Digitalmars-d-learn wrote:
Example code:
struct Foo
{
string name;
size_t id;
}
Array!Foo foo_;
I get errors when I try to use filter like this:
auto found =
On 03/22/2017 05:39 PM, H. S. Teoh via Digitalmars-d-learn wrote:
> the article is turning out to be quite a bit longer
I said "book"; didn't I? :)
Ali
On Wed, Mar 22, 2017 at 11:12:06PM +, Jesse Phillips via
Digitalmars-d-learn wrote:
> On Friday, 17 March 2017 at 19:05:20 UTC, H. S. Teoh wrote:
> > There are actually (at least) TWO distinct phases of compilation
> > that are conventionally labelled "compile time":
> >
> > 1) Template
On Friday, 17 March 2017 at 19:05:20 UTC, H. S. Teoh wrote:
There are actually (at least) TWO distinct phases of
compilation that are conventionally labelled "compile time":
1) Template expansion / AST manipulation, and:
2) CTFE (compile-time function evaluation).
This was an awesome
On Wednesday, 22 March 2017 at 21:04:48 UTC, StarGrazer wrote:
On Wednesday, 22 March 2017 at 21:02:41 UTC, StarGrazer wrote:
On Wednesday, 22 March 2017 at 20:53:17 UTC, crimaniak wrote:
On Wednesday, 22 March 2017 at 20:35:27 UTC, StarGrazer wrote:
I've tried compiles but I guess that only
On Wednesday, 22 March 2017 at 21:02:41 UTC, StarGrazer wrote:
On Wednesday, 22 March 2017 at 20:53:17 UTC, crimaniak wrote:
On Wednesday, 22 March 2017 at 20:35:27 UTC, StarGrazer wrote:
I've tried compiles but I guess that only checks if the code
has valid syntax, not if it actually will
On Wednesday, 22 March 2017 at 20:53:17 UTC, crimaniak wrote:
On Wednesday, 22 March 2017 at 20:35:27 UTC, StarGrazer wrote:
I've tried compiles but I guess that only checks if the code
has valid syntax, not if it actually will compile in context.
https://dlang.org/spec/traits.html#hasMember
On Wednesday, 22 March 2017 at 18:12:31 UTC, Yuxuan Shui wrote:
Hi,
Is there any difference, when a type is passed into an alias
parameter vs into a type parameter?
alias parameters fail with builtin types, ex. 'int'.
hopefully this will be corrected one day.
On Wed, Mar 22, 2017 at 08:35:27PM +, StarGrazer via Digitalmars-d-learn
wrote:
> I've tried compiles but I guess that only checks if the code has valid
> syntax, not if it actually will compile in context.
I'm not sure what you mean by "member of instance", but if you mean
whether some
On Wednesday, 22 March 2017 at 20:35:27 UTC, StarGrazer wrote:
I've tried compiles but I guess that only checks if the code
has valid syntax, not if it actually will compile in context.
https://dlang.org/spec/traits.html#hasMember
I've tried compiles but I guess that only checks if the code has
valid syntax, not if it actually will compile in context.
On Wednesday, 22 March 2017 at 12:31:34 UTC, Mike Parker wrote:
On Wednesday, 22 March 2017 at 12:20:27 UTC, Mike Parker wrote:
have at the bottom of the page the version they were added.
But it's easier to look at the source for DerelictSDL2. In
order to support the SharedLibVersion, the
Hi,
Is there any difference, when a type is passed into an alias
parameter vs into a type parameter?
On Wednesday, 22 March 2017 at 14:06:56 UTC, Atila Neves wrote:
isInputRange looks like this:
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
isInputRange looks like this:
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront; // can invoke popFront()
auto h =
On Wednesday, 22 March 2017 at 05:47:59 UTC, Sebastien Alaiwan
wrote:
On Monday, 13 March 2017 at 11:06:53 UTC, Russel Winder wrote:
It is a shame that dmd and ldc do not just use the standard
GCC option set.
Totally agreed.
Moreover, funny stuff like "dmd -of" (instead of
standard "-o ")
On Wednesday, 22 March 2017 at 08:57:34 UTC, ANtlord wrote:
On Wednesday, 22 March 2017 at 06:47:26 UTC, Ali Çehreli wrote:
On 03/21/2017 09:57 PM, ANtlord wrote:
> Thank you for clarification. But I have one more question. Do
I have to
> use destroy for deallocating object from stack?
Yes
On Wednesday, 22 March 2017 at 12:20:27 UTC, Mike Parker wrote:
have at the bottom of the page the version they were added.
But it's easier to look at the source for DerelictSDL2. In
order to support the SharedLibVersion, the loader implements
functions like this one:
And I've just
On Wednesday, 22 March 2017 at 10:32:44 UTC, Robly18 wrote:
Well, I have a call to SDL_GetVersion in my code, to check
exactly what you're saying. And it spits out "2.0.5", so I
don't think that is the problem. I believe I do have it
installed: I rm'd the old lib files and used make install
On Wednesday, 22 March 2017 at 03:44:17 UTC, Mike Parker wrote:
So given what I know so far, my guess is you're using functions
from 2.0.5 with a 2.0.4 version of the library. You can call
SDL_GetVersion [1] to verify. In that case, you need to use
DerelictSDL2 2.1.x and do no use
On Wednesday, 22 March 2017 at 06:47:26 UTC, Ali Çehreli wrote:
On 03/21/2017 09:57 PM, ANtlord wrote:
> Thank you for clarification. But I have one more question. Do
I have to
> use destroy for deallocating object from stack?
Yes because what is going out of scope are two things:
- A buffer
-
On Wednesday, March 22, 2017 07:06:47 Soulsbane via Digitalmars-d-learn
wrote:
> Example code:
> struct Foo
> {
>string name;
>size_t id;
> }
>
> Array!Foo foo_;
>
> I get errors when I try to use filter like this:
>
> auto found = filter!((Foo data, size_t id) => data.id ==
> id)(foo_[],
Example code:
struct Foo
{
string name;
size_t id;
}
Array!Foo foo_;
I get errors when I try to use filter like this:
auto found = filter!((Foo data, size_t id) => data.id ==
id)(foo_[], 100);
I get this error
source/app.d(15,62): Error: template
On 03/21/2017 11:47 PM, Ali Çehreli wrote:
> method(false);
> method(true);
> }
>
> Gotta love D for allowing such code but it comes with surprises. Why do
> we suddenly get two destructor calls?
>
> ~this
> ~this
Answering own question: There are two destructor calls because I call
On 03/21/2017 09:57 PM, ANtlord wrote:
> On Tuesday, 21 March 2017 at 08:46:43 UTC, Ali Çehreli wrote:
>> Another option is std.conv.emplace:
>>
>> import std.conv : emplace;
>>
>> class MyClass {
>> this(int) @nogc {
>> }
>>
>> ~this() @nogc {
>> }
>> }
>>
>> void method(bool
28 matches
Mail list logo
